8月21日消息,OpenAI 发布官方文章《Codex as a Platform》,把开源的 Codex Harness 定位为开发者构建 Agent 产品的平台层,并开源 Codex CLI、app-server 与官方 Codex SDK 三个组件。文章明确表示,机会不在于用通用聊天框取代现有界面,而在于让这些界面获得 Agent 能力。模型访问与托管服务不在开源范围内。
开源三件套:CLI、app-server 与 SDK
Codex 的 app、CLI 与 IDE 扩展此前是三个入口,背后是同一套开源 harness。它负责让模型收集上下文、拆解任务、调用工具、在配置边界内运行、请求审批并把工作向前推进。8月19日的文章把这套 harness 作为开源组件发布,并按使用场景拆成三个集成层:codex exec 面向脚本、CI 作业或一次性后台任务,运行有边界的 agent 工作流并返回结构化输出;官方 SDK 面向需要启动、恢复或流式执行任务的应用程序代码;app-server 面向把 agent 作为产品一部分的场景,提供持久对话、流式事件与审批处理。OpenAI 的开源组件指南列出了各组件的位置与用途,开发者可以只取其中一层,也可以组合使用。
文章还给出了 harness 设计影响结果的直接数据。官方称,在 ARC-AGI-3 基准上,保留推理与上下文压缩把 GPT-5.6 Sol 的得分从 13.3% 提升到 38.3%,输出 token 减少六倍。这套数字是 OpenAI 自述,用于解释为什么要在一个专门构建的执行系统上运行 agent,而不是只靠提示词加模型响应。
三个控制轴:界面、上下文与运行边界
文章将开发者对 harness 的控制归纳为三个轴。界面轴决定用户从哪里进入 Agent:可以保留现有仪表盘、编辑器或工单队列,不必强迫用户进入一个通用聊天窗。上下文与工具轴决定 Agent 能看到什么:应用自己的系统、文档与动作,包括应用自有的 MCP 服务。运行边界轴决定 Agent 的权力范围:在哪里运行、能接触什么、哪些操作需要审批。
三个轴的共同点,是把 Agent 从"独立聊天产品"改造成"现有产品的一个能力层"。这也是这篇文章与 OpenAI 过往产品叙事的明显区别:Codex 不再只是又一个前端入口,而是被描述为可以被其他产品嵌入的底座。
从文章到落地:Relay 与三家采用方
文章不只有组件。OpenAI 发布了一个名为 Relay 的示例应用:在货运调度仪表盘旁边放置 agent,接入应用自有的 MCP 工具,重新预订货件前必须人工审批。用户不从空白提示开始,而是选中货件、点击"Compare recovery",由应用提供上下文,agent 取数并给出选项,涉及改写的操作需要审批。官方说明,示例使用虚构数据,但集成模式是通用的。
官方还列出了三个公开实现。GitHub 与 JetBrains 从 7 月 7 日起把 Codex 作为 agent provider 接入 IDE 工作流;Cisco 在 Cloud Control 的 App Builder 中使用 Codex SDK;Thrive Holdings 与 Crete 把 Codex 用于税务准备流程,据官方称试点处理了 7000 份申报,准备时间减少约三分之一。
Agent 即组件,与 Anthropic 同赛道
Anthropic 的 Claude Agent SDK 是通用 Agent 平台,驱动 Claude Code,同样面向"把 Agent 能力嵌进自有应用"的场景。两家在 Agent 集成层上已经形成直接竞争,Codex 的开源组件与 Claude Agent SDK 走的是同一条路线:让 agent 成为开发者产品里的一个组件,而不是一个必须把用户拉进来的独立界面。 时间线上还有一处值得注意的对照。今年3月,OpenAI 产品兼平台总经理 Thibault Sottiaux 曾公开表示,再过两三个月,Codex 这类 harness 会变成"原始工具"。8月则把 harness 正式产品化为平台组件。同一家公司内部,harness 的口径在半年内从"即将过时"转向"开源平台化",说明 OpenAI 对 Agent 分发形态的判断仍在快速调整。
OpenAI 开源的是 harness 与集成层;模型访问与托管服务保持独立,不在开源范围内。开发者拿到了可检查、可改造的底座,但模型与托管层仍由 OpenAI 掌握。