OpenAI 将 Codex 的底层核心框架 Agent Harness 开源：你可以轻松将 Agent 接入自己的业务系统

为什么光有模型，还做不成真正的 Agent

一次普通的大模型调用很简单：输入问题，等待回答。可一旦任务从“回答”变成“完成”，缺失的东西会迅速暴露出来。

模型要知道自己正在处理哪个对象；要记得此前做过什么；要读取文件、日志或业务记录；要调用外部工具；要在失败后换一条路线；还要区分哪些动作可以自动执行，哪些动作必须停下来等人批准。任务持续几十分钟甚至跨越多轮时，它还得压缩旧上下文，又不能把早期的重要判断一起忘掉。

Agent Harness 就是负责记住进度、调度工具、限制权限并继续推进任务的执行系统。

Harness 为什么重要，最直接的问题是：同一个模型换一套运行方式，结果会差多少？OpenAI 给出了一个很有分量、但也很容易被滥用的数字。

在 ARC-AGI-3 这套公共任务集里，Agent 要在陌生的交互环境中持续观察、试错并找出规则，因此能否保住此前的判断和行动历史尤其重要。GPT-5.6 Sol 使用 ARC-AGI-3 官方的通用 Harness 时，RHAE（相对人类行动效率）为 13.3%；改为保留此前形成的 reasoning（推理状态），并用 compaction（把旧上下文压成仍可继续使用的摘要）代替简单丢弃最旧内容后，RHAE 升到 38.3%，输出 Token 数降至原来的约六分之一。

背后的机制并不神秘。丢弃 reasoning，相当于让 Agent 每执行一步都重新理解游戏；滚动截断则会让更早的观察和动作逐渐消失。保留推理让计划能够延续，压缩上下文则让 Agent 在长任务中保住关键认识，而不是简单忘掉最旧的内容。

但这个结果只属于特定模型、特定公共任务集和特定评测指标，不能写成“接入 Codex 后所有 Agent 都会提升三倍”。它说明：模型周围的运行架构，也会影响模型最终能发挥出多少能力。

关于 13.3%→38.3% 的完整实验，我们另有一篇拆解：

继续阅读OpenAI 只打开两个 API 设置，GPT-5.6 Sol 在 ARC-AGI-3 的分数从 13.3% 涨到 38.3%模型没换，换的是跑模型的那套程序：保留私有推理 + 用压缩取代删除，每局输出 token 降到约六分之一。→

接进业务系统后，三层分别管什么

知道 Harness 是一套“上岗系统”以后，下一个问题就很实际：把 Codex 接进产品后，宿主应用、Codex app-server 和 MCP 分别负责什么？

这套架构把责任清楚地切成三层，各管一块。

三层不是上下级，而是三种所有权

业务留在应用里，Agent 循环交给 Codex，可信读写由 MCP 接回

宿主应用 掌握业务现场与最终控制

当前对象 · 页面状态 · 业务规则 · 人工批准

↓ 对象、上下文与约束 ↑ 进度、事件与审批请求

Codex app-server 维持 Agent 的运行生命周期

线程与轮次 · 推理循环 · 沙箱 · 流式事件

↓ 工具调用 ↑ 可信结果

应用自有 MCP 把专有系统变成可控工具

可信数据 · 查询工具 · 业务动作 · 权限边界

批准后执行并回写

发布者原始架构图

第一层是宿主应用，也就是你原本的物流后台、工单系统或报税软件。用户选择了哪条告警、哪张工单或哪笔订单，当前页面展示了什么状态，业务允许做什么，哪一步需要人类同意，都由它定义。

第二层是 Codex app-server。它接过这些上下文，保存任务进度，驱动 Agent 持续调用工具，并把执行限制在沙箱和审批规则内。产品也能看到过程、随时中断并回应审批请求。

第三层是应用自有的 MCP 服务，可以把它理解成一组专门给 Agent 使用的业务接口。MCP 不是业务数据库本身；Agent 通过它读取权威记录，也可以请求改订、建单、更新状态等业务动作。只有满足宿主应用的规则和审批条件后，动作才真正发生。

完成后的变化还要回到原来的产品界面。Agent 的结论进入正式业务系统，由原系统继续充当最终记录和控制中心。

这套分工解决了 Agent 产品里最容易混在一起的三件事：

• Codex 负责把任务推进下去；
• MCP 负责把可信数据和受控动作交给 Codex；
• 宿主应用负责告诉两者什么重要、什么允许，以及最终结果应该落在哪里。

从一次性任务到产品功能，三种接法怎么选

大多数任务用不到 app-server。三种接法可以先用一句话记住：脚本或后台任务用 codex exec，业务代码里调用用 SDK，把 Agent 做成产品功能则用 app-server。

codex exec 适合边界清楚的一次性任务，例如在自动化检查流程里审查代码、定时整理记录，或者在后台批量处理一组输入。它既能返回最终文本，也能输出可供程序继续处理的事件或结构化结果。任务启动、运行、结束，生命周期相对简单。

Codex SDK 适合由业务代码直接启动和管理 Codex 任务。应用可以开始新任务，也能继续或恢复过去的工作；产品团队不必自己处理 app-server 的底层协议。

Codex app-server 适合把 Agent 直接做成产品功能。应用可以长期保留任务，看到执行过程，随时中断，临时提供工具，并在 Codex 请求时处理审批。

不要把这三种方式理解成“低配、中配、高配”。选择时只看三个问题：任务是否需要持续状态，产品是否需要观察和干预执行过程，Agent 是否要在用户当前界面里完成有后果的业务动作。

如果只是一次后台分析，直接上 app-server 只会增加集成成本；如果 Agent 要长期存在于运营台里，只靠一条 codex exec 命令又很难承载会话、审批和界面同步。

选择哪一层只是实现问题。更大的产品问题是：这些能力最终应该被放进什么界面？答案未必是再造一个聊天框。

接入 Agent，不等于再加一个聊天框

产品团队接下来要决定的是：AI 应该放在哪里？OpenAI 的答案是，把 Agent 放进工作本来发生的地方，不要给所有软件统一加一个聊天框。

一个脱离业务系统、拿不到当前上下文的通用聊天框，会把整理现场的麻烦全留给用户：请你先把正在处理的订单、页面状态、业务规则和操作目的重新翻译成一段 Prompt。

用户要重新说明自己正在看哪条记录，把看板上的状态复制给模型，再判断模型建议是否基于最新数据。模型给出方案后，用户还要切回业务系统执行。上下文、分析和动作被分散在两个地方，重要边界也很容易在复制粘贴中丢失。

把同一项工作并排来看，差别不在模型会不会回答，而在上下文由谁整理、业务边界从哪里获得，以及结果最终落在哪里。

所以，仪表盘、工单页、报税表格和安全事件队列不会因为 AI 到来就失去价值。它们早已把干活需要的对象、状态、证据和按钮摆在一起。Agent 更合理的位置，是进入这些界面直接使用已有上下文，省掉用户从空白输入框重新描述现场的过程。

聊天当然不会消失。开放探索、模糊问题和临时分析仍然适合对话。应该放弃的，是把通用聊天框当成所有 Agent 产品的唯一形态。

Relay 演示：AI 怎样在物流后台把事情做完

Relay 使用虚构种子数据，不是真实客户系统；它把前面的三层分工和接入方式，落成了一笔完整的物流操作。

从业务对象出发，而不是从空白输入框出发

读、判断、申请、执行、回写，全都发生在原工作流里

01选择异常货物

调度员先选中真实工作对象。

→

02注入页面上下文

路线、承诺时间、货值和异常一起进入任务。

→

03MCP 读取当前记录

Codex 获取可信的运营状态。

→

04调查并比较方案

分析可以自动推进。

↘

人类控制点05人工批准关键写操作

重新订舱、改记录或产生费用时停下。

→

06执行获批动作

只执行被明确允许的变更。

→

07回写并刷新业务状态

结果重新进入系统记录和界面。

Relay 官方演示界面

调度员不是从零写一句“帮我分析物流延误”。他先在异常队列中选择一票货物，再点击“调查延误”或“比较补救方案”。这个点击本身已经交付了业务对象和用户意图，页面则继续提供路线、承诺时间、货值和当前异常等可见上下文。

Codex 随后通过 Relay 的 MCP 工具读取当前运营记录，判断问题发生在哪里，并比较可用方案。分析可以自动进行；但如果下一步是重新订舱、改变业务记录或产生费用，系统就会停下来要求调度员批准。动作获批并执行后，变化重新进入物流记录，业务视图随之刷新。

整个闭环可以压缩成七步：

选择对象 → 注入上下文 → 查询权威数据 → 调查与比较 → 人工批准 → 执行业务动作 → 刷新正式记录

它比“给聊天框接几个工具”多出来的部分，正是产品设计：什么时候自动交付上下文，哪些工具可用，哪种动作有后果，以及人应该在哪里重新接管决定。

类似模式已经进入不同领域。GitHub 与 JetBrains把 Codex 放进现有 IDE 工作流；Cisco在 Cloud Control 的 App Builder 中使用 Codex SDK；Thrive Holdings、Crete 与 OpenAI 则把 Codex 接进报税准备和从业者反馈闭环。

Thrive Holdings、Crete 与 OpenAI 的报税准备试点处理了 7,000 份税表，合作方自报将准备时间缩短了约三分之一。这个数字不是独立第三方评测，但它展示了工作流嵌入的第二层价值：Agent 不只完成一次任务，还能读取生产记录、吸收专家纠正、形成评测任务，再推动下一轮产品改进。

最后说清楚：哪些开源了，哪些没有

还有一个容易被误解的边界：Harness 可以嵌入产品，不等于整套 Codex 都能自由自托管。官方开放的边界没有这么宽。

开发者拿到的是一套可以查看、修改并接进产品的 Agent 执行底座，以及从一次性任务到深度产品集成的不同入口；并没有因此拿到模型和云端服务的开源实现。

更重要的是，Harness 也不会替产品团队生成业务世界。哪张记录是权威数据，哪些工具可以调用，什么动作必须审批，怎样把结果写回系统，这些仍然必须由宿主应用定义。

所以，OpenAI 帮开发者省掉了搭建 Agent 执行底座 的大量工作；业务产品仍要由团队自己做好。差距最终来自对业务的理解，以及能否把数据、工具、权限和人工判断接成一条可靠流程，让 AI 真正在现有系统里把活干完。

延伸阅读：Harness 工程的十二条实践原则。

继续阅读Harness 工程十二条心法：Google 首席工程师一年实践，浓缩成可直接照做的流程和模板核心操作反直觉：选定的模型和 Agent 锁死不动，一个参数都不调，只改它周围的上下文和工具。→