OpenAI Agents API 开放公测，所有开发者都能用上托管的 Codex 编排框架

OpenAI 于 2026 年 9 月 10 日向所有开发者开放了 Agents API 公测，把运行 Codex 和 ChatGPT for Work 的同一套托管编排基础设施，作为一等 API 原语提供出来。这是第一次，任何开发者都可以运行一个长时间工作的 AI 智能体，享有自动上下文管理、并行子智能体委派和沙箱代码执行，而不必写一行编排框架（harness）逻辑 —— 除了标准的模型 token 和工具用量之外，也不用额外付费。

开发者一直在自己解决的编排难题

过去两年的大部分时间里，把一个 AI 智能体推上生产意味着要解决两个不同的问题。第一个是模型问题：用哪个基础模型、配什么提示方法。第二个是编排问题：如何让智能体连续运行数小时乃至数天，模型上下文窗口塞满了怎么办，如何高效地路由工具调用，任务可以拆分时如何拉起并行的工作者。对大多数团队来说，第二个问题耗费的工程时间不比第一个少。

Agents API 把第二个问题整个外包了出去。开发者在创建会话的调用里指定智能体的模型、指令、工具和计算环境；其余一切由 OpenAI 管理。处理这些细节的编排框架，就是 OpenAI 内部用于 Codex 的那一套 —— Codex 如今每周有超过两百万活跃用户，单个会话中的任务可以持续数小时。

托管编排框架如何运作

Agents API 围绕四个概念组织：一个 agent（模型、指令、工具和 MCP 服务器连接）、一个 environment（智能体执行代码、写入文件的沙箱）、一个 session（智能体的持久有状态实例），以及 events（会话产生的流式输出）。会话创建之后，应用提交任务、接收事件；编排循环运行在 OpenAI 的基础设施上。

编排框架内部有三种机制，分别对付长时间运行的智能体的核心难题。

上下文压缩应对的是会让大多数简单智能体循环中止的上下文窗口上限。当会话接近上限时，编排框架会自动把较早的对话轮次总结成一份紧凑的表示，让智能体接着往下做。自己搭智能体循环的开发者，得自己实现这套总结逻辑；Agents API 把它做成了自动的、在服务端完成的。OpenAI 自己的基准测试发现，保留推理和上下文压缩把 GPT-5.6 Sol 的ARC-AGI-3 分数从 13.3% 提高到 38.3%，同时把输出 token 消耗降到六分之一 —— 这一结果表明，决定智能体成败的不只是模型质量，编排框架的设计也能实质性地改变结果。（该测试使用的是 OpenAI 自己的 Responses API，而非这个基准的标准化评测环境；ARC Prize 在回应中指出了这一方法论上的区别。）

工具搜索与程序化工具调用应对的是大型工具目录带来的 token 开销。编排框架不是把所有可用工具的定义都塞进每一次模型上下文，而是用一个工具搜索机制，只在需要时加载相关定义，从而保住提示词缓存、降低 token 成本。程序化工具调用则让智能体可以并行执行多个工具调用、串联操作，并在把结果返回模型上下文之前先做过滤 —— 只保留相关的部分，而不是把每一个工具结果都倒回对话里。

多智能体委派让主智能体可以把复杂任务拆成相互独立的部分，分派给并发运行的子智能体会话，每个子会话有自己的上下文。主智能体负责协调时机，并在子智能体完成后综合结果。开发者通过一个参数配置最大并发数 —— API 文档中的示例最多用到四个并发子智能体。抢先体验客户 Ciridae 描述的成果就来自这一机制：从自研编排系统迁移过来之后，在大量使用子智能体的工作流上延迟降低了 4 倍，评测分数从 0.71 提升到 0.85。这些数字由公司提供，未经独立复现，但这个机制在架构上是成立的：当步骤彼此独立时，串行的多步工作流就可以并行化。

延伸阅读：OpenAI 的 Codex 持续模式：让智能体无限期地自己跑、自己派活

运行编排框架的三种方式

Agents API 支持三种计算配置。OpenAI 托管的沙箱会自动开通和管理执行环境 —— 与运行 Codex 云端任务的是同一套基础设施 —— 是最快的部署路径。自托管环境让机构在自己的基础设施上运行智能体计算，同时由 OpenAI 管理编排框架的控制面。九家生态合作伙伴 —— Blaxel、Cloudflare、Daytona、DigitalOcean、E2B、Modal、Oracle、Runloop 和 Vercel —— 提供一等集成，涵盖托管环境、VPC 部署，以及在 CPU、GPU、内存、冷启动和成本上各不相同的配置。

定价模式很透明：开发者按所选模型的标准 API token 价格付费，按标准价格支付 OpenAI 自建工具（网页搜索、代码解释器）的费用，并按容器价格支付 OpenAI 托管沙箱的费用。没有额外的编排框架或编排费用。

与其他方案相比如何

Agents API 并不是唯一可用的托管智能体编排框架。Anthropic 提供 Claude Managed Agents 作为同类服务 —— 它提供完整的服务端编排，包括有状态会话、基于事件的流式输出、自动压缩和工具执行，并有包括欧盟在内的全球数据驻留选项。谷歌的 Vertex AI Agent Engine 是另一个主要的托管替代方案，围绕其 Agent Development Kit 提供类似的会话编排。截至发稿，这两项服务都没有公布与 Agents API 在同等工作负载下的价格对比基准。

OpenAI 自己的 Agents SDK —— 一个独立的开源编排库 —— 仍然可供那些更愿意把编排循环托管在自己应用里的开发者使用。这个 SDK 保留了可移植性，允许使用非 OpenAI 的模型提供方，并让开发者可以用自己的追踪和调试工具完整看到智能体循环。Agents API 用这份控制权换来了简单：循环运行在 OpenAI 的服务器上，这意味着压缩的时机、工具调用的调度以及子智能体的生命周期管理，都发生在开发者无法直接观察的地方。

对于已经在运行 LangGraph 或 CrewAI 这类框架的团队来说，Agents API 代表的是一种不同的架构理念，而不是直接替代品。那些框架优先考虑的是提供方灵活性和本地可观测性；Agents API 优先考虑的是运维简单，以及随 OpenAI 的模型发布自动演进。OpenAI 宣布的「共同演进」承诺 —— 它将随每一次模型发布维护和改进编排框架，开发者会自动获得编排框架的改进 —— 如果能一直维持到正式发布，可能会成为它最强的竞争差异点。

眼下真正要紧的限制

有两项约束划定了这次公测当前的边界。第一，Agents API 只支持美国的数据驻留。选择沙箱并不能缓解这一点：选用自托管或合作伙伴沙箱，并不会把 API 控制面挪到美国以外。对于在欧盟运营的机构、有严格数据本地化要求的受监管行业，或在美国总部基础设施会带来合规风险的市场，在 OpenAI 增加其他驻留区域之前，这是一道硬性障碍。对这些部署而言，目前可用的替代方案是 Agents SDK、Responses API 或自托管的开源编排框架。

第二，Agents API 在公测期间不支持零数据保留（Zero Data Retention）。零数据保留会让提示词和补全内容在 API 响应之后立即丢弃、不做日志记录，许多企业安全政策以及受 HIPAA 约束的工作负载都要求这一点。这两项限制在新 API 的公测阶段都很常见，可能会在正式发布前解决，但 OpenAI 没有公布时间表。

此外还有一个无论数据驻留如何都存在的可观测性上的结构性取舍：那些在自己的智能体循环之上搭建了内部追踪、会话回放或审计工具的团队，迁移到 Agents API 后会失去这一层，除非他们通过 API 暴露的流式事件接口重建同等的覆盖。

API 背后的基础设施之争

Agents API 契合基础设施史上一个可辨认的模式：一家提供方大规模运营一个复杂系统，摸清了让这个系统在生产中可靠运行需要什么，然后把这份运维经验作为托管服务提供给第三方。Codex 的编排框架并不是作为 API 产品设计的 —— 它是为了运行 Codex 而建的。OpenAI 决定把它开放出来，是承认了对于认真构建智能体应用的团队来说，编排框架与模型同样有价值。

通过在服务端管理编排框架，OpenAI 让自己处在一个无论开发者最终用哪些模型、都能掌握编排层的位置 —— 原则上，即便模型提供方越来越多，这个编排框架也能充当协调层。位于 github.com/openai/codex 的开源代码库让编排框架可以被审视，这在一定程度上回应了透明度的担忧，但托管服务的控制面仍是专有基础设施。数据驻留和零数据保留这两项限制能否在正式发布前解决，将决定 Agents API 能否在经济利益最大的企业部署中，彻底取代自建的编排框架实现。