它托管的正好是大家自己写得最烂的那一层
做过长任务 agent 的人都写过同一批代码：会话状态往哪存、上下文快满了砍哪一段、工具调用失败怎么重试、进程挂了怎么接着跑、几个子任务并行完怎么合并。这些既不是业务逻辑也没有差异化，但占掉了大量时间，而且各家实现的质量参差不齐。 Agents API 把这一层接过去了。最实用的是上下文压缩：会话接近上下文上限时它自动压缩较早的内容，保留 agent 继续工作所需的信息，并且根 agent 和每个子 agent 各压各的——这意味着一个任务可以跨多个上下文窗口，而你不用自己写压缩策略。tool search 按需加载工具定义，省 token 也保住缓存；程序化工具调用允许并行、串联，并在代码里先过滤再把结果带回上下文，而不是把原始返回一股脑塞进去。 它和 Agents SDK 不是一回事，这点容易混：SDK 是你自己部署的开源框架，Agents API 是 OpenAI 替你跑 harness 的托管服务。
两条限制会直接决定一部分团队能不能用
先说最硬的：**目前仅限美国**，并且**不支持零数据留存（ZDR）**——注意，即便你把沙箱换成自己基础设施上的，这条依然成立。 对有数据驻留或合规要求的团队，第二条基本是一票否决项：很多企业采购里 ZDR 是硬条款。想清楚这一点再决定要不要把关键链路迁过去，比试完再发现要迁回来划算。所有调用都要带 `OpenAI-Beta: agents=v1` 头，这也提醒了它的阶段——公测。
换来的是什么
厂商列出的早期用户数据是：Ciridae 延迟降到四分之一、SafetyKit 成本降 60%、Hypha 失败响应减少 86%。这些是客户自报、场景各异，别当成你也能拿到的数。 更值得算的是另一笔账：托管 harness 意味着 agent 的编排层换成了 OpenAI 的实现，好处是省下几个人月和一堆边界情况，代价是这层不再由你控制——压缩策略怎么选、哪些上下文被丢掉，你看不到也调不了。对以编排质量为核心竞争力的产品，这是个需要认真权衡的取舍；对把 agent 当内部工具用的团队，这基本是白赚的。 沙箱这块留了余地：可以用 OpenAI 托管的，也可以接自己的或者 Blaxel、Cloudflare、Daytona、DigitalOcean、E2B、Modal、Oracle、Runloop、Vercel——执行环境仍在你这边，被托管的是控制面。
via: OpenAI《Introducing the Agents API》、OpenAI 开发者文档：Agents API 概览、MarkTechPost 技术解读