重试、超时、成本预算、部署与运维
重试一次看似很小，但很多任务一起失败时，重试会迅速放大成本和负载。下面从单次任务的时间与调用预算开始，安排超时、取消和部署运行，让失败有可控的收尾方式。
1. 预算
每次 run 设置：
- 最大模型 turn；
- 最大工具调用；
- token/金额；
- wall-clock deadline；
- 单工具超时；
- 子 Agent 数和并发；
- 最大重试；
- 最大产物大小。
预算到达时保存 partial result 和 checkpoint，给出明确终止原因。
2. 重试
按 provider、tool、业务动作分别配置。指数退避加入 jitter，尊重限流响应。非幂等动作重试前查询状态。记录原请求、重试原因和最终结果。
3. 部署形态
- CLI：开发/编码 Agent，便于本地工具与 Git；
- Web App：交互、确认和产物展示；
- Slack/Teams Bot：消息入口，需线程、身份和权限映射；
- GitHub Action/App：issue/PR 触发，需最小仓库权限；
- Background Worker：长任务、队列、checkpoint；
- Desktop：Computer Use、本地文件与应用集成。
Harness 与入口分离，同一 run contract 可被不同渠道调用。
4. 生产组件
- API/Gateway；
- queue 与 worker；
- session/checkpoint store；
- object storage；
- secrets manager；
- sandbox；
- tracing/metrics/logs；
- eval runner；
- rate limit；
- feature flags；
- artifact delivery。
5. 运维
- 健康检查不只看进程，还测模型、关键工具和存储依赖；
- Run 有租约/心跳，worker 崩溃后可接管；
- 版本发布保留 prompt/tool/schema 兼容；
- 模型切换做 shadow eval；
- 外部服务降级时明确标记；
- 成本异常和循环调用告警；
- 数据备份与删除流程定期演练。
6. 发布检查
- 固定 eval 通过；
- 迁移可回滚；
- 配置和密钥齐全；
- 权限最小化；
- 关键动作幂等；
- trace 关联完整；
- 取消和超时有效；
- README 与 runbook 更新；
- 生产 smoke test；
- 回滚版本已保存。
补充：从“一问一答”走向事件驱动
用户提交一个十分钟的构建任务后，又问“现在做到哪里了”。如果整个会话一直等构建结束，体验就会很差。事件驱动的做法是先登记任务、返回任务 ID，构建进度和结束状态随后作为事件进入系统。会话可以继续响应用户，而不是反复让模型读取同一段日志。
这里有三个容易混在一起的词：异步表示发起操作后不必一直阻塞等待；并发表示多个任务的进度交错推进；并行表示在同一时刻实际执行多个操作。写了 async 并不保证并行，也不保证模型接口允许在一个尚未补齐工具结果的回合里继续生成。运行时需要适配具体 API 的消息协议。
一个可落地的顺序是：
- 收到任务后，保存
task_id、会话归属、请求参数和取消状态。 - 执行器启动工作；输出按序号分块保存，通知只带必要摘要与位置。
- 事件队列接收
progress、completed、failed或cancelled。同一个事件重复到达时按事件 ID 去重。 - 会话所有者决定立即通知、留待当前回合结束，还是中止旧任务。不要让每个后台线程直接改写聊天状态。
- 收到结束事件后核对退出码与产物，再告诉用户结果。进程重启时从持久化任务状态恢复，而不是凭最后一条自然语言消息猜测。
推送和轮询并不互斥。支持 webhook 的服务可以主动通知；只支持查询的服务仍需要有退避和超时的轮询。选择取决于上游能力，不宜把轮询一概视为错误设计。
语音和机器人为什么需要额外的一层
语音助手不仅要“识别文字再调用模型”，还要处理用户什么时候说完、助手说话时用户插话、已经播放到哪一句。取消生成和停止音频播放也是两件事：旧音频可能已进入播放缓冲。应记录哪些内容实际被用户听到，避免后续上下文误以为整段回答都已播完。
机器人还多了真实物理状态。上层 Agent 可以选择“去取杯子”这样的目标，但轨迹控制、碰撞限制和紧急停止需要满足自身实时要求的控制系统。模型生成一个动作计划，不代表环境会一直保持截图时的样子；动作执行期间仍要感知和检查。这个主题需要专门的仿真与硬件验证，网站中的文本示例不是可直接控制设备的实现。
主题依据：AI Agents in Depth 第 6 章，固定书稿。本节补充概念与设计检查，不宣称复现其中所有产品能力。