Agents API：OpenAI 把 Codex 的长循环做成云端基础设施

OpenAI 在 2026 年 9 月 10 日把 Agents API 公开测试版交给开发者。它的卖点不是再包一层模型调用，而是把 Codex 背后的运行 harness 和执行环境一起变成 API：一个 Agent 可以持续工作、调用工具、操作文件、保存中间产物，还能把任务交给子 Agent。1

OpenAI 把系统拆成四个对象：Agent、Environment、Session，以及 Events 和 Items。Agent 规定模型、指令、工具和 MCP；Environment 是它能够运行代码、读写文件的沙箱；Session 是可持续的任务实例；Events 和 Items 则记录输入、输出和过程状态。官方文档把这四个对象放在同一套接口里，意味着应用不必自己拼接“请求、工具调用、任务状态和长会话恢复”。2

这一步的真正变化，是控制面从应用代码里抽出来了。应用提交任务，Agents API 负责会话、编排、上下文压缩和恢复，应用再通过事件流或 Webhook 接收进度，并决定什么时候继续、暂停或接收新的输入。这个模型更接近“提交一个可持续运行的作业”，而不是“发出一次请求，等一个答案”。12

长任务最先撞上的问题不是模型会不会推理，而是上下文会不会不断膨胀。OpenAI 的 compaction 机制会在上下文超过设定阈值后压缩历史，把关键状态和推理线索放进一个加密的压缩项，再进入下一个上下文窗口。开发者可以让服务端自动压缩，也可以调用独立的压缩端点。3

这个设计解决的是“怎么把任务接着做”，不是“模型记住的一定正确”。压缩项对人不可读，应用仍然需要把待办、版本、验证结果和外部副作用写进自己能查询的运行记录。上下文是工作记忆，不能替代事实日志。更实际的测试方式，是故意在压缩前后插入版本切换、工具失败和需要人工确认的步骤，检查 Agent 是否还知道当前任务停在哪里。

Agents API 支持主 Agent 把相互独立的任务交给多个子 Agent 并行处理。文档给出的默认并发上限是六个，不包括协调者；开发者也可以在创建 Session 时设置上限。适合并行的是独立文档审查、不同故障原因调查或彼此不写同一文件的局部任务。共享文件的多个子 Agent 必须自己协调，创建子 Agent 也不会自动创建新的执行环境。4

这给工程团队一个很具体的判断标准：先按冲突面切任务，再按模型能力切角色。并行的收益来自减少等待，不来自把同一份写权限复制几份。应用还要记录哪个 Agent 执行了哪条命令，因为官方文档明确提供了子 Agent 标识和命令归属查询；主 Agent 的工作和子 Agent 的工作应该在成本、错误和变更审查里分开统计。45

事件流可以实时报告会话、回合、工具调用和子 Agent 的状态。流断开后，官方建议重新建立事件流，同时读取已经保存的 Items，用 Item ID 恢复本地状态，再应用缓冲区里的更新。文档还特别提醒：会话空闲不等于成功，回合完成也不等于每个工具都成功。6

沙箱同样不能被理解成“自动安全”。OpenAI 建议隔离不同工作负载，只允许访问批准的网络端点，把应用密钥放在环境之外，并通过凭据代理向第三方服务注入受限凭据。官方文档还写明，Agents API 当前只支持美国数据驻留，不支持零数据留存；即使选择自托管沙箱，也不会改变这个限制。27

如果把 Agents API 放进自己的系统，第一步不是打开最大并发，而是先定义一条可恢复的任务状态：当前目标、已完成动作、待验证证据、外部副作用和下一步。第二步才是给 Agent 接工具，并为每个高风险工具加上权限、超时和人工确认。第三步再测试多 Agent，把共享文件、重复写入、断线重连和子 Agent 费用单独压测。

这次发布的意义，是把长循环里最容易重复造轮子的部分，放进了一套现成的服务：会话、事件、上下文压缩、沙箱和子 Agent 编排。它没有替团队完成可靠性设计。真正要验收的仍然是四个状态：模型提出了什么，系统允许了什么，工具实际做了什么，验证器确认了什么。公开测试可以让你更快开始，但不能替你决定哪些动作值得让 Agent 自己完成。