你有没有遇到过这种情况：让一个新来的程序员帮你改代码，他兴冲冲地改完了，告诉你"搞定了"，结果你一测试，发现他压根改错了地方。更麻烦的是，等你发现这个问题的时候，他已经在这个错误的基础上又往前走了十步，返工成本直接翻倍。
这正是现在的AI编程智能体正在经历的事。
这些智能体可以自己浏览代码仓库、编辑文件、运行测试，一路做下去不需要人类插手。听起来很美好，但问题是，它们经常会在长时间的工作里重复做同样的无用操作，或者在一个错误的方向上越走越远，甚至有时候会在任务根本没做完的情况下，自信地宣布"任务完成"。
这篇来自Salesforce AI Research的论文，就是在琢磨一件事：怎么给这些AI程序员配一个靠谱的"审稿人"，让它在关键时刻拦一下，但又不至于瞎指挥。
批评一个还没写完的程序，到底有多难
想象你是一个编辑，要给一本正在写的小说提修改意见。
如果书已经写完了，你可以通读全文，判断逻辑是否自洽，结局是否合理。但如果作者只写了三分之一，你要怎么判断某个情节走向是"犯了错误"还是"正常的中间过程"？也许作者正在为后面的反转埋线，你一句"这里写得不对"反而会打断他原本正确的构思。
AI编程智能体面对的审查困境正是这样。
它还在执行任务的过程中，证据不完整，你很难分清楚它当前的操作是一个合理的中间步骤，还是已经南辙北辙的错误。论文作者把这个问题拆成了三个具体的难题。
第一个难题是时机问题：审查应该什么时候介入？如果固定隔几步看一次，可能会眼看着智能体把一个错误命令重复执行好几遍才轮到下一次检查，反应太慢；但如果一有动静就插手，又会打断那些本来能自己走通的正常流程。
第二个难题是反馈的可靠性问题：批评者给出的意见本身靠谱吗？
论文里提到一个关键发现，叫做RuVerBench
RuVerBench：一项研究，发现用大语言模型来验证评分标准时，存在相当多的噪音，也就是说AI评委自己也经常判断失误。
就算是把评判标准写得清清楚楚，让AI按标准打分，它依然会犯错。一个看起来很有道理的诊断，完全可能是对局部证据的误读，结果把本来能成功的工作给带偏了。
第三个难题是执行跟踪问题：批评意见发出去之后，到底有没有被真正解决？智能体可能表面上听话地照做了，但问题的根源其实还在那里，没真正被修复。这就好比你让学生改作文里的病句，他确实在那句话上动了手，但改出来的新句子依然不通顺，只是换了一种错法。
这三个问题叠在一起，才是这篇论文真正要解决的核心矛盾。
Opera：把每一次批评变成一张持续追踪的便利贴
论文提出的解决方案叫Opera，核心思路可以用一个很朴素的比喻来理解。
想象你在带一个实习生做项目，你不会把每个问题都写成一次性的训话，说完就忘。你更可能会在便利贴上写下"这里的参数传错了，改成XX，改完之后看看单元测试是否通过"，然后把这张便利贴贴在实习生的桌子上，直到你确认这个问题真的解决了才把它撕掉。
如果没有这张便利贴会怎样？
你很可能提完意见就不管了，下次检查的时候完全不记得之前说过什么，实习生也可能已经把你的话忘了，或者敷衍地改了个表面的东西就当交差。没有持续追踪，批评就变成了一次性的噗嗤一声，响完就没了。
Opera的设计正是围绕这张"便利贴"展开的，论文里管它叫做
note：持久化的笔记，记录一个被诊断出来的问题、当前给出的指导建议，以及一个固定不变的解决标准，直到问题被确认解决或者被归档之前，这张笔记一直有效。
这个框架围绕三个核心机制展开，分别对应前面提到的三个难题。
什么时候该出手：双轨触发机制
Opera不是简单地每隔几步看一眼，也不是见风就是雨地频繁插手，而是把两种触发方式结合起来用。
一种是固定周期检查，每隔若干轮次看一次整体进展；另一种是事件触发检查，一旦智能体表现出五种可疑行为中的任何一种，立刻介入检查。这五种行为分别是：原地打转没有实质进展、重复执行同样的操作、动作或工具调用失败、宣布任务完成、提交最终的修改。
这五种信号哪个先出现，就先触发一次检查，而且事件触发之后，固定周期的计时器会重新计数，避免同时触发两次检查造成浪费。
有一点很重要，检查本身不等于一定要插手。
批评者看完一轮之后，完全可能判断"这个方向是对的，继续走"，什么都不说。这其实是在模拟一个成熟的审稿人应有的分寸感，不是逮着机会就要刷存在感，而是只在真正需要的时候才开口。
这就好比老师批改作业，不是看到学生写字就要点评字迹，而是只在学生真的解错题时才圈出来。如果老师对每一个字都要评论，学生反而会被淹没在无关紧要的噪音里，抓不住真正的重点。论文的实验也证实了这个判断，拿掉这种"按需静默"的机制之后，效果明显下降。
诊断要精确：九种类型化的操作符
光知道"什么时候该说话"还不够，说什么同样重要。
论文里提到一个很实在的观察，泛泛而谈的批评，比如"考虑一下边界情况"，对智能体来说基本等于没说。它需要知道具体是哪里出了问题，应该怎么改，改完之后怎么验证改对了。
于是Opera要求每一次诊断都必须使用一个
operator：类型化的操作符，把一个诊断出来的问题绑定到具体的证据、修正方向和一个可验证的解决标准上，论文中设计了九种，分别覆盖搜索、查看、编辑、测试、提交五个阶段。
比方说，"repo_localization_search"用来指出目标代码还没找到；"implementation_target_shift"用来指出改错了文件；"requirement_contract_review"用来指出改动违反了任务要求本身；"state_transition_review"用来指出执行逻辑本身有问题，比如先用了数据再做空值检查，顺序反了。每一种操作符都遵循一种叫做
Design by Contract：契约式设计，一种软件工程方法，规定一个组件何时适用、需要什么证据、可以提出什么修正、什么情况算解决、以及和哪些问题互相排斥。
的规范方式，这样每条笔记的边界都很清楚，不会和别的问题混在一起说不清楚。
这个设计解决的根本矛盾是什么？如果批评意见里混杂了好几个问题，智能体很难知道先改哪个，改完一个之后另一个问题的责任到底算谁的也说不清楚。限定每次只提一个问题，用一个明确的操作符和一个固定的验收标准，相当于把一次模糊的训话变成了一份可执行的任务清单，这才让"后续追踪"这件事变得可能。
有没有效果？论文做了消融实验，发现只保留编辑类操作符的版本，和只保留非编辑类操作符的版本，各自都能保留大部分的提升效果，但两者的提升并不是简单相加，说明批评者经常能通过不同的操作符去指向同一个底层问题，具备一定的互相补偿能力。
说出去的话要先过一道关：双重审计机制
这里要面对的是第二个难题，批评本身的可靠性。既然批评者也是一个大语言模型，它自己也可能犯错，给出一个听起来很有道理但实际上是误读的诊断。
Opera设置了两道审计关卡，一道管开笔记和改笔记，另一道管关笔记。这两道关卡本身不会去改写批评者提出的建议，它们只做一件事，接受或者拒绝。
这就像公司财务审批流程里专门设置的审核岗，审核员不会替申请人重新写一份报销单，他只会在金额不对、票据不全或者重复报销的时候打回去。如果没有这道关卡，任何一笔申请，不管合不合理，都会被直接放行，财务系统很快就会乱成一团。
开笔记的审计会检查，这个诊断有没有证据支撑、提出的修正是不是真的必要、给出的验证方式能不能真正证明问题已经解决。论文举了具体的反例，比如那种和任务本身无关的"顺手优化一下代码风格"的建议，或者没有新证据支撑、只是在重复之前说过的话的提醒，这些都会被拒绝，这条笔记保持原样不变。
关笔记的审计更严格，要求必须有实际证据支撑，比如执行结果或者可见的代码改动，才能宣布这个问题真的被解决了，然后笔记会被归档并从智能体的上下文里移除。
这里有个很细致的设计，笔记的解决标准是在开笔记的时候就定死的，后续即便批评者在跟进过程中调整了具体的建议措辞，这个最终的验收标准不会变。
为什么要这么做？因为如果每次更新笔记的时候都把验收标准也一起改了，批评者就有可能悄悄把标准改低来让问题"看起来"被解决了，这就违背了跟踪问责的初衷。固定住最初的目标，才能真正判断这件事是不是被解决了，而不是被绕过去了。
论文做了一个专门的消融实验来验证这道审计关卡到底有没有用，结果相当直接。
| 实验设置 | Terminal-Bench 2.1 | SWE-Bench Pro | DeepSWE |
|---|---|---|---|
| 无批评者 | 65.9 | 75.3 | 32.4 |
| **Opera（带审计）** | **73.8** | **79.3** | **41.3** |
| Opera（去掉审计） | 68.5 | 78.3 | 36.9 |
在Terminal-Bench 2.1上，去掉审计之后，原本7.9个百分点的提升直接缩水到了2.6个百分点，少了将近三分之二；在DeepSWE上也从8.9个百分点掉到了4.5个百分点，少了一半。这说明审计这道关卡在那些中间证据容易被误读、乱提建议代价很高的场景里，起到了非常实在的过滤作用。
成绩单：在三个基准测试上的表现
论文在三个不同的测试环境里验证了Opera的效果，分别是Terminal-Bench 2.1、SWE-Bench Pro的一个100任务子集，还有DeepSWE v1.1，每个测试环境搭配了不同的智能体执行框架和四个不同能力水平的基础模型。
和四个有竞争力的对比方法比起来，Opera在三个基准上都拿到了最高的平均解决率。
| 方法 | Terminal-Bench 2.1 | SWE-Bench Pro | DeepSWE |
|---|---|---|---|
| 无批评者 | 65.9 | 75.3 | 32.4 |
| SWE-PRM | 68.9 | 77.7 | 36.6 |
| SWE-Search | 70.0 | 77.3 | 38.6 |
| LLM-as-verifier | 71.2 | 78.7 | 38.9 |
| Agentic Rubrics | 71.9 | 78.3 | 39.5 |
| **Opera** | **73.8** | **79.3** | **41.3** |
更细致地看不同基础模型的表现会发现一个规律。
能力偏弱的模型从批评者那里获益更多。
比如Qwen3.5-9B这个相对较小的模型，在Terminal-Bench 2.1上提升了12.4个百分点，在SWE-Bench Pro上提升了15.0个百分点，这是四个模型里涨幅最大的。而本身已经比较强的DeepSeek-V4-Flash，在它已经做得不错的基准上提升幅度很小，但是换到更难的DeepSWE上，提升幅度一下子又变大了。
这背后透露出一个朴素的道理，批评者能起到的作用，取决于智能体本身留出的"犯错空间"有多大。
但这不意味着批评者是万能的。论文里有个很诚实的发现，Qwen3.5-9B这个模型在DeepSWE这个基准上，无论有没有批评者辅助，一个任务都没解决成。这说明批评者再怎么提醒，也不能替代智能体本身缺失的能力。它更像是一个称职的教练，能帮运动员纠正动作、提升发挥，但没法让一个还没学会跑步的人直接去跑马拉松。
更有意思的是不同能力的模型，被批评者揪出来的问题类型是不一样的。实验统计了四种模型被批评者采纳的笔记类型分布，发现相对较弱的Qwen3.5-9B最常收到的是"需求理解错误"的提醒，说明它经常没搞懂任务到底要求什么。而更强的Qwen3.8-27B和DeepSeek-V4-Flash则更多地收到"执行逻辑错误"的提醒，说明它们理解目标没问题，但是具体执行的时候逻辑出了岔子。这就好比考试里有的学生是审题就错了，有的学生是审题没问题但算错了，错误类型完全不同，批评者需要能分辨这个差异。
批评者会不会好心办坏事：拯救与误伤的权衡
一个很诚实的发现是，批评者对强模型和弱模型的影响并不对称。
在收到提醒的那些任务里，强模型从批评者那里拿到更多的"拯救"，也就是本来做不出来的任务，经过提醒之后做出来了。但同时强模型也承受了更多的"误伤"，也就是本来能自己做对的任务，因为被插了一句不必要的提醒反而做错了。弱模型正好相反，很少被误伤，但是被拯救的次数也少。
论文给出的解释是，强模型更愿意立刻按照反馈行动，这个行动力是把双刃剑，对的提醒能迅速纠偏，错的提醒也会迅速把原本正确的路线带偏。这就像一个经验丰富的老司机，一听到副驾说"前面好像要转弯"就立刻打方向，技术好能快速纠正，但万一副驾说错了，老司机也会立刻跟着错下去，而新手司机可能半信半疑磨蹭半天才动作，反而躲过了一些错误提醒的坑。
训练配方：用批评者生成的数据训练一个更小的模型
Opera的用途不仅限于推理阶段的临场纠偏，它产生的交互轨迹本身也是宝贵的训练数据。
论文设计了一个对比实验，用Qwen3.5-9B作为学生模型、Qwen3.8-27B作为批评者，让学生模型在批评者的指导下完成一批任务，把这些轨迹收集起来做微调。同时作为对照，另外用Qwen3.8-27B自己独立完成同一批任务，把这些"老师"的轨迹拿来做微调。两种数据训练出来的模型，在没见过的SWE-Bench Pro仓库上表现几乎一样好，都提升了大约10个百分点。
但差别出现在换一个完全不同的测试环境时。
| 训练数据 | SWE-Bench Pro（held-out） | Terminal-Bench 2.1 |
|---|---|---|
| 不训练（基线） | 28.7 | 23.6 |
| 用老师模型的轨迹训练 | **39.5** | 7.9 |
| 用Opera指导下学生自己的轨迹训练 | 38.9 | **25.8** |
用老师的轨迹训练出来的模型，在Terminal-Bench 2.1上成绩从23.6%直接掉到了7.9%，这是一种叫做
遗忘：模型在学习新任务时，丧失了原本已经具备的其他能力。
的现象。而用Opera指导的学生自己轨迹训练出来的模型，不但在目标任务上提升幅度相当，还几乎完整地保留了原来在Terminal-Bench 2.1上的表现。
为什么会有这个差异？论文给出的解释和一个叫做
on-policy：训练数据中的所有动作都来自被训练的模型自身，而不是来自另一个模型的示范。
的概念有关。老师模型的轨迹对学生来说是完全陌生的行为方式，强行学习这种陌生的行为方式，就像让一个习惯左手写字的人去模仿右手写字的笔迹，模仿久了反而会打乱他原本熟练的左手书写能力。而Opera指导下的学生轨迹，每一个具体的动作都是学生自己做出来的，批评者的影响只是通过笔记这种外部提示体现出来，学生学的是"在收到这种提示时该怎么调整"，而不是"该模仿另一个人怎么做事"，这就更接近于强化学习里让模型从自己的尝试中学习的方式，天然更不容易破坏原有能力。
这个发现呼应了机器学习里一个经典的思路，叫做
DAgger：一种模仿学习算法，核心思想是让学习者在自己实际会遇到的状态下接受专家的纠正，而不是单纯模仿专家从头到尾的完整示范。
这也解释了为什么"批评者指导下的自我纠错轨迹"会比"纯粹模仿更强模型"更有价值，学生学到的是如何在自己真实会犯错的那个节点上改正过来，而这些节点，老师很可能根本不会经历，因为老师压根不会犯学生那种错误。
批评者本身该选谁：自我批评还是请外援
论文还做了一个很接地气的实验，就是让一个模型自己批评自己的工作，和请一个更强的外部模型来当批评者，效果能差多少。
结果显示，当策略模型本身能力还不错的时候，自我批评也能带来不错的提升，在DeepSWE上，Qwen3.8-27B和DeepSeek-V4-Flash自我批评各提升了6.2个百分点，和用Claude当批评者的效果差不多。这说明很多时候问题不是模型"不知道"该怎么做对，而是在执行的过程中没有机会停下来好好想一想，批评者框架提供的恰恰是这个"停下来想一想"的机制，哪怕提醒它的还是它自己。
但当策略模型本身能力有限的时候，自我批评就没那么管用了，因为批评者和被批评者共享同一套盲区，看不出自己看不出的问题。这时候请一个更强的外部模型来当批评者，提升幅度会明显更大。比如用GPT当批评者，Qwen3.5-9B的提升至少有12.4个百分点，而自我批评的提升最多只有2.7个百分点。
写在后面
读完这篇论文，一个让我反复琢磨的点是，大家通常会把AI智能体的进步想成是模型本身越来越聪明，但这篇论文提供了一个不太一样的视角，有时候不需要换一个更强的大脑，只需要给现有的大脑配一套合理的流程，让它在恰当的时机被提醒、被追问，表现就能明显提升。这跟人类团队管理里的一些朴素道理其实挺像的，很多时候不是人不行，是流程没给他留出纠错的窗口。
另一个值得单独说一说的细节是那个拯救与误伤的权衡。论文很诚实地呈现了批评者并不是纯粹的增益，强模型获得更多拯救的同时也承受更多误伤，这是一种真实存在的代价，而不是被回避掉的瑕疵。很多论文倾向于只展示好看的那一面，这篇论文把这个权衡摆出来讨论，反而让整套方法显得更可信。
还有一个问题论文留白了，没有展开，就是如果把这套"持久笔记"的机制用在批评者和执行者是完全不同种类的智能体身上会怎样，比如批评者看的是代码，执行者操作的是机械臂或者别的物理系统，这种跨模态的持续追踪机制是否依然成立。这个问题目前没有答案，但想一想还是挺有意思的。
Q&A
Q1：Opera是什么？
A：Opera是Salesforce AI Research提出的一个针对长时任务编程智能体的批评者框架，它把每次纠错当作一张持续追踪的笔记，直到诊断出的问题被真正解决才会关闭，而不是提完意见就不管了。
Q2：Opera和其他批评者方法相比效果怎么样？
A：在Terminal-Bench 2.1、SWE-Bench Pro和DeepSWE三个测试基准上，Opera相比不加批评者的智能体，分别最多提升了12.4、15.0和8.9个百分点，并且在和SWE-PRM、Agentic Rubrics等竞品对比中拿到了最高的平均解决率。
Q3：Opera生成的数据能不能用来训练模型？
A：可以。用Opera指导下学生模型自己产生的轨迹来微调一个更小的模型Qwen3.5-9B，效果能匹配直接模仿更强模型轨迹的训练方式，同时还能避免模型在换到新测试环境时出现明显的能力下降。
