AIREITEROpenAI Agents API 已进入公测，但它既不是更便宜的模型调用替代品，也不是开箱即用的自动化平台。OpenAI 负责管理 Agent Harness，开发者则需要自行选择执行环境、工具和运行边界。
先说结论：这次发布了什么，谁值得关注
OpenAI 于 2026 年 9 月 10 日宣布推出 Agents API 公测版，面向开发者开放。根据官方公告，它提供了一种托管式方式，让云端 Agent 使用 Codex Harness、模型、工具以及开发者选定的沙箱运行。
如果团队已经在开发需要长期运行、频繁调用工具的 Agent，Agents API 会更有吸引力。对于边界清晰的请求，直接使用 Responses API，再配一个简易的应用循环，往往更简单。
| 问题 | 答案 |
|---|---|
| 现在可以使用吗？ | 可以，目前是公测版，还不是 GA |
| Agents API 是否收取独立的平台费用？ | OpenAI 表示不会；但模型和工具的使用仍然会产生费用 |
| 所有应用代码都由 OpenAI 运行吗？ | 不是。你可以选择 OpenAI 托管、合作伙伴托管或自行托管的执行环境 |
| OpenAI 负责管理什么？ | Agent Harness，包括编排和长会话处理 |
| 适合直接用于生产环境吗？ | 适合受控试点；由于仍处于公测阶段，必须准备回滚方案 |
架构的关键：先决定代码在哪里执行
Agents API 将推理循环与实际执行任务的环境分开。Harness 可以负责会话、上下文、工具选择和任务委派，而沙箱则用于运行代码、处理文件或生成产物。
架构文档是理解两者边界的权威来源。根据发布报道，目前提到的合作伙伴执行环境包括 Blaxel、Cloudflare、Daytona、DigitalOcean、E2B、Modal、Oracle、Runloop 和 Vercel。它们的价格和区域能力并不相同，不能简单互换。
| 执行方式 | 适合场景 | 主要取舍 |
|---|---|---|
| OpenAI 托管沙箱 | 快速原型和托管式执行 | 基础设施控制权较少 |
| 合作伙伴沙箱 | 已有合作伙伴关系，或需要特定的部署形态 | 价格和运行行为取决于具体提供商 |
| 自行托管环境 | 已有安全、网络或基础设施要求 | 更多可靠性和运维工作由团队自行负责 |
如果网络策略、密钥管理、数据驻留或文件系统控制不可妥协，应该优先考虑自行托管。如果更看重上线速度，则可以选择托管式执行，但前提是先针对具体提供商测试其套餐、超时、持久化和产物处理行为。
无论采用哪种方式，密钥、文件、网络访问权限和持久化状态等治理决策仍然由团队掌握。
公测版到底带来了什么
Agents API 概览及相关文档介绍了多项能力，主要面向那些一次模型调用无法完成的任务。
长会话与上下文压缩
在长时间运行过程中，自动上下文压缩有助于控制上下文不断膨胀。不过，OpenAI 并未承诺统一的压缩比例或最长运行时长。实际效果需要用具有代表性的工作负载进行测量。
工具搜索与并行调用
工具搜索可以减少每次模型上下文中需要携带的工具信息。对于彼此独立的调用，以编程方式并行执行工具可以缩短整体耗时。但这并不意味着存在依赖关系的调用也能安全并行：如果调用工具 C 必须先拿到结果 B，那么这个流程仍然是串行的。
多智能体委派
主 Agent 可以将子任务委派给其他 Agent，也可以并行处理。这对边界明确的研究、分类或产物生成任务很有用，但同时也会增加失败路径和计费路径。因此，在应用设计阶段就应该明确子 Agent 数量上限和最大轮数策略。
执行环境
文档分别介绍了 OpenAI 托管沙箱和自行托管沙箱。在做选择前，应针对确切的提供商测试软件包安装、文件系统持久化、网络策略、凭据、超时和产物处理等环节。
成本怎么算：没有平台费，不等于免费
OpenAI 表示，公测期间 Agents API 本身不会额外收取平台费用。但最终账单仍可能包含模型 Token、内置或外部工具，以及沙箱基础设施等成本。
| 成本层 | 需要纳入预算的项目 |
|---|---|
| 模型调用 | 每一轮调用及每个子 Agent 产生的输入和输出 Token |
| 内置工具 | 适用时产生的工具专项使用费用 |
| 沙箱 | 计算、存储、网络或提供商收取的其他费用 |
| 应用运维 | 日志、队列、数据库、监控和重试 |
独立的 A8gent 成本分析说明了为什么不能只按一次调用来估算费用。以每月 1,000 次分流任务、每次 3,000 个输入 Token 和 400 个输出 Token 为前提，该分析估算使用 gpt-5-nano 时每月模型 Token 成本约为 $0.31，使用 gpt-5.6-sol 时约为 $27，且不包含托管费用。这些数字是文章基于当时情况进行的计算，并不是 Agents API 的官方报价。
多轮工作流的成本会高于单次调用估算，因为后续轮次会携带不断累积的上下文。预算应当以你自己的实际使用数据为基础。
更稳妥的试点方案应该设置最大轮数、限制并发任务数量、记录每个已完成业务结果对应的 Token 用量，并为单次运行设置支出上限。OpenAI Cookbook 的单次运行支出控制器示例明确说明其中的价格是虚构的，但它的预留机制很有参考价值：每次请求前先按最坏情况预留金额，请求结束后再根据实际用量结算。
正式采用前，先把这些生产问题问清楚
由于公测 API、集成方式和限制都可能发生变化，应保留一套备用方案，确保可以停止新任务，同时不破坏事实数据。
早期实践者之一 @yandt888提出了对美国数据驻留的担忧，以及自行托管执行与零数据保留要求之间可能存在的关系。这只是用户提出的疑虑，并非 OpenAI 的政策声明；在发送受监管数据前，请根据你的账户核实当前的合同条款和区域条款。
正式采用前，请确认：
- 任务失败后能否恢复运行，同时避免重复执行外部操作。
- 会话记录、文件和产物存储在哪里，以及提供商发生故障时会如何处理。
- 团队能否追踪子 Agent 的决策、复现输入，并在公测协议发生变化时完成迁移。
演示终究只是演示：对不可逆操作设置审批门槛，尽可能让工具具备幂等性，并使用真实集成测试提示词注入和部分失败等路径。
更实际的采用边界
当真正棘手的问题是协调跨工具、跨会话或跨专业 Agent 的复杂工作，而且任务需要大量判断时，Agents API 值得优先尝试。可以先从文档分流、内部研究或产物生成这类边界明确的任务开始，再与原本需要自行维护的简单循环进行对比。
| 如果你的优先级是…… | 可以从……开始 |
|---|---|
| 快速获得托管式编排能力 | Agents API 试点 |
| 最大程度控制工作流状态 | 自行构建编排层 |
| 严格要求提供商可迁移 | 与模型无关的框架或网关 |
| 高可靠审批和审计 | 围绕 Agent 搭建工作流引擎 |
| 成本最低且可预测的单轮调用 | 直接调用模型 API |
开展试点时，明确一个成功指标、每项任务的最高成本、最长运行时长，以及一个人工审批节点。如果托管 Harness 没有明显减少工程投入，也没有改善故障恢复行为，就不要让它成为新的公测依赖。
OpenAI Agents API 常见问题
OpenAI Agents API 已经正式发布了吗？
还没有。OpenAI 于 2026 年 9 月 10 日宣布其进入公测阶段。发布材料尚未宣布 GA。
可以使用自己的沙箱吗？
可以。除了 OpenAI 托管和合作伙伴环境外，OpenAI 也将自行托管环境列为可选方案。采用这种方式后，安全、网络、持久化和运维工作将更多由你的团队负责。
它支持多智能体工作流吗？
支持。该 API 支持将任务委派给子 Agent，也支持并行处理。但应设置明确的限制，因为每增加一个 Agent，都可能带来更多延迟、更高 Token 用量和新的失败模式。