TL;DR： 追问协议的最后一道防线是独立确认——用一个没有确认偏差的视角，对整个假说系统做可证伪性检验找反例。本文还讲了追问协议的来路（从 18 个 bug 的实践到写文章时发现的漏洞），以及未来自反性的计划。

← 上一篇 中篇讲了追问协议的七个条件：T1-T3 三个地板条件保证 AI 走得够深，HC1-HC4 四个护栏防止追问过程失控。这篇讲最后一道防线和协议的来路。

独立确认：可证伪性检验

即使有七个条件兜底，AI 自己查自己还是有盲区。确认偏差不是 AI 才有的问题，但 AI 对自己的错误结论没有人类那种"不对劲"的直觉。

所以我们加了最后一道防线：独立确认。

在当前版本中，独立确认者是人类审查者。长期目标是让独立的 AI agent 担任这个角色，但这要求 agent 之间有足够的视角差异来避免共享同一套确认偏差——这是一个尚未解决的挑战。

独立确认的本质不是重新跑一遍 T2 检验，而是用没有确认偏差的视角，对整个假说系统做可证伪性检验。这个方向受到波普尔科学哲学的启发[1]。调查者自己查自己的假说，天然带有确认偏差，会主动找支持自己的证据，忽略矛盾的证据。独立确认者没有这个包袱。

独立确认只做一件事：找反例。

最终会有三种结果：

  1. 找不到反例，说明假说系统完整且正确，确认通过，进入修复阶段。
  2. 找到推翻性反例，说明假说系统有根本错误，反例变成新的证据，回到 5-Why 流程重新调查。
  3. 找到边界性反例，说明假说系统不完整，需要补充适用边界，完善之后再确认。

独立确认是追问协议的兜底机制，用一个外部视角检查前面七个条件没拦住的问题：

  • 对于单线追踪，反例可能揭示被遗漏的症状。
  • 对于确认偏差，反例可能暴露被选择性忽略的证据。
  • 对于浅尝辄止，反例可能证明当前结论在边界条件下站不住脚，说明追得还不够深。

三个问题性质不同：浅尝辄止是深度不够，单线追踪是广度不够，确认偏差是推理偏误。后两个因锚定而加剧。反例的作用就是证明浅层解释站不住脚——无论问题出在哪个维度。

这个方法不是凭空设计的。可证伪性检验的思路在软件调试领域已经被不少从业者显式采用——falsification 驱动的排障流程在 SRE 和安全运营中有实际应用。更直接的证据来自 AI 调试领域：最新的多 agent 调试系统（如 FVDebug、AgentForge、DoVer）都引入了独立的 critic 或 verifier agent，消融实验证明独立验证角色能显著提升诊断准确性[3][4][5]。

这里有两个设计决策值得解释。

第一，为什么只做一轮确认，不做循环。 这是一个工程性的权衡：一轮太少容易漏，两轮以上边际收益不抵成本。如果一轮确认加上反例作为新证据再加上继续 5-Why 还是得不出结论，说明问题已经超出了追问协议的处理能力，升级给用户是更合理的路径。

第二，为什么独立确认只找反例，不做全量检验。 找反例是发散思维，AI 在收敛方向走了很远，需要一个外部视角用力拉一下。全量检验是重复收敛的工作，没有必要。

从实践到协议的迭代

这篇文章不是先有理论再套实践的产物，它是我最近几个月踩坑的完整记录：

  1. 实践阶段：Aristotle 项目里最终统计了 18 个 bug，都是我靠人工追问驱动 AI 挖到根因的。
  2. 提炼阶段：把这些零散的实践经验整理成 tdd-pipeline 的 Phase 6 追问协议，版本是 v0.4.0。
  3. 反思阶段：写这篇文章的大纲时，我给协议做逻辑审查，发现两个设计漏洞：一是 T2 的 framing 没有明确要求预防性，二是独立确认的范围太窄，之前只是复查 T2。
  4. 升级阶段：补充了设计文档，协议从"T2 复查"升级为"可证伪性检验"，版本升级到 v0.4.1，目前还没上线。
  5. 待验证阶段：协议里的每个环节都是从 18 个 bug 攻坚中提炼出来的——比如我拿"ROUTE 段为什么能被遵循"这个反例推翻 AI 的"模型不配合"归因，就是找反例的实际运用。v0.4.1 把这些做法全部显式编码成了协议流程。下一步就是把 v0.4.1 跑起来。

追问协议的最终目标，是把人类追问的经验自动化，让 agent 能在没有人类干预的情况下，完成同等质量的根因调查。

但要诚实地说：这次"实践→反思→升级"的循环是由人驱动的。是我在写文章审查逻辑的时候发现了协议的漏洞，不是协议本身具有自我改进的能力。T1-T3 是单次调查的停止规则，独立确认是对单次假说的可证伪性检验，两者都不涉及对协议自身的反思。协议的自我改进目前还是依赖人的介入。

已知局限与后续计划

当前协议有两个已知局限。

第一，它不能区分"修复失败是因为协议没拦住错误"和"修复失败是因为 bug 超出了协议能力"。

第二，追问协议把人类专家判断终止条件的经验编码成了显式规则，让 AI 能正确使用 5-Why。但 5-Why 本身的适用范围有限——Card 指出它对多因子交互问题的覆盖率低[2]。追问协议让 AI 在 5-Why 能用的场景里用好它，但不能让 5-Why 覆盖它本来就覆盖不了的场景。

后续的计划是给协议加上自反性能力。Aristotle 的反思系统已经有现成的模式可以迁移：代码出错→反思错误→提炼预防规则→commit 到规则库。嫁接到追问协议上的流程是：修复失败→重新调查 bug→同时调查协议哪里没拦住→产出协议修正案→升级协议。

触发自反性流程的条件有三个：同一个 bug 修复失败 2 次以上，每次得到的根因都不一样；需要回滚到比协议建议更深的层面才能解决问题；独立确认通过了但修复仍然失败。协议修正案本身也要通过 T1-T3 的检验才能生效。

v0.4.1 升级的起因有些偶然：不是在实战中发现的漏洞，而是在写这篇文章时审查协议逻辑发现的。后续迭代的目标是把自反性机制内置到协议里，让这类升级可以自动化，目前正在做方案设计，需要整合 Aristotle 的能力。

参考文献

  1. Popper 1959, The Logic of Scientific Discovery, Hutchinson, https://www.routledge.com/The-Logic-of-Scientific-Discovery/Popper/p/book/9780415278430
  2. Card 2017, “The problem with ‘5 whys’”, BMJ Quality & Safety, vol. 26, no. 8, https://doi.org/10.1136/bmjqs-2016-005849
  3. Bai et al. 2025, “FVDebug: An LLM-Driven Debugging Assistant for Automated Root Cause Analysis of Formal Verification Failures”, arXiv:2510.15906, https://arxiv.org/abs/2510.15906
  4. Kumar et al. 2026, “AgentForge: Execution-Grounded Multi-Agent LLM Framework for Autonomous Software Engineering”, arXiv:2604.13120, https://arxiv.org/abs/2604.13120
  5. Ma et al. 2025, “DoVer: Intervention-Driven Auto Debugging for LLM Multi-Agent Systems”, arXiv:2512.06749, https://arxiv.org/abs/2512.06749

交叉引用