这可能是史上最伟大的 issue 报告 有人写了一篇论文评估我 /retro 技能的有效性 太不可思议了 https://arxiv.org/pdf/2610.34938

编码智能体的运行框架如何自我演化？一项关于回溯式适配的实证研究

来源: https://arxiv.org/html/2610.34938 Sebastian Baltes 单位: 海德堡大学 海德堡, 德国 [email protected]

摘要

编码智能体可以依据先前任务的经验，调整其运行框架（harness）——即运行智能体所用的软件、配置与指令，但这些调整是否改善了它们在后续任务上的表现仍不清楚。我们研究了 /retro 技能，它要求智能体回顾一次已完成的会话并提出框架修改建议，并追问它会提出哪些修改、以及实施的修改是否减少了后续任务中的重复工作。我们让 Claude Code 在 30 个 SWE-bench Verified issue 上运行，对 /retro 产生的 125 条建议进行了质性编码，实施了其中 24 条，并在后续 issue 上以全新会话、分别开启和关闭每项框架修改的方式，对 12 项框架修改进行了评估，这些 issue 来自相同的代码仓库。多数建议指向会话中的某个事件，但 43 条 lint 相关建议中有 18 条无论发生了什么都会推荐某种做法。在七次评估中（未开启该修改的会话确实遇到了目标问题），两项修改消除了目标动作，一项降低了其出现频率，四项未见减少，还有一些修改在无关 issue 上增加了工作量。框架的自我演化不只是生成并实施修改：它还需要建立判断修改在后续任务中是否有益的方式，并修订或移除无效的修改。

关键词:

编码智能体, 智能体运行框架, 自我演化, 回溯复盘, SWE-bench

I 引言

编码智能体（如 Claude Code）运行在一个框架内：即运行该智能体所用的软件、配置与指令，包括智能体在每次会话开始时读取的上下文文件（如 CLAUDE.md）。某次会话中弄清了如何运行某个仓库的测试、或哪些测试本来就失败，就可以将这些信息保留在框架中，供后续同一仓库的会话使用。将已完成会话中的修改保留下来用于后续任务，而无需重新训练模型，这就是框架的自我演化[1 (https://arxiv.org/html/2610.34938#bib.bib1)]。被保留的修改是否有帮助则是另一个问题：一项修改可能只描述了某个任务而非整个仓库，可能落在后续会话的上下文之外，也可能被读取后并未改变智能体的行为。

/retro 技能是产生此类修改的一种机制。它指示编码智能体进行一次回溯复盘：对已完成的会话进行回顾，并生成编号的框架修改建议，等待人工批准[2 (https://arxiv.org/html/2610.34938#bib.bib2)]。在我们的研究中，Claude Code 完成任务会话、生成复盘，并实施获批的建议。两个大语言模型（LLM）对建议进行编码，由我们决定实施哪些建议、挑选后续 issue 并标注结果，因此我们研究的是有人工筛选与评估的自我演化，而非自主闭环。我们提出两个研究问题。RQ1：/retro 提出的框架修改是什么？它们在多大程度上基于会话中的事件？RQ2：在什么条件下，已实施的适配能够阻止后续同一仓库的 issue 中出现目标动作？

已实施的框架修改即一项适配（adaptation）。对每项适配，我们将重复工作操作化为：后续会话执行了该适配本意要阻止的某个具体动作，例如在 pytest 未安装时用 pytest 运行测试，或在代码未修改的情况下重跑测试，以确认某个无关的失败是否早已存在。这是一个行为学指标，并非断言该动作没有必要，或阻止它就改善了任务结果。我们将单项适配（各自在一次会话后提出）迁移到同一仓库的其他 issue 上。通过记录后续会话是否遇到目标问题、是否查阅了该适配、以及是否重复了目标动作，我们考察被保留的适配在何时会改变智能体的行为。

II 背景与相关工作

以往研究考察了开发者如何配置编码智能体，以及这些配置是否有帮助。Galster 等 (https://arxiv.org/html/2610.34938#bib.bib3) 在 2,853 个拥有编码工具配置产物的工程化 GitHub 项目中，有 91% 找到了上下文文件[3 (https://arxiv.org/html/2610.34938#bib.bib3)]。Lulla 等 (https://arxiv.org/html/2610.34938#bib.bib4) 在 10 个仓库的 124 个 pull request 上运行 Codex，分别开启和关闭各仓库的 AGENTS.md 文件，启用该文件后中位墙钟时间从 99 秒降至 70 秒[4 (https://arxiv.org/html/2610.34938#bib.bib4)]。在 58 个 SWE-bench Verified 任务上，Zhang 等 (https://arxiv.org/html/2610.34938#bib.bib5) 观察到随机的社区规则文件与精选规则的通过率相同[5 (https://arxiv.org/html/2610.34938#bib.bib5)]。这些研究提供的都是在会话之前撰写或生成的指令。

其他工作则保留了先前尝试中的经验。Agentic Harness Engineering 利用会话轨迹提出框架修改，其作者在后续基准轮次中检验了这些修改的预期效果[6 (https://arxiv.org/html/2610.34938#bib.bib6)]。Wu 等 (https://arxiv.org/html/2610.34938#bib.bib7) 将框架修改追溯到同一任务的后续尝试中，但那些尝试同时使用了多项修改。他们警告说，基于单次会话轨迹的更新可能针对的是某个任务特有的推理，而非反复出现的框架问题[7 (https://arxiv.org/html/2610.34938#bib.bib7)]。Lin 等 (https://arxiv.org/html/2610.34938#bib.bib8) 比较了使用原始框架与更新框架时的任务成功率，并考察了智能体是否将技能加载进上下文并遵循其指令[8 (https://arxiv.org/html/2610.34938#bib.bib8)]。在一项 BenchTrace 实验中，经验在文字冒险游戏的不同子任务之间迁移，六种方法的任务进展均低于不做记忆更新的基线[9 (https://arxiv.org/html/2610.34938#bib.bib9)]。以往工作已考察更新后的框架是否有帮助，以及智能体是否加载并遵循其指令。我们通过在同仓库的其他 issue 上逐一评估单项适配，来补充这些研究。

III 研究设计

我们先运行了 30 次编码智能体会话，并从 /retro 收集了 125 条建议。随后对这些建议进行编码，实施其中 24 条，并在同仓库的后续 issue 上评估 11 项由此产生的适配以及 1 项由作者撰写的对照适配。所有任务会话均以非交互方式运行，使用 Claude Code 2.1.295 与 Opus 5.5，采用相同任务提示模板，/retro 使用源码提交 b0618bc[2 (https://arxiv.org/html/2610.34938#bib.bib2)]。该产物包含提示词、编码手册、标注指令、完整数据以及下文省略的流程细节。

作为 /retro 产出内容的示例，考虑一次 SymPy 会话：它先试图用 pytest 运行测试，而容器中并未安装 pytest，之后才找到仓库的 bin/test 运行器。其四条建议中的第二条，标题为“缺少指向测试运行器的指引”，指出该仓库没有上下文文件，并提议写一个两行的 CLAUDE.md，指明 bin/test、说明 pytest 未安装，并列出完成前要运行的 CI 检查。Claude Code 原样实施了该文件。其预期效果是：该仓库后续的会话会先运行 bin/test。

任务与会话。 探索性样本包含 10 个 issue，来自 Django、SymPy、Matplotlib、Astropy 和 Sphinx 各两个，从基准中开发者预估工作量“15 分钟–1 小时”类别中随机抽样[10 (https://arxiv.org/html/2610.34938#bib.bib10)]。第二个样本包含来自 Astropy、pytest、Sphinx 和 SymPy 的 20 个 issue，并非随机抽取：我们选择了那些探索性会话遇到过环境问题（如先前已存在的测试失败）的仓库，以及在同一仓库中稍后又开了另一个 issue 的 issue。因此，建议数量描述的是这 30 次会话，而非任意编码任务。每个 issue 都在全新的 Claude Code 会话中运行，位于装有该 issue 仓库快照及已安装依赖的 Docker 容器内。提示词给出 issue 描述，不附带额外提示，要求 Claude Code 修改源代码并用现有测试验证其修改。Claude Code 结束后，我们用 /retro 恢复同一会话，并原样保存其输出，无论补丁是否通过隐藏的基准测试。对于探索性样本，我们的实验脚本在调用 /retro 之前提交了补丁，我们从分析中排除了关于该提交的三条评论。

建议编码。 /retro 输出中的每一条编号条目计为一条建议。全部 125 条建议均使用固定的编码手册进行质性编码。触发（trigger） 描述建议的依据与会话轨迹中所记录事件之间的关系：经验驱动（experience-driven） 标记那些基于轨迹中观察到的事件的建议，先验驱动（prior-driven） 标记无需依赖会话事件即可成立的建议（例如仅因仓库缺少 lint 钩子就提议添加），弱（weak） 标记与会话之间存在间接关联的建议。机制（mechanism） 描述建议所推荐的修改类型，使用表 I (https://arxiv.org/html/2610.34938#S4.T1) 中列出的六个编码。两名无法看到彼此标注的编码者产出了初始编码：一是使用 claude-fable-5-1 模型与默认设置的 Claude Code 智能体，基于完整会话轨迹工作；二是使用 gpt-6.1-sol 模型与高推理强度的 GPT，基于轨迹摘录工作。两名编码者使用同一套编码手册，因此他们的一致性反映的是这两种输入之间的一致程度，而非人工评分者间信度。他们对 125 条建议中的 109 条给出了相同的触发编码（Cohen’s κ= 0.67），对 109 条给出了相同的机制编码（κ= 0.84）。第一作者解决了 91 处分歧（按建议与编码分别计数），我们报告解决后的标注。该产物记录了编码者的输入以及对探索性样本的复核。

入选与实施。 一条建议若要能够在其他 issue 上实施并评估，需满足：被编码为经验驱动、提出在允许的文件与设置中的持久性框架修改（包括上下文文件、钩子以及 lint 或持续集成（CI）配置）、可安全应用、不只是修复原始 issue，并且能够给出识别后续会话中重复工作的书面标准。Claude 的初始编码识别出 33 条合格建议，其中 14 条来自探索性样本，19 条来自第二个样本。第一作者在实施前复核了探索性样本的入选标注，而在两名编码者对第二个样本产生分歧的条目上，仅在实施之后才复核。我们从第二个样本中选出了九个 known-failures 文件和一条测试命令指令——这两个类型在其他 issue 上重现了目标问题。同类的其他 SymPy 建议因在该仓库中已评估过而被省略，对其余建议则找不到其他能重现目标问题的 issue。我们在原始容器中恢复原始 Claude Code 会话，以实施这 10 条以及全部 14 条探索性样本的建议。24 次实施中有 11 次产生了我们能够在其他 issue 上评估的适配。其余 13 次要么没有改动任何框架文件，要么只改动了环境或允许位置之外的文件，要么找不到能重现目标问题的其他 issue。作为与这些经验驱动适配的对比，我们还评估了一条被编码为先验驱动的建议中的 pre-commit 配置。该配置由作者在 Claude Code 的权限系统阻止其实施后写就，最终得到 12 项被评估的适配。分歧的解决改变了 16 条建议的入选资格，但它们都不在被评估的 12 项适配之中。

迁移。 我们把对某项适配在某个特意选出、用以重现该适配所针对问题的任务上进行的一次评估，称为一次迁移事件（transfer event）。对每次事件，我们从同一仓库中另选一个 SWE-bench Verified issue，并在全新 Docker 容器中验证其环境能够重现该问题，例如列出的测试在未修改的代码上失败。这种定向选择检验的是：适配在其问题可能出现之处是否改变了行为，而不是它在任意后续 issue 上有多大概率有帮助。五个会话在原始框架下运行，五个在适配后的框架下运行，各自位于全新容器中，使用相同任务提示；适配框架下的变更文件则未经修改地复制进去。我们在 13 次迁移事件中评估了 12 项适配，其中一项适配在两个任务上进行了测试。另有三项适配也在对照任务上（同仓库的无关 issue）进行了评估，以检查它们是否增加了验证工作。两项 Sphinx 适配共用一个对照 issue。

对每个会话，我们记录复现（recurrence）：Claude Code 是否执行了该适配本欲阻止的动作，例如在 pytest 未安装时先尝试 pytest。对于先前已存在的失败，复现意味着一次基线对比（baseline comparison）：比较已编辑代码与未修改代码的测试结果，以判断观察到的失败是否早已存在。我们排除了仅限于该 issue 目标测试或 Claude Code 新增测试的对比，以及仅与已保存失败列表进行的对比。某次会话遇到一个其 known-failures 文件中没有的失败并与未修改代码做了对比，那么它执行了该文件本欲阻止的动作，尽管这种对比本身是合理的验证步骤。任务环境中存在的问题也不一定会被会话遇到：一个过期的闰秒数据文件只会让会话选择运行的那些测试失败，因此只运行该 issue 目标测试的会话从未遇到它。因此我们区分遇到问题与覆盖问题。当会话的轨迹显示出该适配所针对的问题类别（例如任意的先前已存在的测试失败）时，我们称该会话遇到了问题。当某项适配解决了实际遇到的具体实例（例如特定的失败测试）时，我们称该适配覆盖了问题。当某次迁移事件中原始框架的五个会话里至少有三个遇到了问题（不论是否被覆盖），我们将其归类为信息充分的（informative）。当某项适配进入 Claude Code 的上下文时，我们标记为已加载（loaded）；当 Claude Code 读取了被引用的文件或运行了被推荐的命令时，标记为已查阅（consulted）。查阅某文件并不能证明 Claude Code 依据其内容采取了行动。对于涉及先前已存在失败及其对照任务的九次事件，两名 LLM 标注者随后由第一作者在不显示框架标识的情况下，对全部 120 条会话轨迹标注复现情况与遇到的失败。所报告的标注为第一作者的标注，与 LLM 标注在 120 次会话中的 119 次复现判定上一致（κ= 0.98）。一次因认证错误结束的适配会话被排除，我们报告有效会话的数量，并以任务成功率和耗时作为次要结果。

IV 结果

会话与建议（RQ1）。 每次复盘产生两到六条建议，总计 125 条（表 I (https://arxiv.org/html/2610.34938#S4.T1)）。在 125 条建议中，101 条被编码为经验驱动，19 条为先验驱动，5 条为弱