OpenAI 全面开放 Codex Harness：Agent 终于走出聊天框
OpenAI 开放 Codex Harness、CLI、SDK 与 App Server。本文从架构、ARC-AGI-3 实验、企业案例和安全边界解释：为什么 Agent 正在走出通用聊天框。
OpenAI 全面开放 Codex Harness：Agent 终于走出聊天框
这次没有新模型，也没有更长的上下文窗口。但对真正做产品的人来说，OpenAI 开放 Codex Harness 的影响可能比一次模型升级更深：Codex 不再只是终端、IDE 或桌面 App 里的一个成品助手，而开始变成可以嵌进别的软件里的执行层。
过去两年，AI 产品有一个偷懒的默认答案：在原来的软件旁边塞进聊天框。客服、财务、安全运营和开发工具最后都长得差不多——用户先把业务上下文翻译成 Prompt，再跟模型来回“拉扯”。这看起来通用，实际上把最重要的东西丢了：业务界面本身就是上下文，按钮代表允许的动作，列表代表当前状态，权限系统代表谁能做什么。
Codex Harness 开放的真正意义，不是“人人都能再做一个 Codex”，而是开发者可以保留自己的界面、数据模型和审批规则，只把困难的 Agent Loop 交给 Codex。
先说结论
- 开放的是 Apache-2.0 许可的
openai/codex仓库、CLI、SDK、App Server 与底层 Harness；不是 Codex 桌面 App 的 UI，也不是模型权重。codex exec适合一次性自动化，TypeScript/Python SDK 适合程序化集成，App Server 适合做完整的产品级客户端。- Harness 管理上下文、工具、Sandbox、事件、审批与恢复。它不是模型外面的一层“胶水”，而是 Agent 能否可靠工作的关键变量。
- OpenAI 的 ARC-AGI-3 实验显示，只调整推理保留与上下文压缩，GPT-5.6 Sol 的得分就从 13.3% 升到 38.3%，同时输出 Token 减少约 6 倍。
- 开源降低了集成门槛，却不会替你解决身份、隔离、最小权限、审计和结果校验。企业落地最后一公里仍属于宿主产品。
这次真正开放的，不是一个聊天框
App Server 与 Harness 位于开放的 Codex 仓库中；它和未开放源码的桌面 App UI 是两个边界。
公开的 openai/codex 仓库采用 Apache-2.0 许可。开发者可以阅读、修改和商用仓库里的实现。OpenAI 在 App Server 架构文章中说明，Codex 的 Web、CLI、IDE 与桌面端共享同一套底层 Harness，App Server 则把这套能力整理成客户端可消费的双向协议。
OpenAI 将 App Server 定义为客户端连接共享 Codex Harness 的桥。来源：OpenAI，截图于 2026 年 8 月 22 日。
边界必须说清楚：桌面 App 的 UI 没有随之开源，GPT-5.6 Sol 也不是开放权重模型。准确说法是“你可以用开放 Harness 构建自己的 Codex 客户端和工作流”，不是“可以 fork 整个 Codex 产品”。开源软件本身也不等于模型推理、托管计算或企业支持免费。
Harness 到底是什么：模型之外那台真正的机器
把 Agent 理解成“模型 + Prompt”，就像把数据库理解成“硬盘 + SQL”。Demo 也许能跑，生产系统一定会暴露缺失的部分。
一个能够连续工作几十分钟的 Agent，至少要处理这些事情：
- 把用户目标拆成多个 Turn，并保存可恢复的 Thread；
- 在上下文越来越长时决定保留、压缩还是丢弃什么；
- 发现工具，验证参数，执行命令，收集标准输出和文件差异；
- 在 Sandbox 与网络策略内运行，而不是拿着宿主机全部权限；
- 把计划、消息、命令、diff、失败和完成状态持续流给 UI；
- 遇到高风险动作时暂停，请求人类或策略引擎审批；
- 在进程崩溃、网络断开或用户打断后继续，而不是从零再来；
- 最后验证结果是否真的满足业务目标，而不只相信模型说“完成了”。
这些能力合在一起，才是 Harness。模型负责推理和生成下一步动作；Harness 决定模型能看到什么、能做什么、做完后发生什么。它既是执行框架，也是上下文管理器、安全边界和观测接口。
两个设置，为什么能让得分接近翻三倍
OpenAI 专门研究了推理保留与上下文压缩对 ARC-AGI-3 的影响。来源：OpenAI，截图于 2026 年 8 月 22 日。
OpenAI 在 2026 年 7 月公布了一组很适合解释 Harness 价值的实验。同一个 GPT-5.6 Sol，在通用 Harness 上参加 ARC-AGI-3 公共任务集，RHAE 得分为 13.3%；开启两项设置后，得分达到 38.3%。估算的人类测试者基线是 48%。
| 系统设置 | ARC-AGI-3 RHAE | 变化 |
|---|---|---|
| 通用 Harness | 13.3% | 基线 |
| 保留推理 + 上下文压缩 | 38.3% | 接近 2.9 倍 |
| 输出 Token | 约为原来的 1/6 | 成本与冗余同时下降 |
第一项调整是保留模型的私有推理状态，避免每一步都把前面的思考切断；第二项是压缩上下文，在窗口接近上限时整理关键信息，而不是简单滚动截断。模型没换，任务没换，系统行为却明显不同。
这不能被写成“AI 突然聪明了三倍”。更准确的结论是：Agent 基准测到的是“模型 × Harness × 配置”的联合结果。选择模型固然重要，但上下文如何延续、工具结果如何回灌、何时压缩，同样会决定能力上限和 Token 成本。
三个开放入口，对应三种集成深度
OpenAI 没有要求所有开发者都从 App Server 起步。Codex 现在给出三个层次不同的入口。
| 入口 | 最适合 | 你需要管理什么 |
|---|---|---|
codex exec | CI、脚本、一次性后台任务 | 输入、运行边界和结构化结果 |
| Codex SDK | 在 TypeScript 或 Python 服务中启动、恢复、流式读取任务 | Thread 生命周期、应用状态与错误处理 |
| Codex App Server | IDE、桌面端、运维看板等完整交互产品 | 进程、协议版本、事件 UI、审批与权限 |
codex exec 是最短路径：让 Agent 在明确边界内完成一个任务并退出。SDK 则把线程与流式事件带入应用代码；当前仓库同时提供 TypeScript SDK 和 Python SDK。如果产品需要持久对话、中途干预、工具展示和人类审批，App Server 才是完整入口。
这三者不是“低配、中配、高配”的排名，而是部署形态。一个成熟系统很可能同时使用：PR 检查走 exec，批量任务走 SDK，本地工程客户端走 App Server。
App Server：把 Agent Loop 与产品界面拆开
App Server 是长期运行的进程。它在 Codex Core 上管理 Thread，把底层事件翻译成客户端协议，再通过 JSONL-over-stdio 与应用双向通信。官方把协议的核心原语归纳为 Item、Turn、Thread：
| 原语 | 表示什么 | 产品如何使用 |
|---|---|---|
| Item | 消息、命令、diff、工具调用等可展示单元 | 渲染进度和结果 |
| Turn | 用户输入触发的一次工作 | 启动、追加指令、中断并判断完成 |
| Thread | 多个 Turn 组成的持久会话 | 新建、恢复、分叉和读取历史 |
| Approval | 服务端发起的关键控制请求，并非第四个顶层原语 | 展示风险，允许、拒绝或交给策略判断 |
这一点比术语更重要：Agent 不再只能返回一段最终文本。产品可以知道它正在读哪个文件、准备执行什么命令、产生了哪份 diff、为什么停下来以及谁批准了下一步。
业务应用 codex app-server
|--- initialize -------------------->|
|<-- 能力与版本 ----------------------|
|--- thread/start ------------------>|
|--- turn/start + 当前业务上下文 ---->|
|<-- item：计划、命令、diff、消息 -----|
|<-- approval：请求执行高风险动作 -----|
|--- allow / deny / policy -------->|
|<-- turn/completed + 结果 ----------|稳定默认传输是 stdio，协议是 JSON-RPC-like，而非可原样套用的标准 JSON-RPC 2.0：线上消息省略了 jsonrpc 字段。WebSocket 与远程 daemon 仍被官方标为实验能力。做 Web 产品时，更安全的做法是在隔离工作空间旁启动 App Server，由可信后端管理进程并把净化后的事件转给浏览器，而不是把本地 Agent 端口直接暴露出去。
“告别聊天框”不等于不要界面，而是把界面还给业务
通用聊天框的问题不在于“聊天”本身，而在于它要求用户手工搬运上下文。
安全分析师面对的是告警队列、受影响服务和处置记录；税务师面对的是表格、凭证和异常字段；物流人员面对的是延误订单、路线与承运商报价。这些页面并不是 Agent 外面的装饰，它们已经表达了对象关系、当前选择、权限和下一步动作。
更自然的 Agent 产品应该这样工作：用户在业务界面选中对象，点击一个有明确含义的动作；宿主应用自动组装已授权上下文；Harness 规划并调用工具；所有写操作经过策略或人工审批；完成后更新原来的业务状态。聊天可以作为补充输入，但不必霸占整个产品。
例如在物流看板中，“比较恢复方案”比空白 Prompt 更好。系统已经知道延误的是哪票货、交付承诺是什么、有哪些候选路线。Agent 的价值是调取最新数据、分析约束并提出可审计的方案，而不是让操作员把屏幕内容重新讲一遍。
7,000 份税表：垂直 Agent 的价值不在会聊天
OpenAI 与 Thrive Holdings、Crete 公开的 Tax AI 案例展示了另一种路径。过去六个月，他们与 30 多家会计事务所合作；试点季处理了 7,000 份税务申报表，税务准备时间节省约三分之一，吞吐量提升约 50%，草拟申报表准确率最高达到 97%。
更值得注意的是改进闭环：从税务师的修改中提取失败模式，把生产轨迹转成评测，再用 Codex 辅助修复工作流。六周内，字段完成准确率达到 75% 的申报表占比从 25% 提高到 86%。
这个案例不能被偷换成“App Server 已经帮企业自动报税”。官方文章描述的是更广泛的 Codex 驱动生产系统，而且税务结果仍由专业人士审核。它真正说明的是：垂直 Agent 的护城河来自业务数据、反馈闭环、评测和审批，而不是一个更会说话的聊天窗口。
企业真正要补的最后一公里
Harness 帮你省掉大量 Agent Loop 工程，但下面这些责任不会消失：
- 身份映射：每个 Thread 必须知道最终用户、租户与服务身份，不能共享模糊的“系统账号”。
- 隔离与最小权限：工作空间、网络和凭证按任务发放，用完即撤销；不要把生产密钥当环境背景噪声注入。
- 可读审批：审批框要展示准确命令、工作目录、目标资源和预期影响，而不是只写“AI 需要权限”。
- 幂等与恢复：重试发邮件、付款或写数据库时，必须识别已完成动作，避免一次超时变成两次执行。
- 审计链：保存请求、上下文来源、工具参数、批准者、执行结果和最终变更；日志还要进行敏感信息脱敏。
- 结果验证：命令退出码为 0 不等于目标完成。测试、Schema、业务不变量和人工抽查必须在模型之外运行。
- 版本策略：固定 Codex 二进制，使用同版本生成的 TypeScript/JSON Schema，并为未知事件保留向前兼容路径。
最危险的产品不是完全自动化的 Agent，而是看起来有“人类审批”，实际审批者看不到风险上下文的 Agent。界面一旦隐藏关键细节，就会让 Human-in-the-loop 退化成条件反射式点击。
App Server、MCP 与 Agents SDK 怎么选
| 接口 | 最适合 | 主要代价 |
|---|---|---|
| Codex App Server | 完整 Codex 会话、工具、审批、Skill 和事件体验 | 绑定 Codex 协议与进程生命周期 |
| Codex MCP Server | 让其他 MCP Host 把 Codex 当成一个工具 | 丰富事件会被压缩为 MCP 语义 |
| OpenAI Agents SDK | 应用自己定义多 Agent 编排 | 代码仓库工作流与客户端体验需要自建 |
| 跨厂商协议 | 一个控制面连接多个 Harness | 通常只能覆盖共同子集 |
没有统一赢家。深度 IDE 或本地工具更需要原生 Codex 事件；跨厂商控制面更重视可移植性；服务端业务编排可能直接用 SDK。真正需要警惕的是，产品表面宣称“通用”，底层却偷偷依赖某一家特有的审批与会话语义。
一份务实的 30 天落地路线
第一版不要复制完整 IDE，也不要一上来做“全自动数字员工”。选一个高频、可验证、出错可回滚的窄任务，例如只读代码审查：
- 第 1 周：用
codex exec跑通单仓库任务，确定输入、输出与验收标准； - 第 2 周：接 App Server，渲染 Item、Turn 状态、命令与 diff；
- 第 3 周：加入一次性工作空间、网络策略、命令审批和完整审计；
- 第 4 周：用真实失败样本做评测，验证中断、恢复、超时和重复执行。
成功指标也不应是“对话轮数”或“生成 Token 数”，而应该是任务完成率、人工修改量、首次通过率、平均恢复时间和每个成功结果的成本。
结论：真正被开源的是产品可能性
Codex Harness 不会让每个应用一夜之间变成可靠 Agent，也不会消灭专业界面。恰恰相反，它让那些专业界面重新变得重要：产品继续掌握用户身份、业务状态、数据与审批，Codex 在底层负责推理、工具与长任务执行。
这比“给所有软件加聊天框”更难，却也更有价值。聊天框易复制，围绕真实工作设计的上下文、权限、反馈闭环和结果验证不易复制。
如果你准备把 App Server 放进完整系统，建议继续阅读生产级 Agent 为什么需要 Runtime 层和工具调用前授权。可靠起点仍然很朴素：stdio、固定版本、自动生成 Schema、隔离工作空间，以及一个真正能让人看懂风险的审批界面。
FAQ
Codex 桌面 App 和模型权重开源了吗？
没有。公开仓库包含 Codex CLI、SDK、Harness 组件与 App Server；桌面 App UI 和模型权重不在这次开放范围内。
Codex SDK 支持哪些语言？
当前 openai/codex 仓库同时提供 TypeScript 与 Python SDK。早期 App Server 架构文章只提到 TypeScript，集成时应以当前仓库和对应版本文档为准。
App Server 能直接暴露给浏览器吗？
不建议。稳定入口是本地 stdio；应由可信后端管理 App Server 与工作空间，再向浏览器转发经过鉴权和净化的事件。WebSocket 模式目前仍是实验能力。
Harness 会让模型自动变强吗？
不会改变模型权重，但会显著影响系统能够保留的推理、可用上下文、工具反馈和恢复方式。因此同一模型在不同 Harness 和配置下可能有很大表现差异。
App Server 会取代 MCP 吗？
不会。App Server 是更丰富的 Codex 原生客户端协议；MCP 更适合让 Codex 作为工具参与其他 Host，或连接外部工具与数据源。
