写在前面2026 年 8 月两个都叫「Harness」的东西前后脚出现在视野里。8 月 13 日 DeepSeek 放出了 dshDeepSeek 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一段可以持续、可以恢复的长期工作回答「这段工作和历史属于谁」TurnThread 里当前这一轮目标回答「这一轮怎么开始、怎么引导、怎么结束」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 嵌进已有产品运营看板、工单系统、IDEapp-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 公开资料整理。文中不对两者做优劣判断也不预测演进关系。