托管智能体框架如何持续完成长期任务

开发者体验团队的 Charlie 和 API 团队的 Steve 介绍 Agents API：这是一项基于 Codex 运行框架的托管服务。开发者定义指令、工具和数据并选择执行环境，OpenAI 则负责运行框架。

随着模型承担更长的任务，外围软件也必须改变。讲者回顾了从早期 Assistants API、Responses API 到本地可控的 Agents SDK 的演变。

Responses API 为不同类型的模型输入和输出提供基础。Codex 运行框架增加了执行操作的能力，托管的 Agents API 则让应用使用该框架，无须每位开发者自行大规模运营。

Steve 说，团队通常清楚自己想构建的产品，却希望获得基础设施选择、密钥管理和智能体运营方面的帮助。托管服务旨在承担运行框架，同时让开发者控制工具、数据和环境。

讲者指出三个工程问题：将运行框架与执行环境分离、向用户展示有用的活动信息，以及在部署和服务器故障期间保留长期运行任务的状态。

Codex 最初假定自己可以读取和修改本机文件。云端运行框架则必须将命令路由到正确的远程沙箱，并隔离各会话的命令和结果。

开发者可以使用自己的沙箱，也可以使用 OpenAI 托管的沙箱。讲者宣布在 OpenAI 托管环境中通过 API 提供计算机操作能力。

Charlie 说，智能体的路径取决于提示词和工具结果，因此用户需要活动视图，而不是固定的进度脚本。一个内部团队需要按对话轮次展示工具调用和回复。

API 随后提供了这些轮次信息，避免每个应用自行重建。这样的设计决定会影响托管框架究竟能帮开发者承担多少基础设施工作。

长期任务积累的历史可能超过模型上下文窗口。压缩机制将有用信息带到后续上下文中，同时服务还必须经受自身部署和服务器替换。

系统需要找到会话以接收后续指令，也可能需要等待远程工具结果。Steve 说，可靠恢复需要精确记录状态，以便继续执行时不小心重复已完成的操作。

例如，发送文件编辑命令后如果连接中断，没有收到结果并不能说明编辑是否发生。系统继续执行前必须同时考虑环境状态和运行框架记录。

Charlie 演示了一个航班取消后的航空公司改签应用，处理从旧金山到芝加哥的行程。不同智能体会话调查复杂乘客案例，包括必须抵达指定机场的旅客和必须坐在一起的家庭。

演示在 OpenAI 托管沙箱中创建会话，广泛禁用网络访问，并向界面流式发送事件。改签技能为智能体提供步骤，能力目录还可以提供技能和插件。

航班库存工具提供参考性余票信息并可暂时保留座位，但必须由人确认改签。两个子智能体分别检查座位和到达条件，然后才发布建议方案。

要求的输出包括建议方案、备选方案对比和检查约束的 Python 脚本。讲者提醒，允许更多子智能体并发可能增加令牌用量。

第一个案例中，智能体找到飞往指定机场的航班并暂留座位，等待人工批准。活动视图展示了沙箱、航班查询和委派检查。

对于家庭旅客，智能体排除了一班只剩一个座位的航班，以及另一班无法保证全家坐在一起的航班。界面在批准前展示了方案对比和检查脚本。

Charlie 说，同样的模式可以并行处理许多预订，同时保留人工审核。开发者可以专注于业务规则和审批节点，而不必维护长期运行的框架。

讲者列举了 Notion、Rakuten 和 Bain 的用途，包括异步工作和由人类专家检查的模拟客户研究。他们还介绍 AWS Bedrock 托管智能体集成，并邀请开发者考虑规模更大的并行任务。