代码 Agent 别自审:PR 要进审查循环チャプター1×0:08开场0:53事件播报2:14技术拆解4:07工程意义5:19落地建议6:12收尾0:006:500:08主持过去二十四小时里,我没有看到足够扎实的一手 Agent Loop 工程动态;今天把窗口放到近一周。要讲的是七月七日提交的一篇论文,题目叫 S W E Review,它把一个很现实的问题摆上桌面:代码智能体会写 P R,但谁来判断这份 P R 真的修好了 issue?0:27主持这个问题听起来像自动代码审查,其实更尖锐。现在很多 coding agent 的流程是一次性生成补丁,然后看测试过不过,或者让模型自己解释一下为什么对。可真实仓库里,补丁可能只压住了报错,根因还在;也可能改了一个下游调用点,绕开了崩溃,却留下了错误结果。S W E Review 想补上的,就是生成之后那一段审查和返工循环。0:53主持按论文和项目页的说法,S W E Review 的输入包括三样东西:仓库、自然语言 issue,以及一个智能体已经生成的候选 P R。审查智能体不会只盯着 diff 看,它可以浏览文件、搜索代码、检查依赖关系,必要时执行命令。最后它输出两个结果:批准,或者要求修改;如果要求修改,还要给出结构化诊断,告诉下游修改智能体哪里错了、该往哪里修。1:23主持作者同时放出了基准和数据。项目页列出的 S W E Review Bench 包含一千三百八十四个候选 P R,来自五百个 S W E bench Verified issue,并按高、中、低三档候选质量组织。另一个数据集 S W E Review Traj 包含八千九百一十四条决策正确的 agentic review 轨迹,用来训练开源审查模型。1:48主持最直接的数字是这组:在低质量候选生成器上,生成、审查、再修改的循环,把解决率从百分之二十七点五推到百分之五十六点九;中档生成器从百分之五十点九升到百分之六十八点八;高档生成器也从百分之七十二点二升到百分之七十五点四。提升最大的不是强模型,而是本来最容易出错的那一档。2:14主持这里最值得听的点,是它没有把 review 写成一句「请再检查一遍」。S W E Review 的审查者先独立重建问题:读 issue,找根因,形成自己认为的修复方向,然后再看候选 P R。这能减少一种常见偏差:模型先看到补丁,就会被补丁带着走,默认它在正确方向上,只挑小毛病。2:37主持项目的克劳德 Code 插件也延续了这个设计。它把 review 放进一个独立子智能体里,让审查者在不知道 patchgen 过程的情况下先找根因,再拿自己的诊断去对照补丁。插件文档还强调一个判断:如果补丁只在使用点做防御,却没有在产生错误数据的地方修根因,就应该被拒绝。这句话对工程团队很实用,因为很多「看上去绿了」的自动修复,坏就坏在这里。3:08主持论文把评估拆成三个指标。完成率看审查报告能不能被解析;决策准确率看批准或要求修改是否正确;修改后解决率看审查意见喂回生成器以后,最终补丁是不是真的更容易通过可执行验证。第三个指标很关键,因为一个好 review 不是写得像人,而是能让下一轮修改变好。3:33主持从 Loop Engineering 的角度看,这里有三层闭环。第一层是生成器闭环,补丁被拒绝后带着诊断再修。第二层是审查者闭环,审查轨迹本身变成训练数据。第三层是测试时扩展闭环,系统不是盲目多采样十几个补丁,而是用审查决定什么时候继续、往哪里继续。项目页给出的结果是,review guided iterative revision 相比独立重采样,拿到三点七倍的测试时扩展收益,同时样本效率高六点七倍。4:07主持这件事对生产级 coding agent 的提醒很具体:不要让同一个智能体既当作者,又当裁判,还当合并按钮。人类团队不会让提交者自己批准自己的 P R,智能体系统也不该这么设计。至少要把生成、审查、修订、批准这几个角色分开,并保留每一步的证据。4:30主持第二个启发,是审查智能体需要仓库级行动能力。固定上下文审查只看 diff,最多再塞一点相关文件,遇到跨模块 bug 很容易漏。S W E Review 论文中的案例说明,审查者需要追调用链、看上游根因、识别「症状修复」。这意味着工具权限、搜索能力、执行环境和审计日志,不是周边配置,而是 review loop 的核心。4:58主持第三个启发,是指标要从「一次过没过」移到「这一轮循环有没有变好」。resolve rate 仍然重要,但它只能告诉你最终结果。审查决策、诊断是否可执行、修改后解决率、每轮消耗的样本数,才会告诉你这套循环是不是在学习,还是只是在烧 token、碰运气。5:19主持如果团队正在把代码智能体接进研发流程,我建议先从三个小动作开始。第一,所有智能体 P R 都走独立审查,不允许生成器自己给自己盖章。哪怕审查者还是模型,也要换上下文、换任务说明、先独立找根因。5:37主持第二,把 review 输出做成结构化对象,不要只留一段自然语言评论。至少要有决策、置信度、缺陷位置、严重程度、修改建议,以及审查时看过哪些证据。这样下一轮修改可以消费它,平台也能统计哪些缺陷反复出现。5:55主持第三,给循环设停止条件。比如最多几轮,每轮必须带来新证据或新修改;审查者连续批准才允许进入人工合并;如果两轮都在同一类缺陷上打转,就转给真人。闭环不是无限循环,闭环要有刹车。6:12主持今天这篇 S W E Review 值得放进 Agent Loop Engineering 里看,不是因为它又做了一个代码审查机器人,而是因为它把「会写补丁」和「能交付修复」之间缺的那一段补上了。对工程团队来说,下一步要问的不是智能体能不能开 P R,而是这条 P R 进入系统以后,有没有一个独立、可追踪、能促成返工的审查循环。没有这一层,自动写代码越快,坏补丁也会来得越快。