很多 AI agent 系统明明已经做了重试、队列、Checkpoint，但一到线上还是会出现“请求等很久，最后失败”的体验。根因通常不在于没有 timeout，而在于只有一层 timeout：整个 run 设一个大数字，下面的模型、工具、重试、人工等待全都在抢同一份不透明预算。
真正稳的做法，是把时间预算从“一个大阈值”拆成分层协议：Run 有总 deadline，Step 有可支配 budget，Tool 有自身 timeout，超时之后还要知道是降级、重试、转人工还是直接停止。
建议先配合 AI agent Checkpoint 与断点恢复、AI agent 任务优先级队列、AI Agent 并发与可靠性 和 AI Agent 状态机设计指南 一起看。
先给结论：时间预算至少拆成 3 层
| 层级 | 解决什么问题 | 典型字段 |
|---|---|---|
| Run deadline | 这次任务最晚什么时候必须结束 | deadlineAt |
| Step budget | 当前步骤还能再花多少时间 | remainingBudgetMs |
| Tool timeout | 单次调用最多等多久 | timeoutMs |
如果缺任意一层，超时行为就会变成“谁先拖死系统算谁赢”。
一、Run deadline 是业务边界，不是技术参数
Run deadline 先回答的是：这个任务再继续跑下去，还有没有业务意义。比如：
- 客服辅助回复，超过 15 秒就失去价值
- 内容生成草稿，可以接受 2 分钟
- 审批前校验，超过 30 秒应该先转人工
所以 deadline 的来源应该先是业务承诺，再是技术能力。只从工程角度拍一个数字，通常会出现“技术上还能跑，但业务上已经错过窗口”。
二、Step budget 负责把总时间拆开，而不是每步都自由消耗
假设总 deadline 是 20 秒，如果前两个步骤已经花了 16 秒，最后一个写入校验步骤就不该再假装自己还有 10 秒。更稳的方式是每次进入步骤时都计算剩余预算：
{
"runId": "run_123",
"deadlineAt": "2026-05-10T10:00:20Z",
"step": "policy_validate",
"remainingBudgetMs": 3800
}
这样每个步骤能明确知道：自己是在一个充裕场景里运行，还是已经进入濒临超时的收口阶段。
进一步说，预算最好还带上继承关系和可支配范围，否则下游只能看到一个剩余毫秒数，却不知道这笔时间是怎么来的：
{
"runId": "run_123",
"budgetEnvelope": {
"initialBudgetMs": 20000,
"inheritedFrom": "plan_step_03",
"remainingBudgetMs": 3800,
"reservedForFinalizeMs": 800,
"timeoutPolicy": "degrade_then_safe_stop"
}
}
这会让 orchestration、tool gateway 和 callback handler 都围绕同一份预算语义工作，而不是各自把 timeout 当成孤立参数。
三、Tool timeout 不能和 Run deadline 写成同一个数字
很多系统会直接把 tool timeout 设成和 run timeout 一样，例如都 30 秒。这样做的问题是，一个慢工具就足够把整个 run 的时间全部吃光。
更合理的分配方式通常是：
| 调用类型 | 典型 timeout |
|---|---|
| 检索与只读查询 | 1-3 秒 |
| 内部业务 API | 3-8 秒 |
| 模型调用 | 5-20 秒 |
| 外部第三方服务 | 按 SLA 设短 timeout + degrade |
重点不是具体秒数，而是不同调用类型必须服从统一的预算分层。
四、deadline 需要向下游传递，而不是只在 orchestrator 自己知道
如果 orchestrator 知道 deadline，但 tool gateway 和业务服务完全不知道，系统依然容易出现“上游已没预算，下游还在努力处理”的浪费。
更稳的做法是显式传递 deadline：
{
"traceId": "trace_123",
"runDeadlineAt": "2026-05-10T10:00:20Z",
"stepBudgetMs": 2500,
"caller": "agent_tool_gateway"
}
这样下游服务也能基于同一份时间边界决定：继续处理、快速失败，还是直接返回 degrade 建议。
五、超时后的动作必须分层，不是所有 timeout 都重试
一个更有用的超时分类表通常长这样：
| 超时位置 | 常见原因 | 推荐动作 |
|---|---|---|
| 检索超时 | 索引慢、网络抖动 | 降级为少量上下文继续 |
| 模型超时 | 上游拥堵、输出过长 | 降级模型或缩短任务 |
| 写入前校验超时 | 下游接口抖动 | 停止自动继续，转人工 |
| 回调等待超时 | 外部系统无响应 | 挂起 run，等待异步结果 |
只要系统把所有 timeout 一律当作 retry 信号，迟早会把小抖动变成大风暴。
很多系统真正缺的，不是 timeout 类型，而是剩余预算阈值。一个更实用的收口表通常是：
| remaining budget | 推荐动作 |
|---|---|
| > 40% | 按完整链路继续 |
| 15% - 40% | 关闭非关键步骤，优先保主路径 |
| 5% - 15% | 直接走 degrade 或短结果模式 |
| < 5% | 不再继续推理，进入 safe stop / handoff |
没有这张表，系统虽然知道“预算快没了”，但仍然不知道应该在什么时候主动收口。
六、超时设计要和取消、恢复、队列一起工作
时间预算不是孤立模块，它至少会同时影响三件事：
- 是否还能继续执行当前步骤
- 是否应该触发 AI agent 取消、中断与安全停机 的收口逻辑
- 是否需要回到 AI agent Checkpoint 与断点恢复 或队列等待下一个窗口
也就是说，deadline 不是一个“出错时打印日志的字段”，而是驱动状态转移的核心输入。
七、上线后要看预算耗尽点，而不是只看超时率
建议至少记录这些指标：
| 指标 | 用途 |
|---|---|
| run deadline exceeded rate | 看整体业务窗口是否合理 |
| average budget consumed by step | 看哪一步最容易吃掉总预算 |
| budget exhausted before side effect ratio | 看关键动作前是否经常已经没预算 |
| timeout after retry ratio | 看重试是否只是浪费时间 |
| degrade before timeout ratio | 看系统是否能提前收口 |
如果你只统计 timeout 次数，却不知道预算是在哪个步骤被吞掉的，后续优化依然会很盲。
八、失败案例：模型没超时，但整个 Run 已经没有业务价值
某个审批辅助 agent 的总预算是 25 秒。前面检索和工具调用花了 21 秒，系统仍然允许模型继续完整生成解释文本，最终在 24 秒返回。技术上没有超时，但审批界面此时已经被人工跳过，结果等于无效产出。
修复后，团队把剩余预算小于阈值的场景直接切到“短结果 + 人工说明入口”，不再追求完整自动化输出，整体 accepted run 反而更高。
九、Deadline 与超时预算 Checklist
- 是否同时定义 run deadline、step budget 和 tool timeout
- deadline 是否来自业务时效要求，而不是拍脑袋的技术参数
- 每个步骤是否读取剩余预算，而不是假设自己总有完整时间
- budget envelope 是否包含继承来源、保留预算和 timeoutPolicy
- 下游服务是否能收到 deadline 与 budget 信息
- 不同 timeout 是否映射到不同收口动作
- 是否定义 remaining budget 阈值与对应 degrade / handoff 动作
- 超时设计是否与取消、Checkpoint 和队列联动
- 是否持续监控预算在哪个步骤被主要消耗
结语
AI agent 的 deadline 设计，不是“给系统加个 timeout”，而是把时间当成和成本、风险一样的一等约束。只有 run、step、tool 三层预算同时成立，系统才知道自己应该在什么时候继续努力，什么时候果断收口。
延伸阅读：
