OpenAI 于 9 月 10 日发布 Agents API 公测，将支撑 Codex 的智能体运行时与会话基础设施通过 API 对开发者开放，支持托管或自托管沙箱、长时任务、上下文压缩和多智能体编排。该服务在公测阶段免收平台费用，但数据驻留、权限控制与成本等企业治理问题仍需评估。
OpenAI 9月10日宣布，面向开发者推出 Agents API 公测版。该服务把支撑 Codex 的智能体运行框架与基础设施通过 API 开放出来，允许开发者指定任务、模型、工具和执行环境，构建能够持续运行、处理文件、执行代码并协调多个子智能体的应用。
OpenAI称，Agents API 目前向所有开发者开放公测，不另收 API 平台层面的费用，开发者仍需按照所使用的模型、工具及计算环境支付费用。官方公告：Introducing the Agents API。
从“调用模型”转向“托管智能体运行时”
过去，开发者通常需要自行处理模型调用、工具调度、上下文保存、任务恢复和多智能体编排。OpenAI此次提供的 Agents API，则试图把这些环节集中到一个由 OpenAI 管理的运行时中。
根据 Agents API 官方文档，开发者可以围绕四个核心对象构建应用：智能体、执行环境、会话，以及会话中的事件和项目。应用负责提供任务、工具和环境选择，OpenAI则负责会话管理、编排、上下文压缩与恢复。
在最简单的使用方式中，开发者只需要创建一个会话，指定模型和指令，再提交任务。智能体可以在运行过程中输出进度，接受进一步引导，并在同一个会话中继续处理后续工作。
这使 Agents API 与直接调用 Responses API 或使用 Agents SDK形成了区别。Responses API更适合开发者自行掌控模型响应、工具分发和状态管理；Agents SDK则把运行循环、工具执行、交接和会话等部分放入开发者自己的应用。Agents API的特点是由 OpenAI 托管 Codex 运行框架和会话基础设施，减少应用侧需要自行搭建的运行时组件。
可选择 OpenAI 托管或自有环境
Agents API并不把所有应用都限制在 OpenAI 的基础设施中。OpenAI表示，开发者可以选择 OpenAI 托管的沙箱，也可以使用自己的基础设施，或者接入合作伙伴提供的沙箱环境。
此次公布的生态合作方包括 Blaxel、Cloudflare、Daytona、DigitalOcean、E2B、Modal、Oracle、Runloop 和 Vercel。不同环境可以提供不同的 CPU、GPU、内存、存储和网络配置，也可以满足企业在私有网络或 VPC 中运行任务的要求。
OpenAI同时推出了托管沙箱。该环境使用与 Codex 和 ChatGPT 相关的沙箱基础设施，能够让智能体在受控空间内运行代码、处理文件并生成结果。开发者可以向环境中配置文件、软件包、技能和插件，使智能体具备完成特定任务所需的条件。
官方文档给出的快速入门示例，是让智能体在 OpenAI 托管沙箱中创建一个 Python 文件、运行程序并返回实际输出。开发者需要为 API 项目授予 Agents API 会话相关权限，并使用 OpenAI-Beta: agents=v1 请求头；OpenAI 的 SDK会自动处理这一请求头。
不过，托管沙箱并不等于所有数据控制要求都得到解决。当前文档说明，Agents API的数据驻留仅支持美国，同时不支持 Zero Data Retention（ZDR）。选择自托管沙箱，也不会自动使 Agents API符合 ZDR要求。这对于处理敏感数据的金融、医疗和政府客户而言，是部署前需要单独评估的限制。
重点是让智能体持续工作更久
OpenAI此次发布将重点放在长时间、跨步骤的任务上。官方称，Agents API可以自动压缩较早的上下文，在接近上下文限制时保留继续完成任务所需的信息，从而让一个工作流跨越多个上下文窗口运行。
它还支持在任务中调用 MCP、自定义函数和内置工具，例如网络搜索。工具搜索机制可以按需加载相关工具定义，减少不必要的 token 消耗；程序化工具调用则允许智能体在代码中并行执行调用、串联操作，并先过滤或合并大量结果，再把较少的相关信息带回模型上下文。
对于复杂任务，Agents API还提供多智能体能力。主智能体可以把研究、分析或编码任务拆分给多个子智能体，让它们并行工作；每个子智能体拥有相对独立的上下文，主智能体再负责协调和汇总结果。
OpenAI将这些能力描述为 Codex 工作方式的 API 化。官方介绍称，Agents API由开源 Codex harness提供底层基础，开发者可以查看公开代码库，了解模型调用、工具使用和上下文管理等核心逻辑。
OpenAI 试图把“智能体基础设施”变成产品层
这次发布延续了 OpenAI过去一年围绕智能体建立开发者平台的路线。2025年推出的 Responses API与 Agents SDK 已经把内置网络搜索、文件搜索、计算机使用、工具调用、交接和追踪能力带入 API 体系；随后，OpenAI又发布 AgentKit，提供可视化编排、连接器管理、ChatKit 和评估能力。
Agents API的新增重点，不是再提供一个单独的模型，而是把运行环境、长时任务和恢复机制放到平台层。对于开发者来说，这可能减少从原型走向生产时需要自行维护的基础设施；对于 OpenAI来说，则意味着它不仅提供模型，也在竞争智能体执行任务所依赖的“控制层”。
OpenAI此前更新 Agents SDK 时，也强调了沙箱、文件系统工具、MCP、技能、持久化状态和失败后恢复等能力。新版 SDK支持快照和重新加载，使沙箱失效或过期时，智能体可以在新的容器中从检查点继续运行。这些能力与 Agents API形成互补：前者让开发者在自己的应用中管理智能体运行时，后者则把更大部分运行管理交给 OpenAI。
这种产品方向正在从编码任务扩展到企业工作流。AIFlux此前报道的 OpenAI Data agent 已经把企业数据连接、指标分析、仪表板生成和后续行动放进同一个智能体流程；而 GPT-Live-1 API 则把实时语音交互与后台模型和工具调用结合起来。Agents API提供的是更底层的通用运行框架，开发者可以在此基础上构建类似的专业化代理。
仍需解决权限、安全和成本问题
OpenAI强调，智能体可以在沙箱中运行代码、编辑文件、访问工具和生成制品，但这并不意味着企业可以忽略权限控制。越是接近真实工作流的智能体，越需要明确它能够读取哪些文件、连接哪些系统、执行哪些命令，以及哪些动作必须经过人工批准。
OpenAI的 Agents SDK文档提醒，智能体系统应当假设存在提示注入和数据外泄尝试。把模型运行的沙箱与管理智能体的控制层分开，有助于避免凭据直接暴露给模型生成的代码；但具体应用仍需要自行配置网络、密钥、文件挂载和工具权限。
此外，Agents API的价格结构也需要按照完整运行链条计算。API本身没有额外的平台费用，但模型调用、内置工具、外部工具和沙箱容器都会产生相应成本。长时间运行、多智能体并行和较复杂的工具链，可能比一次性的文本问答消耗更多资源。
观察智能体产品时，一个重要区别是“能够完成演示”与“能够可靠地运行生产任务”。上下文压缩可能帮助任务跨越更长时间，但开发者仍需要验证压缩后是否保留了关键事实；并行子智能体可以缩短部分流程，却也会增加协调、重复工作和错误汇总的可能性；自动恢复提高了持续运行能力，但不会自动判断上一次中断前的状态是否安全。
公测阶段的几个待观察问题
Agents API目前仍处于公测阶段，OpenAI表示将根据开发者反馈快速迭代。后续值得关注的重点包括：更多语言和 SDK支持何时到位，OpenAI托管沙箱的区域和数据控制选项是否扩大，以及不同沙箱提供商之间的能力差异能否被稳定抽象。
OpenAI还需要说明更具体的企业治理机制，包括会话和制品的生命周期管理、审计范围、敏感数据处理、人工审批、失败恢复和跨组织权限控制。对于需要在企业内部部署的应用，能够否连接现有身份系统和安全监控平台，往往与模型能力同样重要。
可以确认的是，OpenAI正在把 Codex所代表的长时间编码和工具使用能力，包装成一种面向更广泛开发者的智能体基础设施。Agents API降低了构建长期运行、多工具、多智能体应用的门槛，但它并没有消除这类系统的治理成本。下一阶段的竞争，可能不只是哪个模型更强，而是谁能在可控的执行环境中，让智能体持续、可追踪并且在需要时停下来。
来源：