继 DeepSeek 开源 DSH 之后，OpenAI 开放 Codex Harness：Agent 运行时成新战场

导语：北京时间 8 月 20 日，OpenAI 发布官方博客，把 Codex 定义为开放的 Agent Harness 平台；而五天前 DeepSeek 刚开源了 DSH，GitHub 星标数已突破 17 万。随着头部模型厂商相继开放执行层框架，"Agent 运行时"正在成为新的竞争焦点。本文对比 Codex Harness 与 DSH 的开放程度与生产成熟度，并梳理 Kimi Code、ZCode 等国产 Agent 执行系统的布局。

北京时间 8 月 20 日，OpenAI 对外发布《Codex as a platform: build on the open agent harness》，向开发者介绍如何基于开源的 Codex Harness 搭建属于自己的 Agent 应用。这篇博客被不少开发者视为 OpenAI 在 Agent 基础设施层面的一次重要表态。

Codex App、CLI 以及 IDE 扩展在底层共用同一套 Harness，会话状态、上下文、工具调用、沙箱与人工审批等环节都由它统一管理。开发者可以借助 codex exec、SDK 或 app-server，把这些能力接入企业已有的操作台、客服系统、安全工具和各类内部应用。

就在五天前，也就是北京时间 8 月 14 日，DeepSeek 刚刚开源了 DeepSeek Harness（简称 DSH），并专门为它开设了一个微信公众号，以一只黑色鲸鱼作为标识，与模型产品沿用的蓝色鲸鱼做了明显区分。前后不到一周，两家头部厂商先后把目光投向同一类产品，行业风向可见一斑。

截至 8 月 20 日，DSH 在 GitHub 上已收获约 17.37 万颗 Star 和 1.88 万次 Fork，相关帖子登上 Hacker News，拿到 744 分与 310 条评论。需要说明的是，DSH 目前仍处于 Preview 阶段，却已在短短几天内获得了远超普通开发工具的关注度。

为什么一套尚未成熟的 Harness 能吸引这么多开发者？OpenAI 此番把 Codex 进一步定义为"平台"和"开放的 Agent Harness"，相比过去的接入方式究竟增加了什么？Harness 以往主要服务于模型公司自家的 Agent 产品，头部模型公司为何开始主动开放它？这几个问题的背后，AI 的主战场之一已经悄然延伸到了"Agent 运行时"。

回顾时间线，2025 年 10 月 6 日 OpenAI 宣布 Codex 正式 GA 时，就同步推出了 Codex SDK，开发者可以把 CLI 背后的 Agent 放进自己的工具与工作流。codex exec 后来被用于脚本和 CI 任务，app-server 则开放了线程、回合、事件流和审批协议，让第三方应用能够维持长期会话。2026 年 1 月，OpenAI 还专门拆解过 Codex 的 Agent Loop，讲清模型如何接收指令、调用工具、读取执行结果，再进入下一轮推理。这些能力在 DeepSeek 发布 DSH 之前其实都已经存在。

而在最新这篇博客里，OpenAI 把这些能力统一概括为 Codex Harness，并明确鼓励开发者用它构建自己的产品。Codex 的定位，正由 App、CLI 和 IDE 中的编程 Agent，继续向企业应用的底层执行系统延伸。

开发者媒体 ExplainX 的作者 Yash Thakker 打了一个形象的比方：App、CLI 和 IDE 扩展就像同一栋楼的三扇门，OpenAI 这次想让开发者把目光放到整栋楼上。在他看来，这样的定位也让 Codex 开始与 Claude Agent SDK 进入更直接的比较。

OpenAI 还给出了一组数据，说明 Harness 会给同一个模型的实际表现带来怎样的影响。在 ARC-AGI-3 测试中，GPT-5.6 Sol 单独运行时只拿到 13.3% 的分数；加入 Codex Harness 的持续推理与上下文压缩之后，分数跃升至 38.3%，输出 Token 也缩减到原来的约六分之一。

博客中还列举了几项已经公开的应用：Cisco 将 Codex SDK 用在了 Cisco Cloud Control 的 App Builder 上；GitHub 和 JetBrains 把 Codex 接入了现有的 IDE 工作流；Thrive Holdings 与 Crete 则将 Codex 用于税务准备，一项试点共处理了 7000 份纳税申报表，报税准备时间缩短了约三分之一。

在这些案例中，企业的代码、客户数据、内部工具、审批和任务记录都会流经同一套"运行时"。如果 Codex 成为默认的 Agent 底座，OpenAI 就能离真实工作流更近，也离这些工作流产生的模型调用更近。

相比之下，DSH 的开放要更为彻底：它把模型、工具、技能、会话、沙箱、存储、Agent Loop、调度和 UI 全部做成了插件，底层由 Cordis 统一管理挂载、卸载和依赖关系，讲究"一切皆插件"。

两者的差别主要体现在开放程度上。如果用造汽车来比喻，Codex 相当于把核心的发动机调校好了，你可以接入其它非核心组件，但需要与这台发动机适配；DSH 则允许开发者连发动机都自己来组装。

不过 DSH 并不是第一个开放程度如此之高的 Harness。比如 Pi Harness 采用 MIT 许可证，同样提供 Agent Loop、工具调用、状态管理和多模型接口，它的核心更小，许多外围能力都交给了扩展。

在一些开发者看来，技术上的可改造性并不足以解释 DSH 的独特价值。创业公司当然可以从 DSH 出发，换上自己的模型、界面、工具和权限系统，搭出一款类似 Codex 或 Claude Code 的产品，但同样的事情也能从 Pi、OpenCode 等其他开源项目起步。

DSH 真正特别的地方，在于它做了统一的插件结构：模型适配器、Session、存储、沙箱和 Loop 遵循同一套 Cordis 机制，开发者替换底层组件时，尽量不需要维护一份与上游长期分叉的源码。

Pi Agent 的主要开发者、Flask 作者 Armin Ronacher 评价说，DSH 并不完美，但这是他第一次在看到一个该领域的新项目之后，产生了重新审视 Pi 部分设计选择的想法。

架构虽新，但离生产环境还有距离。DSH 作者之一 Tianyi Cui 在 Hacker News 上提醒，当前只是早期预览版，会有不少粗糙之处，也会出现破坏兼容性的修改。

开发者的实际评价明显分化。一名开发者检查代码后估算，DSH 包含约 45.3 万行代码和 219 个包，他肯定了其执行日志和沙箱设计，也批评首个公开版本只有一笔压缩后的 Git 提交、Benchmark 材料不足，不利于外部开发者理解项目演进。

Reddit 上的试用反馈则集中在性能与成本：有人认为 DSH 可以充分发挥 DeepSeek 模型的能力，但速度偏慢、Token 消耗偏高，产品说明和插件用途也不够清楚。这些属于个人测试结果，不能外推为普遍结论，却说明可改造性并没有自动解决使用成本和成熟度问题。

国内参与内测的开发者透露，约 300 名测试者在两周内完成了 200 多个插件；正式发布两天后，社区整理的精选列表已经收录 270 个插件，随后又出现了 Web UI、移动端控制、模型适配、额度监控和插件市场等成果。

争议也随之而来。有人质疑大量插件只有简单说明、缺少真实用户评分，质量参差不齐；也有人提醒，UI 和远程连接插件一旦出现兼容问题，用户必须具备回滚和排错能力。国内社区目前扩展速度很快，但质量筛选、版本兼容和安全审查都还没跟上。

17 万颗 Star 证明了开发者愿意研究这套"新东西"，但还难以证明，在企业生产端，真正有用户愿意把关键工作交给它。DSH 允许开发者"任意插拔"，然而一名大模型开发者并不建议公司在生产场景轻易投入底层改造，他的原话是："除了交互流程优化，其他方向碰都不要碰 Harness。"

他的理由是，Harness 很难形成一套长期稳定的最优方案。模型仍在快速变化，不同模型需要的执行策略也不相同：有些模型适合先完成规划再调用工具，有些模型则需要边执行边修正。同一组工具交给不同模型，稳定性也可能出现明显差异——一种模型可以同时处理几十个工具，另一种模型可能随着工具数量增加而迅速失去控制。

在他看来，模型公司在这方面拥有天然优势。"Codex 好在光速前进，"他说，"它建立在 OpenAI 的模型能力上，模型更强。DSH 短时间内很难超越。Harness 离开模型能力，其实是没意义的。DeepSeek 关键还是要提高模型能力。"

既然 Harness 难以形成独立壁垒，DeepSeek 为什么还要单独开源、单独做品牌？一名大模型开发者的答案是闭环："对模型厂来说当然需要，模型公司可以拿 Harness 反馈的数据优化模型。"

这里的数据需要准确理解：用户是否允许任务记录用于训练，要看隐私政策。但模型厂可以获得另一种非常有价值的反馈——用户在什么任务上失败、工具调用卡在哪里、一次任务重试多少次、哪种上下文策略消耗的 Token 最少。

过去，DeepSeek 只提供 API 时，任务都运行在 Claude Code、Codex 等外部 Harness 里。DeepSeek 能看到模型请求，却很难完整理解请求之前发生了什么，以及模型输出之后任务到底有没有真正完成。DSH 让 DeepSeek 得以同时观察模型和运行过程，模型团队也能围绕真实任务调整工具调用、推理策略和下一版 Harness。对模型厂来说，Harness 是一条产品和能力的闭环。

流量是另一层收益。DeepSeek 目前没有推出官方 Token Plan，主要依靠 API 收费。OpenCode Go、Cola 等第三方平台把 DeepSeek API 重新包装成月费套餐，既掌握了用户入口，也承担了重度用户击穿套餐成本的风险。有了 DSH，DeepSeek 可以更准确地计算一个 Session 运行多少轮、缓存命中率如何、无效重试消耗多少 Token、哪些步骤用 Flash、哪些步骤调用 Pro。大胆猜想一下，如果它未来推出托管版 DSH 或订阅套餐，计费单位可能从 API Token 转向例如每五小时额度、任务数量、并发和 Pro 模型使用量——不过目前还没有证据显示 DeepSeek 已经决定这样做。

事实上，在 DSH 发布之前，中国模型公司就已经开始建设自己的 Agent 执行系统。月之暗面的产品最早叫 Kimi CLI，官方变更记录显示，2025 年 9 月 14 日发布的 0.8.0 版本已经包含 Shell 工具、基础系统提示词、上下文统计和 Agent Loop；10 月 31 日，月之暗面正式发布 Kimi CLI 技术预览。此后，这套产品逐步升级为现在的 Kimi Code。

Kimi Code 是一款运行在终端中的编程 Agent，负责管理上下文、调用工具、读写文件、执行命令，并根据执行结果继续规划下一步。从功能定义看，它已经具备完整的 Harness；当前代码采用 MIT 许可证，也支持接入其他兼容模型，开发者可以基于源码、SDK 和自定义 Agent 机制继续改造。

它与 DSH 的差别主要在架构目标上。Kimi Code 首先提供一套可直接使用的编程 Agent，开放源码让开发者修改现有产品；DSH 则把模型、工具、会话、存储、沙箱和 Agent Loop 都定义为独立插件，希望开发者沿着这套接口重新组合运行时。两者都可以被 Fork，也都能成为专用 Agent 的基础，只是 DSH 提供了更细的组件边界，更适合需要频繁替换执行策略的开发者。

智谱的布局同样值得关注。2026 年 6 月 16 日，智谱在 GLM-5.2 发布文章中首次介绍 ZCode；7 月 1 日，ZCode 正式对外发布，比 DSH 早了约六周。ZCode 是一款围绕 GLM 模型开发的 Agentic Development Environment，也就是带有自主执行能力的开发环境，它拥有自研的 ZCode Agent，负责管理任务、上下文、终端、文件、权限和代码审查。

从功能上看，ZCode 内部同样运行着一套 Harness；但根据目前公开的信息，智谱并没有开放这套核心运行时的源代码。它提供插件、Skill 和 MCP 扩展能力，开发者可以增加工具和工作流，却不能像修改 DSH 那样重写底层的 Agent Loop。

因此，Kimi Code 和 ZCode 都可以在广义上被称为 Harness，因为它们都负责驱动模型完成连续任务。若把"真正意义上的 Harness"限定为可独立嵌入、可更换模型、可以修改执行循环的通用运行时，三者的开放程度便有明显差异：ZCode 更接近 GLM 的官方执行环境；Kimi Code 是开源的编程 Agent 及其运行系统；DSH 则直接把可拆解、可重组的 Harness 作为产品主体。

从这个意义上看，模型公司向执行层延伸其实早已发生，DSH 反而是最晚的，它带来的新变量是开放深度。过去模型厂商主要争夺 API 调用量；当 Agent 开始进入企业业务之后，竞争进一步延伸到决定模型何时被调用、如何完成任务的执行系统——谁能让更多工作流长期运行在自己的接口上，谁就更接近模型分发和企业软件之间的控制层。