别再手写 while 循环了：OpenAI Agents API 实测，四件脏活它全包，你只写业务
说实话，我对 “AI Agent 平台” 这四个字已经免疫了。
过去一年我装过的框架不下十个。每个都画一样的架构图，每个都说自己解决了编排。真跑起来才发现：上下文要我自己截断，工具结果要我写 while 循环往回塞，会话崩了要我自己存快照。半夜进程 OOM，第二天早上只剩日志里一行报错。
所谓框架，最后就是一层转发请求的薄壳，抽象漏了还得我来兜。
所以 2026 年 9 月 10 日 OpenAI 放 Agents API 公测那天，我的手是往关闭按钮去的。
然后我读到那句定位：把跑 Codex 的那套 harness，变成一个托管 API。
我停下来，把文档从头读了一遍。
先补个背景，你才知道这事儿有多拧巴。Assistants API 在 8 月 26 日下线，Agent Builder 排到 11 月 30 日下线，ChatKit 的托管后端也关停了。整整一年，OpenAI 亲手把 “会话托管 + 编排 + 上下文管理” 这一层从自己服务器上拆走。
下线清单还没凉透，16 天后，它又把这一层装了回来。
结论先放在这：这次收回来的那一层贵得多，是 agent loop 本身。
先搞清楚：它到底把哪四件脏活接管了
判断在前：跑循环这件事，以后你的代码里应该一行都不剩。OpenAI 那边负责 agent loop、编排、长会话、上下文管理、崩溃恢复，落到你身上，是交出去四件脏活。
第一件，while 循环本身。发请求、拿 tool call、执行、回写、再发请求，这个套娃现在跑在 OpenAI 那边。
第二件，编排。多步怎么串、怎么并行、失败怎么重试，以前全是你的 if else。
第三件，上下文。会话接近上下文上限的时候，harness 会自动压缩早期上下文，让任务跨多个上下文窗口接着往下干。这一步是我们过去自己写崩最多的地方。
第四件，崩溃恢复。断线重连、状态续跑，不用你自己拍快照。
落到 API 上是四个对象：
Agent：model、instructions、tools、MCP servers 都挂在这Environment：可选的沙箱，代码和文件在里面跑Session：持久化的实例，任务派给它Events and items：这个会话的输入输出事件流
这套分工不新鲜。”主 Agent 当包工头” 那套多智能体拆法，我在旧文 Codex 多智能体 V2（qqai.club/2195.html） 里从头拆过一遍，这次它被 OpenAI 收编成了官方默认能力。
三步跑通：从零到第一个能连续干活的 Agent
我的体感：上手比我预想的低，三个请求的事。公测期记得带上请求头 OpenAI-Beta: agents=v1，文档示例代码里用的模型是 gpt-6-astra。
第一步，创建 session，顺手把 agent 和 environment 一起定义掉。
# 1. 创建 session，同时定义 agent 与 environment
curl https://api.openai.com/v1/agents/sessions \
-H "Authorization: Bearer $OPENAI_API_KEY" \
-H "OpenAI-Beta: agents=v1" \
-H "Content-Type: application/json" \
-d '{
"agent": {
"model": "gpt-6-astra",
"instructions": "你是仓库助手，先规划要补哪些测试再动手",
"tools": [{"type": "web_search"}]
},
"environment": {"type": "none"}
}'第一步里的 environment 我先设成 none，纯推理跑通，不挂沙箱。要真跑代码再换成托管沙箱，那条路下一章单独讲。
第二步，开事件流。注意订阅要排在派活之前，顺序反了会出事，后面有专门的坑。
# 2. 先开事件流，再派任务（顺序别反）
const stream = await client.beta.agents.sessions.events.stream(session.id);
# 3. 派活。跑完的 session 还能接着用
await client.beta.agents.sessions.events.create(session.id, {
events: [{
type: "agent.session.input.message",
input: [{ role: "user", content: [{ type: "input_text",
text: "补上 auth 模块的测试，跑不通别停" }] }]
}]
});
for await (const ev of stream) {
# 开了子智能体后它们也会发 turn.completed，用 subagent_id 过滤出主 agent
if (ev.type === "agent.session.turn.output_text.delta") process.stdout.write(ev.delta);
if (ev.type === "agent.session.turn.completed" && ev.turn.subagent_id === null) break;
}重点是会话可续：跑完的会话能继续派新活，跑着的会话还能当场改口。发现语言选错了，说一句 no, use TypeScript instead 就行，不用重开。
接你自己的业务也一样。agent 要调你的函数时，会话会进入 agent.session.requires_action 暂停，你的应用把结果回传，会话接着跑。你在 Responses API 里写过的 function 定义可以直接搬过来复用。
连配置都懒得写的话，官方给了五个现成模板：Research Agent、Customer Support Agent、DevOps Assistant、Meeting Assistant、Analytics Agent。改名就能跑。
上下文这摊事：压缩、按需加载、并行调用三件都在里了
结论：这三样加起来，才是我认为这次真正值钱的地方。它省的不是几行代码，是 token。
上下文压缩前面提过，这里说它真正的意义。任务能跨多个上下文窗口持续运行，你不用再自己写 “摘要之后再喂回去” 那套土办法。
第二样是工具按需加载，官方叫 tool search。以前你得把所有工具的 JSON schema 一股脑塞进每一轮请求，现在工具定义按需加载。省 token 还是小事，保住模型 cache 才是关键，prompt 前部不再频繁变动，命中率自然上来。
第三样我最喜欢，programmatic tool calling。工具调用可以并行发、可以串联跑，重点是结果能在你的代码里被过滤和合并，只把有用的那部分回写上下文。以前一页两百行的检索结果全进上下文，现在只进去跟你问题相关的三行。
把 “工具生态塞进 harness” 这个思路拿出来对比的话，我在 DeepSeek Harness 插件生态（qqai.club/2380.html） 那篇里写过，当时的结论是社区版灵活，代价是什么都得自己搭。现在 OpenAI 把同一件事做成了官方 API，代价换成你得接受它的托管规则。
子智能体开起来：一个开关，把串行活扔成并行
这是整套 API 里我最喜欢的部分，改一个字段就生效。
开启方式是 multi_agent.enabled，并发数量由 max_concurrent_subagents 控制。官方 launch 示例给的是 3，overview 示例给的是 4。这个数字别照抄，按你的钱包来。
每个子智能体有自己独立的上下文，干完把结果交回主智能体汇总。好处很直接：一份脏上下文不会被一路带到最后。
说个我自己的用法。调研一个新领域，以前是一个 agent 串行翻十个来源，慢，而且翻到第七个已经开始跑偏。现在主智能体拆成四个子任务同时跑，四个上下文互不干扰，我最后拿到的是一份汇总结论，不是一堆原始草稿。
提醒一句：并发上去了，token 和容器用量是同步上去的。改一个布尔值不会让账单变便宜。
沙箱怎么选：三条路和那张价目表
先把钱的事说清楚：Agents API 本身不额外收费。你付的只有三样，模型 token、OpenAI 工具、容器用量。这一点比很多抽成的玩法厚道。
Environment 那条路分三条：
- OpenAI 托管沙箱，最省事，开箱即用
- 自托管，数据和网络都在你自己手里
- 合作伙伴托管，官方列了 Blaxel、Cloudflare Dev、Daytona、DigitalOcean、E2B、Modal、Oracle Cloud、Runloop、Vercel 共 9 家，并且支持部署到你自己的 VPC
OpenAI 托管沙箱的标准容器费率是这样，每容器每 20 分钟：
- 1GB 0.03 美元
- 4GB 0.12 美元
- 16GB 0.48 美元
- 64GB 1.92 美元
计费按分钟算，5 分钟起。
选哪条路其实很好判断：
- 如果你只是做个几十分钟能跑完的任务，自托管沙箱加用完立刻删，最省钱
- 如果你要跑跨天、需要中途救场的长任务，用 OpenAI 托管沙箱，然后自己挂定时清理
- 如果你团队有网络隔离要求，走合作伙伴加 VPC 部署
别踩这些坑：四个能把账单烧穿的细节
这四个我中过两个，另外两个是读完文档后背发凉的地方。
坑1：会话删不掉，钱一直在烧。现象：调 DELETE /v1/agents/sessions/{id} 返回 409。根因：409 说明沙箱还在忙，会话没有真的停。解法：把 409 当成 “稍后再试” 的正常信号，加重试退避再删。另外别指望托管侧替你兜底，OpenAI 托管沙箱要 1 小时无活动（或者看你有没有 keep-alive）才被删除，而且这个超时是不可配置的。
坑2：以为自托管能换来 Zero Data Retention。现象：合规评审怎么都过不了。根因：公测期的 Agents API 不支持 Zero Data Retention，而且即使你选自托管沙箱，也拿不到 ZDR 资格。解法：有这类硬要求的团队先别上。还有一条同样硬，公测期数据驻留仅限美国。
坑3：事件流接晚了，开头一段全丢。现象：任务明明在跑，你的前端一片空白，或者只看到后半截。根因：Events and items 是这个会话的输入输出事件流，你在派活之后才订阅，开头那批事件已经过去了。解法：订阅动作必须夹在 session 创建之后、派发任务之前。
坑4：并发子智能体一开，账单翻倍。现象：打开 multi_agent.enabled 之后成本明显上一个台阶。根因：每个子智能体各自一份独立上下文，token 各算各的，容器用量也叠加。解法：max_concurrent_subagents 按预算设，别直接抄示例里的 3 或 4，先压到最低跑通再往上调。
顺带一句，长会话这块你要是从语音侧切过来的，可以对照看 GPT-Live-1 语音 Agent（qqai.club/2484.html） 那篇，两边对 “会话长时间不断线” 的处理思路能互相印证。
所以你的代码还剩什么：只有业务
回到开头那两个字，免疫。
我免疫了整整一年，这次被说服的原因很朴素：它终于承认，那些脏活烂活本来就该平台干。
你的代码里不用再出现 while，不用再手写上下文截断，不用再想办法让 session 从崩溃里爬起来。剩下的是什么？是你的 instructions 写得够不够清楚，是那几个业务函数好不好用，是你要派给它的这个活本身值不值得派。
一句话说给自己听：过去一年我们花在 “搭 Agent” 上的时间，九成是在补平台的缺。现在缺补上了，能不能做出真有用的东西，看你自己。
如果你只想先看一处来判断这次是不是又一层壳，我建议直接看上下文压缩和 programmatic tool calling 这两段文档，它们是试金石。
公测期已经面向所有开发者开放，门槛就是那个 OpenAI-Beta: agents=v1 请求头。
关注圈圈，持续带你玩转 AI 工具。
暂无评论内容