Agents API 托管了任务循环，业务权限仍得由应用自己守住

作者：林岚｜OC 开发者生态编辑

据 OpenAI 官方 Agents API 文档，应用可以通过托管接口使用 Codex 的任务执行框架，由平台处理会话、编排、上下文压缩与恢复，开发者提供工具并选择执行环境。

一句话结论：这类接口外包的是 Agent 的运行基础设施，不是业务授权、数据责任和结果验收；“自托管沙箱”也不等于整条链路都留在本地。

为什么一个模型接口还不够

调用一次模型，通常是提交输入并等待输出。让 Agent 持续处理任务，则需要更多状态：它已经看过什么、正在等待哪个工具、连接断开后如何继续，以及用户中途改变要求时该怎样处理。

这些并不都属于模型能力。它们更像后台任务系统的职责，只是现在执行步骤由模型动态决定。开发者如果从零搭建，就要同时处理任务生命周期和模型行为；托管框架试图减少前一类重复工作。

但“框架替你管理状态”不能理解为“状态永远不会丢失语义”。长任务中哪些信息必须持久保存，哪些可以压缩，仍值得应用单独设计。订单编号、授权范围、验收标准这类关键字段，不应只依赖一段可能被概括的自然语言上下文。

先区分谁运行循环，谁运行代码

官方文档将执行环境与托管会话分开：开发者可选择 OpenAI 托管环境，也可使用自托管沙箱。这个区别决定命令和文件操作在哪里发生，却不自动改变会话数据的处理边界。

文档目前明确写明，Agents API 仅支持美国数据驻留，不支持 Zero Data Retention；选择自托管沙箱也不会使它符合 ZDR 条件。来源：数据说明

这是一项采购时应先检查的限制，而不是部署完成后再加一句说明。应用代码在自己的机器上运行，并不能推出所有指令、工具结果和会话状态都不经过外部服务。

对企业来说，正确的问题是逐项询问：哪些数据进入模型请求？哪些工具结果进入历史？生成文件保存在哪里？保留和删除的范围分别是什么？答案需要对应具体产品配置，不能用一个“私有部署”的标签概括。

工具接上了，权限不能跟着整包送出去

设想一个处理售后工单的 Agent。读取订单、查询物流、生成回复草稿，是三种相对可控的操作；退款、修改地址和注销账号，则直接改变业务状态。

如果应用给模型一个拥有全部能力的管理员令牌，再要求它“谨慎使用”，就把权限控制降格成了文字建议。更合理的设计是把不同动作拆成受限接口，在服务端校验对象、额度、角色与批准条件。

这些是应用层的工程责任，并非托管接口已经替所有业务完成的保护。平台管理任务循环，不会知道你公司哪一张退款单需要财务复核。

同样，工具返回的邮件、网页和文档应作为不可信数据处理。它们可以包含业务内容，却不能因为被 Agent 读到，就自动获得修改任务或扩大权限的地位。

恢复任务之前，先问外部动作是否已经发生

分布式系统里，一个请求超时有两种常见可能：操作没有完成，或者已经完成但结果没有送回来。Agent 再聪明，也不能只凭“我没收到结果”断定可以安全重试。

例如创建退款成功后连接中断，下一轮若直接再创建一次，就可能重复付款。应用应提供幂等标识、查询操作状态的接口，以及清楚区分“待确认”和“失败”的结果。

托管恢复让任务更耐中断，但业务动作的恢复必须基于业务记录。这个原则也适用于发邮件、提交表单、开通资源等所有有外部副作用的操作。

费用也要按任务系统来计算

文档说明，模型按所选 API 费率计费，工具和托管容器按对应标准费率计费。这不是买一次接口就包下整项任务的固定价格。

预算因此需要同时覆盖模型调用、工具、环境，以及失败后的重试。长任务应有可观察的进度与停止条件，而不是只在完成时查看最终账单。

一个很实用的产品标准是：用户在任意时刻都能知道任务在做什么、已产生哪些成果、哪些动作已经发生，以及停止后还会留下什么。运行越持久，这些解释越不能缺席。

关键事实

• Agents API 提供托管 Codex 运行框架与持久会话。
• 执行环境与托管编排是不同边界。
• 当前文档限定美国数据驻留，不支持 ZDR。
• 模型、工具和托管环境存在各自计费项。

OC 判断

托管 Agent 会降低搭建门槛，但不会降低业务系统对正确性的要求。最容易被低估的工作，不是再写一个提示词，而是把授权、幂等、审计与人工接管做成真正可执行的接口。

为什么重要

• 对开发者：少写运行框架后，应把精力转向业务控制。
• 对企业：先核对数据边界，再决定部署方式。
• 对用户：持久运行必须配套进度、停止和结果记录。

参考来源

• OpenAI：Agents API overview