OpenAI把Codex“拆开卖了”

Agents API：Codex Harness的云端服务化

OpenAI昨天一口气打出了四张大牌：Agents API、GPT-Live-1 API、Data agent、ChatGPT for Financial Services，一天横跨Agent、语音、数据和金融四条产品线。

但这四张牌里，最值得看的可能还是Agents API，因为这一次，OpenAI把Codex“拆开卖了”。

原本藏在Codex背后、负责让Agent持续工作、调用工具、管理上下文和协同多个Agent的那套能力，被抽出来打包成了云端API，交给所有开发者调用。

Codex的渐进式解耦路径

其实，OpenAI早就在拆Codex了。

早在2025年4月，OpenAI刚发布o3和o4-mini那会儿，就把Codex CLI开源了。它有点像OpenAI版的Claude Code，直接就装在本地终端里。Agent怎么跑，怎么调用工具，都明明白白地放在GitHub上，你愿意折腾，就可以自己拿回去改，自己跑。

不过那个时候只是单纯地把东西给了出来，至于你会不会用、想怎么用，那都还是你自己的事。

一个月后，Codex云端版，也就是我们今天所熟悉的那个产品，才正式上线。用户可以把代码仓库交给它，一个任务对应一个独立的云端沙盒，Codex可以自己改代码、跑测试、修bug，还能同时处理多个任务。

又过了几个月，在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从一个产品提升成了平台。

Agents API的交付模式与计费逻辑

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

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

甚至就连Agent真正干活的机器都能自己选，是用OpenAI的沙盒、自己的基础设施，还是Cloudflare、E2B、Modal等第三方环境，都可以。Harness由OpenAI提供，执行环境由开发者决定。

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

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

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

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

Codex as a Service。

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背后的工具、上下文管理、权限系统和subagent能力开放给开发者，让别人也能拿这套东西做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变成开发者默认的那一层，谁才能吃下最大的蛋糕。

Harness竞争的本质：从智力到执行力

说到底，为什么现在模型公司都开始抢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大战，接下来还会怎么打吧。

JOTO 企业落地观察

• 对企业部署意味着：Harness服务化降低了智能体工程的基础设施门槛，但企业需重新评估自身对执行环境（沙盒/自有/第三方）的可控性要求，尤其在合规与数据主权敏感场景中，完全托管模式可能带来新的治理挑战。
• 对RAG知识工程而言：Agents API未改变知识注入方式，但其长会话上下文压缩机制可能影响RAG检索时机与chunk粒度设计，需验证该机制是否兼容企业私有知识源的实时更新节奏。
• 在AI安全治理层面：Harness托管将工具调用权限、沙盒隔离策略等关键控制点上移至服务商侧，企业需通过API级审计日志、工具白名单配置等能力补足自身治理链路，而非依赖本地沙盒的全栈可见性。
• 对FDE驻场共创提出新需求：当Harness成为黑盒服务层，FDE需更聚焦于业务语义建模与工具契约定义，驻场重点从“搭框架”转向“定契约”与“验行为”