OpenAI 开源的 Codex Harness，藏着 Agent 真正的胜负手
2026 年 8 月 19 日，OpenAI 在官方博客发布《Codex as a platform: build on the open agent harness》，宣布将驱动 Codex App、命令行工具与 IDE 扩展运行的底层执行框架——Codex Harness全面开源，以 Apache-2.0 协议发布在 GitHub 的 openai/codex 仓库中。截至 8 月 21 日，该仓库已收获约 10.9 万 Star、1.66 万 Fork，最新稳定版本为 v0.149.0。
这次开源的不是模型，也不是 Codex 产品本身，而是支撑 Agent 运转的「执行层」。要理解它的意义，得先搞清楚一个问题：Harness 到底是什么？
一、Harness 是什么：模型与真实世界之间的那层「脚手架」
一个常见的误解是：强大的 AI Agent = 好模型 + 好 Prompt。但一个 Coding Agent 实际上由三部分组成：用户界面、模型和 Harness。
- 用户界面：显而易见，可能是命令行、IDE 插件、网页端或云端后台 Agent；
- 模型：比如 OpenAI 的 GPT 系列模型，负责推理；
- Harness：最复杂的一层。它直接与模型交互，最简化地说，就是由一系列提示和工具组合而成的核心 Agent 循环，为模型提供输入和输出。
换句话说，Harness 是模型的「接口层」，是模型与用户、代码之间交互的媒介。Anthropic 在其博客《Harness design for long-running application development》中给出的定义更为工程化：Harness 是一种支撑复杂 AI 智能体运行的外部框架、控制结构与编排系统——它不是单一算法，而是一整套工程化的脚手架，用于管理和放大 AI 的能力。
它是提示词工程之上的更高级抽象：Prompt 决定单次对话的质量，而 Harness 决定多轮、多智能体、长时任务的执行流程和可靠性。
一个能在真实业务中跑起来的智能体，需要理解任务、在漫长对话中保持记忆、审查相关信息、熟练调用工具、对外展示进度、处理崩溃和失败、在关键时刻停下来请求人类审批，最后返回有用的结果。这个包揽所有脏活累活的「执行系统」，就是 Harness。
二、Harness 里到底有什么：Agent 循环及其配套工程
以 Codex 为例，其核心是一个Agent 循环（Agent Loop）：Agent 接收用户输入、构造 Prompt、发送给模型推理、拿到响应。但响应往往不是最终答案，而是一次工具调用（比如「运行这个 shell 命令并告诉我结果」）。此时 Harness 执行工具调用，把输出追加到 Prompt 中，再次查询模型——这个循环可能重复几十次，直到模型产出给用户的最终消息。
模型负责每一步的推理，但其他所有事情都由 Harness 处理：执行命令、收集输出、管理权限、决定循环何时结束。具体而言，Codex Harness 承担的职责包括：
- 对话状态管理：持久化会话，支持多轮任务的持续推进；
- 上下文维护与压缩：当上下文窗口填满时，通过压缩端点将历史编码为更小的表示，而非简单的文本摘要；
- 工具调用：读写文件、运行 shell 命令、执行测试、调用 linter 和类型检查器等；
- 沙箱执行与限制：在内核级沙箱中运行命令，控制文件、网络的访问边界；
- 审批机制（Human-in-the-loop）：高风险操作须暂停并等待人类确认；
- Prompt 组装与缓存：系统指令、工具定义等静态内容放在 Prompt 前部，保证每轮都能命中缓存，降低成本。
三、Harness 设计有多重要？一组惊人的数据
OpenAI 官方给出的数据极具说服力：在难度极高的 ARC-AGI-3 基准测试中，仅对 Harness 做两项关键调整——保留推理（retained reasoning）与上下文压缩（context compaction），GPT-5.6 Sol 模型的得分就从 13.3% 飙升至 38.3%，同时输出 Token 数量减少了约六倍。
也就是说，在 Harness 的加持下，模型不仅「聪明了接近三倍」，还省下了海量的 API 调用成本。这印证了一个行业共识：模型能力固然重要，但如何管理这个模型——即 Harness 的设计——才是决定 Agent 最终表现的关键。
四、本次开源了什么：三层集成接口
OpenAI 将开发者接入方式分为三个层级，覆盖从 CI 脚本到产品级 Agent 的全场景：
1. codex exec —— 最轻量的一次性调用
一条 CLI 命令即可完成自动化任务，适合 CI/CD 流水线、批量脚本、后台一次性作业。它能运行有边界的 Agent 工作流，执行完毕自动退出并返回结构化输出——简单粗暴，无需管理会话。
2. Codex SDK —— 程序员的「操纵杆」
官方提供 TypeScript / Python SDK，可在应用代码中编程式地启动、恢复、流式编排 Codex 任务，精细控制线程与任务的生命周期，介于一次性 CLI 调用和完全自定义 UI 之间。
3. Codex app-server —— 彻底融入产品的核心引擎
这是最重磅的组件。它通过文档化的 JSON-RPC 客户端协议，让你的应用连接到本地 Codex 进程，实现：
- 保持持久的对话状态；
- 流式传输事件（实时看到 AI 在做什么）；
- 中途打断 AI 的工作；
- 将自己应用的工具暴露给 AI 使用（包括应用自有的 MCP 服务）；
- 处理人类审批请求。
事实上，Codex CLI、VS Code 扩展、macOS 应用、网页端这四个产品共享的就是这同一个引擎。OpenAI 在评估后曾拒绝用 MCP 承担这一角色——MCP 面向工具的「请求-响应」模型无法表达流式 diff、多步审批流和持久会话状态，因此自建了 app-server 协议；两者如今分工共存：MCP 负责把外部工具接入 Codex，app-server 负责把客户端接入 Codex。
技术上，Codex 已从早期的 TypeScript 原型重写为以 Rust 为主体的多入口 Harness：codex-rs（约 120 个 crate）构成核心，包含 CLI、TUI、Agent 循环、沙箱、MCP 与云任务等模块；TypeScript 与 Python SDK 则通过启动 CLI 或 app-server 的 JSON-RPC 暴露给外部应用。
需要说明的是开源边界：已开源的是 Codex CLI、SDK、app-server、codex exec、Skills、通用云环境；未开源的包括 VS Code / JetBrains 等 IDE 插件、Codex 网页版、云端托管产品，以及模型本身。
五、官方示例与落地案例
为了让模式更具体，OpenAI 基于 app-server 构建了示例运营应用Relay：在一个虚构的货运看板旁嵌入 Agent，接入应用自有的 MCP 工具，并要求任何关键操作（如重新预订货运）执行前必须经人类审批。用户点击「比较恢复方案」之类的建议动作后，由应用提供上下文，Codex 通过 MCP 工具拉取实时运营数据、解释可选方案，写操作一律经过审批环节——同一模式可用于事故响应、账户运营或研究工作流。
官方公布的落地案例已超出编码场景：税务合作伙伴 Thrive Holdings 与 Crete 借助该框架处理约 7000 份报税单，处理时间缩短约三分之一；Cisco 则基于 Codex SDK 在其云平台上构建了 App Builder。
六、行业坐标：Codex Harness vs DeepSeek Harness
这次开源与一周前（8 月 13 日）DeepSeek 以 MIT 协议开源的 DeepSeek Harness 形成直接对标，但两者定位截然不同：
| 对比项 | OpenAI Codex Harness | DeepSeek Harness |
|---|---|---|
| 定位 | 生产级 Agent 执行层，「精装整机」的底座 | 「一切皆插件」的积木式框架 |
| 架构哲学 | 内核级沙箱安全、确定性优先 | 基于 Cordis 微内核，连 Agent 主循环都可替换 |
| 模型绑定 | 默认 OpenAI GPT 系列，可接任意 OpenAI 兼容端点 | 不绑定自家模型，原生支持近 40 家模型厂商 |
| 开源协议 | Apache-2.0（执行层开源，产品与模型不开源） | MIT（完整开源） |
两条路线侧重点不同，但共同趋势很明确：Agent 的竞争正从模型层下移至执行层——「模型决定智商，Harness 决定能不能把事情做完」。
七、结语
Codex Harness 的开源，本质是 OpenAI 正式背书了一个开发者们早已在「逆向工程」的构建模式：把 Codex 的 Harness 当作基础设施，而不是一个锁死的应用。应用负责业务上下文、业务规则与工具，Codex app-server 提供 Agent 循环与沙箱执行。
对开发者而言，这意味着构建生产级 Agent 的门槛被大幅拉低：你不再需要从零实现会话管理、上下文压缩、沙箱和审批流，而可以把精力放在自己产品真正独特的部分。对行业而言，结合 ARC-AGI-3 上那组 Harness 设计带来的分数跃迁，这是一个清晰信号——下一轮的竞争差异化，将发生在编排层，而不仅仅是模型层。
