使用 ReviewBench 评估代码审查代理

代码审查代理正在兴起，LangChain 内部也构建了一个。评估这类代理是否有效是一个难题：现有的基准很少能反映内部审查标准，因此 LangChain 创建了 ReviewBench。该基准来源于 LangSmith 单体仓库中的真实 PR 反馈，由受信任审查者的评论筛选出具体问题，并转化为可复现的 Harbor 任务。

ReviewBench 的起点是真实审查历史，而不是人为编写的合成缺陷。原始评论噪声很大，包含许多琐碎问题和疑问，因此 LangChain 使用 LLM 门控过滤弱候选，再逐条人工审查，只保留能识别变更引入的真实问题、且足够具体可验证的评论。这使得基准衡量的是代理能否恢复实质缺陷，而非复刻审查者的每句话。

具体任务示例包括：一个数据库 SQL 查询按 ID 删除资源时未检查租户，代理需要识别项目级安全规则；另一个端点迁移丢失了原 API 的过滤器，代理需要对比两版实现发现行为回归。这些任务要求代理理解代码库隐含契约，而不能只扫描变更行。

ReviewBench 目前包含 59 个任务和 64 个基线问题，任务以 Harbor 格式编写。代理在任务开始时获得冻结的 PR 上下文，可通过本地 GitHub 存根查看元数据和 diff，还能检查完整种子仓库，最后提交结构化问题列表。隐藏的验证器使用 LLM 作为评判，比较提交结果与基线。覆盖率衡量是否找到同一代码路径中的同一潜在问题，精确率衡量提交发现中正确的比例，F1 是这两个指标的调和平均。

初步实验使用相同的 Deep Agents 基础框架运行模型，每个任务尝试三次，刻意不使用自定义审查提示。结果显示最强模型仅能恢复约 30% 的基线问题，代理通常会报告有效问题，但仍会漏掉许多真实审查者发现的具体问题。Luna 和 Terra 的表现低于预期，它们的审查策略似乎较窄，往往只关注少量发现就停止。

进一步的对照实验表明，提示策略影响显著。为 Luna 配置了高推理努力和结构化审查提示（要求先明确 PR 变更内容，追踪周围系统对该行为的依赖，并针对调用方、测试和相关实现验证发现）后，在 20 个任务的子集上其得分达到 0.32，高于使用静态审查提示的 Kimi 和 Opus 在同一任务上的得分。这说明改进审查流程本身可能比更换模型或添加工具更有效。

未来，LangChain 计划扩展 ReviewBench，增加更多任务以提高稳定性，并覆盖安全约束、API 兼容性以及需要变更行之外上下文的情况。最终目标是衡量代理能否在真实变更中发现实质问题，同时不增加不必要的噪音。