前言：当测试用例生成遇上“自说自话”的困境
如果你在过去一年里尝试过用大模型生成测试用例，大概率经历过这样的场景：让 LLM 给一个支付接口生成测试用例，它洋洋洒洒输出了 20 条，格式漂亮、描述完整——但你一条条跑下来，发现有 5 条参数类型不匹配直接报错，3 条重复覆盖同一个分支，还有 2 条连断言都没有。你花在“挑拣可用用例”上的时间，几乎快赶上自己从头写的功夫了。
这并非个别现象。根据中国信通院 2025 年 Q4 发布的 AI Safety Benchmark 测试结果，约80% 的大模型引用幻觉率大于 10%，20% 的模型引用幻觉率甚至超过 25%。换个角度说，让一个大模型“单打独斗”地生成测试用例，它输出的内容中至少有十分之一是“看起来对、实际错”的——而这些错误在测试场景中可能是致命的：一条无效断言意味着一个本该被捕获的缺陷从眼皮底下溜走。
学术界和工业界几乎同时意识到一个核心逻辑：解决 LLM 生成质量问题，不能靠“换一个更强的模型”来治本，而应该用“一个生成、一个审查”的多 Agent 协同架构来治根。生成 Agent 负责创造，Review Agent 负责纠错——就像软件开发中没有人会信任未经 Code Review 直接合入主干的代码一样，为什么测试用例就可以跳过这道关？
这篇文章将围绕这个核心逻辑，从学术前沿、框架选型、架构设计、安全风险、竞品对比等维度，完整拆解基于多 Agent 协同的测试用例生成与 Review 体系如何构建。
潮流)
