资源实验室：路由、队列、背压与故障降级

参考：来源 F · 第 16 章进阶

学完你能做到

建立逐步扣减的资源账本
理解队列、背压、熔断与降级
设计上下文裁剪和模型路由评估

真正的资源感知不是“主模型贵就换便宜模型”。它还要回答：高峰时谁先执行、工具变慢时是否继续排队、上下文太长时删什么、失败是否值得重试、降级后哪些能力必须关闭。

资源信封：每个任务领取独立预算，编排器在每一步前检查剩余资源和预期收益。

运行机制	解决的问题	触发信号	错误实现
队列	请求多于并发容量	等待任务数、预计等待时间	无限排队直到全部超时
	下游处理不过来	队列增长、工具延迟上升	仍持续创建子任务
	故障服务被反复调用	连续失败率或超时率	每个请求都等待同一故障
降级	核心服务不可用	熔断开启、预算不足	换模型却继续宣称完整能力
缓存	重复计算和检索	稳定输入和可接受时效	缓存个性化或过期敏感结果

熔断器状态机。半开状态只放少量探测请求，不能一次恢复全部流量。

上下文优化不是粗暴截断

永远保留目标、权限、成功标准、未解决阻塞和最近工具结果。
历史证据保存原文索引，在当前上下文只放与下一步相关的片段。
重复内容去重；已完成步骤压缩成状态，不保留全部寒暄。
压缩结果必须标记为摘要，关键数字、否定、引用和决策不能被无损假设。
被裁掉的信息仍保存在外部事件日志，可按需恢复。

容量保护顺序

if queue.wait_time > sla: reject_or_defer(low_priority)
if dependency.failure_rate > threshold: circuit.open()
if context.over_budget(): prune_by_relevance_and_obligation()
if task.remaining_budget < required_minimum:
  return partial_result(capabilities_disabled, next_step)
route(task, model=cheapest_model_meeting_hard_requirements)

高峰流量演练

25 分钟

假设 100 个学生同时交卷，设计优先队列和最大并发。
主模型 30% 超时、语音工具正常时，画出降级路径。
定义用户在完整分析、部分分析和排队状态下分别看到什么。

综合演算：为十倍突发流量设计容量与降级

论文截止日前请求从每分钟 300 增至 3000。主模型有配额，搜索服务会限流，PDF 解析占用大量 CPU。目标不是“永不失败”，而是优先保住关键功能。

本节追问：如何从服务等级反推队列、并发和降级层次？ 先不要急着看结论。沿着下面四步，逐项区分输入、决策、证据和失败信号。

四步案例推演。手机上可左右滑动查看；每个箭头都代表一次需要证据支撑的状态转换。

阶段	本步要做的决定	什么算证据	最常见的失败
定义等级	区分即时问答、后台报告和可延后索引	每类有延迟与成功率目标	所有任务共用一个 FIFO 队列
计算瓶颈	估算模型 QPS、解析吞吐和外部配额	容量模型能定位最先饱和组件	只扩 Web 实例忽略下游
设计降级	缓存、缩短上下文、延后报告、保留证据基线	每级降级明确用户获得什么	故障时静默返回空答案
演练恢复	模拟限流、超时和积压并观察恢复	解除故障后不会流量洪峰再冲击	服务恢复瞬间释放全部重试

阅读方式：先遮住后两列自己回答，再用“证据”和“失败”两列检查理解。

常见误解

平均延迟达标就认为容量足够

实际上

可观察症状：尾延迟与突发流量仍让大量用户超时。

更可靠的修复：同时看 p95/p99、队列长度、拒绝率和恢复时间。

案例工作坊 · 建议真正动手完成

25 分钟

用给定流量估算三个组件的最小吞吐。
设计三级降级表及触发、恢复阈值。
画出带优先级与死信队列的流量图。

查看参考答案

容量设计从用户服务等级开始，经过瓶颈预算、优先级队列与降级策略，最后用故障演练验证。平均值不能代表高峰可靠性。

迁移检查：换一个场景还会不会

故障恢复后为什么要缓慢放量？