OpenAI 把造 AI 代理的地基开放了：Agents API 公测版都给了什么

OpenAI 近日将 Agents API 公测版面向所有开发者开放，这是近期 AI 行业里最值得认真对待的变化之一。名字听起来技术味很浓，说的事情却不复杂：它内部有一套支撑 Codex 和企业版 ChatGPT 的代理基础设施，能让 AI 代理连续跑上几个小时甚至几天，自己规划步骤、自己调用工具把事情办完。这套东西一直是私家家底，外面的人只能隔着产品用，摸不到底座。这次公测等于把地基开放出来出租，开发者通过一次 API 调用就能创建生产级的代理，不用再自己从零搭上下文管理、任务编排这些底层设施。

它具体给了什么，值得挨个看一眼。上下文自动压缩是长任务的命根子，会话快到模型的记忆上限时，早期的内容会被自动压缩，代理因此可以一口气跑几十个小时不“断片”。工具搜索与并行调用解决的是工具多起来的浪费问题，工具定义按需加载以省 token，多个工具还能同时执行。多代理协同则像是给代理配了个团队，主代理把复杂任务拆给几个并行的子代理，各自维护各自的上下文，最后由主代理汇总结果。环境选择也很灵活，官方提供与自家产品共用的沙箱，还和一批云厂商做了深度集成，私有云部署、不同的 CPU 与内存配置都有得选。计费延续了 API 的一贯风格，不收订阅费，只按实际消耗的 token 和工具调用付费，试用门槛很低。

光说概念还是虚的，看一段最小示例就有体感了。假设我想做一个每天盯竞品价格、发现降价就起草通知的代理，开发者要写的代码大概长这样。

from agents import Agent, Runner

agent = Agent(
    name="价格监控员",
    instructions="每天抓取指定网页的商品价格，与历史记录对比，降价就写记录并起草通知邮件",
    tools=[打开网页, 读历史价格, 写记录, 发邮件],
)

result = Runner.run_sync(agent, "开始今天的工作")

这段代码里藏着理解 Agents API 的钥匙：开发者只提供两样东西，一份岗位说明书，一个工具箱。说明书就是那段 instructions，用大白话告诉代理目标是什么；工具箱是一组普通函数，把查网页、读数据库、发邮件这些能力挂给代理。至于先调哪个工具、按什么顺序干，全由模型自己决定，这是它和你以前写的普通程序最大的区别。你按一下启动键，剩下的事情发生在 OpenAI 的机房里，跑完把结果交回来。

把时间拨回没有这套 API 的日子，就知道它省掉了多少活。那时候开发者手里只有最底层的对话接口，发消息给 GPT，收一段回复，仅此而已。想让 AI 变成能干活的代理，所有的身体零件都得自己造：上下文快满了要自己写压缩和裁剪的逻辑，写不好代理就失忆甚至崩掉；代理要跑代码、操作文件，就得自己租服务器配沙箱做安全隔离，不然一个误操作能把自家系统搞坏；想让几个 AI 分工协作，谁拆任务、谁汇总、中间结果怎么传，调度逻辑全靠手写；工具一多，说明塞不下、模型挑花眼，优化也是自己的事。当时开发者圈子里流传一句话，做一个演示用的代理只要一个下午，做成天天稳定跑的产品要几个月，因为八九成的时间都耗在这些零件上，真正花在业务上的反而少。

现在这一层被整体搬到了服务端。以前要自造的四大件——上下文管理、执行环境、任务调度、工具优化——全部变成了 API 背后的能力，而且和 Codex、企业版 ChatGPT 用同一套底座，OpenAI 负责持续维护升级，模型进步了，你的代理跟着变强。开发者的工作量从造整车变成了只管开车：写好说明书，备好工具，按一下启动键。

说到这里，一个合理的质疑是：我以前用开源框架自己部署一个 agent 服务，对业务系统暴露 API，链路不是一模一样吗？确实一样，这两年很多团队就是这么干的，概念层面没有本质区别，都是模型加工具加循环调度。差距不在“能不能做”，在那个盒子里的成色和维护成本。几个关键维度摆在一起看会更直观。

表格里最容易被低估的是维护那一行。自建代理不是搭完就完了，模型一升级，提示词、工具描述、压缩策略可能全要重调；框架一更新，又得跟着迁移。OpenAI 的说法很直白，它负责维护和迭代，模型升级开发者自动获益，等于把一块永远做不完的活外包了。当然话说回来，自建并没有被判死刑，数据不出门、完全可控、不被单一生态锁死，这三样是托管 API 给不了的，对隐私和合规敏感的场景依然会选自建。真正被改写的是另一群人的命运：原本想搞 agent 却被工程成本吓退的中小团队，现在一周就能上线。文章里引用的客户数据也印证了这一点，有公司的案例审核成本降了 60%，有公司的代理响应失败率降了 86%，还有公司的部署周期从几天缩到了几小时。

工具这件事值得单独展开说，因为这是误会最集中的地方：公测版并不是只给你一个空壳，它自带了一组由 OpenAI 在服务器端托管执行的通用工具，创建代理时按需选用。

• 网页搜索：让代理实时检索互联网，查资料、核信息都用得上；
• 文件检索：从向量存储中查找上传的文档，适合让代理先通读一批材料再干活；
• 代码解释器：在沙箱里写代码跑代码，数据统计、格式转换、生成图表都靠它；
• 图像生成：按提示词出图，不用跳出流程另找工具；
• 托管 MCP：把远程 MCP 服务器上的工具直接暴露给模型，第三方服务即插即用；
• 工具搜索与编程式调用：前者按需加载工具定义以省 token，后者让模型写一段脚本来编排循环、分支和并行的工具调用。

操作图形界面与浏览器的 Computer Use 在框架里同样留了位置，只是它需要在开发者自己的环境中实现执行，不算托管阵容的一员。这些“公共技能”人人用得上，官方做好放在那里；但业务工具得完全自己备，你的订单在哪个库、退款接口怎么调、邮件用什么服务发，只有你自己清楚。所以查订单、退款、发通知这些，还是要用普通代码写成函数登记给代理。这个设计其实很合理：代理的脑在 OpenAI 那边，手的插头在你这边，你决定接哪些工具，它才能碰到你系统的哪些部分，天然就是一条权限边界。而且自家能力一旦按 MCP 标准包装一次，别家支持 MCP 的 AI 也能直接用，工具写一遍到处插。

技术行业里很多大事，回头看都不是“从无到有”，而是“门槛塌方”。云计算没有发明跑网站，它只是把自建机房的活买断了；Agents API 也没有发明 AI 代理，它只是把造代理的地基从专业团队几个月的工程，压缩成了一个人一周的调用。门槛每降一个数量级，做这件事的人就会多一个数量级。往后一两年，值得期待的不是 OpenAI 自己能干多少活，而是那些用这套地基盖出来的、真正会办事的 AI 应用，会一个接一个冒出来。