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 LoopAgent 接收用户输入、构造 Prompt、发送给模型推理、拿到响应。但响应往往不是最终答案而是一次工具调用比如「运行这个 shell 命令并告诉我结果」。此时 Harness 执行工具调用把输出追加到 Prompt 中再次查询模型——这个循环可能重复几十次直到模型产出给用户的最终消息。模型负责每一步的推理但其他所有事情都由 Harness 处理执行命令、收集输出、管理权限、决定循环何时结束。具体而言Codex Harness 承担的职责包括对话状态管理持久化会话支持多轮任务的持续推进上下文维护与压缩当上下文窗口填满时通过压缩端点将历史编码为更小的表示而非简单的文本摘要工具调用读写文件、运行 shell 命令、执行测试、调用 linter 和类型检查器等沙箱执行与限制在内核级沙箱中运行命令控制文件、网络的访问边界审批机制Human-in-the-loop高风险操作须暂停并等待人类确认Prompt 组装与缓存系统指令、工具定义等静态内容放在 Prompt 前部保证每轮都能命中缓存降低成本。三、Harness 设计有多重要一组惊人的数据OpenAI 官方给出的数据极具说服力在难度极高的 ARC-AGI-3 基准测试中仅对 Harness 做两项关键调整——保留推理retained reasoning与上下文压缩context compactionGPT-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 负责把外部工具接入 Codexapp-server 负责把客户端接入 Codex。技术上Codex 已从早期的 TypeScript 原型重写为以 Rust 为主体的多入口 Harnesscodex-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 HarnessDeepSeek 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 设计带来的分数跃迁这是一个清晰信号——下一轮的竞争差异化将发生在编排层而不仅仅是模型层。
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 LoopAgent 接收用户输入、构造 Prompt、发送给模型推理、拿到响应。但响应往往不是最终答案而是一次工具调用比如「运行这个 shell 命令并告诉我结果」。此时 Harness 执行工具调用把输出追加到 Prompt 中再次查询模型——这个循环可能重复几十次直到模型产出给用户的最终消息。模型负责每一步的推理但其他所有事情都由 Harness 处理执行命令、收集输出、管理权限、决定循环何时结束。具体而言Codex Harness 承担的职责包括对话状态管理持久化会话支持多轮任务的持续推进上下文维护与压缩当上下文窗口填满时通过压缩端点将历史编码为更小的表示而非简单的文本摘要工具调用读写文件、运行 shell 命令、执行测试、调用 linter 和类型检查器等沙箱执行与限制在内核级沙箱中运行命令控制文件、网络的访问边界审批机制Human-in-the-loop高风险操作须暂停并等待人类确认Prompt 组装与缓存系统指令、工具定义等静态内容放在 Prompt 前部保证每轮都能命中缓存降低成本。三、Harness 设计有多重要一组惊人的数据OpenAI 官方给出的数据极具说服力在难度极高的 ARC-AGI-3 基准测试中仅对 Harness 做两项关键调整——保留推理retained reasoning与上下文压缩context compactionGPT-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 负责把外部工具接入 Codexapp-server 负责把客户端接入 Codex。技术上Codex 已从早期的 TypeScript 原型重写为以 Rust 为主体的多入口 Harnesscodex-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 HarnessDeepSeek 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 设计带来的分数跃迁这是一个清晰信号——下一轮的竞争差异化将发生在编排层而不仅仅是模型层。
![[光学原理与应用-521]：对光的错误理解与纠偏](http://pic.xiahunao.cn/yaotu/[光学原理与应用-521]：对光的错误理解与纠偏)
