写在前面

2026 年 8 月，两个都叫「Harness」的东西前后脚出现在视野里。8 月 13 日 DeepSeek 放出了 dsh（DeepSeek Harness）的开发者预览，几天后的 8 月 19 日，OpenAI 发了一篇《Codex as a platform》，把已经在驱动 Codex App、CLI、IDE 的那套执行系统，正式讲成一套可复用、可嵌入的开源 Agent Harness。

我这边把两边的官方文档和源码都翻了一遍——Codex 那份是 clone 下来的 openai/codex 仓库，dsh 是之前就在本地跑过的 @deepseek-ai/dsh。翻完最直接的感受是：两者都自称 harness，都在解决「模型之外那层执行系统」的问题，但设计取向几乎是相反的。一个像整车，一个像底盘。

这篇文章不想给两者排优劣，也不预测谁会赢。只想讲清楚一件事：同样是「模型周围的执行系统」，为什么会长成两个方向，以及这两个方向分别适合什么场景。

---

先对齐一个概念：Harness 到底指什么

如果你还没接触过这个词，可以先记住一个等式：Agent = Model + Harness。

模型负责的事其实很窄——给它上下文，它决定下一步做什么，产出一段文字或者一次工具调用。但一个真实的任务远不止「决定下一步」。假设你让 AI 改一个仓库：它要先读文件、再改代码、然后跑测试，中途可能要申请网络权限，进程断了还得能接着来。

这里就冒出一串模型自己答不了的问题：谁记住改到哪一步了？谁真正去执行那条 shell 命令？谁在危险操作前拦一下等你批准？失败了谁决定要不要重试？

这些「脏活累活」的集合，就是 Harness。 它做的远不止给模型套一层 Prompt——状态、工具、执行边界、进度、审批，这一整套围绕模型运转的系统都归它管。OpenAI 官方的说法很直白：「That surrounding execution system is the harness.」

概念对齐之后，两种取向的分歧就好讲了。

---

Codex 的取向：把执行层做成一台一体化引擎

Codex Harness 给人的第一印象是「重」。它的核心实现是 Rust，仓库里 codex-rs 目录下有 104 个 crate（子模块），涵盖 agent loop、协议、传输、沙箱、身份认证一整套。这不是一个轻量脚本，而是一台编译成原生二进制的执行引擎。

它对外暴露能力的方式，是三个层层递进的原语：

• Thread：一段可以持续、可以恢复的长期工作，回答「这段工作和历史属于谁」

• Turn：Thread 里当前这一轮目标，回答「这一轮怎么开始、怎么引导、怎么结束」

• Item：这一轮里产生的一条可持久化记录，比如一条用户消息、一次推理、一条 shell 命令、一次文件改动

你的应用通过一个叫 app-server 的进程连上它，走 JSON-RPC 协议：创建 Thread、启动 Turn、流式接收 Item 和事件、在模型要执行危险操作时把审批请求交回给你的界面。Codex 的 VS Code 插件、CLI，本质上都是这个 app-server 的客户端。

安全边界也是「内建」的。源码里按操作系统分了三套沙箱——Linux 走 landlock、macOS 走 seatbelt、Windows 单独一套。也就是说，「在什么范围内能读写文件、能不能联网」这层约束，是 harness 自己在 OS 级别兜住的，不用应用层自己去搭。

这套设计的代价，是它只跑 OpenAI 自己的模型。Codex 的 agent loop 深度依赖 OpenAI Responses API 的推理链条（reasoning items）传递和压缩，这套机制是 OpenAI 模型特有的。换句话说，你拿到的是一台调校好的引擎，但油箱只认一种油。

它的取向可以概括成一句话：把执行层做厚、做稳、做成开箱即用，代价是绑定一家模型、内核不可改。 你能控制的是「给它什么工具、什么上下文、什么审批规则」，但 agent loop 本身的重试策略、上下文压缩策略，你只能用 OpenAI 给的那套。

---

dsh 的取向：把一切拆成可替换的插件

dsh 的第一印象正好相反——它很「薄」。它基于一个叫 Cordis 的运行时，核心理念只有一句：everything is a plugin，一切皆插件。

薄到什么程度？在 dsh 里，界面上的按钮（比如文件附件）是插件，系统提示词是插件，工具调用是插件——连 agent loop 本身都是一个插件。你看到的整个产品，是一堆插件在 Cordis 上组装出来的结果。

这带来一个 Codex 给不了的能力：你可以把 loop 换掉。 Codex 里 agent loop 的行为是 OpenAI 定死的；dsh 里如果你觉得默认 loop 太啰嗦、爱跑偏，可以写一个自己的 loop 插件替换进去。dsh 还自带一个类似 LangSmith 的 trajectory 视图，agent 每一步动作都能点开看是哪个插件产生的、为什么——这种颗粒度的可观测性，来自它「一切都是插件」的结构。

模型这块 dsh 也不绑定。它默认用 DeepSeek 自家模型，但可以通过 API Key 接任意 provider，包括走 OpenRouter 接一大堆第三方模型。

最能体现取向差异的一点：dsh 可以把 Codex、Claude Code 当成 sub-agent 来驱动。 它有专门的插件，能在一个 dsh 会话里把某个子任务委派给 Codex 去跑，再收回结果。在 dsh 眼里，Codex 不是竞品，而是「一个特别擅长 OpenAI 模型的可调用执行单元」。

代价也很实在：dsh 目前还是开发者预览，官方自己都说「迭代快到没有一处是稳定的」。而且它「开箱即用」的能力比 Codex 弱——给你的是一个框架，墙得你自己砌。

它的取向也能概括成一句话：把一切做成可插拔，换来极致的灵活和可组合，代价是稳定性和开箱体验要你自己补齐。

---

同一个问题的两种答案：三个分歧点

把两边放到一起看，分歧集中在三个地方。

第一个分歧是模型绑定。 Codex 为了在 OpenAI 模型上榨出最大性能，深度适配了一家模型；dsh 把模型当成可替换的 provider。这更像「专精」与「通用」的经典取舍，谈不上谁更先进——Codex 官方披露过一个 ARC-AGI-3 的例子，仅靠 harness 层做「保留推理 + 上下文压缩」两项调整，GPT-5.6 Sol 的得分从 13.3% 提到 38.3%，同时输出 token 减少。这种收益恰恰来自它跟模型的深度耦合，换模型未必能复现。

第二个分歧是内核可不可改。 Codex 开源的是执行层和集成接口，但 agent loop 的行为逻辑你只能用不能改；dsh 把 loop 本身也做成插件，行为逻辑对你是敞开的。前者适合「我信任你的调校，别让我操心」，后者适合「我知道我要什么，别挡着我」。

第三个分歧是怎么扩展。 Codex 的扩展入口是 MCP——你把自己的数据和操作包成 MCP 服务接进去，harness 内核不动；dsh 的扩展入口是插件——从 UI 到 loop 到工具，哪一层都能换。一个是「在稳定内核外围接东西」，一个是「内核本身就是可拆的」。

有意思的是，这两条路在协议层反而在慢慢靠拢。dsh、OpenClaw 这类项目都能通过标准协议把 Codex 接进来当运行时——设计取向不同，不代表老死不相往来。

---

那到底该用哪个

先说结论：这不是一道二选一的题，判断依据是「你的系统需要控制到哪一层」。

如果你要的是在 OpenAI 模型上，快速拿到一套调校好、开箱即用、还带 OS 级沙箱的执行能力，并且能接受绑定一家模型，那 Codex Harness 是省心的选择。尤其当你要把 agent 嵌进已有产品（运营看板、工单系统、IDE），app-server 那套 Thread/Turn/审批的协议是现成的。

如果你要的是跨模型切换、深度定制 agent 行为、或者把多个 harness 编排到一起，那 dsh 的插件架构更贴合。它的价值不在开箱，而在于你愿意花时间打磨之后，能得到一个完全长成你团队工作流样子的 harness。

还有一种常被忽略的情况：你现在可能一个都不需要。 如果你的场景是固定流程的 workflow，已有的方案能稳定处理状态、工具和执行边界，那没必要为了「用上 harness」而引入 harness。它真正的用武之地，是当任务要跨多轮持续、要在受控环境里调工具、要处理审批和失败恢复的时候。

一句话收尾：Codex 把复杂度收进引擎里替你扛了，dsh 把复杂度摊开交给你自己搭。 选哪个，取决于你想省心，还是想掌控。

---

数据口径：本文基于 OpenAI《Codex as a platform》官方文章、openai/codex 仓库（Apache-2.0，截至 2026-08-26 的快照）与 dsh 公开资料整理。文中不对两者做优劣判断，也不预测演进关系。