Opera：面向长 horizon 编程 Agent 的言语型 Critic 框架

  • 关联论文：2609.33987
  • 作者：flyP
  • 更新：2026-10-10

§0 元层五问

  1. 这篇到底在解决什么真问题？ 长 horizon 编程 agent 需要"反馈"才能纠错，但反馈如果给早了、给错了、给完没人管用没用——多数现有 critic 只生成一次反馈就放手，agent 听了没听、问题解没解都不知道。Opera 要让 critic 把"纠错"当成一条 persistent note，追到问题真解决为止。
  2. 它和现有方法的核心差异是什么？ 不是单次"批评 + 改"，而是 persistent note + 触发器（periodic + event-driven）+ 类型化诊断算子 + 证据审计 + 后续动作追踪——把 critic 从"一次性评价器"升级成"持续追踪者"。
  3. 凭什么这件事现在做？ 论文在 Terminal-Bench 2.1 / SWE-Bench Pro 子集 / DeepSWE v1.1 三套基准上，4 种 policy model 全部正向提升，且能反哺训练数据——意味着 critic 信号真的"准到可以蒸馏"。
  4. 最大不确定性在哪？ "审计反馈对可见证据"这一道的过滤标准没有量化，typed operators 的具体类型清单在 abstract 也未列全。
  5. 如果我只看一行，要记什么？ "critic 不只是给反馈，而是把反馈当成 persistent note + 周期/事件触发器 + 类型化诊断 + 证据过滤 + 后续追踪，直到 problem resolved 才放手。"

§1 一句话结论

Opera 把"批评"重构成一条持续被追踪的 persistent note，用周期/事件双触发器和类型化诊断算子在 Terminal-Bench 2.1、SWE-Bench Pro 子集、DeepSWE v1.1 上把 4 种 policy 模型的 resolve rate 各提升 8.9~15.0 pp，并能反哺 Qwen3.5-9B 在 SWE-Bench Pro 留出集上拿到 10.2 pp 的推理期免 critic 提升。

§2 解决什么真问题

  • 批评的"一次性诅咒"：当前主流 critic（Reflexion、Self-Refine、CRITIC 等）都是"生成一段反馈 → 注入下一轮 prompt → 结束"，agent 是否吸收、是否解决根本问题，无人追踪。
  • 批评的时机问题：周期性批评浪费 token、事件驱动批评可能漏掉慢病；Opera 把两者结合。
  • 批评的乱枪打鸟：批评措辞模糊（"写得不好"）、agent 改了一半以为改完。Opera 引入 typed operators 做诊断粒度。
  • 批评的不可审计：批评是否基于真实证据、是否符合当前状态、是否真的对解决问题有帮助，没有一致机制。Opera 在反馈送达前做"对可见证据"的审计。
  • 批评信号能否蒸馏：critic 仅在推理期有用太奢侈，能否把它的判断反哺成训练数据？Opera 给出肯定答案。

§3 核心方法（机制）

3.1 总体框架

Opera 由四个组件构成：

  1. Trigger：何时介入？周期性触发 + 事件驱动触发并行。
  2. Diagnose：用 typed operators 对当前轨迹/状态做类型化诊断（"这是一个 bug / 这是一个 spec 误解 / 这是一个死循环"……）。
  3. Audit：在反馈送达 policy 前，先对照可见证据做一次内部审计——剔除与证据矛盾的诊断。
  4. Track：反馈一旦发出，Opera 不放手。它把这条反馈当 persistent note，跟踪后续 agent 动作直到诊断的问题真被解决，再关闭这条 note。

只有"诊断 + 审计 + 闭环追踪"三者齐全才算一次有效批评。

3.2 触发器设计

  • Periodic：每隔 N 步（步数可配）review 一次，捕获慢病。
  • Event-driven：当 policy 出现"重试同一错误 / 文件未变化 / 连续失败命令"等事件时即时触发，捕获急性病。
  • 双触发避免单一节奏下"漏诊"或"过度打扰"。

3.3 类型化诊断算子

不是给一段文字，而是给一个 typed operator：

{
  category: "missing_spec_understanding",
  evidence: <ref to file:line + commit message>,
  remediation: "re-read README §X, confirm Y, then re-plan",
  severity: high|med|low,
  confidence: 0..1,
}

typed operator 的好处是 policy 可以把它当成结构化指令去执行，比自然语言反馈更稳定。

3.4 闭环追踪

Opera 给每条 note 配一个 lifecycle：open → acknowledged → resolved | dropped。只有 policy 后续动作把诊断的问题真正修掉，note 才进 resolved。如果 agent 只做表面合规（"我把函数名改了"但问题没真解），Opera 通过对比"诊断前 vs 后的实际可观测行为"区分真解决与表面合规。

3.5 关键伪代码

notes = []
for step in agent.run():
    for n in notes.where(status == "open"):
        if n.diagnosed_problem in step.observable_diff:
            n.status = "resolved"
    if periodic_due(step) or event_match(step):
        diag = LLM.diagnose(typed_op_schema, step)
        if LLM.audit_against_evidence(diag, step):
            note = make_persistent_note(diag)
            feedback = render_for_policy(note)
            step.inject(feedback)
            notes.append(note)

§4 关键实验与数据

基准 policy 模型 resolve rate 提升 备注
Terminal-Bench 2.1 4 种 policy 模型 +12.4 pp（最高） abstract 给的是 4 模型中最高值
SWE-Bench Pro（子集） 4 种 policy 模型 +15.0 pp（最高） abstract 给的是 4 模型中最高值
DeepSWE v1.1 4 种 policy 模型 +8.9 pp（最高） abstract 给的是 4 模型中最高值
Terminal-Bench 2.1 平均 4 模型中 最高平均 resolve rate abstract 描述为"competitive critic baselines 上"
SWE-Bench Pro（留出仓） Qwen3.5-9B 蒸馏 +10.2 pp（无 critic 推理期） fine-tuning on Opera-guided rollouts ≈ 用更强模型蒸馏

附加事实：fine-tuning 后的 Qwen3.5-9B 在切换 harness（OpenHands → Terminus-2）后能力保留，而单纯蒸馏"更强模型"在这一切换上会显著掉点。

⚠️ 诚实标注：12.4 / 15.0 / 8.9 均为 abstract 给出的"最高提升"而非平均；4 个 policy 模型具体清单 abstract 未列全；Terminal-Bench 2.1、SWE-Bench Pro 子集的具体大小、split 切分未公开。

§5 亮点与局限

亮点

  • 闭环追踪概念新颖：把 critic 从"一次性生成器"升级成"持续追踪者"，明确区分"表面合规 vs 真解决"。
  • typed operators：结构化诊断比自由文本更可执行、更可审计。
  • 双触发器：periodic + event-driven 互补，慢病急性病都接得住。
  • 反哺训练数据：Opera-guided rollouts 接近 on-policy，能在推理期无 critic 仍然保留收益——这一点是 abstract 重点强调的工程价值。
  • 跨 harness 鲁棒：fine-tune 后的 Qwen3.5-9B 在 OpenHands → Terminus-2 切换下不掉点，说明学到的是"问题修复能力"而非"特定 harness 风格"。

局限

  • typed operator 清单未公开：哪些 category、每个 category 的判定标准是什么，abstract 没列。
  • 审计器自身不可审计：LLM 审计自身是否能避免自我合理化，原文未明确量化。
  • policy 模型清单未列：4 种模型具体是哪 4 种（GPT-4 系？Claude 系？开源？）、平均提升 vs 最高提升差距多少未量化。
  • SWE-Bench Pro 子集切分不透明：留出仓是哪些仓库、是否与已公开 SOTA 任务重叠，原文未明确。
  • Token 成本未给：critic 一直在跑，token 增量与收益比 abstract 没量化。
  • 持久化 note 数量上限未给：长 horizon 任务里 note 是否会无限膨胀未在 abstract 说明。

§6 工程落地启发（§八 六坑）

  1. 现象：critic 输出自然语言、不结构化。 影响：policy 把模糊指令执行得乱七八糟。修复：把 critic 改成 typed operator schema，强制 category/evidence/remediation/severity/confidence 五字段。
  2. 现象：critic 反馈发出后无 lifecycle。 影响：agent 假装改了，critic 不知道。修复：每条 note 强制带 status：open → acknowledged → resolved | dropped，并定义"实际可观测行为"判定标准。
  3. 现象：周期触发浪费 token、事件触发漏慢病。 影响：成本/覆盖失衡。修复：双触发器并行，periodic N 步 + event-driven 列表（重试/未变/连续失败）。
  4. 现象：critic 反馈与可见证据矛盾。 影响：agent 被带偏。修复：在送达 policy 前过 audit-against-evidence 闸，剔除无证据诊断。
  5. 现象：critic 信号只在推理期有用，没反哺训练。 影响：长期成本高。修复：把 Opera-guided rollouts 当 on-policy 训练数据蒸馏小模型，推理期可下线 critic。
  6. 现象：critic 强耦合到具体 harness。 影响：换 harness 即掉点。修复：训练阶段跨多种 harness 收集 critic rollouts，让被训模型学到"问题修复能力"而非"风格"。

⚠️ 诚实标注：上述 6 坑是基于方法描述的工程推断，原文未给每坑的实测频次。

§7 与同方向工作的关系

  • vs Reflexion / Self-Refine：Reflexion 类是"反思回 prompt"，Opera 是"反思 + 持续追踪"——闭环与否是核心差异。
  • vs CRITIC / Self-Critique：CRITIC 偏训练期偏好数据，Opera 偏推理期闭环；两者互补。
  • vs Agentless / AutoCodeRover 等 SWE Agent：这些是端到端 policy；Opera 是 policy 之上的 critic 层，可与任意 policy 拼装。
  • vs SWE-RL / RL on coding：纯 RL 微调改权重；Opera 不改 policy 权重，只改外部 critic 信号，可叠加。
  • vs Human-in-the-loop 审查：人类审查是终极 critic，Opera 是把审查流程自动化、闭环化的工程实现。

§8 适合谁读

  • AI 编程 agent 工程师：想让 policy 在长 horizon 任务上少走弯路的人，Opera 是少数"持续追踪式 critic"的完整方案。
  • Agent 评测研究者：12.4 / 15.0 / 8.9 pp 是值得复现的硬数字，需要关心 Terminal-Bench 2.1 与 SWE-Bench Pro 子集的可复现性。
  • RLHF / 偏好数据团队：Opera-guided rollouts 接近 on-policy，是做 critic-free 训练数据蒸馏的好材料。
  • 企业内 AI 工程团队：把 critic 做成持久化 note + 闭环，是把 LLM agent 当生产系统管理的一条工程原则。
  • 教师 / 课程设计者：把"批评—跟踪—解决"作为 agent 课程的元能力非常合适。

§九 评级四子项

子项 评分 依据
方法新颖度 A- persistent note + 闭环追踪有新意，但 typed operators / 审计想法业内已有雏形
实验充分度 B+ 3 个基准 + 4 policy + 蒸馏后提升，数字硬；但 policy 清单与子集切分未量化
工程可操作度 A 双触发器 + typed operator + lifecycle 都可直接复现，仓库已开源
可落地性 A- 仓库 + 蒸馏路径清晰；token 成本与 typed operator 清单需要自评

§十 边界声明

  • 仅基于 arxiv abstract（v2）+ paper_card + 候选人检索；未读 PDF 全文。
  • 12.4 / 15.0 / 8.9 / 10.2 pp 均为 abstract 显式数字；policy 模型 4 种具体清单 abstract 未列全；SWE-Bench Pro 子集具体仓库与 split 未公开。
  • 作者归属 abstract 显式 v1 Kai Mei 一人，v2 是否有新增作者 abstract 未明示，机构归属未在 abstract 列明。
  • "工程落地启发"6 坑为基于方法描述的工程推断，不等同于论文自报实测坑点。

flyP · 2026-10-10 · 基于 arxiv 2609.33987 abstract v2 / paper_cards/1749-2609-33987.md / lessons-2026-W37~W40 写作指引