DeepSeek Harness vs Claude Code vs Codex：到底差在哪
一句话版：三者都能"读代码、跑命令、调模型、改文件"，能力清单高度趋同；真正的分水岭是 开源与可审计性、模型是否绑定、成本模式、扩展机制。DeepSeek Harness 是唯一可以本地审计实现、任意换模型、完全自托管的开源选项（MIT），代价是 Developer Preview 期的不稳定与更高的上手门槛。
本文基于官方源码 deepseek-ai/deepseek-harness（审计基线 0.1.0-rc.7 @ 99f6f02）与三方公开产品文档写作。DSH 侧的命令、包名、事件名均与 TypeScript 实现核对；Claude Code / Codex 侧只描述公开产品状态，不逐条对照版本。
短答案
| DeepSeek Harness | Claude Code | Codex | |
|---|---|---|---|
| 出身 | DeepSeek AI，开源 MIT | Anthropic，商业闭源 | OpenAI，商业（云 + 本地 CLI） |
| 模型绑定 | 不绑：任意 OpenAI 兼容端点 | 默认绑 Claude 系 | 默认绑 OpenAI 系 |
| 运行位置 | 本地进程（默认 127.0.0.1:3080） | 本地 CLI + 远程会话 | 云端工作区 + 本地 CLI |
| 可审计性 | 全源码可读 | 不可 | 不可（CLI 可看行为，非实现） |
| 成本模式 | 只花模型 API 费 | 订阅或 API 计费 | 订阅或 API 计费 |
| 状态 | Developer Preview，会有破坏性变更 | 稳定商业产品 | 稳定商业产品 |
选型判断不需要看功能清单——三家都能干活。要看的是：你愿不愿意把"agent 的实现"当黑盒，以及模型是不是只能有一家。
能力面：趋同，不用逐条比
| 能力 | DeepSeek Harness | Claude Code | Codex |
|---|---|---|---|
| 文件 / 命令工具 | tool-fs / tool-bash | 内置 | 内置 |
| 会话持久化 | ~/.dsh/sessions/（zstd，可检索） | 有 | 有 |
| 子 Agent | 有（subagent 能力） | 有 | 有 |
| 技能 / 提示词封装 | skills 系统 | skills | 有 |
| MCP | 插件挂载 | MCP 客户端 | 部分 |
| 自定义扩展 | 一切皆插件（Cordis） | hooks + plugins（预览） | 受限 |
| 沙箱 | 默认受限（bwrap/Landlock） | 权限确认 | 云 sandbox |
| Web UI | 有（Hermes 式工作台） | 无（终端为主） | 云端 IDE |
DSH 侧每一项都有对应页面：内置工具、会话、子 Agent、技能系统、MCP、插件机制、沙箱与安全、Web UI。
真正的分水岭
1. 开源与可审计性
DSH 整个运行栈（agent 循环、工具执行、会话、沙箱、凭据处理）都在 deepseek-ai/deepseek-harness 仓库里，MIT 许可，可以：
Claude Code / Codex 是闭源产品，行为只能通过文档和黑盒观察。对个人用户无所谓；对"agent 要进生产、要过合规"的团队，这是硬性区别。
2. 模型绑定
DSH 的模型路由是插件化的（llm-pi-ai，配置见 多模型），任何 OpenAI 兼容端点都能接：DeepSeek、自建网关、其他厂商，甚至同一会话里多个 provider 路由。官方 provider 名 deepseek-official 只是默认值，不是绑定。
Claude Code 围绕 Claude 模型优化（付费墙内），Codex 围绕 OpenAI 模型。接第三方模型在这两个产品里是旁路玩法，不是主路径。
3. 成本模式
DSH：软件本身零费用（MIT），只付模型 API 的钱；跑本地模型也完全可行。
Claude Code / Codex：订阅或 API 计费，价格含产品层。对个人开发者，订阅的"全包"体验通常更省心；对高用量团队，DSH 的自带模型路由可能更省。
4. 扩展机制
DSH 的架构承诺是 一切皆插件（Cordis 底座）：工具、服务、事件、UI 面板都能挂载，插件通过 dsh plugin add（bundle）或 repository 清单（cordis.patch.yml）接入（见 插件）。
Claude Code 提供 hooks / MCP / plugins（预览）作为扩展面；Codex 的扩展面更窄。深度定制场景下，DSH 的缝（seam）体系（ctx.llm、ctx.tools、ctx.sandbox…）是目前三者中最接近"框架"的。
什么场景选谁
| 场景 | 选 | 理由 |
|---|---|---|
| 想审计 agent 实现、自托管、公司合规 | DSH | 全源码可读、本地运行、凭据 0600 托管（凭据） |
| 要换模型 / 接自建网关 / 跑本地模型 | DSH | 模型路由插件化，任意 OpenAI 兼容端点 |
| 深度定制工具链、做插件/技能分发 | DSH | 一切皆插件，dsh-plugin 生态 |
| 最快上手、预算固定、要厂商兜底 | Claude Code / Codex | 零配置、稳定、文档全 |
| 深度在 OpenAI / Anthropic 生态内 | 对应厂商产品 | 生态整合 > 可审计性 |
| 能接受破坏性变更、愿意跟着 rc 迭代 | DSH | Developer Preview 是明确的提醒 |
常见问题
DeepSeek Harness 是 Claude Code 的开源替代品吗？
定位不同：Claude Code / Codex 是"产品"，DSH 是"开源框架 + 可组合的 agent 应用"。它能替代"用 agent 干活"这件事，但你要自己接受 rc 迭代节奏、自己搭模型接入。想快速跑起来先看 快速上手。
DSH 能接 Claude / GPT 的模型吗？
能。llm-pi-ai.providers 接受任意 OpenAI 兼容端点，官方 provider 名 deepseek-official 只是默认路由（见 多模型）。模型名、端点、key 都在本地配置，不锁厂商。
DSH 能直接迁移 Claude Code / Codex 的工作流吗？
不能无缝迁移：概念体系不同（插件/Cordis 组合 vs hooks/MCP），CLI 与配置格式也不同。但高层能力（子 agent、技能、MCP、会话检索）都能找到对应物，迁移成本主要在重配环境，不在能力缺失。
DSH 适合生产环境吗？
视"生产"而定：它默认 loopback 监听（127.0.0.1:3080）、凭据 0600 落盘、沙箱默认受限（沙箱与安全），隐私基线不差；但官方状态是 Developer Preview，"会有破坏性变更"，锁版本、读 changelog、用 dsh web --dump-config 验证组合是前提（见 启动配置）。
结论
能力面三家趋同，比不出高低。真正的决策变量是：开源可审计、模型自由、成本透明（选 DSH）vs 开箱即用、厂商生态、稳定迭代（选 Claude Code / Codex）。DSH 现在处于 Developer Preview，意味着最自由也最不稳定——适合愿意跟着源码走的人；想零折腾开工，商业产品更省心。