AI 生成的代码，用 AI Agent 来做代码审查，到底值不值得？
正如我之前写过的，我一直在尝试搭建一个模拟完整软件开发生命周期（SDLC）的 AI Agent 工作流。过程中遇到不少问题，所以还在反复迭代。不过，需要调整的地方越来越少，改动的幅度也越来越小了。我觉得把它第一次端到端跑完的主要结果拿出来聊聊，应该挺有意思。
目前还处在开发阶段，所以我盯得比较紧。我注意到一件事：很多拉取请求（PR）都被 Code Reviewer Agent 直接通过了，几乎没什么评论。但另一方面，我也发现端到端 QA Agent 有时会标记出问题，然后创建后续工单来修复。
简单说一下这个工作流的设置：当 Engineer Agent 完成了某个工单需求的编码后，它会提交一个 PR。在合并之前，会有另外两个 Agent 对其进行验证。一个是 Code Review Agent，它会把 diff 与工单的验收标准以及技术设计文档进行比对。另一个是 QA Agent，它会端到端地验证改动的行为。在每个完整阶段结束时，还有一个全量的端到端 QA Agent，负责执行在执行开始前就编写好的测试计划。这模仿了一个高质量的 SDLC 周期，流程如下：
- 先将需求写清楚
- 编写测试计划，明确验证需求是否满足所需的步骤
- 编写代码，实现改动，使系统逐步达到目标状态
- 对代码进行质量检查
- 验证代码行为（即单元或组件级别测试）
- 执行预编写的测试计划（即集成测试）
于是，我让 Claude Code 去调查并拉取数据。它返回了以下内容（AI 生成）：
Claude 的调查结果
以下是一个完整项目运行（49 个工单，四个阶段）中决策日志的实际展示。
数字
到底抓到了哪些问题
来自三种检查（Code Review、单元/组件 QA、端到端 QA）的每一次拒绝都是有实质内容的，没有一条是风格上的吹毛求疵。但真正有意思的是，被抓住的问题类型呈现出了某种规律。
AI 生成的代码，用 Agent 做代码审查到底值不值？
代码审查员的三次拦截都发生在早期，而且全是同一类遗漏：任务声称完成了，实际上根本没完成。比如：某个注册记录标记为已完成，但从来没真正创建过；某个验收条件被悄悄删掉，因为平台不支持；某个部署流水线一次都没真正跑过。第一阶段之后，审查员就全部批准了——剩余三个阶段零拦截。值得注意的是，这些批准并非敷衍了事。从审查结论来看，审查员经常重复运行命令、独立验证各项声明。只是它再也找不到问题了。
按工单进行的 QA Agent 只抓住了一个问题，而这是整个运行中最有启发性的数据点：代码审查员批准了一个工单；两分钟后，QA Agent 否决了同一个工单——因为它针对真实外部服务执行了代码，发现根本跑不通。所有模拟测试都是绿色的。两者的区别不在于多了一双眼睛，而在于：一个 Agent 读了代码，另一个 Agent 跑了代码。
按阶段进行的端到端检查是明显的赢家：失败率 23%，抓到的正好是按工单检查在结构上无法发现的那类问题。它的失败案例包括：“本阶段的每个工单都单独通过了，但它们无法整合到阶段目标中”以及“新解析器通过了测试，但在真实生产数据上失败了。”
收获
我觉得有趣的是，这次运行跟现实中的软件开发生命周期（SDLC）如出一辙。多少次，我写完了代码，觉得它看起来是对的，100% 确定没问题，然后一执行就发现了之前没考虑到或理解错的地方。有意思的是，同样的事情竟然也发生在 Agent 身上。
因此，我把代码审查员和 QA Agent 合并成了一个，确保 Agent 不只是读代码，还要执行代码。能不能把这段提示词也加进 Engineer Agent 里，从而彻底省掉 QA Agent？这或许是未来值得测试的方向。目前来说，我还是觉得单独启动一个 Agent 更稳妥。
代理代码审查对AI生成的代码值得吗？
集成测试是AI真正能大显身手的领域。作为软件工程师，我们都知道集成测试的重要性，但它也是最昂贵的一种测试。它通常需要手动操作，要求系统处于某种特定状态，并且往往要跟多个依赖系统交互。要把这些环境搭建好，不仅步骤多，而且非常耗时。在这个环节，AI确实能帮上大忙，提升整体质量。
有一点值得提醒：这些数据只能体现检查发现了什么问题，而不能说明它们漏掉了什么。高批准率可能说明工程代理（Engineer agent）工作做得好，也可能是检查本身跟它有同样的盲区——仅仅靠决策日志是分辨不出来的。另外，这只是一个项目的一次运行结果，所以我会持续跟踪后续更多运行的数据来观察。
那么，代理代码审查到底值不值得？如果只针对AI生成的代码本身，意义不大。但如果是为了执行代码、检查各个模块能否集成在一起，那绝对值得。