告别盲目堆算力：让AI编程智能体从经验中学会“思考”
核心不是多生成几条轨迹，而是让轨迹先被压缩、比较，再成为下一轮的上下文
这篇论文讨论的不是“把同一个问题重试更多次”这么简单，而是如何把一次长程编程尝试压缩成可比较、可复用的经验，再用经验指导下一轮搜索。
30 秒结论： 并行探索负责发现不同路径，结构化复盘负责去噪，递归锦标赛投票（RTV）负责选择和聚合，并行蒸馏提炼（PDR）负责把经验带入下一轮。论文在特定模型、基准和预算下观察到成功率提高、完成轨迹变短；这不等于增加测试时计算在所有任务上都更有效，也不等于推理成本自动下降。
本文信息截止到 2026-09-15。文中的数值沿用论文实验设置，不能直接外推到其他模型、提示词、并行度或部署硬件。
1. 问题：为什么单纯增加尝试次数不够？
在长程修复任务里，额外 rollout 往往只是重复同一种失败：同一个错误假设被不同轨迹重新验证，终端日志越积越长，却没有新的可执行线索。于是“多试几次”增加了 token 和 wall-clock 成本，却未必增加有效搜索覆盖。
这就是当前 AI 编程智能体的难点：一次尝试往往包含几十步推理、终端操作、代码修改、报错和回退。短答案可以直接比较对错，长轨迹却很难在生成过程中比较，更难把一条轨迹中的局部进展迁移到下一条轨迹。
因此问题应当改写为：
如何把长轨迹中的有效诊断、失败模式和已验证进展，变成下一轮智能体真正能使用的上下文？
2. 关键机制：先压缩经验，再扩展搜索
论文的关键不是给模型加一个“思考”按钮，而是把测试时计算拆成三个不同职责：
| 机制 | 解决的问题 | 输出 |
|---|---|---|
| 并行 rollout | 如何覆盖多条可能路径？ | 多条独立任务轨迹 |
| 结构化 summary | 如何从长轨迹中去掉噪声？ | 可比较的经验摘要 |
| RTV + PDR | 如何选择并复用经验？ | 下一轮任务的经验上下文 |
一条原始轨迹可能混有重复日志、无效尝试和暂时性的猜测。结构化复盘不应只是“把全文缩短”，而要至少保留三类信息：
- 核心假设：最初认为问题位于哪个模块，依据是什么？
- 关键进展：已经定位了什么，哪个修改或测试被验证有效？
- 失败模式：在哪一步卡住，哪类修复或路径已经被排除？
这样，后续模块比较的是“可行动的经验”，而不是几万 token 的终端转储。
3. 一轮 PDR + RTV 是怎样运行的？
可以把一轮过程压缩成下面这条链：
并行探索 N 条轨迹
↓
为每条轨迹生成结构化 summary
↓
RTV：分组比较，逐轮聚合候选经验
↓
PDR：把聚合后的经验注入下一批并行任务
↓
再次 RTV，选择最终候选3.1 并行探索与结构化复盘
首先启动 \(N\) 个相互独立的编程任务。每个任务拥有自己的环境和上下文，尝试解决同一个 issue。任务结束后，不直接把完整轨迹交给评审器，而是为每条轨迹生成统一格式的复盘摘要。
这里的并行化只解决“搜索广度”，不解决“如何判断哪条轨迹值得继承”。后一个问题由 RTV 处理。
3.2 RTV：递归锦标赛投票
RTV（Recursive Tournament Voting）不要求评审器一次性给所有候选做全排序，而是反复执行小规模比较：
- 将候选摘要分成小组，常见直觉是两两比较；
- 让模型判断每组哪条经验更有希望，并说明胜出的依据；
- 把胜者或提炼后的经验送入下一轮；
- 重复若干轮，直到得到少量候选或最终候选。
小组比较的价值不在于“锦标赛”这个名字，而在于降低单次判断的上下文负担。评审器只需比较局部候选，并能把“为什么这条路径更好”一并提炼出来。
但 RTV 不是可靠性证明：评审器仍可能误选，尤其当成功与失败的差异藏在测试结果或细微代码 diff 中时。
3.3 PDR：并行蒸馏提炼
PDR（Parallel Distillation Refinement）把 RTV 产出的经验摘要注入新一批并行任务。新任务仍然独立探索，但不再从完全空白的上下文开始：
- 成功经验提供可能的诊断路线；
- 失败模式提醒模型避免已经验证无效的方向；
- 已完成的子问题可以成为下一轮的起点。
因此它形成的是“串行的经验传递 + 并行的候选生成”，而不是简单地把所有 rollout 数量乘大。
4. 论文报告了什么证据？
论文在 SWE-Bench Verified 和 Terminal-Bench v2.0 上评估这套 PDR + RTV 流程。下面只列出文章中最值得保留的报告值：
| 模型与指标 | 基线 | 使用框架后 | 说明 |
|---|---|---|---|
| Claude-4.5-Opus / SWE-Bench Verified | 70.9% | 77.6% | 论文实验设置下的成功率变化 |
| Claude-4.5-Opus / Terminal-Bench v2.0 | 46.9% | 59.1% | 不同基准，不能与上一行混作同一指标 |
| PDR 轨迹步骤数 | — | 约减少 50% | 反映搜索轨迹变短，不等于 wall-clock 成本减半 |
这些结果支持两个较窄的结论：
- 经验复用可以让长程任务的候选选择和下一轮搜索受益；
- PDR 不只可能提高成功率，也可能减少完成任务所需的平均操作步骤。
它们不能直接证明：所有模型都能得到同样幅度的提升、更多并行度一定更好，或总推理成本一定下降。其他模型的结果应按论文表格逐项读取，不能用“提升 4%–16%”这样的范围替代具体实验条件。
5. 这套方法的边界
5.1 经验摘要会丢信息
摘要是有损压缩。若失败原因藏在一段具体日志、一个未被注意的测试差异或一处代码上下文中，摘要器可能把真正有用的证据删掉。
5.2 评审器错误会被递归放大
RTV 的早期误选可能影响后续经验池。递归聚合减少了一次性排序的负担，却没有消除 judge bias；不同模型作为生成器和评审器时，误差来源也不相同。
5.3 “步骤更少”不等于“系统更便宜”
框架增加了 summary、投票和经验注入的额外调用。要判断部署收益，至少还要同时报告 token 数、并行资源、端到端 wall-clock、失败重试和实际 API 成本。
5.4 描述性经验还不是可执行制品
复盘摘要能告诉下一轮“应该注意什么”，但不一定能直接复用一个已经验证的补丁、测试脚本或调试环境。把经验从文本描述推进到持久化外部制品，是自然但仍需单独验证的下一步。
6. 一句话总结
对长程编程智能体而言，测试时扩展的关键变量不只是尝试数量，而是经验能否被表示、比较并重新注入搜索过程。PDR + RTV 给出了一条可检验的路径：并行探索产生多样性，结构化复盘减少噪声，递归评审选择经验，下一轮 rollout 再验证这些经验是否真的有用。