OpenAI Agents API开启公测，云端智能体开始“连续上班”

OpenAI于当地时间2026年9月10日开放Agents API公测，开发者现在可以通过一次API调用，创建由OpenAI负责运行和维护的云端智能体。智能体能够执行代码、读写文件、调用外部工具、保存中间结果，并在跨越数小时甚至数天的任务中持续推进，而不是每次只返回一段模型文本。

**Agents API是OpenAI提供的托管式智能体运行基础设施，负责协调模型、工具、沙盒、上下文和任务状态，让开发者无需从零搭建智能体执行框架。**这次更新的重点，不是又发布了一个更大的模型，而是把Codex背后的执行框架和云端计算环境，进一步封装成可供第三方应用直接使用的产品。

对于已经做过智能体原型的开发者来说，这个变化很实际：过去需要自行维护任务队列、容器生命周期、文件系统、上下文截断、失败重试和子任务调度；现在，这些工作可以交给OpenAI提供的运行时处理。开发者更需要关注的，则变成智能体应该掌握哪些工具、能访问哪些数据，以及在什么条件下允许它采取行动。

一次调用创建生产级智能体，但“生产级”不等于零配置

OpenAI表示，开发者可以指定任务、模型、工具和运行环境，通过一次API调用创建一个面向生产环境的智能体。这里的“一次调用”更准确地说，是把基础设施初始化和运行流程封装起来，并不意味着开发者不需要设计工作流。

一个真正可用的智能体，至少需要明确四件事：

1. 任务边界：智能体可以做什么，不能做什么；
2. 工具权限：能否访问数据库、代码仓库、浏览器、企业内部系统或文件目录；
3. 执行环境：代码和文件在哪个沙盒中运行，使用多少CPU、GPU、内存与存储；
4. 恢复策略：任务失败、容器过期、上下文耗尽或外部工具不可用时，如何继续执行。

Agents API的价值，在于把第四件事从“应用开发者必须自己实现的基础设施”变成了运行时能力。开发者仍要设计业务逻辑，但不必再把大量时间花在如何让一个任务稳定跑过多个容器、多个上下文窗口和多个执行阶段上。

这也是它与传统函数调用接口的主要区别。普通函数调用通常是模型给出一个工具请求，应用执行工具，再把结果交回模型；Agents API则更接近一个托管的任务操作系统，模型可以在运行时中反复思考、调用工具、读取产物、调整计划，并在需要时进入下一轮执行。

长任务是这次更新真正的核心

**长周期智能体是指能够跨越多个执行阶段、上下文窗口和计算环境，持续完成一个复杂目标的智能体。**Agents API支持智能体连续执行数小时甚至数天，这让它瞄准的场景不再只是客服问答或短文本生成，而是软件工程、数据分析、研究调查、文档处理和持续运营等任务。

例如，一个代码智能体可以先分析一个大型仓库，接着运行测试、定位失败用例、修改多个文件，再执行回归测试，最后生成变更说明。一个研究智能体则可能先收集资料，再整理数据、运行分析脚本、生成图表，隔天继续补充新的数据源并更新报告。

过去，这类任务最容易在三个地方断掉：

• 上下文窗口不够用：早期的任务计划、工具结果和文件摘要不断累积，最终挤占模型可用上下文；
• 执行容器不稳定：沙盒可能到期、重启或发生故障，导致应用需要重新建立环境；
• 中间状态没有保存：即使模型知道下一步要做什么，应用也可能没有保存已经完成的文件、日志和检查点。

Agents API引入了上下文管理能力。当会话接近上下文限制时，运行时可以自动压缩早期信息，把历史内容整理成更紧凑的摘要，让智能体跨越多个上下文窗口继续执行。它的思路类似于把一份越来越长的项目日志，定期整理成“当前目标、已完成工作、关键决策、待办事项和文件状态”，而不是把所有原始记录永久塞回模型。

这种压缩并不是没有代价。摘要如果丢失了关键细节，智能体可能在后续阶段重复工作，或者错误理解早期决策。因此，开发者仍然需要把关键状态写入结构化文件、数据库或任务记录，而不能只依赖模型记忆。上下文管理解决的是“信息太多”的问题，不会自动解决“状态没有被可靠建模”的问题。

沙盒从附属组件变成智能体的工作区

**Hosted Sandbox是OpenAI托管的隔离执行环境，智能体可以在其中运行代码、处理文件、安装软件包并生成产物。**OpenAI此次同步推出OpenAI Hosted Sandbox，开发者无需自行搭建完整的容器和任务调度基础设施，就能为智能体配置文件、软件包、技能和插件。

该环境复用了Codex和ChatGPT使用的沙盒基础设施。对开发者来说，它提供的不是一个简单的代码解释器，而是一块可以被智能体持续使用的远程工作区：智能体能够创建文件、修改文件、运行命令、读取执行结果，并把中间产物留给后续步骤继续处理。

这对以下任务尤其重要：

• 在真实项目目录中进行代码审查和修改；
• 处理大量PDF、表格、日志和图片文件；
• 运行数据清洗、统计分析和可视化脚本；
• 生成可下载的报告、压缩包、图表和代码补丁；
• 在隔离环境中执行不应直接影响生产系统的命令。

沙盒的意义在于把“让模型输出代码”升级成“让智能体在受控环境里完成工作”。不过，隔离环境并不意味着可以无条件授予权限。企业仍需考虑网络访问、敏感文件挂载、依赖包来源、执行时长、资源配额和产物扫描等问题。尤其是能够连续运行数天的任务，权限管理和成本上限比模型本身的推理能力更容易成为生产事故的来源。

不只支持OpenAI托管沙盒，也支持外部基础设施

Agents API并不要求所有开发者使用OpenAI托管的计算环境。开发者也可以把智能体部署到自有基础设施，或者接入合作伙伴提供的沙盒。

OpenAI已经宣布与Blaxel、Cloudflare、Daytona、DigitalOcean、E2B、Modal、Oracle、Runloop和Vercel等服务商合作，为开发者提供不同的CPU、GPU、内存和存储配置。这个设计对企业客户尤其重要：模型调用可以由OpenAI提供，但代码执行、数据处理和网络访问未必需要离开企业现有的云环境。

| 运行环境 | 适合场景 | 主要优势 | 需要注意的问题 | |---|---|---|---| | OpenAI Hosted Sandbox | 快速原型、代码任务、文件处理 | 配置简单，与OpenAI运行时集成度高 | 资源规格、网络策略和数据边界需要核查 | | 开发者自有基础设施 | 企业内部系统、敏感数据、定制化执行 | 数据和权限控制更灵活 | 需要自行承担运维、扩缩容和故障处理 | | 合作伙伴沙盒 | 特定CPU/GPU需求、跨云部署、全球业务 | 可选择不同资源与地域 | 供应商能力、计费和兼容性存在差异 |

这意味着Agents API并非单纯的“把智能体托管给OpenAI”。它更像一个可插拔的执行层：OpenAI负责模型原生的智能体编排，外部基础设施负责提供不同类型的计算和数据边界。对需要GPU推理、企业内网访问或特殊合规配置的应用来说，这种架构比完全封闭的托管环境更有吸引力。

工具搜索和程序化调用，解决工具太多的问题

工具调用本身并不新，但当一个智能体接入几十甚至几百个工具时，工具定义会大量占用上下文，也会让模型更难判断应该调用哪一个。Agents API提供工具搜索和程序化工具调用，允许智能体在需要时才加载工具定义，而不是在每一轮都把全部工具说明放进上下文。

**工具搜索是指智能体先根据当前任务检索可能相关的工具，再按需加载具体工具定义。**例如，一个企业智能体可能同时拥有CRM、工单、财务、仓库和邮件工具；当用户要求查询订单时，系统不必把所有工具完整展示给模型，只需先找到订单查询和库存查询相关工具。

程序化工具调用则允许应用以更明确的方式组织工具执行，包括：

• 并行运行多个互不依赖的工具调用；
• 将一个工具的结果传递给下一个工具；
• 对工具返回结果进行筛选、聚合和格式化；
• 在满足条件后才继续执行下一阶段。

这能减少两类浪费。第一类是上下文浪费，智能体不再反复携带无关工具定义；第二类是执行浪费，互相独立的查询可以并行完成，而不是排队等待。对于需要同时检查多个代码模块、多个数据源或多个业务系统的任务，收益会比单轮文本问答明显得多。

但工具搜索也引入了新的评估问题：系统是否能稳定找到正确工具？工具名称和描述是否足够清晰？多个工具功能相近时，模型会不会选择权限更高但并不合适的工具？因此，工具目录设计、权限分级和调用审计，将成为智能体工程中的基础工作，而不是文档里的边角内容。

多智能体协作：最多3个并发子智能体只是起点

Agents API支持将复杂任务拆分成多个子任务，由子智能体并行执行，再由主智能体协调和汇总。OpenAI给出的示例中，开发者最多可以配置3个并发子智能体。

**多智能体协作是指由一个主智能体负责规划和汇总，再把相互独立的子任务分派给多个专门智能体并行处理。**例如，主智能体可以把一项市场研究拆成竞品资料收集、价格整理和用户评价分析三个子任务，最后统一检查结果并生成报告。

它的价值不只是“同时调用三个模型”。更关键的是隔离任务上下文：负责代码审查的子智能体不需要看到全部产品需求，负责数据分析的子智能体也不需要加载完整的项目讨论记录。每个子任务拥有更小、更干净的上下文，主智能体只接收经过整理的结果。

| 工作方式 | 执行特点 | 适合任务 | 主要瓶颈 | |---|---|---|---| | 单智能体串行执行 | 所有步骤由一个智能体依次完成 | 流程简单、依赖关系强的任务 | 速度慢，历史上下文容易膨胀 | | 主智能体+子智能体 | 独立任务并发处理，主智能体负责协调 | 研究、审查、资料收集、批量分析 | 协调开销、结果一致性和成本 | | 多智能体完全自治 | 多个智能体自由协商和执行 | 探索性研究、复杂规划 | 难以预测，调试和审计更困难 |

目前“最多3个并发子智能体”更像是一个实用的起点，而不是无限扩展的承诺。并发数越高，不一定意味着任务越快：如果多个子智能体争用同一数据源、修改同一文件或等待同一个外部系统，协调成本可能抵消并行收益。生产应用需要明确任务依赖、锁定共享资源，并设置超时和回滚机制。

它与Responses API、Agents SDK是什么关系

开发者需要区分Responses API、Agents SDK和这次公测的Agents API。Responses API更接近底层模型响应接口，适合生命周期较短、开发者希望自行管理循环、工具分派和状态的工作流；Agents SDK则提供更高层的智能体编排能力，包括任务转移、工具执行、安全防护和会话管理；Agents API则进一步把长周期执行、沙盒和云端运行时纳入托管基础设施。

可以把三者理解成不同层级：

• Responses API：开发者自己驾驶，控制力最高，适合短流程和定制化执行；
• Agents SDK：提供一套智能体开发框架，适合在应用中编排多个智能体和工具；
• Agents API：把执行环境、状态管理和长任务运行也纳入云端服务，适合不想自建运行基础设施的团队。

开发者不必在整个应用中只选一种方案。短请求可以走Responses API，复杂工作流交给Agents SDK，需要持久化执行和沙盒能力的任务则使用Agents API。这样的分层比“所有场景都交给一个超级智能体”更符合生产系统的实际需求。

基于开源Codex执行框架，但不是简单复制Codex

Agents API基于Codex背后的开源执行框架打造。OpenAI表示，开发者可以查看公开代码库，了解模型调用、工具协调和上下文处理的核心逻辑；OpenAI则负责持续维护该框架，并随着模型更新改进智能体能力。

这点对工程团队有两个影响。第一，开发者能够看到一部分运行时设计，而不是面对完全不透明的托管黑盒。第二，OpenAI可以把Codex在代码编辑、文件操作、命令执行和任务恢复方面积累的经验，直接迁移到更广泛的智能体应用中。

不过，开源执行框架与托管Agents API并不是一回事。开源代码提供了理解和自建的基础，托管服务还涉及调度、沙盒供应商、资源隔离、持久化状态、监控和服务可用性。团队需要根据数据敏感程度、运维能力和部署速度作出选择，而不是简单地把“可查看源码”理解为“所有运行细节都可以自行控制”。

定价：公测不额外收平台费用，但成本不会消失

目前Agents API已向所有开发者开放公测，OpenAI表示不会额外收取一项独立的API使用费用。需要注意的是，长期运行并不等于免费运行：模型Token、工具调用、沙盒资源、文件处理和外部基础设施，仍可能带来实际成本，具体以官方账户和合作伙伴的计费规则为准。

长任务的成本结构与普通聊天请求不同。一次持续数天的任务，可能经历数百轮模型调用，产生大量工具结果，并占用CPU、内存或GPU资源。如果应用没有设置预算和终止条件，智能体可能因为反复尝试、错误重试或工具异常而持续消耗资源。

建议开发者在公测阶段至少加入以下控制：

• 为单次任务设置最长运行时间；
• 为模型调用、工具调用和沙盒资源设置上限；
• 对高风险工具增加人工审批或二次确认；
• 保存每个阶段的输入、输出、文件变更和错误日志；
• 使用固定测试集评估任务成功率、平均耗时和单位任务成本；
• 对重复失败的步骤设置熔断，而不是让智能体无限重试。

OpenAI想卖的不是“更会聊天”，而是云端工作流

这次发布的战略信号非常清晰：OpenAI正在把竞争重点从模型调用推向智能体基础设施。模型能力决定智能体能不能做出正确判断，但真正决定企业是否愿意部署的，是任务能不能跑完、失败后能不能恢复、权限能不能审计，以及成本是否可控。

Agents API的优势在于，它把Codex式的文件和代码操作能力、上下文压缩、沙盒执行、工具搜索和多智能体编排，组合成了一套面向生产的运行时。对于想快速把智能体从演示原型推进到真实业务的团队，这比再增加一个聊天界面更有价值。

但它也不是万能的“自主员工”。数天级别的连续执行会放大所有工程问题：错误目标会持续错误，错误权限会持续造成影响，模糊的工具描述会导致错误调用，缺乏检查点的工作流会在故障后难以恢复。开发者不能只测试最终答案，还需要测试中间步骤、异常分支、权限边界和恢复行为。

我们的判断是，Agents API对以下团队最有用：

1. 已经拥有明确业务流程，但不想自建沙盒和任务调度系统的产品团队；
2. 需要让智能体处理文件、代码和数据，而不只是生成文本的开发者；
3. 希望同时利用OpenAI模型和外部云计算资源的企业；
4. 需要把研究、审查、分析等长任务拆分给多个智能体的应用团队。

而对于只需要一次模型响应、简单函数调用或严格掌控每一步执行逻辑的应用，直接使用Responses API或自建运行时可能更合适。Agents API真正解决的是“如何让一个智能体稳定地工作很久”，不是“如何让每一次回答都更聪明”。

随着公测推进，开发者最值得观察的并不是演示中智能体能完成什么，而是四项生产指标：长任务成功率、容器故障后的恢复率、工具调用的可审计性，以及每个完成任务的综合成本。如果这些指标能够达到企业可接受的水平，云端智能体才会从概念产品变成真正的应用基础设施。

参考来源

• IT之家：OpenAI Agents API开放公测——关于公测时间、云端智能体能力、Hosted Sandbox、合作伙伴沙盒和最多3个并发子智能体的报道。
• OpenAI Agents SDK中文文档——介绍Agents SDK与Responses API的适用场景、工具调用、任务转移、会话和沙箱智能体等能力。
• OpenAI Agents SDK演进介绍——关于模型原生运行框架、快照恢复、跨容器执行和持久化智能体的官方说明。
• OpenAI Agents SDK Python代码库——用于了解OpenAI智能体SDK实现和开发进展的公开代码库。

本文根据2026年9月11日可获得的公开资料整理。Agents API处于公测阶段，具体模型支持、资源规格、计费和合作伙伴能力可能随版本更新而变化。