附录 D. 阈值校准

这是一份参考附录。第一遍阅读时无需关注：每章的学习最小量都基于 AgentClinic-production 的默认阈值设计。本文件汇总了所有「低/默认/高」表格、阈值偏移练习以及需要重新审视阈值的信号。在将流程迁移到您自己的项目、且标准值不再适用时，请使用本附录。

所有表格的通用原则：阈值只有成对才有意义。只调整一个值而不重新计算关联值，这不是校准，而是拆除控制回路。每个章节都明确列出了此类偏移的风险。

D.1 变异测试（第 5 章）

第 5 章中的数值是 AgentClinic-production 的默认值，适用于中等事件流量和成熟的 SDD 流程。在您的项目中，阈值取决于 P0 遗漏的代价、路由图的复杂度、CI 的 SLA 窗口以及输入流量的稳定性。任何行的偏移都必须伴随 validation.md 中的记录及理由说明。

练习

cd book2/examples/stress-mutator

mkdir -p out
cp expected/expected_failures.json out/expected_failures_depth5.json
sed -i 's/"depth_of_diagnostics_min": 3/"depth_of_diagnostics_min": 5/' out/expected_failures_depth5.json

python3 scripts/immunity_score.py \
  --validator-results out/validator_results.json \
  --expected expected/expected_failures.json \
  --out out/immunity_default.json

python3 scripts/immunity_score.py \
  --validator-results out/validator_results.json \
  --expected out/expected_failures_depth5.json \
  --out out/immunity_depth5.json

第一次运行应该通过：平均诊断深度为 4，超过阈值 3。第二次运行应以退出码 1 结束：同一个验证器无法通过人为收紧的阈值 depth_of_diagnostics_min = 5。这个差异显示的不是变异体中的新缺陷，而是收紧阈值的代价。

何时重新审视阈值

• 一个季度内没有任何合并被阈值阻止——阈值过低，冗余。
• 一周内同一 mutation_id 出现超过 10 次回归——depth_of_diagnostics 不足，需增加。
• recovery_time_p95 在 strict_reject_rate 上升时趋近于零——古德哈特定律的迹象。
• 出现新的事件类别——重新计算所有三个阈值。
• 同一 seed 连续五个冲刺重复相同的 mutation_id 集合——需要种子轮换。

风险：如果 strict_reject_rate 上升而 depth_of_diagnostics 同时下降，这是古德哈特定律的症状。两个参数只能成对调整。

D.2 影子规范筛选（第 6 章）

权重 0.5*mttr_gain + 0.3*early_signal + 0.2*coverage - 0.4*false_escalation 以及 keep/reject 阈值是 AgentClinic-production 的默认值。在您的项目中，它们取决于误报升级的代价、早期信号的重要性、历史数据库的规模以及提示样本的可用预算。

练习

使用保守风险配置文件（更高的误报升级惩罚）运行拍卖：

cd book2/examples/shadow-auction
python3 scripts/score.py --candidates candidates/candidates.yaml --incidents data/incidents.jsonl --weights "0.3,0.4,0.2,0.8" --out out/scorebook.json

python3 scripts/decide.py --scorebook out/scorebook.json --budget-tokens 2000 --keep-threshold 0.70 --reject-threshold 0.40 --out-auction out/auction.json --out-quarantine out/quarantine.json

在此配置文件下，shadow.p0.voice_handoff 从 winner 移至 disputed，而 shadow.alert.red_color_urgency 仍留在 rejected。这是新配置文件的表现：团队对 MTTR 缩减的奖励减少，对误报升级的惩罚加重。

何时重新审视阈值

• 一个月内没有任何 winner 在事后分析中显示正面效果——keep-threshold 过低。
• disputed 比例持续高于 40%——公式无法区分案例。
• 一个阶段选出超过 8 个获胜者——budget-tokens 未考虑 QWEN.md 的大小。
• 出现历史数据之外的新事件类别。
• mttr_gain 和 false_escalation 同时上升——古德哈特定律的症状。

风险：false_escalation 惩罚和 mttr_gain 权重只能成对调整。单独调整一个会破坏「有用信号 ↔ 虚假噪声」的关联。

D.3 分层预算（第 9 章）

1000 万令牌的预算，按 900 万/100 万（本地/前沿）分配，是 AgentClinic-production 在中等事件流量下的默认值。在您的项目中，预算规模和比例取决于事件流量、阶段平均成本、争议审查比例以及对 local-coder 故障的敏感度。

练习

cd book2/examples/budget-keeper

python3 scripts/compile.py --budget-spec specs/budget_network_5m.yaml --out out/budget_plan_5m.json
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 "failover_to_frontier==2 && degraded_queue==18 && token_health_min>=0.5"

检查在预算减半时 token_health_min 是否仍高于 0.5。在准备好的 5M 版本中，比例保持不变：本地层获得 4.5M，前沿层获得 0.5M。如果只更改 daily_budget_tokens 而不更改阶段配额，compile.py 必须因总和错误而失败。

何时重新审视阈值

• 一个月内没有任何 degraded_mode 触发——预算冗余，或实际流量低于预期。
• token_health_min 每周低于 0.5 超过一次——本地层不足。
• 本地层故障时 failover_to_frontier 持续为 0——网关过于严格，前沿层未起到保险作用。
• 手动超时后 manual_queue 比例连续两个月上升——manual_timeout_sec 过短。
• 每日消耗低于 daily_budget_tokens 的 60%——应压缩预算。

风险：9M/1M 的划分与阶段 SLA 相关联。不更新规范中的 budget_plan_phases 就进行调整是不可行的——前沿层将无法容纳「争议」案例。

D.4 指标的古德哈特防护（第 10 章）

阈值 silent_p0 ≤ 5%、manual_review_rate ≥ 15%、edge_drift ≤ 0.12、audit_trace_coverage = 1.0 是 AgentClinic-production 的默认值。在您的项目中，它们取决于遗漏 P0 的代价、人工审核员的可用性、输入流量的动态以及审计的监管要求。

练习

cd book2/examples/goodhart-validator

mkdir -p out

# 将 spec 复制到本地 out/ 并将 silent_p0_cap 放宽至 0.08
cp specs/validation.yaml out/validation_loose.yaml
sed -i 's/threshold: 0.05/threshold: 0.08/' out/validation_loose.yaml

python3 scripts/run_validation.py \
  --validation out/validation_loose.yaml \
  --metrics fixtures/new_metrics_bad.json

# 危险版本：同时放宽两个独立防护
cp specs/validation.yaml out/validation_unsafe.yaml
sed -i 's/threshold: 0.15/threshold: 0.10/' out/validation_unsafe.yaml
sed -i 's/threshold: 0.05/threshold: 0.20/' out/validation_unsafe.yaml

python3 scripts/run_validation.py \
  --validation out/validation_unsafe.yaml \
  --metrics fixtures/new_metrics_bad.json

第一次运行应保持红色：silent_p0=0.18 的糟糕发布仍然违反 silent_p0_cap。第二次危险的版本之所以通过，仅仅是因为同时放宽了两个独立的防护。这说明了为什么不能逐行 YAML 校准防护指标。

何时重新审视阈值

• 一个季度内没有任何发布被 silent_p0_cap 阻止——要么团队没有进行风险变更，要么阈值过于宽松。
• manual_review_rate 在 mttr_gain 上升时连续三个冲刺下降——古德哈特定律的症状，人工审核员不再作为保险。
• edge_drift 稳定在 0.10–0.11 附近波动——实际输入动态接近阈值。
• audit_trace_coverage 在任何一次运行中低于 1.0——违反监管不变量，需热修复，不是校准。
• 出现未纳入 silent_p0 的新事件类别——需要新不变量，而非重新审视旧阈值。

风险：silent_p0 和 manual_review_rate 只能成对调整。edge_drift 仅在 audit_trace_coverage=1.0 时有意义，否则漂移是基于部分样本计算的。四个阈值构成统一的风险契约：单独放宽一个而脱离其他阈值意味着破坏它，而非调整它。

完整指标网络

正文中使用了简化版的 mermaid 图表，包含三个指标和一个守卫。完整的依赖网络如下：

flowchart LR
    MTTR[MTTR]
    silent_p0[silent_p0]
    manual_review_rate[manual_review_rate]
    escalation_rate[escalation_rate]
    postmortem_regression[postmortem_regression]
    audit_trace_coverage[audit_trace_coverage]
    silent_p0 -->|positive_interdependence| MTTR
    escalation_rate -->|positive_interdependence| MTTR
    manual_review_rate -->|negative_interdependence| MTTR
    manual_review_rate -->|negative_interdependence| escalation_rate
    audit_trace_coverage -->|negative_interdependence| escalation_rate

audit_trace_coverage -->|negative_interdependence| silent_p0
    postmortem_regression -->|positive_interdependence| audit_trace_coverage
    postmortem_regression -->|negative_interdependence| manual_review_rate

逻辑与简化版相同：红色区域是 MTTR 和 silent_p0；通向其弱化的路径是通过缩减人工检查和丢失审计追踪。

D.5 生产就绪性（第 11 章）

23/25 的阈值是 AgentClinic-production 的默认值，适用于中等成熟的 SDD 流程和混合操作类型。在您的项目中，阈值取决于切换错误（cutover）的代价、流程成熟度、人工审查负载以及操作特性（无状态/有状态）。

练习

脚本 check_readiness.py 硬编码了 THRESHOLD = 23。通过副本以其他值运行：

cd book2/examples/real-api && mkdir -p out
cp scripts/check_readiness.py out/check_readiness_t22.py
sed -i 's/THRESHOLD = 23/THRESHOLD = 22/' out/check_readiness_t22.py
python3 out/check_readiness_t22.py --readiness fixtures/readiness_block_audit.json

当 THRESHOLD = 22 时，readiness_block_audit.json 仍因 audit_trace_coverage=0.7 < 1.0 而被阻止，尽管总和 22/25 通过。这表明 audit_trace_coverage 是独立的阻止不变量，而非总和的一部分。本练习展示的是阈值敏感度，而非建议降低自动准入门槛。

何时重新审视阈值

• 一个季度内没有任何就绪性被阈值阻止——对于团队当前成熟度而言阈值过低。
• 半手动事件比例连续三个冲刺上升——23/25 的阈值因 Verification 或 Process 中的系统性缺口而无法达到。
• 出现 stateful=true 的操作类别——要求 backup_verified 并将该类别的阈值提升至 24/25。
• 一个月内所有就绪性失败都集中在同一轴上——这是 SDD 模板的缺口；应修复模板而非移动阈值。
• 就绪性工件构建时间超过切换 SLA——重新审视哪些分数可以自动化，而非降低阈值。

风险：23/25 的阈值与任何总和下的 Security 零分不兼容——此类失败将独立于结果阻止合并。低于 23/25 意味着运营模式改变：这不再是自动准入，而是半手动或金丝雀模式。即使「低」档（21/25）也意味着每次 implement 步骤后停止并由操作员明确确认，而非代理自行执行修复的权利。