十二、标定与验收
12.1 异因指纹粒度标定
先标定指纹粒度、缓扩 Worker。指纹错一档，决定的是钱烧在 L1 死循环还是 L3 人工，比 max_workers 更贵的参数。
1. 10 个典型任务复用 prompt 回归测试集（一份资产两用）。
2. 每个任务注入 3 类故障：同因重复、异因漂移、跨模块关联。
3. 跑指纹聚类，记录分类准确率。
4. 调归一化正则，直到 30 个样本分类准确率 ≥ 90%。
健康线：
指标	健康阈值	异常含义
L3 占比	≤ 20%	超过 → 粒度过细
卡死 L1（同因误聚 ≥2 轮才挣脱）	0 次	出现 → 粒度过粗
直冲 L3 占比	≤ 10%	超过 → 指纹粒度过细或逃生舱落点不当
每次标定记录四指标：L1/L2/L3 分布；重写额度消耗（自动/人工批准）；每任务 token 成本；误判人工裁定次数（裁定频繁说明规则还在替人做决定）。
指标归因规则：健康线指标是诊断信号，不直接绑定单一根因。L3 占比升高需按多因素顺序排查——任务选择是否不适配 → worker 能力是否不足 → 契约质量 → 环境稳定性 → 预算是否过低 → 最后才是指纹粒度。禁止"指标异常即调指纹"的单因归因。

12.2 运行期度量指标（上线后盯这些数字）
指标	健康线	恶化动作
首轮通过率	≥ 60%	低于 → 检查 Brief 质量 / 指纹粒度
平均修复轮次	≤ 1.5 轮	超过 → 检查 L1 是否误聚同因
升级人工率	≤ 15%	超过 → 检查粒度过细或任务不适配
重写后回归率	≤ 5%	超过 → 检查灰/白分类质量
L3 占比	≤ 20%	超过 → 指纹粒度过细
卡死 L1 次数	0	出现 → 指纹粒度过粗
ROI 实测	≥ 设定阈值（起步 3）	低于 → 该类任务移回单 agent，校准 Phase -1 预估
契约违规次数	趋近 0	频发 → 契约文档不清晰或白测试生成有误

12.3 Code 层验证方法
Stress test：故意给超大任务，看系统是否崩溃或烧爆 token——会，就是 hard limit 没做对。

十三、待验证的开放问题
1. ROI 起步阈值 3~5 是否适配当前业务成本？
2. "首次指纹漂移即判 L2 + 逃生舱两级用尽升 L3"的新阶梯能否有效拦截打地鼠模式？（触发条件已从"异因 2 次"改为"首次漂移"；基线已限定为"最近一次计入阶梯的失败指纹"）
3. Monitor"传统代码监控 + 异常唤醒 Agent"方案是否跑通？
4. max_workers=3 下的领导综合质量是否达标？
5. Contract as Code（类型层+行为层）是否完全阻断契约漂移？
6. 特征测试"自指验证 + 已知 Bug 清单"能否安全支撑受控重写？
7. 已知 Bug 清单完整性：生成期对账（白轨在旧实现上的失败 → 补录清单）是清单的系统性来源，但其覆盖率与人工补录的橡皮图章风险（补录人 = 重写受益人）待验证；补录已限定由独立 Reviewer 执行，第二人复核的必要性待实测确认。
8. 异因指纹聚类粒度标定：过粗卡 L1，过细直冲 L3。

十四、修订记录
版本	变更	来源
v2.0→v2.1	Phase -1、ROI 公式、Code 层硬边界、Reviewer Bash 白名单、依赖链 blocked、契约统一维护、反作弊条款、场景分层、模型路由起步统一、文件所有权、时间盒弹性化、Worker 扩至 6 类、Observability、Human Checkpoint	一轮评审
v2.1→v2.2	失败类型分类（v2.4.2 起精简为三类：环境类 / brief 覆盖性缺口 / 依赖未就绪；原"五分类"已废弃，不再作为实现依据）、verdict/worker/日志 schema、上下文预算分配、度量指标、端到端 JWT 示例、Contract as Code、状态持久化、预算池隔离	二轮评审
v2.2→v2.3	五级阶梯雏形、重写权限、逃生舱、受控双跑、高腐化区回流、预算结转	三轮评审
v2.3→v2.4	双轨测试四细则、异因优先判 L2、借调上限、腐化区 schema、子集容忍补充、标定验收线	落地实现 + 三轮评审增量
v2.4→v2.4.1	七处修复（白测试后门分离、重写次数 1+1=2、L2 触发统一为首次漂移、prompt 数字对齐、清单改引用 ID、交叉引用、三前提门+放行闭环）；恢复 verdict schema、运行期指标表（补 ROI/契约违规两行）、日志 schema、上下文预算分配表；恢复失败类型精简版（环境不计轮、覆盖性 diff）；生成期三支裁定、白轨对账措辞、旁路回 L3 选项；悬空引用清理、开放问题 2/7 改写、Checkpoint ③ 补契约变更；新增附录 A、附录 B	四轮评审 + 合并期补漏
v2.4.1→v2.4.2	五轮复核收口，全部为口径澄清，未新增机制：① 判定顺序"先过滤后定级"；② 比较基线口径（上轮 = 最近一次计入阶梯的指纹；不计阶梯失败不更新基线；首次计入仅登记不判级）；③ brief_rewrite 计数口径（覆盖性缺口补 brief 不计入）；④ 重写期措辞改为"重写 agent 禁止自行改契约，确需变更走 Checkpoint ③"；⑤ L3 出口与顾问模式措辞统一，落点决定权写明；⑥ 生成期裁定 1 补重生成上限 3 次；⑦ 裁定 3 补执行者（独立 Reviewer）；⑧ 附录 B ROI 2.7→3.4；⑨ 附录 B 批 2 并行改拆批（max_workers=3）；⑩ Checkpoint ③ 显式列"L1 额度用尽申请第 2 次重写"；⑪ 清单名等价说明	五轮复核
v2.4.2→v2.4.3	Sol 复核（87 条）中的"硬伤组"共 22 项，仍全部为消歧/补定义，未新增子系统：① 空报告规则改为"未执行检查才判无效"（原规则会把正常全绿误判为无效）；② issue 结构化（id/acceptance_id/severity/evidence_uri），严重度例外不走子集容忍；③ 放行条件补双向覆盖约束（防"授权了却没修"漏网）；④ 列表排序改为契约逐字段声明；⑤ 契约生命周期时序表 + 契约 owner（领导无写权限）；⑥ Phase 6 拆类型层/行为层；⑦ 补 brief 与重写 brief 的 Code 层判据（防伪装绕开计数）；⑧ 状态迁移表 + "不许跳级"精确定义；⑨ 环境重试补指数退避与白名单；⑩ 非文件级冲突（资源/契约/数据/环境）；⑪ worker 类型注册表（code-reviewer/debugger 为别名与变体）；⑫ Phase 1 四档结论 + 原仓库不可复现豁免；⑬ 字段名统一（max_ladder_level / not_found / search_trace）；⑭ 修订记录标注"五分类"废弃；⑮ prompt 去数字；⑯ reviewer 只读兜底 + builder 生成物写入；⑰ 起步期安全/验收例外；⑱ test-runner 单独计费；⑲ 时间盒基数；⑳ M5 并行依据；㉑ 五样 vs 四件套映射；㉒ 指标多因素归因	Sol 复核

附录 A：六类 Worker 返回 Schema

repo-scout
{
  "status": "done | need_clarification",
  "conclusion": "direct_use | adapt_reference | exists_but_incompatible | not_found",
  "verification_failure": {"reason": "string", "evidence": "string"} | null,
  "candidates": [{
    "url": "string", "license": "string", "last_commit": "date",
    "verification": "原仓库测试+我方冒烟通过 | null",
    "adapt_note": "改动幅度参考信号，非门槛"
  }],
  "search_trace": ["query/source"],
  "license_conflicts": []
}
字段名以本 schema 为准：conclusion = not_found 时 search_trace 必填完整；conclusion = exists_but_incompatible 时 verification_failure 必填。禁止使用 notfound / searchtrace 等无下划线写法（此前版本的笔误已废弃），Code 层校验按本 schema 执行。

builder
{
  "status": "done | blocked | need_clarification",
  "files_changed": [{"path": "string", "summary": "one line"}],
  "tests": {"passed": 0, "failed": 0},
  "contract_refs": ["contract#section"],
  "reuse_notes": [{"source": "url+license", "where": "path"}],
  "blockers": []
}

reviewer：即 5.1 verdict schema，不重复定义。

test-runner
{
  "status": "done | timeout_killed",
  "summary": {"total": 0, "passed": 0, "failed": 0, "skipped": 0},
  "failures": [{"name": "string", "error_head": "首3行"}],
  "log_path": "详细日志落盘路径，不进主上下文"
}

data-worker
{
  "status": "done | blocked",
  "rows_processed": 0, "rows_rejected": 0,
  "checks": [{"name": "string", "pass": true, "detail": "string"}],
  "anomalies_path": "string"
}

deployer
{
  "status": "deployed | rolled_back | failed",
  "environment": "string",
  "health_checks": [{"name": "string", "pass": true}],
  "rollback_point": "string | null"
}

附录 B：端到端示例（JWT 迁移）
任务：用户认证从 session 迁移到 JWT，涉及 80+ 文件。

Phase -1：单 agent 试跑 3 次均偏（80 文件上下文超限）✓；输出可验证（187 存量测试）✓；ROI ≈ 3.4 ≥ 起步阈值 3 ✓。

Phase 0：交付物 = 迁移代码 + 迁移指南 + 回滚方案。验收（每条带 ID）：A1 存量 187 测试全过；A2 新增 12 测试全过；A3 access token TTL ≤15min；A4 refresh 轮换生效；A5 恶意样本拒绝率 100%；A6 认证中间件 P99 增幅 ≤5ms。边界 = 不迁移 OAuth、不改权限模型。预算 = 5M token、3 天。冒烟 5 条：登录→带 token 访问→refresh→登出→过期拒绝。

Phase 1（基础设施类，时间盒 28%；基数 = 本任务 Phase 1 的 token 配额 5M × 28% = 1.4M token，由 Code 层计时，到时未出结论默认判"确认没有"）：jose 库 → 直接可用（MIT、活跃）；迁移教程 → 参考改写（通过原仓库测试+我方冒烟，原仓库测试仅作证据之一）；双 token 并存中间件 → 确认没有（附 search_trace）。

Phase 2（→ Checkpoint ①）：M1 token-service → M2 中间件（双 token 并存）→ M3a-d 路由迁移（80 文件按目录切 4 批）；M4 前端 token 存储；M5 e2e 补齐。
文件所有权表：M1=src/auth/token-service/；M2=src/middleware/auth.ts；M3a-d=src/routes/{admin,user,order,billing}/；M4=web/src/auth/；M5=tests/e2e/（应用代码只读）。
契约（类型层示例）：
# auth-contract.yaml —— 领导维护，worker 只读
jwt_payload: {sub: string, role: enum[admin,member,viewer], exp: int, jti: string}
access_token: {ttl_seconds: 900, header: "Authorization: Bearer <token>"}
refresh_token: {rotation: true}
error_response: {code: enum[AUTH_EXPIRED, AUTH_INVALID, AUTH_REVOKED]}
行为层（CI 测试）：轮换断言、TTL 上限断言。
反作弊条款第 4 条（随本示例归档）：A4 refresh 轮换生效 → 断言：轮换前后 refresh token 值不相等 ∧ 旧值使用返回 AUTH_REVOKED。

Phase 4：批 1：M1 ∥ M4；批 2：M2 → M3a ∥ M3b ∥ M3c（受 max_workers=3 约束，M3d 顺延至下一批）；批 3：M3d ∥ M5。
M5 可并行的依据：M5 拆为"用例编写"（不依赖迁移实现，可基于契约先行）与"最终全量重跑"（依赖 M1-M4 全部完成）。批 3 的 M5 仅指用例编写部分；最终重跑固定在 Phase 6、所有迁移模块通过后执行，用例版本需与冻结契约版本一致。

Phase 5 实录（v2.4.2 规则重演）：
• Round 1：M3b 失败（A4 轮换断言红，指纹 rotate_assert_fail）。按判定顺序先过滤：覆盖性 diff 发现 A4 未在 brief 验收 ID 清单中 → 判 brief 覆盖性缺口 → 回 Phase 3 补 brief（补轮换条款 + 反作弊断言）。该次失败不计阶梯轮次、不计入 brief_rewrite_auto；指纹照常登记，但不更新比较基线。
• Round 2：通过。
• 对照演示阶梯路径（假设 Round 2 未通过）：Round 2 是首次计入阶梯的失败 → 仅登记指纹，不判级；Round 3 失败且指纹漂移（如 middleware_order）→ 判 L2，默认落妥协模式；持续失败 → 升顾问模式 → 再升 L3 人工决策（受控重写 / 顾问 / 旁路 / 放弃）。

Phase 6：冒烟 5 条全过 → 全量 199 测试 → 契约对齐（类型层编译器 + 行为层 CI 测试）→ 按 ID 对照 A1-A6 → 交付四件套（代码 / 指南 / 回滚方案 / 日志包）。
清单区分：Phase 0 的"产出五样"（交付物、验收标准、边界、预算、冒烟场景）是需求阶段产物；本例的"交付四件套"是客户交付物。二者不同层级，冒烟场景与验收标准已作为交付物附件（指南、日志包）的组成部分随行，不单独列为第五件。

参考来源
• Anthropic《How we built our multi-agent research system》(2025.6)
• Claude Code Subagents 官方规范 (2025.7)
• wshobson/ai-agents 与 VoltAgent 社区实践
• AgentPatterns.ai (2026) Orchestrator-Worker 模式总结
• Michael Feathers, Working Effectively with Legacy Code（特征测试模式）
• 第一~五轮评审与落地实现反馈（已整合）
• Sol 复核（逻辑漏洞 24 / 不可执行 21 / 缺失项 20 / 冲突 18 / 框架级 4）——硬伤组 22 项已并入 v2.4.3，其余见配套《Sol 复核处置分诊表》

定稿说明：v2.4.3 仍未新增任何子系统，本轮全部变更为消歧、字段统一与逻辑补洞。剩余两类决策（B 组新增子系统 28 项、C 组框架级 4 项）见《Sol 复核处置分诊表》。下一步建议执行 12.1 标定（10 任务 × 3 类故障），由实测数据决定第六轮的取舍，而非继续纸面评审。