本文永久链接 – https://tonybai.com/2026/08/24/codex-as-a-platform-open-agent-harness

大家好，我是Tony Bai。

【导读】

在三大模型厂商的编程 Agent 竞赛里，Anthropic 的 Claude Code、Google 的 Antigravity（前身 Gemini CLI）都是闭源产品，只有 OpenAI 的 Codex 用 Rust 重写并全面开源。近日 OpenAI 开发者博客发文《Codex as a platform：build on the open agent harness》，第一次系统性地把 Codex 拆成“Harness”与“应用层”两部分，告诉所有开发者：你不需要再造一个聊天框，直接把这台引擎装进你自己的产品就行。并给出三种官方集成路径。

【文章要点】

  • 唯一开源牌：三大厂商编程 Agent 中，只有 Codex（Rust 重写）开源，Claude Code、Antigravity 均为闭源。
  • 核心结论：Codex App、CLI、IDE 插件只是三种呈现方式，真正可复用的是底层的 Agent 循环（harness），已经开源。
  • 三条集成路径示例：codex exec（无交互批处理）、Codex SDK（程序化调用）、app-server（长连接 + 流式事件 + 审批），分别对应脚本任务、应用集成、产品级嵌入三种场景。
  • 一个真实证据：在 ARC-AGI-3 测试中，仅靠"Harness"层面的上下文压缩与推理保留优化，GPT-5.6 Sol 的分数就从 13.3% 提升到 38.3%，token 消耗还降低到 1/6——说明Harness和模型同样重要。
  • 落地案例：GitHub、JetBrains、Cisco、Thrive Holdings 等已经把 Codex 嵌进各自的 IDE、云控制台、报税工作流中，验证了“Agent 进产品，而不是产品进 Agent”的思路。

三大厂商，三种选择，唯独 Codex 开源

目前编程 Agent 赛道上活跃的三个重量级选手是：Anthropic 的 Claude Code、Google 的 Antigravity（前身 Gemini CLI），以及 OpenAI 的 Codex。前两者都是闭源产品，企业只能在官方划定的边界内使用；而 Codex 在 2025 年用 Rust 重写核心后，选择了一条完全不同的路——把驱动 App、CLI、IDE 插件的底层系统全部开源，代码仓库就放在 openai/codex，Apache-2.0 协议。

这个选择正在换来实实在在的市场份额增长。而就在近期，OpenAI 开发者博客发布了一篇态度鲜明的文章——《Codex as a platform：build on the open agent harness》，第一次把“为什么开源”和“开源之后能干什么”讲清楚了。

这篇文章的核心论点只有一句话：你平时用的 Codex App、命令行、IDE 插件，只是同一套底层系统的三种Harness，而这套系统本身是开放的、可以被搬进任何产品里的。

从“三个客户端”到“一个可复用的 Agent Harness”

大多数人对 Codex 的认知，停留在 App、命令行（CLI）、IDE 插件这三种交互形式上。OpenAI 在文章里明确指出，这三者只是冰山一角——真正驱动它们的，是开源的 Codex harness。

“Harness”这个词在这里可以理解为“智能体的运行Harness”或者“执行框架”。它负责：

  • 帮模型收集上下文；
  • 在多轮任务中维持状态、推进思考；
  • 调用工具、读写文件、执行命令；
  • 在配置好的边界内运行，必要时向人类请求批准；
  • 把一次任务的产出，衔接到下一次任务里。

按照 OpenAI 的说法，这一层过去是“藏”在产品背后的私有能力，现在被拿出来公开，开发者可以直接检查它、理解它的行为，并按自己产品的需要改造这层“胶水”。

这意味着，OpenAI 想传达的信息是：不要逼着每个团队都把工作流搬进一个通用的编程助手里，而是把 Agent 能力嵌进团队本来就在用的软件——工程工作流、运维看板、安全事件调查台、客服控制台，或者任何一个为某个具体岗位定制的内部系统。

拆开Harness看看：Agent 循环里到底装了什么

OpenAI 把一个“够格”的 Agent 需要具备的能力列得很直白：理解任务、维持长期上下文、检索相关信息、调用工具、暴露执行进度、处理失败、在必要时请求人工审批、最终返回一个有用的结果。

围绕这套能力运转的执行系统，就是 harness。Codex harness 具体负责：

  • 管理对话状态（conversation state）；
  • 流式执行（streaming execution）；
  • 工具调用；
  • 按配置好的沙箱与审批策略执行任务；
  • 在多轮对话之间承接上下文。

而 Codex app-server 把这些能力包装成一份文档化的客户端协议：应用可以创建会话线程（threads）、发起一轮任务（turns）、接收事件流，并处理审批请求。换句话说，如果你的软件需要一个 Agent，不用再从零造一个运行时，直接接入 Codex，再决定“应用层”要自己掌控哪些部分。下面示意图展示了“应用层（界面、业务上下文、审批）、Codex app-server（Agent 循环、沙箱执行）和 应用自有的 MCP 数据与动作”三段式架构。

一个容易被忽略的数据：Harness设计本身就能大幅提升模型表现

文章里提到一个很值得单独拎出来说的数据：在 ARC-AGI-3 测试中，仅仅是调整Harness层面的两个设置——保留推理内容（retained reasoning）和上下文压缩（context compaction）——GPT-5.6 Sol 的得分就从 13.3% 提升到了 38.3%，接近翻三倍，同时输出 token 消耗还降低到原来的六分之一。

这组数字说明一件事：模型能力固然重要，但“怎么把上下文喂给模型、怎么在多轮任务里维持状态、什么时候该压缩历史”这些看似工程细节的问题，同样能决定 Agent 的最终表现上限。这也是 OpenAI 强调“harness 值得被开源、被审视、被改造”的底气所在——它不是一层无关紧要的壳，而是直接影响结果的关键变量。

三条集成路径：脚本、应用、产品，怎么选

OpenAI 没有要求所有开发者用同一种方式接入 Codex，而是按照场景给出了三条路径：

集成方式 适用场景 特点
codex exec（非交互模式） 脚本、CI 任务、一次性后台工作 运行一个有边界的 Agent 工作流，返回结构化结果，不需要维持会话
Codex SDK 应用代码需要启动、恢复、流式获取 Codex 任务 提供直接的程序化接口，适合把 Agent 能力嵌进已有系统
Codex app-server Agent 本身就是产品的一部分 支持本地进程连接、长会话、流式事件、中断任务、暴露工具、处理审批请求

用 OpenAI 原文的说法：“SDK 简化常见的程序化工作流；app-server 则把生命周期和用户体验的控制权直接交给产品团队。”

这三层刚好对应从“跑一次任务”到“嵌入一个持续运行的产品体验”的复杂度递增。想快速试一下效果，从 codex exec 开始；要往现有系统里接 Agent 能力，用 SDK；要做一个“Agent 常驻在界面里”的产品，用 app-server。

示例应用 Relay：把 Agent 嵌进一个虚构的物流运营看板

为了把这套理念落到实处，OpenAI 团队自己动手做了一个示例应用 Relay——一个基于 Codex app-server 搭建的虚构物流运营看板。

它的交互逻辑很有代表性：用户不是从“打开一个空白对话框、自己写 prompt”开始的，而是先在看板上选中一个具体的运单，点击一个业务动作，比如“比较恢复方案（Compare recovery）”。这时应用会把相关上下文喂给 Agent，Codex 通过应用自有的 MCP 工具拉取最新的运营数据，解释可选方案；如果这个动作会产生实质性影响（比如重新预订一批货物），就必须经过人工审批才能执行。执行完成后，应用会刷新自己的业务视图——Agent 循环、对话状态、流式动作都由 harness 负责，产品始终掌控着自己的看板、记录和控制权。

Relay 用的是虚构的种子数据，但这套集成模式是通用的——同样的思路可以套用在事件响应、账户运维、调研工作流，或者任何“Agent 应该在一个已有产品体验里工作”的场景上。

已经在发生的事：谁在真实落地这套模式

文章列举了几个已经公开的实践案例：

  • GitHub 和 JetBrains：把 Codex 作为 Agent 提供方接入现有的 IDE 工作流；
  • Cisco：在 Cisco Cloud Control 的 App Builder 中使用 Codex SDK；
  • Thrive Holdings 与 Crete：把 Codex 用在一个融入了从业者反馈的报税工作流里，试点处理了 7000 份报税单，准备时间缩短了约三分之一。

OpenAI 特别强调，这套模式不局限于工程团队——客服团队排查客户问题、运维团队协调工作流、安全团队分诊事件、销售团队调研客户、市场团队筹备campaign，都是同一个模式：应用提供上下文、工具和审批环节，Codex 负责底层的 Agent 循环。

开源 vs 闭源：这对 Claude Code、Antigravity 意味着什么

回到开头的问题：为什么这篇博客值得被认真对待？

因为它把“开源”这件事从口号变成了一套可操作的分层架构——Harness开源、集成路径公开、示例应用可参考、真实客户案例可查证。对企业和开发者来说，这直接决定了几件事能不能做：

  • 能不能审查它的行为：闭源的 Claude Code、Antigravity 是黑箱，你只能相信厂商的产品设计；Codex harness 可以被直接检查、调试、二次开发。
  • 能不能按自己的产品重塑交互：闭源方案通常意味着你只能用官方给的界面；开源的 harness 让团队可以保留自己已有的看板、编辑器、审批流，把 Agent 作为能力嵌入进去，而不是被迫迁移到一个新的通用聊天界面。
  • 能不能掌控运行边界：沙箱策略、审批规则、可访问的工具和数据，这些“运行时决策权”留在了应用手里，而不是被厂商的产品设计代劳。

当然，需要说明的是，开源的只是“Harness与集成层”，模型访问权限和托管服务本身仍然是独立的、闭源的部分——OpenAI 在文中也明确划清了这条线。这不是“完全开源”的叙事，而是“把可复用、可审查的工程部分开放出来，把真正的护城河（模型）留在自己手里”的务实策略。这也解释了为什么开源没有削弱 OpenAI 的商业模式，反而可能通过更广泛的生态集成，扩大 Codex 的分发面。

给开发者的行动清单

如果读完想立刻上手，可以按这个顺序推进：

  1. 先去看一眼 openai/codex 仓库，了解 harness 的整体结构；如果你对Rust语言不是很了解，可以看看我的《Rust 第一课》长专栏。
  2. 明确自己的场景属于哪一类：一次性脚本任务 → codex exec；已有系统要接入 Agent 能力 → Codex SDK；要做一个 Agent 常驻的产品体验 → app-server；
  3. 参考 开源组件清单，确认自己需要用到的组件（CLI、SDK、app-server、Skills、Plugins）分别在哪个仓库；
  4. 如果打算做产品级集成，读一遍 Relay 的设计思路，想清楚自己的“应用层”要保留哪些界面、暴露哪些 MCP 工具、在哪些动作上设置人工审批。

小结

三大模型厂商在编程 Agent 赛道上的路线分化，正变得越来越清晰：Anthropic 用 Claude Code 巩固闭源产品体验的护城河，Google 把 Antigravity 收进自己的生态位，而 OpenAI 选择把最容易被复制、最应该被信任的那部分——Agent 的执行Harness——开放出来，换取更广的生态位和更快的集成速度。

这篇博客与其说是一次产品发布，不如说是 OpenAI 对“编程 Agent 的下一阶段应该长什么样”给出的一份路线图：Agent 不该是一个必须打开的新窗口，而应该是任何产品都能装进去的一个引擎。

至于这条路线最终能不能真正撬动 Claude Code 和 Antigravity 把守的市场，还要看开发者用脚投票的结果。

延伸阅读

还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：

  • 抛弃臃肿框架，回归“驾驭工程 (Harness Engineering)”的第一性原理
  • 用 Go 语言手写 ReAct 循环、并发拦截与上下文压缩引擎等，复刻极简OpenClaw
  • 构建坚不可摧的 Safety Middleware 与飞书人工审批防线
  • 在底层实现 Token 成本审计、链路追踪与自动化跑分评估
  • 从“调包侠”进化为掌控大模型边界的“AI 操作系统架构师”

扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。

还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：

  • 告别低效，重塑开发范式
  • 驾驭AI Agent(Claude Code)，实现工作流自动化
  • 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码，开启你的AI原生开发之旅。

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。