本文要点
- 从SDK和自建编排，变成OpenAI托管harness和会话基础设施。
- 从单模型调用，变成任务、工具、环境和subagents的会话级API。
- 从只看模型价格，变成按tokens、tools和执行环境评估总成本。
阅读辅助
先看数字、证据和来源，再读正文。
Agents API的当天增量是public beta，而不是旧Agents SDK重新包装。
2026-09-10 · OpenAI发布Introducing the Agents API，宣布Agents API进入public beta。
OpenAI在9月10日把Agents API推到public beta，把Codex背后的运行层变成可购买、可托管、可组合的API能力。开发者过去要自己拼接agent loop、上下文压缩、工具路由、沙盒环境、长任务状态和子Agent编排；现在OpenAI给出的叙事是，一次API调用可以创建agent session，平台负责harness和基础设施，应用团队把精力放在工具、知识和业务流程上。
公告里的确定信息集中在状态、范围和计费。发布日期是2026年9月10日，正文写明Agents API “is available in public beta today to all developers”。同一段也写明“no additional fees for using the Agents API”，但这不是免费使用；下一句紧接着说开发者仍按agents使用的tokens和tools付费。公告还列出可选环境：OpenAI托管sandbox、自有基础设施，以及Blaxel、Cloudflare、Daytona、DigitalOcean、E2B、Modal、Oracle、Runloop、Vercel这9家sandbox伙伴。
生产化边界仍要单独看。OpenAI没有在公告里给出GA时间、企业SLA、默认速率限制、会话保留策略、审计日志粒度或sandbox网络权限细节。Ciridae的客户引语提供了醒目的数字：eval score从0.71到0.85，subagent flows带来4x latency reduction。这可以说明某个客户迁移后的体验，但不能直接外推为所有Agent工作流都会得到同等收益。
受影响最大的是正在自建Agent平台的开发者团队。它们要重新计算“买模型”和“买运行层”之间的边界：继续自建可以保留更多控制权；使用Agents API可以减少编排和运维负担，但也会把长会话、工具调用、沙盒隔离和可观测性的一部分交给OpenAI及其生态伙伴。企业买方则要把问题从“模型是否足够强”改成“托管执行环境能否被审计”。
这次公测新增了哪一层
OpenAI公告开头先解释背景：Codex和ChatGPT for Work已经服务全球数百万人，长任务Agent要在实践中跑好，需要一套能够管理上下文、高效使用工具、协调subagents的harness，也需要能够让任务稳定运行数天的基础设施，包括文件、代码执行和中间结果保存环境。随后才给出news peg：Agents API进入public beta，把“powers Codex”的同类harness和基础设施通过API交给开发者。
这和已有Agents SDK不是同一个层级。Agents SDK文档描述的是一个轻量但强的多Agent工作流框架，包含agents、tools、guardrails、human in the loop、sessions和tracing等概念。它适合应用代码层的编排。Agents API公告强调的是OpenAI托管并维护harness，开发者选择执行环境，让会话在云端保持运行，并把上下文管理、工具搜索、程序化工具调用和subagents放进同一个session对象里。
公告里的JavaScript示例把这个抽象写得很直观：client.beta.agents.sessions.create接收agent配置，里面有模型、MCP工具、multi_agent开关、vault、openai_hosted环境，以及一段让主Agent委派deployment、error和dependency分析给subagents的任务。示例中的max_concurrent_subagents: 3只是代码样例，不是OpenAI宣布的并发上限。早报因此把它作为“示例并发”，而不是产品容量承诺。
| 组件 | 公告中的定位 | 早报采用口径 | 未披露边界 |
|---|---|---|---|
| Agents API | public beta today to all developers | 9月10日面向所有开发者公测 | GA时间和兼容性承诺未披露 |
| Codex harness | same harness and infrastructure behind Codex | Codex运行层产品化 | harness版本策略仍待观察 |
| OpenAI hosted sandbox | powers Codex and ChatGPT的同类sandbox | 可运行代码、处理文件、产出artifacts | 网络、密钥和持久化权限未展开 |
| 工具体系 | MCP、自定义函数、内置web search | 工具连接进入会话级配置 | 第三方MCP安全边界待验证 |
| 计费 | no additional fees；pay for tokens and tools | API本身无额外费，使用仍按tokens和tools计费 | 沙盒资源和失败重试成本需实测 |
这张表的重点是状态和范围。OpenAI说的是public beta，不是GA；说的是all developers，不是只限企业白名单；说的是Agents API没有额外费用，不是免费运行Agent；说的是可以选择OpenAI托管、自有基础设施或伙伴sandbox，不是所有执行环境都由OpenAI统一托管。
状态词和计费词要逐句读
这类平台公告最容易在转述中失真。OpenAI原文的几个短语需要保留时态和动作边界：
| 原文措辞 | 中文表述 | 不能写成 |
|---|---|---|
| “Today, we’re introducing the Agents API in public beta” | 今天推出Agents API public beta | 已正式GA或全面稳定发布 |
| “available in public beta today to all developers” | 今天面向所有开发者公测可用 | 仅限企业客户或邀请制 |
| “There are no additional fees for using the Agents API” | 使用Agents API本身无额外费用 | 使用Agent完全免费 |
| “you simply pay for the tokens and tools your agents use” | 按Agent使用的tokens和tools付费 | 只按模型token付费 |
| “Keep agents working across long sessions” | 让Agent在长会话中保持工作 | 再次提高长上下文窗口 |
| “automatically compacts earlier context” | 接近上下文上限时自动压缩早期上下文 | 永久保留完整上下文 |
尤其是最后两项。公告里的“Keep agents working across long sessions”不是说模型上下文窗口再次扩大，而是说OpenAI构建了context management，能够在session接近上下文限制时自动压缩早期上下文，保留Agent继续执行所需信息。它解决的是长任务续航和状态整理，不是宣布新的上下文长度数字。
计费也类似。OpenAI的价格页是公告指向的背景入口，但公告没有给出“一个完整Agent任务多少钱”。它只确认Agents API本身没有额外平台费，用户为tokens和tools买单。真实账单还会取决于会话长度、上下文压缩前后的token量、工具调用频次、web search或其他内置工具价格、MCP服务自身成本、沙盒资源、失败重试以及人工审核流程。开发者不能用“0额外费用”替代成本评估。
工具、上下文和沙盒是同一个产品面
Agents API把多个此前分散的Agent工程问题合并到同一层。第一个是上下文管理。OpenAI说API会在session接近上下文限制时自动compact早期上下文，让工作流跨多个context windows继续推进。对长任务来说，这比单次prompt能装多少token更接近真实约束，因为持续任务需要决定哪些中间结论、文件变化、工具结果和失败路径被保留。
第二个是工具使用。公告称Tool search会按需加载相关工具定义，以减少token使用和成本，同时保留模型缓存。工具可用后，programmatic tool calling允许Agent并行运行调用、串联相关操作，并在代码里过滤或合并结果，只把相关结果带回上下文。OpenAI明确列出支持MCP、自定义函数和内置web search。这个组合说明，OpenAI不只是在封装函数调用，而是在优化“工具太多时如何让Agent找到、调用、压缩和回填结果”。
第三个是执行环境。开发者可以选择OpenAI-managed sandbox、自有基础设施，或伙伴sandbox。OpenAI hosted sandbox使用与Codex和ChatGPT相同的sandboxing infrastructure，能运行代码、处理文件、产出artifacts，并可配置文件、packages、skills和plugins。伙伴名单达到9家，从Cloudflare、Vercel这类边缘和前端生态，到E2B、Modal、Runloop这类Agent执行环境，再到Oracle、DigitalOcean等基础设施提供方，覆盖的是部署地点、冷启动、CPU、GPU、内存、文件和secret存储机制的选择问题。
这些功能分开看都不新鲜。MCP、函数调用、sandbox、session、subagent编排在不同产品里已经存在。OpenAI这次的变化，是把它们组织为一个面向生产Agent的默认控制面，并把“由谁维护harness”变成商品的一部分。开发者不再只是调用模型，而是在选择一套运行Agent的制度：会话如何延续，工具如何曝光，代码在哪里执行，文件如何保存，subagents如何并行，日志如何追踪。
Ciridae案例能说明什么
公告客户轮播中最具体的数字来自Ciridae。其CTO Jack Weissenberger的引语称，使用Agents API后，evaluation score从0.71提升到0.85；subagent support使工作流“drastically sped up”；旧系统观察和编排subagents比较繁琐，而新API带来4x latency reduction。这些数字提供了一个重要信号：OpenAI把subagents和可观测编排作为迁移价值，而不只是把模型包装成新端点。
但这个案例必须按客户自述处理。公告没有披露Ciridae评测任务是什么、样本量多大、旧系统基线如何、是否同时更换模型、是否改变提示策略、latency reduction的统计口径是什么，也没有第三方复现实验。0.71到0.85说明评估分数有变化；4x latency reduction说明该客户在某条subagent工作流上感到延迟下降。它们不能写成“Agents API普遍把评分提高到0.85”或“所有客户延迟降低4倍”。
更有价值的是它暴露了OpenAI想卖的具体痛点：observe and orchestrate subagents。多Agent系统难的不只是把任务拆成几份，而是让每个子Agent有自己的上下文、让主Agent能协调结果、让开发者能观察过程并控制延迟。若这部分由平台内建，Agent应用的瓶颈会从“会不会写循环”转到“是否信任平台的调度和记录”。
公告中与Ciridae相关的数字口径
| 数字 | 来源位置 | 可采用结论 | 不能外推 |
|---|---|---|---|
| 0.71到0.85 | Ciridae客户引语 | 某客户称eval score提高 | 不是所有任务的平均提升 |
| 4x latency reduction | Ciridae客户引语 | 某subagent流程延迟下降 | 不是Agents API官方SLA |
| “1 of 8”客户轮播 | 公告页面 | OpenAI展示多客户背书 | 不是8家都披露同样数字 |
对自建Agent平台的影响
过去一年，很多团队已经把Agent基础设施拆成几层：模型API、工具注册表、权限系统、任务队列、沙盒、文件系统、日志追踪、评测与回放。OpenAI的Agents API不是替代所有层，而是向上吃掉其中最难规模化的一部分：harness维护、长会话状态、工具选择、subagent并行和运行环境抽象。对中小团队，这可能直接降低搭建成本；对大企业，它会触发一轮新的架构取舍。
第一种取舍是控制权。自建harness可以把权限、日志、调度和回滚嵌进内部系统，代价是模型每次升级都可能要求重写prompt、工具适配和context策略。OpenAI在公告中说，它会随模型发布维护和持续改进harness，并提供versioned access。这对开发者很省事，但也意味着平台行为会随OpenAI版本演进。企业如果依赖这些能力，需要清楚每次模型或harness变化是否会影响回归测试、审计证据和合规责任。
第二种取舍是执行环境。OpenAI hosted sandbox适合快速开始和规模化，但高敏代码、私有数据和受监管工作流未必能直接进入第三方托管环境。自有基础设施可以保留数据边界，却需要自己承担隔离、资源调度、冷启动和文件持久化。伙伴sandbox提供更多部署选项，但每家在VPC、secret、GPU、区域、成本和日志上的承诺都不同。Agents API把选择摆到同一页面，不代表企业可以跳过供应商审查。
第三种取舍是工具风险。MCP、自定义函数和web search让Agent能进入真实系统，也把攻击面放大。一个看似便利的MCP连接，可能把内部数据、权限令牌、外部检索结果和代码执行串到同一条长会话里。OpenAI的工具搜索和programmatic tool calling有助于降低token浪费，但安全问题不只来自token，更多来自“Agent是否被允许做这个动作”“谁批准了这个工具”“错误结果如何回放”。
Agents API的核心价值不在“多了一个调用端点”，而在OpenAI把Agent运行层从应用开发者手里收拢到平台侧。模型公司过去卖的是能力单位，现在开始卖任务执行的组织方式：会话、工具、沙盒、子Agent、上下文和产物。
这会让Agent应用的入门门槛下降，但不会让生产门槛消失。真正复杂的部分会换一个名字继续存在：自建团队要解决的是调度和可靠性；购买托管API的团队要解决的是信任、审计、数据边界和供应商锁定。OpenAI越把Codex harness做成默认路径，企业越要问清楚harness版本、日志粒度、MCP权限和sandbox隔离。
早报判断是，这次公测把2026年的Agent竞争从“谁的模型更会做题”推向“谁能提供可运行、可监管、可计费的Agent工作台”。Ciridae的数字给了迁移动机，但还不是普遍性证据。接下来决定Agents API含金量的，不是更多演示视频，而是更多可复现案例、明确SLA和可审计的执行记录。
后续需要盯住的证据
后续首先要看生产承诺。public beta意味着开发者现在可以试用，但它还不是稳定版合同。OpenAI是否公开GA时间表、弃用政策、harness版本迁移说明、速率限制、并发限制、会话最长保留、任务失败重试规则，以及是否提供企业级SLA，会决定Agents API能不能从原型进入关键业务。
安全与审计是另一条主线。OpenAI hosted sandbox的默认网络权限、文件持久化、secret注入、出站访问控制和artifacts生命周期都需要更细说明。MCP和自定义函数尤其要看权限最小化、审批、日志回放和异常阻断。如果企业无法逐条追踪工具调用和子Agent决策，就很难把它用于真实生产变更、财务分析或安全自动化。
成本账本也需要拆开。公告明确说Agents API没有额外费用，按tokens和tools付费，但Agent任务的真实成本通常来自多轮上下文、工具失败、并行subagents、sandbox资源、人工确认和回归测试。若OpenAI后续能把observability and usage做成可分解报表，开发者才容易比较自建harness、OpenAI托管和伙伴sandbox之间的总成本。
生态迁移会影响锁定风险。Agents SDK、Codex开源仓库和新的Agents API会形成三层关系：本地或应用内框架、公开可读的Codex逻辑、OpenAI托管运行。若三者接口和概念保持一致，开发者可以先在SDK或本地Codex中验证，再迁移到托管API；若三者演进节奏分裂，Agents API会更像一个单独平台，迁移成本会更高。