35 views · 0 likes · 0 reposts (at collection)
A Study Tests How Coding Agents Learn from Retrospective Skill Changes
- Who
- Christoph Treude and Sebastian Baltes
- What
- published an empirical study evaluating retrospective adaptation coding agents modifying their work instructions after completing tasks
- When
- Quote
论文 10 月 26 日发布在 arXiv 上。
What happened
A study by Christoph Treude of Singapore Management University and Sebastian Baltes of Heidelberg University tested whether coding agents improve by revising their work instructions after tasks. Across 7 tests where the target problem occurred, 2 changes eliminated it; some changes also added checks on unrelated tasks and increased median runtime. The authors say project-wide guidance may remain useful, while task-specific failure notes may not transfer to later tasks.
Read next
See the full storyStudy Finds Limits to Coding Agents Learning from Revised Instructions不知道你有没有用过 /retro Skill，就是在编码任务完成后，让 AI 复盘刚结束的工作，列出几条修改建议，由人决定采不采纳。
除了 /retro 这个用在写代码上的，还有一些其他类似的复盘自我进化的 skill，听起来很美好：AI 干完一个任务后，回头看自己哪里卡住了，再提议修改 Skill，下次就不用再重复同样的弯路。这样不用重新训练模型，只修改 Skill 文件。
其实我一直是抱怀疑态度的，如果没有清晰的标准还是挺难自我优化好的。完全依赖人的话也难，一方面对人的要求有点高，另一方面每次这么做一下也挺累。
有篇论文《How Do Coding-Agent Harnesses Self-Evolve? An Empirical Study of Retrospective Adaptation》，专门测试了"让 AI 编程助手干完活后自己复盘、修改工作手册"的做法。
结果是，7 次有效测试里只有 2 项改动彻底消除了想解决的问题，有的改动还让 AI 在不相关的任务上多做了检查。
论文作者是新加坡管理大学的 Christoph Treude 和德国海德堡大学的 Sebastian Baltes，论文 10 月 26 日发布在 arXiv 上。
研究方法是这样的。
作者从 SWE-bench Verified 中选了 30 个问题，这是一套从真实开源项目里收集的代码修复题目，涉及 Django、SymPy、Astropy 等 Python 项目。
前 10 个是随机抽的，后 20 个专门从之前碰到过环境问题的项目里挑，比如项目里本来就有测试失败。Claude Code 每修完一个问题就运行一次 /retro，一共得到 125 条建议。
作者挑出 24 条让 Claude Code 落实，其中 11 项能拿来测试，再加上作者自己写的 1 项对照，共 12 项。测试时，在同一个项目里找另一个确认会出现同样问题的任务，用原来的设置跑 5 次，用改过的设置再跑 5 次，比较 AI 会不会再做那个本想避免的动作。
这次研究用的是 Anthropic 的 Claude Code，背后的模型是 Opus 5.5。
主要发现有四点：
1. 大部分建议有依据。
125 条里有 101 条针对的是任务中真实发生的事。另有 19 条的理由跟这次任务里发生的事无关，其中 18 条是建议加代码格式检查。
原因之一是 /retro 的指令本身就规定，项目里没有提交前检查、也没有自动化检查流程的，算作一个"发现"。作者把其中一条"提交代码前自动跑格式检查"配置好后测试，5 次里 AI 一次都没读它，也没运行它。
2. 13 次测试里，只有 7 次在原设置下真的碰到了目标问题，结果才有参考意义。
这 7 次里，彻底消除问题的有两项。
一项是在 CLAUDE.md 里写明 SymPy 项目要用 bin/test 跑测试，并说明没有安装 pytest。改之前，5 次里 5 次都先去试 pytest 然后失败；改之后是 0 次。
另一项是给 Astropy 项目写了一份"本来就会失败的测试清单"。
以前 AI 遇到测试失败，会在没改过的原始代码上再跑一遍测试做对比，确认失败是不是自己造成的；有了清单，它直接查清单，这种对比从 5 次中的 3 次降到 0 次。
3. 剩下 5 项改动，都没覆盖下一个任务里实际遇到的情况，比如清单里列的失败测试和下次碰到的不是同一批。
这 5 项里只有 1 项让对比次数减少，从 5 次降到 2 次，另外 4 项没有变化。
4. 有的改动增加了工作量。
Sphinx 项目的一份失败清单写着"不在清单里的失败，都当成是你自己的修改造成的"。
结果在一个不相关的任务上，5 次里有 4 次 AI 额外做了对比检查（原来是 0 次），用时中位数从 82 秒涨到 245 秒。前面那份有效的 CLAUDE.md 还顺带加了一句"完成前运行格式检查"，AI 每次都照做，用时中位数从 88 秒涨到 156 秒。
至于最后有没有修好问题，用不用这些改动，每组 5 次里的成功次数最多差 1 次，看不出成功率有提高。
作者的结论是，这个项目用什么命令跑测试这类全项目通用的信息，记下来以后一直有用；在某个环境里哪几个测试失败这类信息，换个任务就可能对不上。
评估一项改动，要看问题有没有出现、AI 有没有读这项改动、行为有没有变。保留下来的改动也要持续评估，因为过时或不完整的说明可能不起作用，甚至增加工作量。
作者也说明了研究的局限：每种设置只跑了 5 次，样本小；测试任务是特意挑的会重现问题的任务，可能高估改动的效果；只测了一个 AI 工具、一个版本的 /retro，而且只涉及环境类问题。
以我的经验，只有明确的可以程序自动验收标准的 Skills 才能自我进化，比如说你写个 Skill 去优化代码性能，这个代码性能是可测量可量化的，那么给一些测试样例去优化 Skill，那么能越来越好。 对于一些没有明确的验收标准的 Skill，比如你写一个写作的 Skill，写作的好坏并没有很明确的验收标准，只能是 AI “自己打分”，但是这个打分其实和真实人类的体感还是有差距，AI 打分很好的稿子可能真人看起来一股 AI 味。 真想写好 Agent Skills，还是要人去用，人去指出优化的方向，才能优化好。 但有一点，没必要人自己去写 Skill，最好是人指挥 AI 去优化 Skill，AI 在具体执行上是做的蛮好的。 另外做好版本管理，一轮一轮迭代，有时候还会出现负优化，得回退到旧的版本。View the quoted post on X
The story so far
Researchers Christoph Treude of Singapore Management University and Sebastian Baltes of Heidelberg University tested whether coding agents improve when they revise their instructions after completing tasks. In seven tests where the target problem recurred, two instruction changes eliminated it. Some changes also added checks to unrelated tasks and increased median runtime. The authors said project-wide guidance may remain useful, while notes about specific task failures may not transfer to later work.
Keep up with AI, one email a day
Model releases, price changes and compute developments, with original sources. Free, confirmed by email, and easy to unsubscribe. Read a past issue · 2026-11-03