智能体真正难的，往往不是让模型“会思考”，而是让一个跑几十分钟甚至几天的任务不断线、能恢复、可审计。OpenAI在9月10日公测的 Agents API，把长会话、上下文管理、工具装载和子智能体编排做成托管运行时。我的核心判断是：它卖的不是又一个模型入口，而是把团队反复自建的“智能体操作系统”收进API。

发生了什么

官方发布页称，开发者可以提交模型、工具、环境和任务，创建托管会话；执行环境既可选 OpenAI 托管沙箱，也可放在自有基础设施或合作方环境。官方文档还显示，POST /agents用于创建可复用智能体，POST /agents/sessions用于启动带环境和输入的托管会话。

这里要严格区分两件事：官方确认的是产品能力与公测状态；客户案例中的成本、延迟或失败率改善，是特定团队的自报结果，不能外推成通用性能承诺。

技术变化不在“多一个端点”

过去做智能体，应用通常要自己维护循环：调用模型、解析工具请求、执行工具、把结果塞回上下文，再处理超时和重试。会话一长，还要决定删掉哪些历史、怎样保存中间文件、子任务何时并发。Agents API把其中一部分变成版本化运行时。

这张图也说明了责任边界：运行时负责“怎么持续跑”，环境决定“在哪里动手”，业务系统仍要决定“允许动什么”。托管沙箱能降低隔离和生命周期管理成本，却不会自动替你写好最小权限、数据分级和审批策略。

对开发者的实际影响

最直接受益的是长链路、高波动任务。例如事故排查要查监控、读代码、并行分析依赖，最后保存证据报告。传统服务需要常驻工作进程并维护状态；托管会话允许任务异步推进，子智能体各自持有上下文，主智能体再汇总。

但对“输入一句、返回一段文字”的简单功能，这套结构可能增加复杂度。一次客服分类、固定字段抽取，用 Responses API 或普通函数调用更透明，也更容易估算费用。

我的判断：护城河会从循环代码移到治理数据

当会话续跑、压缩和编排成为平台能力，自研一套通用代理循环的价值会下降。真正拉开差距的将是三类资产：高质量工具接口、能覆盖失败路径的评测集、以及把人类审批嵌入关键动作的业务规则。换句话说，框架代码更薄了，治理并没有消失。

还有一个长期风险：运行时行为随平台迭代，调度与压缩细节并不完全由你控制。对金融审批、生产变更等可追责场景，团队应记录模型、运行时版本、工具输入输出和人工授权，而不能只存最终答案。

上线前检查表

1. 先把任务拆成只读、可逆写入、不可逆写入三类，分别设置权限。
2. 为每个工具规定超时、幂等键、最大调用次数和脱敏日志。
3. 用真实失败样本评测恢复能力，不只测“理想流程能跑通”。
4. 给成本设置会话级预算，防止子智能体并发放大消耗。
5. 准备终止、导出状态和人工接管路径，避免托管等于失控。

适合它的是跨多个系统、持续时间长、需要文件工件的任务；不适合的是低延迟单轮请求、强确定性交易路径，以及无法把敏感执行环境交给第三方管理的系统。

不要把迁移理解成“删掉旧循环”

更稳妥的迁移应从影子流量开始。让新旧运行时同时读取同一批脱敏任务，但只有旧系统能真正写入；比较两边的完成率、工具调用次数、人工接管次数与总成本。接着只开放一个可逆工具，例如生成草稿或写测试分支，再逐步放开权限。若一开始就把生产凭据、部署权限和完整仓库交给新会话，很难判断失败来自模型、工具、沙箱还是业务规则。

还要给“成功”写清定义。智能体返回一段自信总结，不代表任务完成；事故排查必须附查询时间范围和证据链接，代码修改必须通过测试并留下差异，数据处理必须核对输入输出行数。运行时可以保存中间工件，业务侧仍要验证这些工件是否满足验收条件。

最后是退出成本。至少保留工具定义、评测样本与会话摘要的可导出格式，把平台专属字段隔离在适配层。这样即使未来改用自托管循环，也不必重写全部业务逻辑。

如果运行时由平台托管，你最不愿交出去的是执行环境、日志还是调度策略？

关注「蜗牛聊AI」，一起看懂技术变化背后的真正机会。

---

本文首发于 java4u.cn，转载请注明出处。