很多团队在单 Agent 试点阶段，会把稳定性问题归咎于模型波动，觉得“今天聪明、明天迟钝”就是大模型系统的常态。可一旦 Agent 开始串接检索、数据库、工单、邮件或内部 API，真正拖垮稳定性的往往不是推理能力，而是工具层没有被赋予明确的延迟预算。某个检索慢了 8 秒、某个写库接口偶尔卡住 15 秒、某个权限查询在高峰期抖动，都会把原本还能控的单 Agent 运行拖进排队、超时、重复重试和状态过期的连锁反应里。
OpenAI Agents SDK 对运行过程的定义、LangGraph 对持久状态的设计，以及 Anthropic 对工具调用边界的说明都指向同一件事：工具不是被模型随手调用的黑盒，而是运行时里需要被治理的执行单元。对 TaskPilots 的独立运行 Agent 来说，延迟预算和降级逻辑不是性能优化附属项，而是让系统在工具变慢、结果不完整或外部依赖波动时仍能保持可控的基础能力。
为什么这个问题重要
延迟没有预算时，单 Agent 会在最慢的一步上失控
单 Agent 的问题不在于步骤少，而在于所有步骤都串在同一条运行链上。一次规划、一轮工具调用、一段结果校验、一次状态写回，任何一个环节拖得太久，整条 run 都会被一起拖住。如果系统没有明确规定“这一类工具最多等多久”“这一轮运行最多耗时多久”，它就会默认一直等下去，直到用户先失去耐心，或者队列先把自己压垮。
这类失控最容易被误看成模型不稳定，因为从表面现象看，都是“回答忽快忽慢”“有时能完成、有时中途失败”。但真正需要管理的，是工具层的等待边界和让出策略，而不是继续放大 Prompt 或增加重试次数。
- 没有 run 级预算时，单次慢调用会吞掉后续所有步骤的时间。
- 没有 step 级预算时，规划、检索、写回之间会互相抢占执行空间。
- 没有 tool 级预算时，运行时无法区分“值得继续等”和“该立刻降级”。
没有降级逻辑，超时就会被放大成用户可见的不稳定
延迟本身不一定致命，真正致命的是超时之后系统不知道怎么办。检索慢了，Agent 是该改用缓存答案、缩小回答范围、推迟副作用，还是直接升级人工？如果这些分支没有提前设计，超时就只会落成三种坏结果：盲等、盲重试，或者拿半截结果硬着头皮往下做。
对外部用户来说，这三种表现都会被感知成“不稳定”。他们看不到内部是哪个工具抖了，只会记得系统一会儿沉默、一会儿重复、一会儿给出不完整结果。降级逻辑的价值，就是在最坏情况下仍然给出可预期行为，而不是让失败表现随机化。
适用场景
最需要这套方法的，是有真实 SLA 和副作用的单 Agent 流程
如果单 Agent 已经开始处理客户对话、工单流转、销售跟进、内容审批、内部运维执行或跨系统资料同步，那么它通常已经不再是“能跑就行”的实验功能。这类流程往往同时具备三个特征：有明确的响应时间预期、有多个外部依赖、并且运行结果会改变真实业务状态。只要这三个条件同时出现，延迟预算和降级逻辑就该进入运行时主设计，而不是事后补丁。
尤其要优先处理那些“用户在线等结果”又“后面还会写状态”的链路，因为这里最容易同时出现等待过长、上下文过期和重复副作用。系统不是慢一点而已，而是会在慢的过程中逐步变得不可信。
如果还是纯离线试验，可以先做轻量版预算
并不是每个单 Agent 原型都要一开始就做完整预算树。如果当前只是离线研究、一次性摘要或纯建议生成，没有严格响应时限，也不触发外部写操作，那么可以先采用轻量版：只定义总体超时、记录慢调用分布，并把最慢的工具先单独监控起来。
一个实用判断标准是：用户是否能感知这次等待，或者等待过程中系统是否可能占住资源、阻塞后续任务、让状态失真。只要答案里有一个“会”，就该把预算从“以后再说”提到当前设计里。
推荐系统结构
先把 run 预算拆到步骤，再拆到工具和回退策略
比较稳的做法，是先定义一条运行链路的总预算，再把它分摊到关键步骤和关键工具，而不是让所有环节共享一个模糊的“请求超时”。比如一条 20 秒预算的 run，可以先预留 2 秒给规划、6 秒给主检索、3 秒给结果校验、3 秒给状态写回，再保留一定缓冲给重排和网络抖动。这样一来，系统才能在某个工具耗尽预算时做出明确判断，而不是把整条链路一起拖死。
- run 级预算：定义一次任务最多能占用多久系统时间。
- step 级预算：定义规划、检索、执行、校验和写回各自的时间上限。
- tool 级预算：根据工具类型、历史分位延迟和副作用等级设定不同 deadline。
- fallback 级策略：规定预算耗尽后是降级回答、延后执行、切缓存、换工具还是人工接管。
这套结构的关键不是数字多精确，而是运行时必须知道“什么时候不再继续等”，以及“停止等待后下一步应该是什么”。只有预算和回退同时存在，超时才不会演变成失控。
在 TaskPilots 里，预算、状态快照和降级决策要一起入账
映射到 TaskPilots，独立运行 Agent 不该只记录工具返回值，还应显式记录 `run_budget`、`step_deadline`、`elapsed_ms`、`fallback_mode` 和最新 `state_snapshot`。这样一次运行在超时后，不只是“失败了”，而是能清楚知道：它在哪一步耗尽了预算、有没有触发降级、降级后是否写回了安全状态、后续是应该恢复继续还是直接人工接管。
这也能和站内关于 持久状态如何让单 Agent 重试更安全、以及 为什么工具结果要先校验再推进 的原则拼成一套完整运行时逻辑。预算告诉系统何时该停，校验告诉系统哪些结果可用，状态快照则保证停下来之后还能安全恢复。
风险与失效点
预算设错和回退设错，都会把单点抖动放大成系统问题
延迟预算不是越紧越好，也不是越宽越安全。预算设得过紧，会把本来只是偶发慢调用的情况误判成失败，导致系统频繁走降级路径，用户看到的是“系统总在保守退回”；预算设得过宽，则会让长尾延迟吞噬线程、队列和会话窗口，最后形成整体雪崩。真正难的地方，是让预算和外部依赖的真实分布匹配，而不是拍脑袋给一个统一超时值。
- 预算过紧：正常抖动也会频繁触发 fallback，体验会显得过度保守。
- 预算过松：尾延迟持续占住资源，系统整体吞吐开始下降。
- 回退无验证：降级路径若直接使用缓存或替代工具，也可能引入过期或错误结果。
- 回退无冷却：超时后立刻重试同一工具，只会把局部故障扩大成队列拥堵。
很多所谓“单 Agent 不稳定”，最后追到根上，其实不是模型不可靠，而是预算体系和回退路径根本没有被当作系统部件来设计。
涉及不可逆动作的地方，必须保留人工兜底
降级逻辑不代表任何情况下都要自动给出替代动作。只要后续步骤涉及发信、提交审批、修改配置、更新客户状态、创建外部记录或任何不可逆副作用，就不应该在信息不完整或预算耗尽时继续自动推进。更稳的做法，是把这种场景定义为“允许停住，但不允许猜着做”。
因此，高影响链路里至少应保留两类人工兜底点：一类是预算耗尽但又必须完成的关键步骤，另一类是降级结果虽然可用、但置信度不足以触发副作用的场景。人工接管不是为了替系统慢慢等，而是为了在证据不足时接管最终判断。
验证指标
上线前先压测长尾延迟和回退路径，而不是只看平均时间
上线前最常见的误判，是平均响应时间看起来不错，于是团队就以为系统稳定。可单 Agent 的稳定性更容易被 p95、p99 和冷启动拖垮，因此验证必须覆盖长尾延迟和完整回退路径。至少要准备三类演练：工具偶发慢 2 到 3 倍、工具返回部分结果但超时、以及多工具连续抖动下预算如何被重新分配。
- 分位压测：分别测量正常、冷启动和高峰期下的 p50、p95、p99。
- 故障注入：人为制造超时、半返回、网络抖动和错误码，确认系统会走对 fallback。
- 状态校验：确认降级后仍会留下可恢复的状态，而不是只返回一个失败标记。
- 副作用检查：确认 budget 耗尽后，不会继续触发不安全的写操作。
上线后持续看预算命中率、降级成功率和恢复时间
进入生产后，建议至少长期观察六类指标：端到端执行成功率、各关键工具的 p95/p99 延迟、预算耗尽触发率、fallback 激活率、fallback 后任务完成率，以及从降级到恢复完成的中位时间。只有把这些指标放在一起看，团队才能区分“系统真的更稳定了”还是“只是更常失败但失败得更安静了”。
除此之外，还值得单独追踪状态一致性错误率和重复副作用事件数。前者说明降级后有没有留下清晰事实层，后者说明系统是不是在超时场景里仍然会误重试。只看平均时延，不看这些结果型指标，往往会把稳定性问题藏起来。
下一步 / FAQ
先从一条高价值链路画出预算树和三类 fallback
最务实的第一步，不是一次性给所有工具上统一超时，而是挑一条最重要的链路，先画出它的预算树：总预算是多少、哪些步骤最关键、哪些工具最容易拖慢、超过预算后允许哪三类回退。通常至少要有三种 fallback：缩小任务范围、改走低风险替代路径、以及停在安全状态等待恢复或人工接管。
只要这条链路的预算树和回退规则跑通，后续就能用同一套方法扩展到其他工具。单 Agent 真正需要的，不是永远更快，而是在不可避免变慢时仍然有确定动作。
FAQ
问：预算是不是设一个总超时就够了？
答：通常不够。总超时只能告诉你任务什么时候整体失败，不能告诉运行时该在哪一步停、该让哪个工具降级、又该保留哪些缓冲给后续步骤。
问：更强的模型能不能替代预算和 fallback？
答：不能。模型再强，也无法消除外部工具的网络延迟、服务抖动和依赖拥塞；预算和回退处理的是运行时现实，不是推理质量。
问：fallback 是不是就是重试？
答：不是。重试只是其中一种选择，而 fallback 更关注在预算耗尽后，系统要不要换路径、缩范围、切缓存、延后执行或升级人工。
问：预算会不会让系统显得太保守？
答：如果预算和业务价值匹配得当，系统不会更保守，而是更可预测。真正伤害体验的，通常不是“及时降级”，而是“既没成功也没及时停下”。