Codex 第 41 课：Codex Harness 到底在做什么——从 CLI、SDK 到一套 Agent 运行层

8 月 19 日，OpenAI 发了一篇《Codex as a platform: build on the open agent harness》。标题里同时出现 Platform、Open 和 Harness，乍看像是在宣布一套刚刚开源的新东西。

这篇文章的分量，在于 OpenAI 把此前分散的组件放回同一张图里，集中解释了自己的平台思路：Codex 不只是一款给程序员使用的 Agent 产品，它还可以成为其他软件里的 Agent 运行层。

这篇文章要回答的也就是两件事：Codex Harness 到底负责什么，它进入其他产品以后，会改变什么。

这不是一次从零开始的开源

先把时间线理清楚。

2025 年 4 月，Codex CLI 的开源仓库已经出现。8 月，Codex 进入 VS Code、Cursor 和 Windsurf 等 IDE。9 月底，TypeScript SDK 的脚手架和 App Server 已经进入公开仓库。10 月 6 日，Codex 正式版发布，OpenAI 同时对外推出 Codex SDK，让开发者可以在自己的工具和工作流里调用同一个 Agent。

到了 2026 年 2 月，Codex App 上线。CLI、IDE 扩展、SDK、App Server 和桌面应用已经逐渐形成了一套产品体系。

因此，2026 年 8 月这篇文章不能被写成“Codex Harness 突然开源”。更准确的说法是：OpenAI 把过去一年陆续开放的 CLI、SDK 和 App Server，统一定义成一套 open agent harness，并明确把它们当作平台能力向外提供。

这次变化更像一次正式定调。

以前开发者看到的是几个入口。CLI 可以在终端里执行任务，SDK 可以被程序调用，App Server 可以支撑 IDE 一类的深度客户端。现在 OpenAI 把这些入口背后的共同部分说清楚了：它们都建立在同一套 Agent 循环上，聊天界面只是外层呈现。

Harness 是模型外面的执行系统

只调用一次模型，流程很简单：把问题发过去，等它返回一段文字。

真正能做事的 Agent 要复杂得多。它需要理解当前任务，读取相关文件和业务数据，决定下一步调用什么工具，把工具返回的真实结果放回上下文；如果任务很长，还要压缩上下文、保留进度、处理失败，并在危险动作发生前向人申请批准。

这些工作不会由模型权重自动完成。模型可以判断“下一步应该运行测试”，但测试在哪里运行、能访问哪些目录、结果怎样传回来、失败后是否重试，仍然要有一套执行系统负责。

这套包在模型外面的系统，就是 Harness。

放到 Codex 里看，它主要处理几件事：

• 保存 Thread 和多轮任务状态；
• 把模型输出、命令执行和工具调用持续变成事件；
• 在沙箱里执行文件、Shell 和网络操作；
• 根据权限策略发起审批；
• 在上下文变长时进行压缩，让任务可以继续；
• 把执行结果重新交给模型，进入下一轮判断。

所以，同一个模型放进不同 Harness，最终效果可能相差很大。OpenAI 在原文里给了一个 ARC-AGI-3 的例子：保留推理状态并进行上下文压缩后，GPT-5.6 Sol 的分数从 13.3% 提高到 38.3%，输出 Token 同时降到原来的六分之一。

这个数字来自特定模型和评测，不能直接换算成企业项目的收益。但它说明了一件事：模型能力相同，状态怎么保留、上下文怎么整理、工具结果怎么返回，仍然会明显影响任务结果。

过去我们总把 Agent 好不好用归因于模型够不够聪明。以后更现实的问题会是：模型有没有拿到正确上下文，工具是不是可靠，任务中断后能不能恢复，权限和审批有没有真正落到执行层。

一张图看懂 Codex Harness 的位置

OpenAI 原文里最有价值的是下面这张架构图。

左边是企业自己的应用。它掌握产品界面、用户当前正在处理的业务对象、可见状态、业务规则和用户授权。

中间是 Codex App Server。它负责 Agent Loop、线程与回合、流式事件、沙箱执行和运行时审批。

右边是应用自己管理的 MCP 服务。它向 Agent 提供可信数据和业务动作，例如读取订单、查询告警、创建工单、调整一票货物的运输方案。

这套分工很重要，因为 OpenAI 没有把 Codex 画成业务系统的主人。

拿客服退款来说，客户资料、订单状态、退款政策和员工权限仍然属于原来的系统。Codex 可以调查问题、查询日志、整理证据、生成处理建议。是否退款、最多退多少、谁有权批准，必须由业务系统决定。批准后的结果也要写回订单或工单系统，不能只留在一段 Agent 对话里。

安全调查也是一样。Codex 可以汇总告警、检查提交记录、定位受影响服务。封禁账号、回滚生产环境、关闭外部访问，仍然应该有清楚的权限和复核流程。

我认为这才是 Codex Harness 对企业最有价值的地方。它没有要求企业把工作全部搬进 Codex，而是让 Codex 进入工作本来发生的地方。界面、业务规则和正式记录继续由企业掌握，Agent 专心处理调查、推理和受控执行。

三种接入方式，其实对应三种产品深度

OpenAI 把接入方式分成三层。

codex exec 最轻。它适合脚本、CI 任务和一次性后台工作。系统给 Codex 一个范围清楚的任务，它完成后返回结构化结果。例如检查一次代码改动、生成发布说明，或者在合并前跑一次 Agent 审查。

Codex SDK 再深一层。应用代码可以启动任务、继续同一个 Thread、恢复历史任务并接收流式事件。它适合内部工具、自动化平台和需要程序控制的 Agent 工作流。开发者不必直接处理 App Server 的全部协议细节。

App Server 最深。Agent 已经成为产品体验的一部分时，产品需要自己展示进度、处理中断、暴露工具、接住审批请求，并决定每类事件在界面上怎样呈现。这时使用 App Server，产品团队得到的控制更多，承担的集成工作也更多。

App Server 公开的是一套双向协议。里面最核心的三个对象是 Thread、Turn 和 Item。

Thread 是一段可以持续的任务。Turn 是其中一次用户输入到 Agent 返回结果的过程。Item 则是过程里的具体事件，可以是一段 Agent 消息、一次命令执行、一处文件修改或一个工具调用。

这意味着产品不必等到最后才拿到一句“任务完成”。它可以实时告诉用户 Codex 正在查什么、运行了什么命令、修改了哪些文件，在哪里被权限挡住。出现高风险动作时，流程暂停，用户看清内容以后再决定是否继续。

SDK 解决的是“怎样方便地调用 Codex”，App Server 解决的是“怎样把 Codex 做成产品的一部分”。两者都不是这篇文章发布当天才出现，这次的新意在于 OpenAI 把它们放进了一套明确的集成层级。

Relay 展示了 Agent 产品可能长什么样

原文用 Relay 做了一个演示。它是一套使用虚构物流数据的运营应用，不是真实客户案例。

界面左边是货物异常、路线进度和运营数据，右边是 Codex。用户先选中一票延误货物，再点击“调查延误”或“比较恢复方案”。应用自动把当前货物、可见状态和任务意图交给 Codex。

Codex 通过应用管理的 MCP 工具查询最新记录，寻找延误原因，比较可行方案。只读调查可以直接进行；如果要重新预订运输方案，这个有实际后果的写操作必须等待人工批准。批准以后，Codex 才能调用工具修改记录，业务界面随后刷新。

这个例子最值得注意的细节，是用户没有从空白聊天框开始。

“比较恢复方案”这个按钮已经包含任务意图，当前选中的货物提供了业务对象，页面提供了现场信息。用户不必重新写一段提示词，解释自己正在看哪一票货、哪里出了问题、希望得到什么结果。

这也说明，Agent 产品的入口未必是聊天框。它可以是告警旁边的“调查原因”，工单里的“生成处置建议”，合同页面上的“检查风险”，或者任务卡片上的“开始实现”。输入框仍然可以保留，但它不再负责承载全部上下文。

它会带来什么影响

Agent 的竞争会从模型扩展到运行系统

模型仍然重要，但真实任务还要比较上下文管理、工具质量、沙箱、审批、事件流、任务恢复和可观测性。以后企业选择 Agent 平台，不能只看一次回答或一张榜单，还要看它是否能在受控环境里把长任务做完。

现有软件会直接长出 Agent 能力

过去两年，不少 AI 产品都在争夺一个新的聊天入口，希望用户把工作搬进去。Codex Harness 指向另一条路：运营人员继续用运营后台，安全团队继续看调查控制台，客服继续处理工单，只是在原来的页面里多出一个能调查、建议并执行获批动作的 Agent。

对 SaaS 厂商和企业软件团队来说，这比再做一个通用 AI 助手更实际。已有产品本来就掌握用户身份、业务对象、权限和记录，缺少的是一个可以持续完成认知任务的运行层。

Harness 会成为企业 AI 交付中的公共基础设施

代码审查、告警调查、客服诊断和研究任务，业务界面不同，底层都需要线程、事件、工具、权限和审批。如果这部分能被统一，平台团队就不必为每个场景重新造一次 Agent Runtime，业务团队可以把精力放在数据、工具和验收标准上。

这也会让新的治理问题浮出来。公共工具由谁维护，权限模板由谁定义，App Server 升级后谁负责兼容，Agent 的运行记录保存多久，一次错误动作怎样追溯和补偿，这些都不是开源代码自动解决的。

业务界面会变成上下文工程的一部分

页面当前选中了什么，哪些字段可信，哪些操作可用，哪个动作需要批准，本身就是上下文。好的 Agent 产品不会让用户每次重新描述现场，也不会把所有规则拼成一段越来越长的提示词。业务对象、界面状态、工具定义和权限策略会一起决定 Agent 看见什么、能够做什么。

还要看清几条边界

Codex Harness 开源，不等于 Codex 模型开源。官方文章说得很清楚：开放的是 Harness 和集成面，模型访问与托管服务仍然是另外一层。

开源也不等于拿来就能进入生产。企业仍然要固定版本、测试协议兼容性、限制工具权限，并为高风险动作设置审批和回滚。App Server 当前部分远程传输能力仍标为实验性，也不适合在没有额外安全设计的情况下直接暴露到公网。

它同样不会替企业定义业务事实。订单以交易系统为准，客户状态以 CRM 为准，代码结果要经过测试。Agent 能调用工具，只能证明动作执行过，不能自动证明业务结果正确。

最后，它也不是完整的业务工作流引擎。一个任务如果要等待几天审批、处理外部事件、超时升级和失败补偿，仍然需要业务系统或工作流平台接住。Codex 更适合作为其中负责理解、调查和执行的一部分。

真正值得关注的是平台化

回到这篇文章本身，它的分量不在于新增某个 SDK，也不在于突然放出一批代码。

OpenAI 做的事情，是把 CLI、SDK、App Server 和它们背后的 Agent Loop 统一成一套平台叙事。开发者可以从 codex exec 开始做一次有边界的任务，也可以用 SDK 组织程序化流程，还可以用 App Server 把 Codex 嵌进自己的产品。

我的判断是，Codex 正在从一款编程 Agent，向一套可被其他软件调用的 Agent 运行层移动。

这不会让企业落地突然变简单。真正困难的工作仍然是定义业务上下文、做可靠工具、划清权限、设计审批、建立验收和回滚。但至少从现在开始，团队不必把每个 Agent 都从“提示词加模型接口”重新造起。那套负责状态、工具、执行和边界的公共部分，已经有了一套可以检查、接入和改造的实现。

这才是 Codex Harness 这次最值得看的地方。

原文信息

作者：马振原（@ma_zhenyuan） 原文：X Article 2090669090642006364 原文地址：https://x.com/ma_zhenyuan/status/2090669090642006364