9 月 10 日，OpenAI 低调上线 Agents API 的 public beta。与以往发布不同，这次没有大规模宣传，但它把原本需要开发者自己维护的 agent loop 直接搬到云端：开发者提交任务后，OpenAI 会在托管环境中运行模型、调用工具、执行命令并保存状态。对正在构建 Agent 应用的团队来说，这可能意味着沙箱、断连恢复、状态持久化等基础设施工作开始由平台接管。
从“自己跑循环”到“托管执行”
根据实测者的整理，Agents API 的核心思路是把 OpenAI 用于 Codex CLI 的 Codex harness 云化。开发者不再需要自行维护模型推理、工具调用和执行环境之间的循环，而是通过一个请求创建会话，由 OpenAI 在云端启动 agent 实例，完成任务拆解、代码运行和工具调用。
OpenAI 当前 agent 产品线包括 Responses API、Agents SDK、Agents API 和 Agent Builder。它们对应不同控制粒度：Responses API 给开发者更高控制权，但需要自己实现循环；Agents SDK 提供更细的工程接口；Agents API 则把整个执行循环托管；Agent Builder 更偏向拖拽式搭建。Agents API 的位置，是把“运行 agent”这件事尽量变成一种可直接调用的云服务。
该 API 目前挂在 SDK 的 client.beta.agents 命名空间下，说明仍处于 beta 阶段，后续接口细节可能变化。其实测反馈也强调，部分能力边界需要结合文档和实际运行结果判断。
会话、环境与事件流构成基本框架
Agents API 的抽象集中在几个概念上。Harness 是 OpenAI 托管的执行实例，负责模型和工具循环；Session 是持久化会话，可保存 agent 配置、对话历史和执行产物；Turn 表示一轮任务执行；Environment 则是 agent 实际工作的环境，目前支持 OpenAI 托管环境等形态。
开发者可以通过 POST 请求创建 session，并在请求中指定模型、指令、环境和输入内容。实测中使用的是 gpt-6-astra 模型，同时开启 stream 参数获取事件流。Python SDK 对应 client.beta.agents.sessions.create(…)。
事件流会返回任务过程中的中间状态和最终状态。终态包括 agent.session.turn.completed、turn.failed 和 turn.cancelled。需要特别注意的是，turn 完成并不等同于所有工具调用成功，开发者仍需检查 agent 的实际输出；单独出现 agent.session.idle 也不能作为成功依据。
Agent 配置可以内联在 session 创建请求中，也可以先通过 client.beta.agents.create 保存为可复用 agent，再通过 agent_id 引用。凭据不直接混入 agent 配置，而是放在 vault 中，这一设计对多 agent 场景较为重要。若同时传入 agent_id 和 agent 对象，系统会按 session 覆盖配置，但 tools 等数组字段是整体替换而非合并，新增工具时需要携带完整列表。
工具调用与多 Agent 协作仍有明确边界
工具语义与 Responses API 保持一致。开发者可以定义 function tool，当 agent 需要调用自定义函数时，请求会出现在事件流和 required_actions 中，由开发者本地执行后将结果返回，任务才能继续。结果交付支持流式事件和 webhooks 两种方式，若不希望维持长连接，可通过 webhook 接收会话状态变化。
控制接口方面，开发者可以向已有 session 发送新消息实现续跑或转向，也可以取消当前 turn、获取历史产物或删除会话。一个重要限制是事件流不会回放。如果连接断开，不能通过重新订阅补齐遗漏事件，而需要拉取 session 和已保存 items 恢复现场，再决定重试或继续执行。
API key 需要 api.agents.read、api.agents.write 和 api.responses.write 三个权限。官方提醒不要将 key 放入 agent 沙箱，因为 agent 可执行任意代码，密钥进入沙箱等同于暴露。
多 Agent 能力是实测中重点关注的部分。开启 multi_agent 后，系统会自动给协调者 agent 注入创建 subagent、发送消息、等待和中断等协调工具。开发者不能预先声明这些工具，subagent 也是协调模型在运行时动态创建。事件流中会出现 agent.session.subagent.created，每个 turn 可通过 subagent_id 归因到具体 agent。
但实测者总结，这套机制并不适合会话内的精细确定性编排。委托行为由模型决定，而非开发者直接编排。如果需要“先 A 后 B、失败走 C”这类流程，更适合把编排放到会话外，由应用层为每个角色创建独立 session，并用自己的状态机管理拓扑、重试、超时和分支。
- Agents API 适合任务可拆分为独立并行子任务、希望减少沙箱与状态管理成本的场景。
- 对流程确定性和合规要求较高的系统，建议把 Agents API 当作托管 worker，编排层自行实现。
- 如果需要 agent 间自由路由的去中心化 swarm，现阶段更适合使用 Agents SDK 的 handoff 机制。
对 Agent 开发者的实际意义
从实测结果看，Agents API 并非要取代 Agents SDK，两者更像互补关系。SDK 提供精细控制，Agents API 降低运行和运维负担。它最直接的价值，是把沙箱管理、断连恢复、状态持久化、事件推送等长期困扰 Agent 系统的基础设施能力，封装成 API 的一部分。
这也反映出 OpenAI 正在把 Agent 能力从模型接口进一步推进到运行平台层。过去开发者需要自建执行循环、工具调度和状态存储，而现在部分固定成本可以转交给云端服务。对于想快速验证 Agent 应用的团队，这降低了工程门槛；对于复杂生产系统，则需要仔细划分哪些逻辑交给托管服务，哪些仍由应用层控制。
Beta 阶段，multi_agent 能力仍可能继续迭代。实测者建议，评估该 API 时应重点测试断连恢复和事件流稳定性，因为这两处文档承诺相对较少，也最容易在工程环境中暴露问题。
原创文章，作者：点点，如若转载，请注明出处：https://www.dian8dian.com/openai-jiang-agent-yun-xing-huan-jing-bian-cheng-yun-fu-wu
