OpenAI把Codex“拆开卖了”

OpenAI昨日一次性发布了四项重要更新。

Agents API、GPT-Live-1 API、Data agent、ChatGPT for Financial Services，一天之内覆盖了Agent、语音、数据及金融四条业务线，每一条都具备独立分析的价值。

不过，在这四项更新中，最引人注目的或许是Agents API。

因为这一次，OpenAI将Codex“拆分出售”了。

原本隐藏在Codex背后、负责支撑Agent持续运行、工具调用、上下文管理以及多Agent协作的那套能力，被提取出来并封装成云端API，向所有开发者开放调用。

01 Codex即服务？

实际上，OpenAI早已开始拆分Codex。

早在2025年4月，OpenAI刚推出o3和o4-mini时，就将Codex CLI进行了开源。它类似于OpenAI版本的Claude Code，直接安装在本地终端中。Agent如何运行、如何调用工具，都在GitHub上清晰展示，如果你愿意折腾，可以自行修改并运行。

不过，那时只是单纯地提供了代码，至于你是否会使用、如何使用，都是你自己的事情。

一个月后，Codex云端版本，也就是我们今天所熟知的产品，才正式上线。用户可以将代码仓库交给它，每个任务对应一个独立的云端沙盒，Codex可以自行修改代码、运行测试、修复错误，还能同时处理多个任务。

又过了几个月，在2025年10月，OpenAI发布了Codex SDK。

简单来说，SDK是一套面向开发者的工具包，使Codex不仅作为独立产品使用，还能嵌入到其他应用程序中。SDK允许开发者用几行TypeScript代码启动与Codex CLI相同的Agent，获取结构化输出，并保留任务状态，在暂停后继续运行。

但是，SDK主要适用于在程序中调用Codex，尚未开放完整的Codex交互能力。它非常适合后台工作流、自动化脚本和服务端程序。但如果你想构建一个类似Codex IDE的完整客户端，仍然面临一些挑战。

于是，到了2026年2月，OpenAI正式公开了Codex App Server，首次系统地阐述了Codex内部的Harness结构。

OpenAI明确解释，Codex Web、CLI、IDE扩展和Mac App看似不同的产品，但底层都在运行同一套Codex Harness，即负责Agent Loop、Thread、工具执行、认证和状态管理的层次。

App Server为这整套Harness添加了一套双向JSON-RPC接口。JetBrains、Xcode或其他客户端无需重新构建Agent Loop，只需启动App Server，即可驱动完整的Codex。

有了App Server，其他产品就可以直接连接完整的Codex Harness。

不过，走到这里，还有最后一个难题未解决。

SDK控制的是本地Codex Agent，而App Server本身也是一个需要开发者启动和维护的常驻进程。虽然将Codex集成到产品中已经实现，但想将其稳定地运行成在线服务，仍然存在困难。

举一个具体的例子：如果你使用App Server构建自己的Coding Agent网站，前端已经连接了Codex，但当用户点击“修复这个仓库”后，后续的大量运行和基础设施问题，仍需要你自行解决。

然后，到了8月19日，OpenAI将过去一年陆续开放的CLI、SDK、App Server统一纳入了“开放Codex Harness”的平台叙事中，并明确将Codex从一个产品提升为平台。

接着，在（美国时间）9月10日，也就是昨天，Agents API正式开放公测。

这一次，开发者只需告知API四件事——任务、模型、工具、运行环境——即可直接创建一个Agent。负责长会话上下文压缩、工具调度和子Agent协作的Codex Harness由OpenAI自行托管和维护。

甚至Agent实际运行的机器也可以自行选择：是使用OpenAI的沙盒、自己的基础设施，还是Cloudflare、E2B、Modal等第三方环境，都可以。Harness由OpenAI提供，执行环境由开发者决定。

官方口径很明确，Agents API本身不额外收费。也就是说，Harness托管、长会话管理等能力，并未单独收取一层Agent平台费用。

开发者按实际使用的模型Token和工具付费；如果使用OpenAI自己的托管沙盒，计算资源另算。

串联起这一年多的历程，OpenAI一直在做同一件事：将Codex从一个具体产品，一层一层拆解成可复用的能力，同时让开发者越来越不需要自己操心。

如果一定要给这条产品线起个名字，它很像当年的SaaS，只不过这次被服务化的不是软件，而是Codex。

Codex as a Service。

02 Harness也开始分叉了

盯上Harness的当然不止OpenAI。

DeepSeek Harness（以下简称DSH）发布时，就给出了一个非常响亮的等式：Agent = Model + Harness。

在DeepSeek看来，模型只是Agent的一半，另一半则是负责让它理解环境、调用工具、管理状态、持续执行任务的Harness。两者互相协调，Agent才能真正执行任务。

DSH将Harness本身做成了一套高度模块化的开放框架：模型、工具、Skills、Session、沙盒、存储、Agent Loop、调度，甚至UI都可以替换。

“一切皆插件”的口号并非只是说说而已，最好大家都来写插件，都来适配DSH，最后不管上面运行的是DeepSeek，还是其他模型，底层都可以是同一套Harness。

这与OpenAI现在走的方向形成了一个有趣的对比。

OpenAI虽然也开源了Codex Harness，但Agents API明显在往另一个方向走：Harness你可以使用自己的，也可以拿走开源的，但如果你嫌麻烦，还可以直接不管，让我来替你安排。

所以我们认为，它更像是一种“服务”。OpenAI负责托管和持续维护Harness，开发者只需决定要让Agent做什么、用什么工具、在哪里执行。甚至以后模型升级了，Harness如何跟着改，OpenAI也准备一并负责。

某种意义上，现在Harness这一层隐约出现了两条路线：

以DeepSeek为代表的路线更像是建设开放生态，把每一个零件都做成插件，让开发者自己组装；而以OpenAI为代表的一方则像在押注云服务，把钱和需求给到位，剩下的我帮你解决。

我们甚至可以认为，一个想让Harness越来越像Linux，另一个则想让Harness越来越像AWS。

当然了，这只是个比喻。OpenAI也开源了Codex Harness，DeepSeek未来也并非没有可能提供更多的托管服务。但至少在现阶段，两边产品的重心差别明显。

有趣的是，在将Harness变成服务的这条线上，Anthropic其实比OpenAI更早一步。

早在2025年9月，Anthropic就推出了Claude Agent SDK，将Claude Code背后的工具、上下文管理、权限系统和子Agent能力开放给开发者，让别人也能拿这套东西做Agent。

今年4月，它甚至比OpenAI更早推出了Claude Managed Agents。Session、Harness和沙盒被拆成三个独立层：Anthropic负责托管Harness和长任务，沙盒既可以由Anthropic提供，也可以接入其他执行环境。这个思路与今天的Agents API已经相当接近，Anthropic自己给它的定义就是“一个用于长期Agent任务的托管服务”。

所以某种意义上，OpenAI这次是在沿着Anthropic已经走过的路继续前进，区别只不过是OpenAI手里有一个更“产品化”的Codex。

但因为Codex和Claude Code长期给人的产品印象还是不太一样，所以即使它们讲的是同一套故事，带来的感觉也大相径庭。Claude Code给人的感觉更像是让开发者坐在终端里和Agent一起写代码，而Codex App一开始强调的就是“同时监督多个长期Agent”的界面。

顺带一提，谷歌也早已加入这条路线。今年5月的I/O大会上，Gemini API推出Managed Agents，同样将Antigravity Harness和沙箱做成了托管服务。但谷歌的牌面不止于此，这一点咱们后面再讨论。

不过话说回来，谁先谁后好像也不是那么重要……最后当然是谁把自家的Harness变成开发者默认的那一层，谁才能吃下最大的蛋糕。

03 谁是大赢家？

说到底，为什么现在模型公司都开始抢Harness了？

就像DSH给出的等式那样，Agent = Model + Harness，模型可以告诉Agent下一步应该做什么，但真要把一个任务从头跑到尾，它还得知道文件在哪里、需要调用哪个工具、出了错怎么恢复、结果最后要写在哪里。

换句话说，模型决定Agent的能力上限，而Harness越来越决定它到底能不能把活做完。

而一旦竞争的维度从“智力”走向“执行力”，最占优势的，未必是那些模型做得最好的AI公司。

因为Agent真正开始干活之后，需要的那些东西——邮件、文档、会议、通讯、账号权限等等——往往掌握在传统平台公司手里。

国内最近打得热闹的“办公Agent大战”，其实就是一个非常典型的例子：大厂在互联网平台时代积累下来的那些东西，以前更多只是各自生态里的部分功能，但到了Agent时代，这些东西恰好就是Agent真正干活时需要调用的工具。

现在大家做办公Agent，表面上是比谁家的AI员工更聪明、更有本事，背后其实也在重新利用自己过去积累的平台优势。谁手里有更多企业数据、文档、工具和权限，谁就更容易让Agent真正把事情做完。

模型公司需要一点点接入它们没有的入口，而那些做了十几年办公软件和互联网平台的公司，本来就掌握着这些入口。

换句话说，AI公司要重新连接现实世界，而平台公司手里原本就有一大串钥匙。

沿着这条路往前看，如果非要找一个最有优势的“全家桶”选手，谷歌恐怕是最夸张的那个。

从TPU、云基础设施、Gemini，到Search、Workspace、Chrome和Android，谷歌几乎覆盖了AI从底层技术到最终用户的所有关键环节。Search、Gmail、Calendar、Drive、YouTube、Maps等产品，又天然构成了一套可以被Agent调用的数字环境。这些资产在上一代互联网里是一个个独立入口，到了Agent时代，却可以被重新组织到同一个任务之下。

事实上，谷歌已经开始把散落在各个产品里的Agent能力，在底层往同一套执行系统里收。Gemini Spark、Gemini API里的Managed Agents，乃至Search里的部分Agent体验，背后正在逐渐共享同一套Antigravity Harness。

但到了用户这一端，事情还是有点乱。

今天谷歌同时有Gemini Spark、Workspace Studio、Antigravity、Gemini Enterprise，以及Search里的Information agents。它们面对的用户和场景各不相同，但对于普通人来说，当他们想把一件复杂的事情整个交给谷歌，还是不知道应该找谁。

对谷歌来说，它已经拥有完成这一切所需的大部分条件，缺的只是一个足够简单的产品答案。

而如果谷歌真把这件事做明白了——无论是做出了一个统一的Agent工作台，还是让同一个Agent执行系统穿透整个谷歌生态，让用户习惯“有问题找谷歌”，全球Agent市场的竞争格局恐怕都要再变一变。

话虽如此，谷歌就算真把这套“全家桶”塞进一个Agent，国内用户大概率也只能先围观一下。

还是先看看国内的Agent大战，接下来还会怎么打吧。