跳过主要内容
全部文章
对比

DeepSeek Harness 对比 Codex CLI（附对比 Claude Code）：2026 版

Codex CLI 对比 Claude Code 对比 DeepSeek Harness：从 MCP 命名、hooks 复用、子代理委派等维度，对比 OpenAI、Anthropic、dsh 三者的终端 agent。

DeepSeek Harness（dsh）和 OpenAI 的 Codex CLI 都是开源、以终端为中心的 coding agent——但 dsh 是作为一个通用插件 harness 构建的（连模型适配器和 hook 都是 Cordis 插件），而 Codex CLI 则是 OpenAI 自己的、与其模型和基于 ChatGPT 的鉴权深度绑定的 agent。值得注意的是，dsh 可以把任务委派给 Codex 作为子代理，也能直接复用一份 Codex 的 hooks.json，所以两者并不是严格的二选一关系。

结构上相似的地方

两个项目都是开源的，都是以 CLI 为主要形态、从终端里运行的工具，发布后都围绕自己快速形成了插件/扩展生态。两者也都会从工作目录加载 AGENTS.md 文件作为项目级指令——这是多个 coding agent（包括 dsh）共享的一个约定，如果你在评估两者之间的迁移，这是相对容易迁移过去的一部分。

两者的分歧在于扩展模型的深度不同。dsh 的 Cordis 架构意味着一个 hook、一个 MCP 桥接、一个模型适配器、一个工具，本质上是同一种底层构造——注册在同一个共享 Context 上的插件。相比之下，Codex CLI 的扩展面更窄，更聚焦在 MCP 客户端支持和它自己的 hooks 格式上，没有 dsh 那种"任何东西都能注册成插件"的微内核设计。

MCP 工具命名：同一套形状

如果你之前给 Codex CLI 接过 MCP server，这套心智模型几乎可以原样搬到 dsh 上。dsh 的文档特意点出，它的 MCP 工具命名——mcp__<serverName>__<rawName>——与 Claude Code、Codex 采用的是同一套"server 限定"命名形状。实际好处是：你不需要重新学习"哪个工具属于哪个 server"这套心智模型。

不过 dsh 的覆盖范围比一个完整的 MCP 客户端要窄一些——它明确只桥接 Tools，不桥接 Resources 或 Prompts（两者都在文档里被标注为"延后实现"，目前 harness 侧还没有任何消费者）。如果你依赖的某个通过 Codex 接入的 MCP server 更多用到这两类能力，在假设"直接平替"之前先确认这个缺口。

一份 dsh 的 MCP server 配置（stdio 传输）：

- id: mcp-github
  name: '@deepseek-ai/dsh-mcp-client'
  config:
    serverName: github
    transport: stdio
    command: npx
    args: ['-y', '@modelcontextprotocol/server-github']
    env:
      GITHUB_TOKEN: !!js process.env.GITHUB_TOKEN

streamable-http 写法和重连行为，见《如何在 DeepSeek Harness 中使用 MCP Server》。

Hooks：dsh 直接复用 Codex 的 hooks.json

dsh 提供了官方的 dsh-hooks-codex 桥接包，能把一份已有的 Codex hooks.json 翻译成 dsh 自己的扩展点监听器——和 dsh 通过 dsh-hooks-claude-code 对待 Claude Code hooks 是同一套模式。如果你的团队已经有 Codex 的 hook 脚本，尝试 dsh 时未必需要从头重写。事件如何映射的细节见《DeepSeek Harness 中的 Hooks 与斜杠命令》。

子代理：dsh 可以调用 Codex 自己的 app-server

dsh 的子代理系统包含一个专门的 dsh-subagent-codex provider，通过 Codex 官方的 app-server 协议把任务委派给 Codex——是与 dsh-subagent-claude-code、一个 Agent Client Protocol provider、以及若干进程内选项并列的子代理后端之一。子代理分"一次性"和"可续接"两种模式，一次性委派支持 outputSchema、depthLimit、toolFilter、persona，每一项都需要 provider 显式声明支持。实际意义是：dsh 可以把一个 Codex 驱动的子代理当作更大的 agentic 工作流里的一环来编排，而不是单纯把 Codex 当作竞品。完整 provider 表见《DeepSeek Harness 子代理》。

ChatGPT/Codex OAuth：社区桥接，不是 dsh 内置功能

生态里有一个值得注意的现象：有一批社区插件，专门用来让你在 dsh 内部复用已有的 Codex CLI ChatGPT 订阅登录态，把它暴露成一条模型路由，而不需要单独申请 DeepSeek 原生 API key。FindHarness 收录的例子包括 dsh-codex-connect（"把 ChatGPT OAuth 和 OpenAI Codex 模型接入 DeepSeek Harness"）和 dsh-codex（"通过 OpenAI 的 Codex 登录流程，在 DeepSeek Harness 里使用你的 ChatGPT 订阅"）。这是社区自己搭建的，不是 dsh 官方文档记录的功能——但它的存在也说明 Codex CLI 那套基于 OAuth 的 ChatGPT 登录流程在生态里足够广为人知，才会有多位独立作者分别把它桥接过来。

模型 provider 与交互形态

维度dshCodex CLI
许可协议MIT，开源开源
原生模型DeepSeekOpenAI 的 Codex/GPT 系列模型
Provider 灵活度内置目录（Anthropic、OpenAI、Bedrock、Vertex、Azure、Codex 原生鉴权）+ 任意 OpenAI 兼容自定义端点主要围绕 OpenAI 自家模型与鉴权体系构建
主要交互界面本地 Web UI + headless CLI 模式以终端 CLI 为主
版本状态developer preview，无 SemVer 承诺，GitHub Issues 已禁用活跃开发中的开源项目

哪个更适合你的工作流？

  • 你已经在用 Codex CLI 的 ChatGPT OAuth 登录，想继续用：社区桥接插件能把这个凭据带进 dsh，而 dsh 的 dsh-subagent-codex provider 意味着你可以在一个 dsh 编排的工作流里把 Codex 当作后端调用，而不是必须二选一。
  • 你想要开箱即用、覆盖面最广的原生多 provider 配置：dsh 内置的 provider 目录（Anthropic、Bedrock、Vertex、Azure、Codex 原生鉴权、任意 OpenAI 兼容端点）比一个主要围绕单一厂商模型构建的工具要更宽。
  • 你想要一个单一、紧密集成、组件更少的工具：如果你不需要一个通用的插件微内核，Codex CLI 更窄的扩展面反而更可预期。
  • 你在搭建一个"agent 调 agent"的系统：dsh 的子代理 provider 注册表——可以互换地调用 Codex、Claude Code 或进程内 agent——是更自然的选择。

Codex CLI 对比 Claude Code 对比 DeepSeek Harness 速览

Codex CLI 和 Claude Code 都是以终端为主、绑定单一厂商的 coding agent——一个和 OpenAI 的模型及 ChatGPT 鉴权深度绑定，另一个绑定 Anthropic 的 Claude 模型——纸面上看，这让它们是一对直接竞品。dsh 用一种具体的方式改变了这个叙事：它能把两者都当子代理来调用（dsh-subagent-codex、dsh-subagent-claude-code），也为两者都提供了官方的 hooks 桥接包（dsh-hooks-codex、dsh-hooks-claude-code），可以直接翻译任意一方已有的 hooks.json；而它的 MCP 工具命名（mcp__<serverName>__<rawName>）也被文档特意标注为与 Codex CLI、Claude Code 相同的"server 限定"命名形状。所以孤立地做一次 Codex CLI 对比 Claude Code，会错过对 dsh 用户更有用的问题：你想让 dsh 编排哪一个（或者两个都要），而不是替换掉哪一个。

维度Codex CLIClaude CodeDeepSeek Harness（dsh）
厂商 / 模型OpenAI，Codex/GPT 系列模型Anthropic，主要是 Claude 模型DeepSeek 原生 + 内置多 provider 目录
dsh 能否将其作为子代理调用能——dsh-subagent-codex能——dsh-subagent-claude-code——（dsh 是编排方）
Hooks 桥接进 dsh能——dsh-hooks-codex 复用 hooks.json能——dsh-hooks-claude-code 复用 hooks.json原生 Cordis hook 监听器
MCP 工具命名mcp__<serverName>__<rawName>mcp__<serverName>__<rawName>同一套形状——mcp__<serverName>__<rawName>

FAQ

我在 Codex CLI 上已经用的 MCP server，dsh 也兼容吗？

如果那个 server 只暴露 Tools，命名约定是一致的，应该能以同样的方式工作。dsh 目前不桥接 MCP 的 Resources 或 Prompts，如果你的 Codex 配置依赖这两类能力，请先确认这个缺口。

我能不改代码就把 Codex 的 hooks.json 拿到 dsh 里用吗？

可以，这正是 dsh-hooks-codex 桥接包的用途——它把该文件翻译成 dsh 的扩展点监听器。我们没有对每一种 hook 类型逐一独立验证过，安装后建议自己测试一下具体用到的 hook。

dsh 能不能让我用已有的 ChatGPT/Codex 订阅，而不用单独申请 DeepSeek API key？

这不是 dsh 内置功能，但有多个社区插件——比如 dsh-codex-connect——把 Codex 的 ChatGPT OAuth 登录桥接成 dsh 的模型路由。安装前请像对待任何第三方插件一样先审查源码。

dsh 能不能把 Codex CLI 当作更大工作流的一部分来调用，而不是替代它？

可以——dsh-subagent-codex provider 通过 Codex 官方的 app-server 协议把任务委派给 Codex，因此 dsh 可以充当一个编排者，把 Codex 作为它的执行后端之一。

哪个更开放？

两者都是开源的。更本质的架构差异在于：dsh 把每一种扩展类型——包括 hook 和 MCP 桥接——都当作同一种 Cordis 插件来处理，而 Codex CLI 保持着一个更窄、更聚焦的扩展面。

Next steps