发布全景：从三层积木到一次托管调用
在 Agents API 之前，OpenAI 的智能体能力散落在三层积木里：Responses API 负责把模型与网页搜索、文件搜索、计算机操作等内置能力组合，偏「模型 + 工具」；Agents SDK 负责定义与编排智能体工作流，偏「编排逻辑」；底层的运行时、会话管理、沙箱与重试，则需要开发者自行拼装。官方博客的说法是：过去构建定制化智能体，开发者通常要自行组装智能体运行时、上下文与会话管理、工具与外部数据连接、执行环境以及相关基础设施。
Agents API 把这些组件收编为托管服务。开发者在单次 API 调用中指定任务、模型、工具与执行环境，OpenAI 在自己的基础设施上运行智能体循环，协调模型调用、工具使用与上下文管理。发布时间上存在轻微口径差异：OpenAI 官方开发者论坛的发布帖与社区记录显示为 9 月 10 日前后，亦有中文媒体将报道时间标注为 9 月 17 日；无论以哪一日为准，均属 9 月中旬的公开测试版发布，功能清单一致。
需要澄清一个容易混淆的点：此处的 Agents API（托管服务）与 2026 年初已深度解构过的 Agents SDK（编排框架，见站内 R-TECH-07）不是同一层的东西——SDK 让你自己跑编排逻辑，API 则干脆把编排连同运行时一起接走。本站此前对 Agent Harness 工程范式的分析（见 R-TECH-17）指出，Harness 层的五原语——工具沙箱、权限审批、上下文压缩、可观测性、状态记忆——正在成为厂商竞争的真正焦点；Agents API 是这一判断迄今最直接的注脚。
Agents API 的本质不是多了一个 SDK，而是把「搭建智能体所需的全部运维脚手架」折叠进一次托管调用——企业级 Agent 的竞争焦点，正从「谁的模型更强」转向「谁能省掉更多工程活动部件」。第三方分析师的总结更为具体：一个手工构建的长时运行智能体需要任务队列、状态数据库、沙箱集群、压缩例程与重试策略五件套，而且每件都要有人负责与值班；Agents API 的卖点就是这五件套的消失。
架构拆解：Harness 托管与执行环境三选一
Agents API 的架构可以用一句话概括：Harness 归 OpenAI，执行环境归你选。官方文档明确说明，OpenAI 负责托管并持续维护 Harness——即运行智能体循环、协调模型调用与上下文的那层工程；开发者控制的则是智能体的能力边界（工具、知识、技能）与代码执行的位置。
执行环境提供三种选择：其一是 OpenAI 托管沙箱，复用支撑 Codex 与 ChatGPT 的同一套沙箱基础设施，可预置文件、软件包、技能与插件；其二是自有基础设施，在开发者自己的 VPC 内部署；其三是沙箱合作伙伴，官方列出九家集成商——Blaxel、Cloudflare、Daytona、DigitalOcean、E2B、Modal、Oracle、Runloop、Vercel——覆盖全托管环境与 VPC 内部署两种形态，并支持不同的文件与密钥存储方式、CPU/GPU/内存配置，以匹配各自的性能、冷启动与成本需求。
从官方公开的调用示例可以读出更多结构信息：sessions.create 接口中，agent 对象携带模型（示例用 gpt-6-astra）、工具列表（含 MCP 类型的 HTTP 传输）、multi_agent 配置（启用子智能体、并发上限 3）；vault_ids 用于密钥引用；environment 对象声明 openai_hosted 类型与技能目录路径。示例任务是一个典型的运维排障场景——调查服务 API 的 5xx 错误率，把部署、错误与依赖分析分派给子智能体，并把发现、证据与建议写入工作区目录。这个示例本身就是 OpenAI 对「托管 Harness 适用场景」的产品表态：长会话、多工具、可并行的排障与研究类工作。
运行时能力：压缩、工具检索与子智能体
官方博客列出的运行时能力清单，恰好与本站 R-TECH-17 归纳的 Harness 五原语高度重合，值得逐项对照：
跨长会话的上下文压缩
当会话接近上下文窗口上限时，系统自动压缩早期上下文，保留智能体继续工作所需的信息。开发者可以构建跨越多个上下文窗口的工作流，而无需自己实现压缩逻辑——这直接对应「上下文压缩」原语，也是长时运行（数小时乃至数天）任务的前置条件。
工具检索与程序化工具调用
工具检索（tool search）按需加载相关工具定义，减少令牌用量与成本，同时保护模型缓存；工具就位后，程序化工具调用（programmatic tool calling）允许智能体并行执行调用、串联相关操作、在代码中过滤或合并结果——面对大体量数据时只把相关结果带回上下文。API 同时支持 MCP、自定义函数与网页搜索等内置工具。这对应「工具沙箱」原语之外的效率维度：工具越多，检索与调用的经济学越重要。
多智能体并行
multi_agent 配置允许把复杂任务拆成独立片段，委派给并行运行的子智能体；每个子智能体维护隔离的上下文以防互相干扰，完成后把结论返回主协调者。这与本站 R-TECH-16 拆解过的监督者-子智能体模式（AWS Field Advisor）同一谱系——差别在于编排由谁持有：AWS 的方案架在 AgentCore 上自建，OpenAI 则把它做成了 API 参数。
计费模型与开源底座
计费结构相对克制：使用 Agents API 本身不加收平台费，开发者按智能体消耗的令牌与工具调用付费；OpenAI 托管沙箱按标准容器费率计费，模型用量按所选模型的 API 费率单独结算。这个结构与「托管化」的定位一致——OpenAI 不在 Harness 层设独立租金，而是让收入随模型与算力消耗自然发生。
另一个值得注意的信号是底座的开放性：多家媒体报道指出，该系统运行在开源的 Codex Harness 之上——OpenAI 已开放这套底层代码库，外部团队可以检视连接模型调用、上下文记忆与集成工具的核心协调逻辑，而运维维护由 OpenAI 负责。这形成了一个有意思的双轨：核心逻辑可审计、可自托管（走 Codex CLI 或自建路线），托管服务则负责免运维。对工程团队而言，这提供了「先托管后迁移」的退路——至少在 Harness 层面，代码不是黑箱。
权衡分析：锁定效应与零数据保留缺位
第三方分析师的批评集中在两点，值得逐条正视。
其一，锁定效应。Pareekh Jain（Pareekh Consulting 首席分析师）指出：如果 OpenAI 同时提供模型、上下文管理、工具、编排与执行环境，迁移到其他平台的难度会显著上升；这种依赖还可能削弱企业在定价与条款谈判中的地位。Amit Kumar Jena（Kanerika AI 开发负责人）补充：追求多模型策略的企业可能更倾向于自持 Harness，或采取混合路线。客观地说，这一批评适用于所有托管 Harness——Anthropic 的 Managed Agents、AWS 的 AgentCore 同样面临，只是 OpenAI 的纵向覆盖最完整，风险也最集中。
其二，零数据保留（Zero Data Retention）不支持。据 InfoWorld 报道，即便企业使用自己的沙箱，该 API 也不支持零数据保留。对医疗、金融等强监管行业，这一限制可能直接构成合规障碍；Jena 认为「即使企业用自有沙箱也无法做到零保留」会限制其在受监管行业的采用，Fersht（HFS Research CEO）则判断更可能率先采用的是初创公司、SaaS 企业与已在用 OpenAI 的企业。
此外，采用速度还取决于生态竞争：分析师点名了同一类别的既有玩家——Anthropic 的 Claude Managed Agents（4 月起公开测试）、AWS Bedrock AgentCore（托管 Harness 已于 6 月正式可用，且允许中途换模型而不丢上下文）、Microsoft 的 Foundry Agent Service，以及开源侧的 LangGraph。换言之，Agents API 进入的是一个已有多家在场的拥挤赛道，而非空白地带。
竞争坐标：四家托管 Harness 的对照
把 Agents API 放进托管 Harness 赛道的坐标系，可以更清楚地看到各家取向的差异：
| 厂商方案 | 托管范围 | 模型绑定 | 公开进度（据公开报道） |
|---|---|---|---|
| OpenAI Agents API | Harness + 沙箱 + 上下文管理全托管 | OpenAI 模型 | 公开测试版（9 月中旬） |
| Anthropic Claude Managed Agents | 受治理策略约束的托管智能体运行 | Claude 系 | 公开测试（4 月起） |
| AWS Bedrock AgentCore | 托管运行循环、工具执行、上下文、状态与恢复 | 多模型，支持中途切换 | 托管 Harness 已正式可用（6 月） |
| Microsoft Foundry Agent Service | Azure 侧托管智能体服务 | 多模型 | 已可用（据分析师引述） |
表中最值得注意的分歧是模型绑定的松紧：OpenAI 与 Anthropic 的托管方案天然绑定自家模型，AWS 则把「中途换模型不丢上下文」作为卖点。对于把模型多样性视为供应链安全的企业，这个维度可能比 Harness 功能清单更有决策权重。
对工程团队的启示
其一，把「省掉的活动部件」算成账。是否采用托管 Harness，本质是「五件套的自建成本」与「控制权让渡的长期风险」之间的权衡；团队应先盘点自己现有的队列、状态库、沙箱运维与值班投入，再评估托管报价，而不是直接比较 API 单价。其二，数据保留条款先行。零数据保留缺位对受监管行业是硬约束——合规团队应在技术选型之前介入，而不是等 POC 跑通后再补审查。其三，保留一条自持退路。Codex Harness 开源意味着「托管起步、关键负载自持」的混合路线可行；即便全部托管，也建议把工具定义、技能与知识层设计成可迁移的形态，避免 Harness 之外再叠加一层隐性绑定。至于该 API 的正式可用时间、企业级合规选项（数据保留策略、审计导出）与托管沙箱的详细定价档位，目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。