双 Agent 测试流程让覆盖率提升17个百分点

把补测试交给 AI，最难的不是让模型写出代码，而是让团队相信这些代码值得合并。作者在 Meta 的通知团队尝试了两个 LLM agent：一个写测试，一个独立审查，再由工程师决定是否合并，测试覆盖率从约 35% 提高了 17 个百分点。

这段经历值得读，因为它把 AI 编程工具的重点从「能生成什么」移到了「怎样验证才能交付」。不过，覆盖率上涨能证明补测有进展，还不能证明测试足够有效，更不能直接证明线上故障减少。

覆盖率提高了，但团队没有停止负责测试

作者所在的 Meta 通知团队约有 20 人，每天处理数亿条通知。系统规模很大，交付速度也快，测试覆盖率却停留在约 35%。

原因并不是大家认为测试不重要，而是总有更紧急的工作。尤其是给别人写的代码补测试，很容易在每轮迭代中被推迟。

他们把这部分工作交给两个 LLM agent 后，覆盖率提高了 17 个百分点。按起点计算，大约到了 52%。这里是「百分点」，不是相对增长 17%。

原文标题容易让人以为团队彻底不写测试了，实际描述的做法要克制得多：AI 承担生成和初步审查，工程师仍然掌握合并决定权。作者也没有说所有测试都改由 AI 编写。

改变的是补测试的分工，测试质量的责任仍由团队承担。

两个 agent 的价值，在于把审查放进流程

这套流程可以拆成三步：

1. 第一个 agent 编写测试，承担重复、耗时的生成工作。
2. 第二个独立 agent 审查测试，重点看边界情况、断言是否有效，以及看似合理却实际错误的内容。
3. 工程师做最终判断，决定哪些测试可以合并。

「断言是否有效」是其中很关键的一项。测试能够执行，不代表它能发现错误；有了断言，也不代表断言检查的是正确行为。

作者认为，单个 agent 不经审查就提交测试，很难获得团队信任。增加审查环节后，生成结果才达到了他们愿意采用的程度。

但原文只说第二个 agent 是独立的，没有交代两者是否使用不同模型、拿到什么上下文，也没有提供具体提示词、测试框架或运行流程。因此，可以借鉴的是职责拆分，不能把它当成一套已经写清实现细节的方案。

为什么作者把验证看得比生成更重要

作者后来还参与了银行实时风险平台的 AI 工具建设与审查。在那类系统里，错误数字可能直接构成事故，接受 AI 输出的门槛自然更高。

他由此提出一个判断：生成已经很便宜，验证才是工具真正需要交付的价值。团队是否采用 AI，不只取决于模型能做多少事，还取决于输出能否经过检查、达到可交付标准。

这里要区分两类材料：Meta 的覆盖率变化是作者报告的实践结果；银行场景主要用于说明风险不同、信任门槛不同，没有提供另一组量化实验。

这篇文章同时也是一本售价 $34 的指南的首章。后续内容据称涉及评估、影响范围、推广和生产监控，但当前原文没有展开，不能把这些目录当成已经展示过的落地证据。

我的判断

我赞同把验证流程放在工具设计的中心。对积压的补测任务，先生成、再审查、最后由人合并，是一个容易理解、也便于保留责任边界的起点。

但「两个 agent」本身不是质量保证。审查者可能重复生成者的误解；如果需求和预期行为没有说清，两者也可能对同一个错误达成一致。作者没有给出证据，证明独立审查能消除这些问题。

覆盖率同样只能回答部分问题。它反映代码被测试执行到的程度，不能单独说明测试能否拦住真实缺陷。原文没有给出耗时、成本、人工修改量、错误测试比例，也没有与「单 agent 加人工审查」做对照。

这是一条有实践结果支撑的流程经验，还不是双 agent 优于其他方案的充分证明。

能拿来做什么

• 给前端组件或 Node 模块补测试时，可以先选一小批长期积压的任务，试行「生成、独立审查、人工合并」，观察团队是否真的愿意接受产出。
• 给审查 agent 明确职责，要求它检查边界情况、断言是否验证预期行为，以及测试是否包含缺乏依据的假设，避免只做代码风格点评。
• 评估效果时，同时记录覆盖率变化、人工审查时间和需要修改的内容，再决定是否扩大使用范围，别只凭新增测试数量判断收益。