AgentEvolver：边干活边升级自己的 Agent 系统

模型不动，让 Agent 的工具、技能和流程边干活边升级

3 分钟版

问题　Agent 可以把一件事做完，却没有因此变得更会做事。想让「做任务的经验」沉淀为可复用的能力，难点不在于让它多写一个工具，而在于管理：改过的组件有没有被测过？测的是不是同一个版本？之后真的被用上了吗？改动会不会把正在进行的任务搞乱？

思路　底座大模型保持不变，把 Agent 系统里八类东西都变成「可升级、带版本号」的组件：工具、技能、子 Agent、工作流、连接器、环境、记忆、插件。每次改动都走同一套流程：发现缺口 → 写候选版本 → 结构检查 → 和旧版本对比测试 → 决定保留或回滚 → 记录之后谁用了它。一个共享的 Runtime 统一调度任务和预算，持久的计划与可恢复的上下文保证任务方向不跑偏。

结果　团队报告：在 SWE-bench Pro Public（731 个代码修复任务）上，开启进化后解决 600 个（82.08%），不开启为 578 个（79.07%），净多解决 22 个。六个应用案例展示了改进后的能力如何进入后续的网站、游戏和研究工作，也如实记录了未完成的目标和一个失败的策略。

所以呢　这 3.01 个百分点是团队自报、没有逐题配对数据，也不能归因到哪个模块——作者自己都写明了。论文真正的价值在于提出了一种「能力进化的记账方式」：区分「交付物做没做好」和「留下的能力好不好用」。做 Agent 平台的公司可以直接借鉴这套版本、证据与成本归集的规则。

关键数字

• 82.08% SWE-bench Pro Public 解决率（开启进化）（§4.1 · Fig. 4）
• +3.01 pp 绝对提升（百分点）（§4.1）
• 8 类 可进化的组件族（Table 1）
• -30.08% Godot 亮度工具的中位延迟（§4.2.2 · Table 4）
• 400 步 每题协调者步数上限（Table 3）

局限与疑问

• 82.08% 为团队自报，来自另一台机器的运行；原始逐题结果、实际配置和完整成本记录未公开（作者自述）。
• 只知道净增 22 题，无法做配对显著性检验，也无法归因到任何具体子系统。
• SWE 对比只有一个协调者，不检验多 Agent 协作的作用。
• 六个案例为有目的抽样，部分组件族由任务指定，不代表平台整体成功率。
• 同一个 Agent 既提出又评估修订，存在自我评判与过拟合开发反馈的风险。
• 进化本身的开发成本（失败候选、评估调用）未在 SWE 结果中给出。

arXiv 摘要页 · PDF