模式矩阵 /模式白皮书/F4

文档状态：本页为公开评审稿。模式定义与分类可供讨论和引用；未附来源链接的数字与应用示例只用于说明机制，不作为行业基准。

问题

测试失败、lint 报错、build 挂掉、CI 红了——这些 deterministic 失败信号是 agent 最 valuable 的反馈，因为它们对错明确、不靠主观判断。但每次失败都让工程师手动排查、手动修，重复劳动量大，而且很多失败的修法是模式化的（依赖缺失、配置错位、明显的逻辑错），人来修是浪费。

Self-Heal Loop 让 agent 自动消化这些信号闭环修复：失败信号触发 → 诊断根因 → 生成修复 → 应用 → 重新验证，没修好就再来一轮。它是反思模式里最贴近"agent 自主"的形态，也是反思模块唯一一个 mandatory loop——失败一次没修好必须再来，不存在"single-pass self-heal"这种合法形态。Aider 把它做成命令行 flag，Spotify Honk 把它做到 production scale（每月 650+ merged AI PR），GitHub Copilot Rubber Duck 把它做成 cross-model dual-review。

分类依据：反思 × 循环

• 纵轴 · 反思：agent 自己检测错误并修复，自我修复是反思机制最实用的应用，软件领域尤其常见。它不是改进一个本来可用的输出，而是从一个已经坏掉的状态恢复——agent 把失败信号读懂、诊断、改正，整个过程是对自己产出的审视和纠错。
• 横轴 · 循环：结构是检测失败 → 诊断 → 修复 → 再测试的强制循环。这个 loop 是结构性的、mandatory 的，跟 Generator-Critic 那种 optional replay 不同——起点是"输出已坏"，loop 是恢复手段，没修好就必须再迭代一轮，终止条件是测试通过、max_iterations 触底、或检测到 regression 触发 rollback。

解决方案与机制

一个 production-grade Self-Heal Loop 由六段流水线加三重停止机制构成。流水线：Test Fail → Diagnose → Generate Fix → Critic → Atomic Apply → Verify，验证失败时 git revert 回到 Diagnose 重做。

三重停止机制是把 Generator-Critic 升级成 Self-Heal 的关键，缺一就有"把 main branch 改坏"的风险：

1. max_iterations 硬熔断：loop 最多几轮（Aider 用 3）。防止 agent 无限打地鼠。
2. dual-model critic verifier：用一个不同 model family 的 reviewer 审修复方案。同 family 的 LLM 有共同盲区，cross-family review 引入独立训练历史的视角打破 self-bias。GitHub Copilot Rubber Duck 在 3 个风险节点（plan 后、实现后、写测试但运行前）强制 cross-model 验证。
3. stability check via signature：用 failure signature 比对，分辨"修了同一个问题"（hash 重复）还是"换了新问题"，并做 regression detection（severity 升级或 affected files 翻倍即回归，全部 rollback）。

Spotify Honk 的 format/lint/build/test 四级 cascade 值得照搬——便宜信号先跑挡掉明显问题，贵信号留给真正的语义级问题。

适用条件

• 代码 / 测试 / CI 这类对错明确的领域：CI 失败自动修、lint 自动修、测试失败自动诊断修复，这是 Self-Heal 的主战场，因为有 deterministic ground truth。
• Coding agent 标配能力：Aider、Spotify Honk、GitHub Copilot 都把它当默认 feature，是 coding agent 的基础设施。
• 有清晰分层 ground truth 信号的工程流水线：format/lint/build/test 分层清楚的 CI 才适合上 self-heal，信号越分明、修复越可靠。

已知失效方式

• 没有 deterministic 失败信号还硬用：写作、设计这种主观判断没有客观对错信号，走 Generator-Critic（F1）而非 Self-Heal。修复代价大于失败代价的任务（生产数据库改 schema）走治理模块的 Approval Gate 加人审。
• 打地鼠：没有 stability check，agent 修一个错引入新错，几轮后代码一团糟。防法是 failure signature 比对加 regression detection 加 max_iterations 三层一起上。
• 回归级联：每轮 fix 不是 atomic commit，一连串 cascade 后 rollback 还原不到正确状态。防法是 per-iteration atomic commit 加 "modify only files in diagnosis" 严格约束。
• 虚假恢复：agent 改的是 test 而不是 code，把测试改弱让它过——指标全绿、问题全在。防法是 critic 显式审"改的是 production code 还是 test"加 test coverage 不许下降。
• 触底不转人工："修不好就崩溃"是不可接受的工程做法。HITL handoff 必须是一等公民，触底转人审，且队列要有人每天清。

验证指标

• 自愈成功率（健康区 60-80%）：自动修复成功的比例，剩余转人工。Spotify Honk 配三重停止后约 70%。低于 50% 说明 ground truth 信号不清或诊断能力不足。
• 平均修复轮数（健康区 ≤3 轮）：超过 3 轮还不收敛，dev tool 场景应转人工，production scale 才支撑得起更多轮。
• regression 率（健康区 <10%）：修复引入新失败的比例。高说明 stability check 或 atomic commit 缺失。
• HITL 队列清空时延（健康区 当天清零）：触底转人工后多久有人处理。队列堆积说明组织侧 ops 路径没打通。

参考实现

for i in range(MAX_ITERATIONS):           # MAX=3, Aider 同源
    diagnosis = diagnose(current_failure)
    fix = generate_fix(diagnosis)         # 只改 diagnosis 里的文件
    critique = cross_family_critic(fix)   # 不同 vendor, 打破 self-bias
    if critique.block:
        return "blocked_by_critic"        # 转 HITL
    commit = atomic_apply(fix)            # per-iteration atomic commit
    new_failure = verify()                # format/lint/build/test 四级 cascade
    if new_failure is None:
        return "fixed"
    if is_regression(current_failure, new_failure):   # severity 升 / files 翻倍
        rollback(all applied commits)
        return "rolled_back_regression"
    current_failure = new_failure
return "max_iterations_human_handoff"     # 触底转人审

四个工程要点：dual-model critic 用 cross-family 不用同 family 不同 size；regression detection 规则按业务定（可加性能、安全、覆盖率回归）；atomic commit 必须真 atomic，一次别改 5 个文件否则 rollback 不回去；触底必须真有人看 HITL 队列。

应用示例

一家 DevTool 公司做 CI/CD 自动修复 Agent。第一版很激进——任何失败都自动修，最多 10 次 iteration，没有 critic、没有 rollback、没有 stability check。第二周 incident：测试失败 → agent 改代码 → 又失败但是不同错误 → 又改 → 改 9 次后把无关代码都改了一遍，main branch 一团糟，rollback 还原不到正确状态因为 9 次 commit 不是 atomic 的。复盘出三个根因：没有 stability check（在打地鼠）、没有 critic 验证（agent 自己说修了就 apply）、没有 git audit trail。第三版彻底重写，加三重停止机制——max iterations 硬熔断、dual-model critic（Sonnet 写、GPT-5.4 审，cross-family）、stability check via signature 比对。验证走 format/lint/build/test 四级 cascade，每轮 atomic commit 便于精确 rollback，触底转 HITL 人审 PR。修完 main branch incident 清零，自愈成功率 70%（剩 30% 转人工），代价是单次修复延迟从约 30 秒涨到约 90 秒——金融场景这点延迟换准确率值得。

相关模式

• Generator-Critic（F1）：兄弟模式，边界要钉清楚。Generator-Critic 是"生成后改进"——chain 是线性管道、replay 是 optional、起点是输出可用；Self-Heal Loop 是"失败后修复"——loop 是 mandatory 结构、起点是输出已坏。这点决定了它们的 stop condition、rollback、blast radius 全不同。前者用于主观任务，后者用于有 deterministic 失败信号的任务。
• Adversarial Review（协作模块）：cross-family critic 衔接。Rubber Duck 的 dual-model review 是这个思路的轻量版，Adversarial Review 把它推到极端（multi-agent debate）。
• Iterative Hypothesis（推理模块）：Loop 同源思路，都是"试—验—再试"的迭代结构。
• Guardrail Sandwich（行动模块）：sandbox 同源。Honk 把 agent 放隔离 container 加限权运行，把 blast radius 从"production 全开"压到"sandbox 内全开"。

设计结论

Self-Heal Loop 不是简单的自动修代码，而是定义 agent 自主性的边界——能 self-heal 的领域（有 deterministic ground truth）agent 可以独立干，不能的领域（blast radius 不可逆）必须人介入，这条线跟 DevOps 几十年"什么能自动化、什么必须人审"的判断完全同源。

企业证据

当前没有与本模式绑定的公开评审案例。模式定义不因此视为已经获得企业验证。

案例收录要求说明业务约束、实现结构、已知失败和迁移边界。参见 贡献与评审规则。