一个端点，POST https://api.openai.com/v1/agents/sessions，加一个 OpenAI-Beta: agents=v1 请求头。
就这些。OpenAI 把 Codex 客户端里那套跑 Agent 的 harness，搬到了服务端，做成了任何后端程序都能调用的 REST API。
这不是新模型，是新的「跑法」。
过去你想让 Agent 长期运行、读写文件、跑命令、拆子任务，得自己搭一套：沙箱 VM、上下文管理、断点恢复、工具编排。现在 OpenAI 说，这些我来，你只管给工具、定环境。
听起来很香。但先别急着接。
先把四个概念捋清楚，不然文档看不下去
OpenAI 把整套东西拆成四个词。这四个词搞懂了，剩下的都是细节。
| 概念 | 是什么 | 谁负责 |
|---|---|---|
| Agent | 模型 + 指令 + 工具 + MCP 服务器 | 你定义 |
| Environment | 可选沙箱或计算机，Agent 在里面读写文件、加载 skills、跑命令 | 你选，OpenAI 可托管 |
| Session | 一个持久的 Agent 实例，处理任务并响应输入 | OpenAI 托管 |
| Events / items | 会话期间的输入输出 | 双向 |
工作流也很直白：创建会话 → 分配任务 → 流式或 webhook 跟进 → 继续或干预。
注意最后一步「干预」。这不是那种提交任务然后等结果的批处理 API，你可以在 Agent 干活的过程中插话、改方向。这一点对做产品的团队很关键——用户等不了黑盒跑十分钟。
托管 harness 到底托管了什么
这是全文最该看的部分。OpenAI 帮你扛的活，列出来是这样的：
- 在沙箱里跑命令和代码
- 应用 skills 和指令
- 通过工具或 MCP 连外部数据
- 工作过程中随时干预
- 压缩之前的上下文
- 把子任务委派给 subagent
- 断点续跑
我盯着「压缩之前的上下文」看了很久。这是自建方案里最容易翻车的一环。 上下文一长，要么爆窗口，要么模型开始忘事，要么你花大力气做摘要还丢信息。OpenAI 把它做成托管能力，等于把这块脏活收走了。
多智能体通过 agent.multi_agent 开启，用 max_concurrent_subagents 控制并发。工具支持三类：programmatic_tool_calling、mcp（HTTP transport）、web_search。环境两种：self_hosted 或 OpenAI 托管沙箱。
SDK 覆盖 Python、TS/JS、Go、Java、Ruby，调用方式统一成 client.beta.agents.sessions.create(...)。这点做得挺克制，没有搞语言歧视。
两个必须知道的限制，第二个更坑
第一个是数据驻留：目前仅限美国。
第二个是：不支持 Zero Data Retention（ZDR）。
而且这里有个陷阱——即便你选 self_hosted 自托管沙箱，也不会因此变成 ZDR 合规。 因为会话编排、上下文压缩这些还是在 OpenAI 那边跑的。
这句话对做金融、医疗、法务类应用的团队，基本等于判了缓刑。ZDR 不是「有更好」，是很多合规清单上的硬性勾选项。勾不上，项目就过不了审。
所以如果你的客户合同里写了数据不留存，这个 API 现在还不能碰。不是能力问题，是合规问题。
计费模糊，是隐藏成本
官方口径是：模型用量按所选模型计费，OpenAI 工具按标准价，托管沙箱按容器价。
听起来清楚，但社区有人实测后提出了几个问题，我觉得都问在点子上：
- 每次执行 agent session，是不是都新建一个环境？
- 环境是不是至少按一小时计费？
- 能不能主动关闭环境来省钱？
这几个问题官方文档没给明确答案。如果环境按小时起算，那你跑一个 30 秒的小任务，可能也要付一小时的钱。 高频短任务的场景下，这个成本结构会很难看。
我的建议是：上线前先拿小流量压测，把账单跑出来再决定。 别信估算，信账单。
另外社区还测了沙箱的网络访问，有 enabled / disabled / restricted 三种模式。受限模式下访问外部域名会直接返回 “Domain forbidden”。这个设计是对的，但你要提前想清楚 Agent 需要访问哪些域名，不然调试时会一脸懵。
该不该用：三类团队，三种答案
社区吵得很凶，一派说「这更像是加强 vendor lock-in」，另一派很实际——「为了省掉自己维护一个沙箱 VM 的麻烦」。
两边都对。关键看你站在哪。
第一类：小团队 / 独立开发者，该上。
你自己维护沙箱 VM 的成本，不只是钱，是时间。安全隔离、资源回收、镜像更新、网络策略，每一样都是坑。我当年自己搭过一套，光是把「Agent 跑飞了把磁盘写满」这个问题解决，就花了两周。如果 OpenAI 能帮你扛这些，省下来的时间够你做两个功能。
第二类：有合规要求的团队，先等。
ZDR 不支持 + 数据仅限美国，这两条卡死了很多场景。不是不能谈，是现在谈不了。等官方给出 ZDR 路线图再说。
第三类：规模已经很大的团队，谨慎上。
你的量级下，托管成本可能高于自建。而且会话状态和执行环境都在别人手里，迁移成本会随时间累积。如果一定要用，把架构设计成可替换的——把 Agents API 包一层自己的抽象层，别让业务代码直接调 client.beta.agents.sessions.create。哪天要换，改一层就行。
说到底，这是一次「跑法」的标准化
Agents API 的实质，是把 Codex 客户端那套 harness 服务端化，让长期运行、能读写文件、能拆子任务的 Agent，成为任何后端程序都能调用的一等公民。
代价是把会话状态和执行环境交给 OpenAI。
能力上限没变，变的是你要不要自己扛运维和合规。 这笔账，每个团队算出来都不一样。
你会把 Agent 的会话状态交给 OpenAI 托管吗？还是宁愿自己维护那套沙箱？评论区聊聊你的取舍。