博客 · 对比
「它不想做下一个 Codex」—— DSH vs Codex
2026 年 8 月 14 日 · dshbase
「DeepSeek 版 Codex」是大多数人第一反应——也是这个项目最想反驳的。反驳不是话术，两者对「Agent 应该怎么配置」有根本分歧：按场景配置（我在做什么任务？）还是按能力配置（这个 Agent 跑哪些插件？）？过去一周我们实跑了 dsh 0.1.0-rc.6、手动装了社区插件，区别体现在具体的地方，而不只是理念。
Agent 预设，而非场景
Codex 类产品按场景区分模式（日常/办公、办公/代码），你选一条道，产品填好剩下的一切。DSH 改用 Agent 预设：一个 Agent 所运行的插件集合——工具、提示词、能力。你可以复制一个改改，或建一个全新的，包括非编码的预设（比如写作工作台）。
这是实打实的体验差异。在 Codex 里你要迁就被给到的模式；在 DSH 里，预设本身就是模式，是一个你能版本化、能分享的文件。当 Data Agent 预设（dsh-data-agent）出现在插件目录里时，它不是给厂商提的需求——只是有人发布了一个你能一条命令装上的预设。
可重建的会话
Codex 的会话是不透明的。DSH 的会话是只追加的事件日志——系统提示词、推理、工具调用、权限变化都成为事件，下一轮历史从日志重新推导，而不是保存在黑盒状态里。Agent 失败或死循环时，你能定位到具体跑偏的步骤。
测试期间我们比预想更依赖这一点：一个加载即崩的插件，报错能精确对应到单个事件，而不是一句笼统的「任务失败」。想了解日志里到底有什么，见我们的会话日志拆解。这是 Codex 不提供的观测优势。
插件模型
Codex 让用户自定义 Skills 和 MCP，但其余是封装好的。DSH 把一切都做成插件——UI、工具、工作流，甚至 Agent 循环本身。你不是租一个 Agent，而是组装一个 Agent。
话好说，关键是生态到底成不成。我们花了时间验证。我们的插件目录已收录1100+ 个社区插件，其中包括我们在 dsh 0.1.0-rc.6 上深度实测的 101 个。结果并不全干净：
- 11 个 npm 包装上就能用——一条
dsh plugin add <名字>搞定。 - 4 个需要 Web/TUI 环境——装得上，但只在 Web UI 或终端 profile 里才真正起效。
- 3 个直接安装失败。
- 81 个是 GitHub 源码仓库，用
dsh plugin add github:owner/repo安装——生态的大头还没上 npm。
最后一个数字很关键。「一切皆插件」要成立，插件得容易分发，而 101 个里 81 个走的是 GitHub URL 而非 registry。这是快速迭代期生态的早期形态——目录里每张卡片都标着确切安装命令和验证状态。
模型灵活性
DSH 支持目录和自定义提供方——你填上基础 URL、协议、模型列表，就能在里面跑 GLM。Codex 绑定 OpenAI 模型。如果你的成本或合规要求把你逼离 OpenAI，DSH 跟着你走，Codex 不会。
DSH vs Codex 速览
| DeepSeek Harness | Codex | |
|---|---|---|
| 配置模型 | Agent 预设（插件集合） | 场景模式 |
| 会话 | 只追加事件日志、可重建 | 不透明 |
| 扩展 | 一切皆插件（npm / GitHub） | Skills + MCP，核心封装 |
| 模型 | DeepSeek + 任意 OpenAI 兼容 | OpenAI 模型 |
| 插件生态 | 实测 101 个社区插件（11 npm、81 GitHub 源码） | 精选 Skills/MCP 市场 |
现实检验：装 101 个插件
「一切皆插件」听起来干净，直到你真的动手装几十个。下面是营销不会提、我们在 dsh 0.1.0-rc.6 上真踩到的：
ERR_PNPM_FETCH_404——npm 镜像落后于官方，刚发布的包返回 404。修复：加--registry=https://registry.npmjs.org。ERR_REQUIRE_ESM——插件被编译成 CommonJS，却依赖了 ESM-only 的包。作者得把它重建成 ESM。- 装了但不激活——包没有
dsh.bundle清单，dsh plugin add只当普通依赖装上，永远不加载。 cannot get property "systemPrompt" without inject——插件 bug：代码调了ctx.systemPrompt却没声明inject: ["systemPrompt"]。allowBuilds提示——GitHub 托管的插件带prepare构建脚本，pnpm 默认阻止。
完整清单和一行修复见我们的排错指南。诚实的说法：DSH 的插件模型比 Codex 更开放，但开放意味着你自己就是质量把关人。Codex 由厂商替你筛选；DSH 里你得先读几条报错，才能认出「好插件」长什么样。
FAQ
DeepSeek Harness 只是 Codex 的开源复刻吗？
不是。表面的相似——读文件、跑命令的 Agent——之下是另一种配置模型（预设 vs 场景）、另一种扩展模型（一切皆插件 vs Skills+MCP），以及 Codex 没有的可重建会话。
哪个更好上手？
Codex。选个场景就能开工。DSH 前期要求更多——先选或建预设、加提供方——但之后把掌控权还给你。
DSH 插件能对标 Codex 的 Skills 和 MCP 吗？
机制不同。DSH 插件是带 apply 函数的 TypeScript 模块，能当 npm 或 GitHub URL 分享；更好写，但活在 dsh 进程里。MCP 跨客户端更可移植。
DSH 插件生态到底多成熟？
早期但真实：目录现已收录 1100+ 个社区插件——但首轮实测的 101 个里，81 个是 GitHub 源码（非 npm）、3 个安装失败。是生态「第一周」的形态，不是精修市场。
实操上
- Codex 类：精致、场景驱动、配置最少——「租来的」Agent。
- DSH：组装预设、重建会话、审计每一步、扩展 Agent 本身——「自己搭的」Agent。
想要成品，Codex 在精致度上赢。想看清、能改 Agent 是怎么拼起来的——并且愿意沿途读几条 ERR_REQUIRE_ESM——DSH 是更有意思的赌注。这个项目坚持「不想做下一个 Codex」说得太对了：它想做 Codex 做不了的事——一路可检查到底。