文 | 字母 AI
OpenAI 昨天一口气打出了四张大牌。
Agents API、GPT-Live-1 API、Data agent、ChatGPT for Financial Services，一天横跨 Agent、语音、数据和金融四条产品线，每一条都值得单独拿出来说道。
但这四张牌里，最值得看的可能还是 Agents API。
原本藏在 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 从一个产品提升成了平台。
这一次，开发者只需要告诉 API 四件事——任务、模型、工具、运行环境——就可以直接创建一个 Agent。负责长会话上下文压缩、工具调度和 subagent 协作的 Codex Harness 由 OpenAI 自己托管和维护。
甚至就连 Agent 真正干活的机器都能自己选，是用 OpenAI 的沙盒、自己的基础设施，还是 Cloudflare、E2B、Modal 等第三方环境，都可以。Harness 由 OpenAI 提供，执行环境由开发者决定。
开发者按实际使用的模型 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 虽然也把 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 任务的托管服务 "。
但因为 Codex 和 Claude Code 长期给人的产品印象还是不太一样，所以即使它们讲的是同一套故事，带来的感觉也大相径庭。Claude Code 给人的感觉更像是让开发者坐在终端里和 Agent 一起写代码，而 Codex App 一开始强调的就是 " 同时监督多个长期 Agent" 的界面。
顺带一提，谷歌也早已加入这条路线。今年 5 月的 I/O 大会上，Gemini API 推出 Managed Agents，同样把 Antigravity 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 大战，接下来还会怎么打吧。
