美国时间9月10日，OpenAI在一天之内推出了四张产品牌，其中最值得关注的是一张看似最轻的牌——Agents API。它不增加新功能，而是把藏在Codex背后、负责让Agent持续工作、调用工具、管理上下文和协同多个Sub-agent的那套能力，抽出来打包成一条托管API，交给所有开发者调用。
这一次，开发者只需要告诉系统四件事——任务、模型、工具、运行环境——剩下的长会话压缩、工具调度、状态保存，全部由OpenAI接管。
官方的口径很明确：Agents API本身不额外收费。开发者按实际使用的模型Token付费；如果用OpenAI自己的托管沙盒，计算资源另算。
听起来慷慨。但如果你把过去一年半的时间线拉回来，会发现OpenAI一直在做同一件事：把Codex从一个具体产品，一层一层拆成可以被复用的能力，同时让开发者越来越不需要自己操心。
这不是一个简单的产品升级，而是一次从"IaaS式按量计费"向"PaaS式生态锁定"的商业范式转移。类比云计算的发展史，它很像AWS从EC2（提供虚拟机）进化到EKS/Kubernetes托管（提供完整平台）的路径——区别在于，这里的"基础设施"不是服务器，而是Agent的运行时环境。
六步拆解：从CLI到托管API的渐进解耦Codex拆解的起点是2025年4月。当时OpenAI刚发布o3和o4-mini，顺手把Codex CLI放到了GitHub上。它有点像OpenAI版的Claude Code，装在本地终端里。Agent怎么跑、怎么调用工具，全摆在明面上。你愿意折腾就可以自己改、自己跑。但那只是给了东西，至于你会不会用，那是你自己的事。
一个月后，Codex云端版正式上线。用户可以把代码仓库交给它，一个任务对应一个独立云端沙盒，Codex可以自己改代码、跑测试、修bug，还能同时处理多个任务。
到了2025年10月，OpenAI发布了Codex SDK。这是一个TypeScript工具包，允许开发者用几行代码启动同一个驱动Codex CLI的Agent，拿到结构化输出，保留任务状态，甚至在暂停后继续跑。但它主要适合服务端的工作流和自动化脚本，想做一个完整的客户端仍然困难。
真正的转折发生在2026年2月。OpenAI正式公开Codex App Server，第一次系统地把Codex里面那套Harness讲清楚了。所谓Harness，就是负责Agent Loop、Thread、工具执行、认证和管理状态的那层东西。OpenAI明确解释：Codex Web、CLI、IDE扩展和Mac App看起来是不同的产品，但底下其实都在运行同一套Codex Harness。App Server给这一整套加了双向JSON-RPC接口，JetBrains、Xcode或者其他客户端可以直接接入，不需要重新造轮子。
但这里还有最后一个麻烦：App Server本身是一个需要开发者启动和维持的常驻进程。如果你想用它做一个线上的Coding Agent网站，前端接上了Codex，但用户点下"修复这个仓库"之后，后续的大量运行和基础设施问题，还是需要你自己扛。
2026年8月19日，OpenAI把过去一年陆续开放的CLI、SDK、App Server统一收进了"开放Codex Harness"的平台叙事里，明确把Codex从一个产品提升成了平台。
然后就到了9月10日。Agents API来了。
Harness由OpenAI提供并托管，执行环境则由开发者决定——可以用OpenAI的沙盒，也可以用Cloudflare、E2B、Modal等第三方，甚至完全自建机器都行。OpenAI卖的是编排能力，而不是具体的算力。
不收平台费，才是真正的平台策略Agents API的一个关键信号是：它不单独收取任何"平台管理费"或"Harness订阅费"。
这在直觉上是反常识的。如果一套完整的Agent生命周期管理能力——包括长会话压缩、工具调度、多Agent协作、安全护栏——都是免费的，那OpenAI图什么？
答案是：它要的是入口，不是单次交易。
当开发者不再需要自己维护Agent的状态管理、工具路由、重试机制和错误恢复，他们就不再去买现成的开源框架或者自己开发了。他们的代码、项目、用户数据，全部沉淀在OpenAI的API调用记录里。
这种策略的核心逻辑是：降低边际使用成本，提高迁移总成本。 Token本身是可以比较价格的，不同模型的单价可能相差一倍以上，但迁移一个已写好的Agent工作流到新平台的工程成本，可能是前者的十倍以上。一旦开发者习惯了你提供的Harness，换平台的隐性成本就会迅速攀升。
这与当年AWS的战略高度一致：EC2的虚拟化技术本身已经标准化，真正让AWS形成壁垒的不是虚拟机本身，而是围绕它建立的Kubernetes托管、自动扩缩容、负载均衡、监控告警等一系列"附带服务"。这些服务单独看都不贵，但组合在一起，客户就难以离开了。
对开发者来说，Agents API确实减轻了负担。对一个想让Agent持续工作的团队而言，自己实现可靠的Agent Loop通常需要数月以上的开发工作量，而现在只需要调一次API。但对OpenAI而言，这条API正是它争夺AI生态控制权的第一个物理入口。
群雄逐鹿Harness：Linux路线 vs AWS路线盯上Harness这一层的，不止OpenAI一家。整个行业目前出现了两条截然不同的路线。
第一条是"开源共建"路线，代表是DeepSeek Harness（DSH）。 DSH提出了一个公式：Agent = Model + Harness。 模型只决定Agent能做什么，Harness决定它能不能把活做完。DSH把这个Harness做成了一套高度模块化的开放框架：模型、工具、Skills、Session、沙盒、存储、Agent Loop、调度，甚至UI都可以替换。它的口号是"一切皆插件"，目标是让开发者自己组装，最终不管上面跑的是DeepSeek还是别的模型，底下都可以是同一套Harness。这条路更像是在建设一个操作系统——让Harness越来越像Linux。
第二条是"云托管"路线，代表是OpenAI和Anthropic。 Anthropic实际上比OpenAI更早踏出了这一步。2025年9月，Anthropic推出了Claude Agent SDK；今年4月，它推出了Claude Managed Agents，把Session、Harness和沙盒拆成三层，Anthropic负责托管Harness和长任务。OpenAI的Agents API思路与之高度接近，区别在于Codex自带了一个更强的产品化形象。
谷歌则走出了第三条路。今年5月的I/O大会上，Gemini API推出了Managed Agents，同样把Antigravity Harness和沙箱做成了托管服务。但谷歌的真正筹码不在于Harness本身，而在于它手里握着一串别人没有的钥匙：Search、Gmail、Calendar、Drive、YouTube、Maps。这些在过去互联网时代是独立的入口，到了Agent时代，恰恰是Agent最需要调用的"工具集"。
这就是为什么行业竞争的重心正在发生偏移。当Agent竞争的维度从"智力"走向"执行力"时，最占优势的未必是模型做得最好的AI公司。因为Agent真干活的时候需要的邮件、文档、会议、通讯、账号权限，往往掌握在传统平台公司手里。AI公司要重新连接现实世界，而平台公司手里原本就有一大串钥匙。
谷歌几乎覆盖了AI从底层技术到最终用户的所有关键环节：TPU、云基础设施、Gemini、Search、Workspace、Chrome和Android。它已经开始了把所有散落在各产品里的Agent能力往同一套执行系统里收拢的动作。缺的只是一个足够简单的产品答案。
对国内而言，办公Agent大战也遵循同样的逻辑。大厂在互联网平台时代积累的文档、通讯录、IM工具、OA审批，在Agent时代就是天然的Executor入口。谁能把自己的工具链变成Agent调用的第一顺位选项，谁就能占据更大的蛋糕。
接下来关注什么Agents API的发布不是终点，而是一个新阶段的起点。以下几个观察指标可以帮助跟踪这一趋势的实质影响：
Token收入增长率与托管沙盒使用率的变化关系。 如果托管沙盒的使用量增速显著超过纯Token调用量，说明平台粘性的积累正在加速。 第三方执行环境（如E2B、Modal）接入Agents API的比例。 如果大量开发者选择用自己的基础设施而非OpenAI沙盒，平台锁定效应会被稀释；反之则验证了"卖编排而非算力"的逻辑成立。 Anthropic Claude Managed Agents与Google Gemini Managed Agents的用户迁移速度。 先发布的两家能否建立先发优势，取决于它们的工具库和企业客户基础是否足以抵消迁移成本。 企业内部Agent部署中，原生平台公司与传统AI厂商的份额分化。 当Agent真正开始替员工做事时，企业会更信赖已经深度集成在工作流中的平台，还是更依赖模型性能最优的AI厂商？这个答案将决定下一轮行业格局的轮廓。恒正网配资提示：文章来自网络，不代表本站观点。
