OpenAI 把 Codex 的底层 Harness 单独拿出来了：这次，它不只是一个 Coding Agent
OpenAI 今天发了一篇关于 Codex 的文章。
标题很官方：
Codex as a platform：build on the open agent harness。
翻译一下，意思其实很简单：
Codex 不准备只做一个 App、一个命令行工具，或者一个 IDE 里的编程助手了。
OpenAI 把支撑 Codex 运行的那套开源 Harness 单独拿了出来。上下文怎么维护、工具怎么调用、任务怎么跨多轮继续、什么时候需要人工确认、沙箱权限怎么限制，这些原本藏在 Codex 背后的 Agent 能力，现在都可以被开发者直接复用。
这也意味着，以后开发 Agent 产品，不一定非得再造一个聊天框。
客服还是使用原来的客服后台，安全团队继续盯着 incident dashboard，运营人员依然在自己的业务系统里处理任务。
产品负责界面、业务规则、数据和工具。
Codex 在下面，负责跑 Agent Loop。
这件事，可能比再发布一个 Coding Agent 更值得关注。
真正可以复用的，是 Agent Loop
很多人理解的 Agent，还是一段提示词加一个模型。
用户输入任务，模型返回答案。
但真正能干活的 Agent，显然没这么简单。
它需要理解任务，持续维护上下文，检查相关资料，调用工具，展示执行进度，处理工具报错，还要知道什么时候可以自己继续，什么时候必须停下来请求人工批准。
最后，还得把一个真正能用的结果交出来。
围绕模型运行的这一整套执行系统，就是 Harness。
Codex Harness 负责管理会话状态、流式输出执行过程、调用工具、限制沙箱权限、执行 approval 规则，以及让任务能够跨多个回合持续进行。
OpenAI 在文章里还专门举了一个例子。
在 ARC-AGI-3 测试中，仅仅通过保留推理状态和压缩上下文，GPT-5.6 Sol 的成绩就从 13.3% 提高到了 38.3%，同时输出 Token 数量减少到了原来的六分之一。
这组数字挺有意思。
它说明同一个模型，外面套着什么样的 Harness，最后跑出来的效果，真的可能差很多。
模型负责"会不会"。
Harness 负责"能不能把这件事持续做完"。
OpenAI 开放的，到底是什么
这里需要先说清楚一件事。
OpenAI 开放的并不是 Codex 背后的模型权重，而是模型上面的 Agent Harness 和产品集成层。
目前公开出来的主要包括：
模型访问和托管服务，依然是单独的一层。
但对于开发者来说，这已经足够重要了。
因为 Harness 开源以后，开发者可以直接查看应用和模型之间到底发生了什么，也可以根据自己的产品需求，对这层能力进行改造。
产品不需要迁就一个通用聊天框。
原来的编辑器、仪表盘、任务队列、地图、业务记录和审批流程都可以保留。应用负责向 Codex 提供业务数据、文档、系统能力和 MCP 工具，同时决定 Agent 可以访问哪些文件、调用哪些工具、在哪里运行，以及哪些操作必须经过人工确认。
说白了，Codex 不再要求所有工作都搬进它的界面。
它开始主动往别人的产品里走了。
三种接入方式，分别对应三类场景
OpenAI 这次给出的接入方式，主要有三种。
第一种是 codex exec。
适合脚本、CI 流程或者一次性的后台任务。
比如自动分析一次代码仓库、修复一批问题，或者在流水线中执行一个边界明确的 Agent 任务。任务跑完，返回结构化结果，整个过程不需要一直保持会话。
第二种是 Codex SDK。
适合在应用代码里启动、恢复和监听 Codex 任务。
开发者可以直接通过程序控制任务，接收流式事件，也可以把 Codex 能力包装进自己的业务逻辑中。
第三种是 Codex app-server。
这个更适合真正把 Agent 变成产品的一部分。
它可以保持长期会话、持续接收事件、中断任务、暴露工具，并处理人工 approval 请求。SDK 更像一个方便调用 Codex 的程序接口，而 app-server 则把 Agent 的完整生命周期交给产品团队控制。
简单概括就是：
只想跑一次任务，用 codex exec。
想在代码里调 Agent，用 SDK。
想把 Agent 真正嵌进产品，用 app-server。
重点不是再造一个聊天框
这篇文章里有一个判断很值得注意：
最有价值的方向，不是给 Codex App 换一个 Logo，再做一遍。
而是围绕具体工作流，重新设计 Agent 产品。
比如安全分析人员打开系统时，看到的应该是告警队列、受影响的服务和调查记录，而不是一个空白输入框。
客服工程师需要看到用户账户历史、产品日志、内部文档，以及一份可以修改的回复草稿。
产品团队可能更习惯任务看板。当一个任务被移动到"准备开发"状态时，后台自动启动一个范围受限的实现任务。
这些界面不只是为了好看。
它们本身就是上下文。
界面告诉 Agent，用户正在看什么、当前任务是什么、有哪些数据可以使用；同时也给用户留下审核结果和决定下一步操作的位置。
应用负责产品上下文、业务规则、工具和授权；Codex app-server 负责 Agent Loop 和沙箱执行。
这张图基本把分工说清楚了。
上层产品仍然属于开发者。
业务数据、界面、规则、审批、工具，都由应用掌握。
Codex 只接管最下面那套通用但很麻烦的 Agent 执行循环。
Relay：把 Codex 塞进运营系统
为了说明这种模式，OpenAI 还做了一个叫 Relay 的示例应用。
Relay 是一个虚构的物流运营系统。
用户进入系统以后，不需要从零写一段提示词，而是先选择一条异常运输记录，然后点击类似 Compare recovery 的操作。
应用会把当前货物、运输状态和异常信息直接提供给 Codex。
Codex 再通过应用提供的 MCP 工具获取最新运营数据，分析可选的补救方案，并向用户解释每个方案的影响。
如果只是查询和分析，Agent 可以直接继续。
但如果需要重新预订运输路线，修改真实业务记录，就必须先经过人工批准。
审批通过后，Codex 才能调用工具完成操作。底层数据发生变化，应用再刷新原来的业务界面。
在这个过程中，Harness 负责 Agent Loop、会话状态、执行过程和工具调用；产品继续负责仪表盘、业务记录和审批控制。
Relay 将 Codex 嵌入物流运营仪表盘，关键业务操作必须经过人工批准。
当然，Relay 里的数据是虚构的。
但这个模式并不只适用于物流。
事故响应、账户运营、科研工作流、客户支持，甚至很多内部管理系统，都可以按这个思路改造。
已经有人开始这样用了
这种形态并不只是一个概念。
GitHub 和 JetBrains 已经把 Codex 接入原有的 IDE 工作流。
Cisco 在 Cisco Cloud Control 的 App Builder 中使用了 Codex SDK。
Thrive Holdings 和 Crete 则把 Codex 放进了税务申报流程，并通过从业人员反馈持续优化 Agent。他们的试点处理了大约 7000 份报税材料，准备时间减少了约三分之一。
而且这些案例并不限于写代码。
客服团队可以用它调查用户问题，运营团队可以用它协调复杂流程，安全团队可以用它处理告警，销售团队可以用它研究客户，市场团队也可以用它整理资料和生成活动方案。
这些场景的共同点都是：
应用提供上下文、工具和审批。
Codex 负责下面的 Agent Loop。
Codex 开始从工具，变成平台
过去提到 Codex，首先想到的还是写代码。
App、CLI 和 IDE 插件，也确实都是围绕编程场景展开的。
但这篇文章给出的方向已经很明确了。
Codex App、CLI 和 IDE Extension，更像是 Codex Harness 的几种官方示例。
真正可以被复用的，是它们下面那套上下文管理、工具调用、权限控制、人工审批和多轮任务执行能力。
很多工作天然发生在仪表盘、时间线、地图、文档和业务记录里。
这些界面并不应该全部被一个万能聊天框替代。
更合理的方式，是保留原来的工作环境，然后给它接上一个能够理解上下文、调查问题、提出下一步建议，并在获得批准后执行操作的 Agent。
所以，这次真正值得关注的，可能不是 Codex 又多了一个调用方式。
而是 OpenAI 开始重新定位 Codex：
模型负责提供能力。
Harness 负责把能力装进具体工作流。
产品负责业务上下文、规则、工具和最终控制权。
Codex，正在开始做这一层的平台。