说起 Codex，大多数人脑子里浮现的是三个东西：终端里的 CLI、桌面上的 App、编辑器里的插件。我们用它写代码、跑测试、改 bug，然后关掉窗口，很少去想它背后是什么。

但 OpenAI 最近发了一篇文章，标题叫《Codex as a platform》，把这件事讲清楚了：这些界面都只是表象，真正支撑它们的，是同一个开源的可执行引擎，官方叫它 harness。文章由 Nicolas Bonamy 和 Derrick Choi 撰写，信息量不小，而且透露出一个信号，Codex 正在从"一个编程工具"转向"一个可以被嵌入任何产品的平台"。

我想聊聊这个被大多数人忽略的底层，以及它对我们意味着什么。

智能体的真正难点，从来不是"回答"而是"执行"#

一个能用的智能体，绝不是"提示词加模型回复"这么简单。它需要理解任务、在多次往返中保持上下文、检索相关信息、调用工具、报告进度、处理失败、在必要时请求人类批准，最后返回一个有用的结果。

这一整套环绕在模型外面的执行系统，就是 harness，也就是智能体循环（agent loop）。它是 Codex 最核心、也最容易被忽视的部分。

文章给出了一个很有说服力的数据点。在 ARC-AGI-3 基准上，仅仅是加入了"保留推理"和"上下文压缩"这两个执行层面的能力，GPT-5.6 Sol 的分数就从 13.3% 提升到了 38.3%，几乎是原来的三倍，而输出 token 反而减少了六倍。

这个数字值得细品。模型本身没有变，变的是它周围的执行机制。这说明在当下的智能体竞赛里，模型能力固然重要，但"如何调度、如何记忆、如何压缩、如何收尾"这些工程问题，往往才是决定实际效果的分水岭。

开源的是执行层，不是模型#

Codex 的 harness 是开源的。这意味着你可以拆开应用和模型之间的这层"夹心"，看清楚它到底怎么运作，再按你的产品需求去改造它。

文章把开发者能掌控的部分分成了三层，每一层对应一个决策。

第一是界面。团队可以保留自己现有的仪表盘、编辑器、队列、地图、审批流，而不是把所有人都赶进一个通用聊天窗口。第二是上下文和工具。应用可以暴露自己真正关心的系统、文档、数据和动作，包括应用自己维护的 MCP 服务。第三是运行边界。宿主应用可以决定智能体在哪里运行、能碰哪些文件、哪些动作需要审批、如何观察它的工作、结果如何回流到业务系统。

这句话其实点破了一个很关键的产品立场：开源的是执行层和集成面，模型访问和托管服务是分开的。换句话说，你拿到的是一个可以自由组合的"引擎"，而不是把整个平台都送给你。

三种接入方式，对应三种场景#

文章给出了非常实用的分层，不同场景用不同接口，不必一刀切。

对于脚本、CI 任务或一次性后台任务，用 codex exec，跑一个有边界的智能体工作流，拿到结构化输出即可。对于需要在应用代码里启动、恢复、流式处理 Codex 任务的场景，用官方 Codex SDK，走程序化接口。而当智能体本身就是产品的一部分时，用 Codex app-server，它让你的应用连接到一个本地 Codex 进程，保持会话打开、流式收发事件、中断任务、暴露工具、响应审批请求。

这里的逻辑很清晰：SDK 帮你简化常见的程序化工作流，app-server 则把生命周期和用户体验的掌控权交给产品团队。选哪一层，取决于你离"产品"有多近。

别再造一个"换个 logo 的 Codex"#

文章里最有意思的一句话是：最诱人的机会，不是把 Codex App 换个 logo 重新做一遍，而是打造真正贴合某个团队工作方式的软件。

它举了几个场景来说明。安全分析师需要的，是一个能看到调查队列、近期告警、受影响服务，并且在开补救工单之前必须走审批步骤的界面。客服工程师需要的，是账号历史、产品日志、内部文档和一份草拟回复。产品团队想要的，是一个任务看板，把某个 issue 拖到"就绪"状态，就能触发一次有边界的实现流程。

在这些例子里，界面本身就是体验的一部分。它告诉智能体用户正在看什么、给它合适的工具，也给了用户一个可以审查"下一步会发生什么"的地方。智能体不应该脱离上下文裸奔，它应该嵌在用户本来就熟悉的工作界面里。

Relay：一个把智能体嵌进业务系统的范本#

为了把这个思路讲清楚，文章用了一个叫 Relay 的示例应用。它是一个物流运营的演示程序，把智能体放在一个虚构的货运仪表盘旁边，接入应用自己维护的 MCP 工具，并且在重新订舱这类关键动作上强制要求人工审批。

用户的使用方式很自然：不是从头写一条 prompt，而是选中一个运单，点击一个动作，比如"比较恢复方案"。这时应用负责提供相关上下文，Codex 拉取最新的模拟运营数据，智能体解释有哪些可用选项，任何会产生后果的写操作都必须经过审批。

这个例子的关键不在于物流本身，而在于它的集成模式是通用的。同样的套路可以用于事故响应、账户运营、研究流程，或者任何"智能体应该在一个已有产品体验内部工作"的场景。harness 负责智能体循环、会话状态、流式活动和工具交互，而产品继续掌控自己的仪表盘、记录和控件。

已经有人在这么干了#

文章列举了几家已经落地的玩家：GitHub 和 JetBrains 把 Codex 带进现有的 IDE 工作流；Cisco 在 Cloud Control 的 App Builder 里使用 Codex SDK；Thrive Holdings 和 Crete 把 Codex 用在了税务申报流程里，结合从业者的反馈，试点处理了 7000 份申报，准备时间缩短了大约三分之一。

注意，这些场景早就不局限于工程了。客服排查问题、运营协调流程、安全团队分诊事故、销售研究客户、市场团队策划活动，用的都是同一套模式：应用提供上下文、工具和审批，Codex 负责底层的智能体循环。

我的几点看法#

读完这篇文章，我有三个比较直接的判断。

第一，Codex 的竞争重心正在从"模型"转向"执行循环"。大家都在接入越来越强的模型，真正的差异化会落在谁的执行机制更可控、更可嵌入、更透明上。那个从 13.3% 到 38.3% 的数字，就是最好的注脚。

第二，“把智能体嵌入工作流"和"用一个聊天框替代一切”，是两条截然不同的产品路线。前者的门槛更高，因为它要求你去理解某个具体行业的人到底怎么干活，但护城河也更深。通用聊天框已经卷成红海，垂直嵌入反而可能是更宽的出路。

第三，控制权会成为核心竞争力。文章反复强调审批、沙箱、运行边界这些词，不是偶然的。当智能体真的开始替你执行"有后果的动作"时，谁掌握审批权、边界划在哪里，就决定了企业敢不敢把它放进生产环境。

总结#

Codex 的 App、CLI 和 IDE 插件，只是它展示能力的橱窗。真正值得关注的，是橱窗背后那个开源、可复用的智能体循环。OpenAI 把 harness 开源出来，等于把"如何让智能体在真实产品里工作"这件事的主动权，交还给了开发者。

对普通用户来说，这意味着未来的 Codex 可能不再只是你终端里的一个命令，而是藏在你每天使用的那些软件背后的隐形引擎。对开发者来说，这是一个明确信号：与其再造一个聊天机器人，不如想想怎么把智能体织进用户已有的工作流里。

参考来源：

Codex as a platform: build on the open agent harness，作者 Nicolas Bonamy、Derrick Choi，OpenAI Developers，https://developers.openai.com/blog/codex-as-a-platform