学习指南: 应用部分 9. 模型路由与令牌预算

模块「应用部分 9. 模型路由与令牌预算」中第 3 / 5 节课

您正在未登录状态下查看课程。请登录，以保存进度并参加测试。

主题：应用部分 9. 模型路由与令牌预算

难度级别：中级

预计学习时间：4-6小时（理论+实践），额外2小时用于完整阈值校准流程

前置知识：熟悉SDD周期（第一卷中的信号收集、检测、诊断）

第一卷第15部分：智能体可替换性

第一卷第14部分：项目技能与Qwen Code钩子

基础Python和命令行操作

理解MTTR、SLA、事件升级等概念

学习目标：模拟并验证廉价模型层级故障场景，确保仅关键任务进入昂贵层级，同时保持token_health_min ≥ 0.5

按事件管理阶段（分类、分级、诊断、计划、修复、事后分析）分配令牌，local-coder与frontier-reviewer之间保持90/10比例

制定并应用反古德哈特定律规则验证预算优化，将MTTR与四项守门指标关联

确定紧急模式（红色按钮）的激活条件，并论证何时手动模式比继续自动化更安全

为毕业项目创建budget-note.md工件，记录故障风险、影响、守护阈值及决策

概述：本章将每日令牌预算从静态限额转变为SDD流水线的可管理路由表。层级预算（tier-budgeting）按工作阶段在各模型层级间分配令牌：廉价模型local-coder处理常规任务（分类、分级、初步诊断），昂贵的frontier-reviewer仅在关键审查、争议决策和事后分析时启用。核心技能是故障模拟：当廉价层级宕机时，系统不应自动将全部队列重定向至昂贵层级，否则配额将在数分钟内耗尽，真正的P0/P1事件将无资源可用。本章包含可运行示例（compile.py、simulate.py、inspect.py）、15分钟和45分钟故障场景，以及与反古德哈特定律验证的集成以防止指标扭曲。

核心概念：层级（tier）：处理层次结构中的模型级别。local-coder是用于大规模常规任务的基础层级，frontier-reviewer是用于争议和高风险案例的顶层层级。角色而非模型名称：不同项目中可能有不同的实现。

令牌健康度（Token health）：跟踪已消耗和剩余令牌与计划比例的预算健康度综合指标。最小值token_health_min用作阻止自动切换的守护阈值。

故障转移至前沿（Failover to frontier）：层级故障时的负载切换计划。分级切换：仅高严重度和高时效性任务进入frontier-reviewer，其余进入降级队列或手动通道。

降级队列（Degraded queue）：降级队列——廉价层级故障时无法在标准模式下处理、但尚未需要立即升级至昂贵层级的任务。

120秒后手动队列（Manual queue after 120s）：120秒超时后开启的手动通道，用于自动处理未完成的任务。并非退回混乱：继承相同的证据协议和PostToolUse验证。

控制储备（Control reserve）：仅在风险、队列或不确定性上升时激活的预算保险层。不是"剩余随便用"。

红色按钮（紧急模式）：在正式条件下激活的受保护管理模式：两个令牌健康度风险窗口、队列超限、关键严重度SLA超限或local-coder宕机。限制新队列，禁止大规模自动修复，为P0/P1保留frontier-reviewer。

反古德哈特定律验证：禁止以其他指标恶化为代价认定发布成功的规则。MTTR需与escalation_share、silent_p0、unresolved_manual_ratio、postmortem_gap和token_health_min共同验证。

预算守护者（Budget-keeper）：令牌预算控制服务，每分钟重新计算spent[p]、queue[p]、quota[p]、事件时效、影响范围和置信度差距，以做出路由决策。

预算演练（Budget-drill）：每日训练演练：将昨日告警流通过当前budget_network.yaml回放，并人为关闭local-coder 15/30/45分钟以校准系统灵敏度。

实践练习：标题：编译预算计划并验证比例

问题：在book2/examples/budget-keeper目录中，从specs/budget_network.yaml编译预算计划。验证daily_budget_tokens等于10,000,000，local层级配额总和为9,000,000，frontier层级为1,000,000。将结果与参考outputs/budget_plan.example.json对比。

解答：1. cd book2/examples/budget-keeper

python3 scripts/compile.py --budget-spec specs/budget_network.yaml --out out/budget_plan.json
验证字段daily_budget_tokens: 10000000
计算local-coder总和：3000000 + 2000000 + 1500000 + 800000 + 700000 + 300000 + 700000 = 9000000
计算frontier-reviewer总和：120000 + 140000 + 180000 + 120000 + 200000 + 240000 + 0 = 1000000
diff out/budget_plan.json outputs/budget_plan.example.json — 应无差异（或仅注释不同）

难度：初级

标题：45分钟故障模拟与综合检查

问题：模拟local-coder故障45分钟，队列中有20个事件，手动超时120秒。同时验证四个条件：failover_to_frontier == 5、degraded_queue == 15、manual_queue_after_120s == 15、token_health_min >= 0.5。解释为何不能单独检查各指标。

解答：1. python3 scripts/simulate.py --plan out/budget_plan.json --scenario scenarios/fail_local_45m.json --out out/fail_result.json

python3 scripts/inspect.py --result out/fail_result.json --query "failover_to_frontier==5 && degraded_queue==15 && manual_queue_after_120s==15 && token_health_min>=0.5"
预期返回码：0（所有条件满足）
为何不能单独检查：仅验证failover_to_frontier==5无法保证其余15个任务未通过其他机制进入frontier；仅验证token_health不显示队列分布；&&复合条件保证整体图景——任一指标失败即中断演练并需排查

难度：中级

标题：15分钟与45分钟故障对比分析

问题：模拟local-coder短故障15分钟。验证token_health_min >= 0.7。解释为何短故障对frontier层级的消耗较缓和，以及这如何影响生产环境守护阈值的选择。

解答：1. python3 scripts/simulate.py --plan out/budget_plan.json --scenario scenarios/fail_local_15m.json --out out/fail_15m_result.json

python3 scripts/inspect.py --result out/fail_15m_result.json --query "token_health_min>=0.7"
返回码：0
解释：15分钟故障时队列积累较少，需升级至frontier-reviewer的任务较少，备用预算消耗较少。45分钟故障时队列增长，frontier层级压力增大，token_health下降更明显。
生产结论：守护阈值0.60（低于45分钟故障观测到的谷底0.5，但留有裕量）在可预测故障时阻止自动切换；45分钟故障击穿守卫，需人工决策

难度：中级

标题：毕业项目风险表述

问题：基于模拟结果，在capstone/budget-note.md中为你的主案例（如high_memory_usage）创建记录。记录风险、影响、simulated_floor、alert_threshold和decision。解释simulated_floor与alert_threshold的区别。

解答：最小片段：

risk: "local-coder不可用45分钟"
effect: "5个任务进入frontier-reviewer，15个保持降级/手动"
simulated_floor: "token_health_min == 0.5（45分钟时的下探值）"
alert_threshold: "token_health_min < 0.60（反古德哈特定律表的守卫值）"
decision: "不将全部队列转入昂贵层级"

区别：simulated_floor（0.5）是模拟中观测到的谷底，测试场景的实际最小值。alert_threshold（0.60）是守卫阻止生产环境自动切换的警戒线。0.5至0.60之间是预警区——系统仍在运行，但需操作员关注。

难度：中级

标题：压缩预算校准（5M）

问题：使用specs/budget_network_5m.yaml校准500万令牌的变体。验证90/10比例保持。模拟相同45分钟故障，分析总预算减半如何影响系统行为和守护阈值的适用性。

解答：1. python3 scripts/compile.py --budget-spec specs/budget_network_5m.yaml --out out/budget_plan_5m.json

验证：daily_budget_tokens == 5000000，local总和 == 4500000，frontier总和 == 500000
python3 scripts/simulate.py --plan out/budget_plan_5m.json --scenario scenarios/fail_local_45m.json --out out/fail_result_5m.json
python3 scripts/inspect.py --result out/fail_result_5m.json --query "token_health_min>=0.5"
分析：预算减半时绝对配额减少，但系统相对压力增大——相同20个事件流消耗更大比例的储备。token_health_min可能跌破0.5或守护阈值0.60变得不可达。结论：按流量比例扩展预算时保持control_reserve裕量；流量不匹配时重新审视守护阈值或将frontier层级比例增至15-20%

难度：高级

标题：反古德哈特定律网关验证

问题：为预算网关编写validation.md的YAML片段。条件：若MTTR P95 < 5分钟且升级比例 < 8%，则在silent_p0 > 2%、unresolved_manual_ratio > 5%、postmortem_gap > 10%或token_health_min < 0.60时验证失败。解释为何采用这种成对检查。

解答：validation.md片段：

checks:
  - id: anti_goodhart_budget
    if:
      all:
        - mttr_p95 < "5m"
        - escalation_ratio < 0.08
    then:
      fail_if:
        - silent_p0 > 0.02
        - unresolved_manual_ratio > 0.05
        - postmortem_gap > 0.10
        - token_health_min < 0.60

为何成对检查：若无此机制，系统可能通过压低升级（静默P0）、将复杂任务推入手动通道而不做事后分析、或耗尽frontier层级预算来优化MTTR。以其他指标恶化为代价改善单一指标——这是典型的古德哈特定律扭曲。网关阻止这种"节约"。

难度：高级

案例研究：标题：生产环境local-coder故障：autoscale_200pct事件

场景：生产系统appointments-api，早间负载高峰。11:00时廉价模型local-coder的本地端点因集群网络故障不可用45分钟。20个与自动扩容至200%负载相关的事件进入队列。手动超时设置为120秒。每日预算：1000万令牌，local-coder与frontier-reviewer分配比例为900万/100万。

挑战：经典陷阱：廉价层级故障时自动将全部流量重定向至昂贵层级。这将导致100万frontier-reviewer配额在数分钟内耗尽，之后真正的P0/P1事件将无资源可用。替代陷阱：将所有任务留在降级队列，增加MTTR并可能违反关键案例的SLA。第三陷阱：不跟踪令牌健康度，未注意到危险级别的下探。

解决方案：应用分级故障转移策略：仅5个影响范围最大且时效超过90秒的任务进入frontier-reviewer。15个任务留在降级队列。120秒后，未自动处理的任务开启手动通道manual_queue_after_120s。预算守护者每分钟重新计算token_health、spent[p]、queue[p]、quota[p]。当token_health_min < 0.60（守护阈值）时，自动切换被阻止，需人工决策。本场景中token_health_min达到0.5——击穿守卫，激活红色按钮审查。

结果：四项检查条件同时满足：failover_to_frontier == 5、degraded_queue == 15、manual_queue_after_120s == 15、token_health_min >= 0.5。昂贵层级为真正的P0/P1保留。关键任务MTTR未受影响。手动通道继承证据协议，使local-coder恢复后能够审计所有决策。阶梯式回退：先30% local-coder配额用于分类/分级，三个稳定窗口后恢复诊断/计划，完整恢复仅在PostToolUse审计后。

经验教训：不能单独检查故障指标——仅&&复合条件保证完整性

simulated_floor（0.5）与alert_threshold（0.60）之间需要预警裕量，而非仅应急响应

手动模式不是退回混乱，而是保留证据链的可控降级

稳定后的阶梯式回退防止过早恢复引发二次级联错误