质量门控与证据验证模式

质量门控与证据验证模式

学习目标

读完本章后，你将能够：

• 设计证据驱动的质量门控（非主观评估）
• 应用”默认拒绝”策略防止虚假审批
• 实现重试升级机制（软阈值 → 硬阈值 → 升级）
• 在自己的多 Agent 系统中集成质量验证

前置知识

• 多 Agent 路由与隔离基础
• Agent 核心循环设计

---

核心概念

为什么多 Agent 系统需要质量门控？

在多 Agent 协作中，单个 Agent 的自我评估往往过于乐观。研究表明，没有外部验证的 Agent 评估会出现”幻想审批”（Fantasy Approvals）—— Agent 将基础实现评为 A+，而实际上存在明显缺陷。

质量门控的核心原则：

“默认拒绝”策略（Default-to-Deny）

质量验证 Agent 应该默认拒绝，只有在看到压倒性证据时才批准：

传统模式	默认拒绝模式
默认通过，除非发现明显问题	默认拒绝，除非证据充分证明通过
评分倾向虚高（90+ 分）	评分保守（C+/B- 为正常首次实现）
“看起来不错”即可通过	需要截图、测试报告、数据证据

为什么有效：默认拒绝策略打破了”宽松审批”的正反馈循环，确保只有通过严格验证的产出才能进入下一阶段。

质量门控的三层架构

第一层：任务级 QA（Dev-QA 循环）

每次实现后，QA Agent 对单个任务进行验证：

## 任务级 QA 流程
1. 生成自动化测试证据（截图、测试报告）
2. 交叉验证自动化结果与预期
3. 输出 PASS/FAIL + 具体反馈
4. IF FAIL: 返回 Developer 修改
5. IF PASS: 进入下一个任务

第二层：集成级 QA（Reality Check）

所有任务通过后，Reality Checker 进行全局验证：

• 验证整个系统的端到端流程
• 交叉引用所有 QA 发现
• 默认 “NEEDS WORK”，除非证据充分
• 产出认证报告（含证据链接）

第三层：阶段级 Gate（Phase Gate）

一个阶段的所有工作完成后，阶段门控决定是否进入下一阶段：

Gate	验证内容	门槛
Phase 0 → 1	市场机会 + 用户需求	TAM > 门槛, ≥3 个验证痛点
Phase 1 → 2	架构 + 设计 + 预算	架构评审通过, 预算合理
Phase 2 → 3	脚手架 + 基础设施	基础设施可运行
Phase 3 → 4	所有任务 Dev-QA 通过	100% 任务 PASS
Phase 4 → 5	Reality Check 通过	无 blocking 问题
Phase 5 → 6	发布验证	部署成功, 监控正常

---

重试升级机制

三级重试模型

为什么限制 3 次？

• 第 1 次失败：通常是理解偏差或粗心错误，返回原始 Developer 修改即可
• 第 2 次失败：可能是能力或设计问题，需要更高级别的 Developer 介入
• 第 3 次仍失败：超出 Agent 能力范围，需要人工判断是需求问题还是技术问题

证据要求矩阵

不同质量等级的证据要求：

验证项	最低证据	理想证据
UI 正确性	截图	多设备截图 + 像素对比
功能正确性	测试通过	测试 + 边界条件测试
性能指标	基准测试	基准 + 负载测试 + profiling
安全性	无已知漏洞	SAST + DAST 扫描报告

---

问题与规避

幻想审批（Fantasy Approvals）

问题：QA Agent 在没有充分证据的情况下给出高评分。

对策：

• 强制 QA Agent 默认 “NEEDS WORK” 或 “C+” 评分
• 要求每个正面评价附带证据链接
• Reality Checker 作为最后一道防线

QA 验证的自动化程度

问题：完全手动 QA 速度慢，完全自动化 QA 可能遗漏用户体验问题。

对策：

• 使用自动化工具（如 Playwright）捕获截图和数据
• QA Agent 基于自动化证据做判断
• Reality Checker 补充人工视角的全局评估

重试循环中的上下文丢失

问题：Developer 重新实现时，可能忘记 QA 的具体反馈。

对策：

• QA 输出格式化的反馈报告，包含：
  • 失败原因（具体到代码行或组件）
  • 建议修复方向
  • 相关证据截图
• 每次重试时，将 QA 反馈作为 Developer 的系统提示注入

---

设计取舍

主观评估 vs 证据驱动

方案	优势	代价
主观评估	快速、灵活、覆盖广	容易过度乐观、不一致
证据驱动	可重复、客观、可审计	需要自动化工具支持、速度较慢

推荐：对关键质量属性（功能正确性、安全性）使用证据驱动；对体验属性（美观度、可用性）使用主观评估 + 清单核对。

单次验证 vs 持续验证

方案	优势	代价
单次验证	简单、快速	只能反映某个时间点的状态
持续验证	实时发现问题、回归防护	需要持续集成基础设施

推荐：在 Dev-QA 循环中使用单次验证（快速迭代），在 Phase Gate 中使用持续验证（确保阶段整体质量）。

---

参考来源

• Phase-Gate Process, PMI PMBOK Guide
• Evidence-Based Software Engineering