我开始认真查 Codex Harness，其实是因为一个很简单的疑问。
这两天国内不少自媒体都在说：“OpenAI 把 Codex Harness 开源了。”我顺着这个说法去 GitHub 找了半天，却始终没找到什么新仓库。搜索来搜索去，最后还是那个熟悉的 openai/codex。
可问题也恰恰出在这里：这个仓库不是早就开源了吗？
再往前翻历史，会发现事情比“OpenAI 突然开源了一个 Harness”有意思得多。2025 年 4 月，Codex CLI 发布时就已经以开源项目的形式出现；2025 年 10 月，OpenAI 又发布了 Codex SDK；2026 年 1 月，官方专门解释了 Codex 的 Agent Loop；2 月又公开介绍了驱动 CLI、IDE、Web 与桌面应用的 Codex App Server。直到 2026 年 8 月 19 日，OpenAI 才用一篇标题非常明确的文章——《Codex as a platform: build on the open agent harness》——把这些东西正式统一成一个新的叙事：
Codex 不只是一个你去使用的编程助手，它本身正在变成一套别人可以嵌入、复用和构建产品的 Agent Harness。
所以，如果只把这次事件理解成“OpenAI 又开源了一个 GitHub 项目”，反而会错过它真正的战略意义。
先说结论：Codex Harness 并不是 8 月 19 日才突然开源
这件事首先需要做一个事实层面的纠偏。
| 时间 | Codex 相关关键节点 | 意义 |
|---|---|---|
| 2025 年 4 月 | Codex CLI 作为轻量级开源 Coding Agent 发布 | openai/codex 仓库已经公开，采用 Apache-2.0 |
| 2025 年 10 月 | Codex 正式 GA，同时发布 Codex SDK | 开发者已经可以把驱动 Codex CLI 的 Agent 能力嵌入自己的工具和工作流 |
| 2026 年 1 月 | OpenAI 发布《Unrolling the Codex agent loop》 | 第一次系统解释 Codex Harness 的核心 Agent Loop |
| 2026 年 2 月 | OpenAI 发布《Unlocking the Codex harness: how we built the App Server》 | 公开讲解 App Server，并明确 CLI、IDE、Web、桌面 App 背后使用同一套 Harness |
| 2026 年 8 月 19 日 | 发布《Codex as a platform: build on the open agent harness》 | 正式把 Codex 从“产品”重新定位为可供第三方构建的 Agent 平台 |
也就是说，没有一个“8 月 19 日新创建的 Codex Harness 仓库”。你在 GitHub 找不到，是因为它一直就在 openai/codex 里。
这次真正的新变化，更接近一次平台化定调、能力边界梳理和官方支持承诺：OpenAI 明确告诉开发者，这个开源仓库背后的 Agent Loop 不再只是 Codex CLI 的内部实现，而是一套你可以依赖、嵌入、围绕它建立产品的运行层。
那么，Codex Harness 到底是什么？
如果只把 Agent 理解成“模型 + Prompt”，很难理解 Harness 为什么突然成了 2026 年的行业关键词。
一个真正能长时间工作的 Agent，至少还需要处理这些事情：
- 收集和维护任务上下文；
- 跨多轮保存会话状态；
- 读取文件、执行 Shell、调用 MCP 或其他工具；
- 把工具结果重新送回模型并继续下一步；
- 在长任务中压缩上下文，避免会话失控；
- 流式输出进度、工具调用、Diff 和结果；
- 限制文件、网络和命令权限；
- 遇到高风险操作时请求人工批准；
- 失败、中断后恢复任务。
包围在模型外面的这整套执行系统，就是 Harness。
OpenAI 自己给了一个很有说服力的数据。在 ARC-AGI-3 测试中，模型仍然是同一个 GPT-5.6 Sol，只通过 retained reasoning（保留推理）和 context compaction（上下文压缩）两项 Harness 层变化，得分就从 13.3% 提升到 38.3%，同时输出 Token 减少约 6 倍。
这并不意味着所有现实任务都会得到三倍提升，但它至少证明了一件事：
同一个模型，被放进不同的 Harness，最终表现出来的“智能体能力”可以完全不同。
这也是为什么 2026 年行业竞争正在从单纯的“谁模型更强”，逐渐转向模型 + Harness 的联合竞争。
8 月 19 日到底“发布”了什么？关键是三层集成方式
OpenAI 在新的平台化文章里，把 Codex Harness 的开发者入口明确整理成三层。它们不是三个互不相关的产品，而是同一套 Agent 能力的不同暴露深度。
| 方式 | 适合场景 | 你需要控制多少 Harness |
|---|---|---|
codex exec | 脚本、CI、批处理、一次性后台任务 | 最低。给任务，等待结构化结果 |
| Codex SDK | 程序化启动、恢复、流式管理 Agent 任务 | 中等。用 SDK 控制 Thread / Turn，不必自己实现协议 |
codex app-server | 自定义 IDE、运营台、安全平台、企业内部应用 | 最高。直接驱动 Harness 的会话、事件、审批和工具循环 |
其中最值得关注的是 App Server。
它通过一套双向 JSON-RPC 风格协议，把 Codex 的核心运行层暴露给客户端。应用可以：
- 创建、恢复或分叉 Thread；
- 启动 Turn，并在执行中继续 steer；
- 实时接收 Agent Message、工具执行、文件变化等事件；
- 处理命令执行和文件修改审批；
- 配置工作目录、Sandbox、网络访问和模型；
- 把自己的 MCP 工具交给 Codex 使用。
换句话说，你完全可以不要 Codex 官方的 UI，只把它的 Agent Loop 嵌进自己的产品。
这才是战略变化：从“让用户来用 Codex”，变成“把 Codex 塞进用户原来的软件”
过去几年 AI 产品有一种非常明显的惯性：无论做客服、财务、运维、研究还是编程，最后都想把用户赶进一个聊天框。
OpenAI 这次平台化文章的观点反而很明确：很多真实工作并不应该从一个空白聊天框开始。
一个运维人员理解问题时，可能靠的是告警时间线和监控面板；一个物流人员依赖的是订单、地图和库存；一个安全分析师依赖的是事件图谱；客服依赖的是客户资料和工单历史。
真正更自然的 AI 形态不是把这些界面全部扔掉，而是：
原来的专业软件继续负责呈现业务上下文，Agent 在里面负责理解、调查、建议下一步，并在获得批准后执行操作。
OpenAI 在文章中用一个叫 Relay 的示例来演示这种模式：一个物流运营界面保留原来的运输记录和操作流程，Codex 在旁边读取上下文、通过 MCP 查询数据、比较恢复方案；一旦涉及重新预订运输等有副作用的动作，再通过 UI 请求人工批准。
这其实是一个很重要的产品范式变化：
AI 不一定要成为一个新的 App，AI 可以变成旧 App 里面的“执行大脑”。
那它和 DeepSeek Harness 是不是竞争关系？是，但不是一模一样的竞争
这部分最值得聊。
DeepSeek Harness 在 2026 年 8 月 13 日公开开发者预览，而 OpenAI 的《Codex as a platform》发布于 8 月 19 日，两者只差 6 天。时间确实巧得让人很容易产生联想：是不是 DeepSeek 刚发布 Harness，OpenAI 马上就跟着把 Codex Harness 开源了？
从目前能核实的时间线看，不能这么下结论。
原因很简单：Codex CLI 的开源历史可以追溯到 2025 年 4 月，SDK 在 2025 年 10 月已经公开；OpenAI 在 2026 年 1 月、2 月已经连续发布 Agent Loop 与 App Server 的工程文章。也就是说，Codex Harness 的绝大部分架构和开放工作明显早于 DeepSeek Harness 的 8 月发布。
因此，更合理的解释是：
DeepSeek 与 OpenAI 正在同一时间看到同一个行业趋势：模型越来越强之后，真正决定 Agent 产品差异的下一层，就是 Harness。
两者确实开始进入同一个战略战场，但设计哲学明显不同。
| 维度 | Codex Harness | DeepSeek Harness |
|---|---|---|
| 核心定位 | 把成熟的 Codex Agent Loop 变成可嵌入的平台能力 | 从一开始就把 Harness 作为独立、可组合的 Agent 基础设施 |
| 架构哲学 | 更 opinionated，强调已经验证过的 Agent Loop、Sandbox、Approval、App Server | 更激进的微内核路线，基于 Cordis，强调 Everything is a Plugin |
| 扩展边界 | 通过 SDK、App Server、MCP、Skills 等逐层开放 | 模型、工具、Skills、Session、Sandbox、Storage、Loop、Scheduling、UI 均可插件化 |
| 成熟度 | Codex CLI 已运行一年多，多种官方产品共享同一 Harness | 刚进入 Developer Preview，明确存在破坏性变更 |
| 协议 / 嵌入 | codex exec、SDK、App Server | Web、Headless、SDK / JSON-RPC、ACP、MCP 等 |
| 许可证 | Apache-2.0 | MIT |
| 最突出的优势 | 成熟、产品级、和 Codex 模型及生态深度共设计 | 可替换性与组合自由度极高，适合研究和构造不同 Agent |
如果说 DeepSeek Harness 像是在问：
“Agent 的每一块骨架能不能都做成插件？”
那么 Codex Harness 更像是在说：
“我们已经把一套在 Codex App、CLI、IDE 里跑过的 Agent Loop 做出来了，你可以直接拿这套成熟运行层去做自己的产品。”
所以它们是竞争对手，但并不是简单的“两个 CLI 谁更好用”。真正竞争的是：未来开发者到底会选择哪一套 Harness 作为自己 Agent 产品的底座。
为什么 OpenAI 愿意把 Harness 做得这么开放？
表面看，这似乎是在把自己的核心工程能力送给别人。
但站在平台战略上，它其实非常合理。
第一，模型仍然是“刀片”，Harness 可以成为“刀架”
OpenAI 开源的是 Agent 运行层，不是 GPT 模型权重。开发者可以免费查看、修改和复用 Harness，但真正运行高质量 Codex 工作负载时，仍然会自然使用 OpenAI 的模型、订阅和云端能力。
当越来越多第三方软件建立在 Codex Harness 上时，Harness 本身就会成为模型分发渠道。
第二，OpenAI 想把 Codex 从产品做成基础设施
一个单独的 Codex App 能覆盖的工作流永远有限；如果让 JetBrains、GitHub、企业内部平台、安全产品、运维控制台都可以调用同一 Agent Loop，Codex 的触达面会扩大一个数量级。
第三，Harness 本身正在成为一种“事实标准”竞争
未来真正有价值的不只是“谁有 Agent”，而是：
- 第三方工具怎么接入；
- Skills 用什么格式；
- 会话怎么持久化；
- 权限和审批怎么表达；
- 外部应用如何驱动 Agent；
- 多 Agent 如何编排；
- 模型与 Harness 的边界在哪里。
OpenAI 的 App Server、DeepSeek 的 Cordis 插件体系、Anthropic 的 Claude Agent SDK，以及 MCP / ACP 等协议，本质上都在争夺这一层的生态控制权。
对其他 AI 公司意味着什么？
这次发布会进一步逼迫模型公司回答一个问题：
你的模型除了 API 之外，有没有一套真正成熟、可以拿来干活的 Agent Runtime？
以前模型厂商可以只比较 Benchmark、价格、上下文窗口；但当用户真正开始让 Agent 连续工作数小时甚至数天以后，Context Management、工具调用、Sandbox、权限、恢复机制和可观测性都会变成竞争力。
这意味着未来一家模型公司的产品栈很可能不再只是：
Model → API
而会逐渐变成：
Model → Harness → SDK / Protocol → Agent Apps → Ecosystem
DeepSeek 选择把 Harness 做成极致插件化底座；OpenAI 选择把已经产品化的 Codex Loop 平台化。无论最后哪一种路线占优，都说明Harness 已经正式从“工程实现细节”升级成战略资产。
对普通开发者意味着什么？
最直接的价值，是你以后做一个 Agent 产品，不一定需要从零重新造 Agent Loop。
如果你只需要在 CI 里让 Agent 自动检查或修改代码，可以从 codex exec 开始；如果你的服务端需要启动和恢复任务，可以用 SDK；如果你要做自己的 IDE、运维面板、SRE Agent 或企业工作台，就可以直接围绕 App Server 建客户端。
开发者真正需要投入精力的地方会逐渐从：
“我怎么让模型循环调用工具？”
转向：
“我的业务上下文是什么？什么工具应该暴露？哪些动作必须审批？怎样验证结果？用户应该看到怎样的界面？”
这其实是件好事。大量重复的 Agent 基础设施工作正在被平台吸收，开发者可以把更多时间用在垂直领域价值上。
对普通人意味着什么？AI Agent 可能越来越“不像 AI 产品”
这次平台化对普通用户的影响反而容易被低估。
今天很多人理解 AI Agent，想到的仍然是 ChatGPT、Claude、Codex 这种独立窗口。但如果 Codex Harness 这种平台路线成功，未来你遇到的 Agent 很可能根本不会有一个叫“AI”的独立入口。
它可能直接出现在：
- 财务软件里的“帮我找出异常并解释原因”；
- 物流系统里的“比较恢复方案”；
- WordPress 后台里的“诊断这个站点为什么变慢”；
- 电商后台里的“分析今天退款率异常并给出处理方案”；
- 开发平台里的“修复这个 Issue 并跑完整测试”。
用户看到的还是熟悉的软件，背后却多了一套能够理解环境、调工具、持续执行并申请权限的 Agent Loop。
这也意味着权限、责任和可审计性会越来越重要。当 AI 从“给建议”变成“真的替你执行动作”，一个好的 Harness 不仅要聪明，还必须让人知道它做了什么、为什么做、哪些操作需要批准，以及出了问题能不能追溯。
Codex Harness 会不会压过 DeepSeek Harness？现在下结论太早
如果只看今天的成熟度，Codex Harness 显然领先：它已经支撑 Codex CLI、IDE、Web、App 等多个官方产品，Agent Loop、Sandbox、Approval 和 App Server 都经过了更长时间的真实使用。
但 DeepSeek Harness 的竞争力也非常鲜明：它并没有试图复制 Codex，而是把“可组合性”推得更远——连 Loop、Session、Sandbox 和 UI 都可以作为插件重新组合。
因此，未来很可能形成两种不同吸引力：
- 想快速把成熟 Agent 能力嵌进产品：Codex Harness 更有吸引力；
- 想研究、替换、重新设计 Agent 各个组成部分：DeepSeek Harness 的 Cordis 路线更自由。
真正值得观察的并不是短期 Star 数，而是未来一年：
谁能形成更多第三方应用、插件、Skills、工具适配、企业案例和稳定协议。
我认为这次发布最重要的信号
在过去很长一段时间里，我们会把一个 AI 产品的强弱简单归因于模型。
2026 年以后，这种解释正在越来越不够用。
同一个模型，不同上下文管理方式、不同工具集合、不同 Agent Loop、不同审批策略和不同恢复机制，最终会表现成完全不同的产品。
DeepSeek 在 8 月 13 日把一句话写得非常直接：
Agent = Model + Harness
6 天后，OpenAI 又正式告诉整个开发者生态：Codex 下面那套 Harness，不只是我们自己内部用的实现，你也可以把它当平台。
这两个事件未必存在直接因果关系，但它们在如此接近的时间出现，本身已经非常说明问题。
AI Agent 的下一场核心竞争，正在从模型层向 Harness / Runtime 层外溢。
模型决定一个 Agent 理论上有多聪明，而 Harness 决定这种智能到底能不能被安全、持续、低成本地转化成真实世界里的工作。
如果未来几年 Agent 真正进入企业软件、操作系统、开发环境和普通人的日常应用，那么 2026 年这波“Harness 开源潮”很可能会被回头看成一个非常重要的节点：AI 公司开始不再只卖“大脑”，而是争夺谁来定义智能体的“身体和神经系统”。
相关阅读与资料
- OpenAI Developers：Codex as a platform: build on the open agent harness
- openai/codex GitHub 官方仓库
- OpenAI：Unrolling the Codex agent loop
- OpenAI：Unlocking the Codex harness: how we built the App Server
- Codex App Server 官方文档
- OpenAI：Codex is now generally available（Codex SDK 发布）
- DeepSeek Harness 官方页面
- 吾爱分享：DeepSeek Harness——这个开源 Agent 框架到底强在哪？
评论