美团、中科大 PluginRSI：让智能体把有效经验存成插件，下一轮接着用

一个编程智能体在修复问题时找到了更好的测试方法，下一轮重写运行框架，这个方法却可能被一起改掉。任务做了很多，版本更新了很多，真正有效的经验未必能留下来。

美团、中国科学技术大学等机构提出的 PluginRSI，关注的正是这件事：从执行轨迹中发现有效机制，把它们封装成插件，经评测后存进共享库，供后续框架重新组合。智能体的改进由此有了可以逐轮积累的载体。

论文：PluginRSI: Recursive Improvement of Agent Harnesses with Reusable Plugins

作者：Yaorui Shi、Yuchun Miao、Yuxin Chen、Jiayuan Zhang、Yueqing Sun、Xierui Song、Xiang Wang、An Zhang

单位：中国科学技术大学、美团、武汉大学、新加坡国立大学

论文链接：https://arxiv.org/abs/2609.32423v2

项目主页：https://syr-cn.github.io/PluginRSI/

开源仓库：https://github.com/syr-cn/PluginRSI

背景：递归改进，怎样避免有效机制被覆盖

递归自我改进（RSI）希望智能体利用已有反馈，持续提高后续任务表现。其中一条路线是优化 harness，也就是组织工具、角色、技能和记忆的运行框架：如何检查错误、什么时候调用工具、怎样保留证据，都由它协调。

这个过程与强化学习有相似的反馈循环：运行任务，得到轨迹与得分，据此调整，再验证效果。PluginRSI 在搜索过程中固定底座模型和提出修改方案的模型，更新的是外部程序与工作流。

问题在于，如果每一轮都把整个框架作为修改对象，多种机制便容易缠在一起。一版程序得分上涨，很难分辨是哪项修改起效；下一次重写，也可能覆盖先前有效的局部设计。

论文因此将改进单位细化到插件，同时保留整体重组的空间。搜索过程既要找到更好的框架，也要留下能够继续使用的机制。

创新点：将插件实现与调用流程分开

PluginRSI 将框架表示为“插件集合＋工作流”。插件负责实现机制，工作流决定何时调用它们，以及如何把输出交给后续步骤。

插件覆盖四类能力：角色规定求解时的职责与行为；工具执行终端命令等操作；技能提供调试、检查等可复用程序；记忆组织和返回已有执行证据。每个插件包含一份 YAML 规格与 Python 实现，接口、配置、提示词和来源等信息都有明确位置。

这样，系统可以先固定其他部分，只修改一个插件，观察局部贡献；也可以从库中挑选不同插件，重新安排它们的协作方式。两种操作分别对应“插件变异”和“框架重组”。

方法：局部验证入库，整体验证换版

每轮开始时，系统已经拥有当前框架的任务得分和执行轨迹。提出修改的智能体据此分析行为、检查实现，再生成候选方案。

在插件变异阶段，默认并行探索 8 个候选。每个候选使用独立抽样的 20 道任务，其中 10 道当前能完成、10 道尚未完成。成功样本用于检查已有能力是否受损，失败样本提供具体的改进线索。

每个候选只替换一个插件，工作流及其他插件保持不变。新旧版本在同一批任务上比较，得分提高的变体进入共享库。入库依据是这次局部比较，因此下一阶段还要检查整体效果。

在框架重组阶段，提出修改的智能体阅读先前执行反馈与本轮变异结果，从更新后的库中选择插件，同时调整工作流。新框架在全部优化任务上重新评测，只有得分严格提高，才替换当前版本。即使整体方案没有被采纳，已经通过局部验证的插件仍可供后续使用。

公开代码将这些约束落实到了检查中：变异阶段会核对工作流文件是否变化，记录新旧插件在同一批有效任务上的得分差、改善数和退化数；重组阶段再评测完整候选。轨迹、实现差异和失败反馈共同参与下一轮方案生成。

案例：从“哪里做错了”到“以后怎样处理”

论文附录展示了实际发现的插件。它们将轨迹中的问题转化成更具体的处理机制。

例如，原有终端工具执行命令、截断输出后直接返回。改进版本先检查完整输出中的执行失败与测试失败，包括退出状态显示成功、实际内容却包含失败的情况，再补充恢复提示。如果同一个测试命令反复出现同一条失败诊断，它还会提醒智能体重新检查。

这个变体在筛选批次上解决了 5 道此前失败的任务，同时有 1 道原本成功的任务退化，净成绩从 10/20 提高到 14/20。改善与退化都被记录，构成后续组合时的证据。

记忆插件也出现了类似变化。原先按词语重合度检索工具输出，容易反复返回当前对话里已经出现的信息；改进后先去重，只返回尚未交付的条目，并概括近期新增证据。该变体在对应筛选批次上从 10/19 提高到 14/19。

角色插件则把“尽量小改”细化成修复边界规则：涉及批量写入、事务或清理时，将保护范围放在确实需要它的最小持久化操作序列上。经验由此进入具体的行为指令与实现逻辑。

实验：软件修复、终端任务与跨模型迁移

SWE-bench Verified 实验使用 400 道任务进行优化与框架选择，另外 100 道用于留出评测；Terminal-Bench 2.1 则划分为 59 道优化任务和 30 道留出任务。各方法共享任务划分、接口端点和环境沙箱。

下面列出与 Meta-Harness 的留出集比较。SWE-bench 两行分别在对应模型下优化并评测，数值为任务解决率。

跨模型实验将选定框架冻结，再更换求解模型，不进行额外优化。例如，Kimi-K3 优化出的框架换用 GPT-5.6 Terra 或 GLM-5.2，留出集解决率均为 64%；相应的 Meta-Harness 为 60% 和 59%。

跨领域问答的提升较温和。在数学、引用意图分类和经济学共 150 道任务上优化后，系统转到金融、科学、物理、法律和医学共 250 道题，平均准确率从 Meta-Harness 的 56.8% 提高到 58.8%。不同领域所需策略的重叠程度，会影响迁移收益。

优化效率按累计求解轨迹数比较，PluginRSI 在所测预算内用更少轨迹找到更强框架。额外探索也有成本：附录统计，每条求解轨迹分摊的总输入、输出词元分别增加 7.5% 和 19.8%，其中包含提出修改方案的消耗。

消融与复用：有效经验究竟留下了多少

消融实验说明，收益来自两阶段搜索的配合。以 Kimi-K3 的 SWE-bench 留出集为例，完整系统为 69%；去掉插件变异降至 57%，去掉框架重组降至 59%。直接给 Meta-Harness 增加插件库，结果为 64%，接近其原有的 63%。

初始库来自已有研究与开源系统，经整理和人工检查后包含 75 个插件。将其缩减为 4 个基础插件、保持初始工作流不变，PluginRSI 仍达到 67%。丰富的起始组件有帮助，但并不足以解释完整系统的收益。

经过 15 轮进化，插件库从 75 个增至 132 个。最终候选约有 1,300 行 Python 代码，工作流维持在 300 行以内，主要增长发生在插件实现中。

更直接的复用检验，是把框架重置为初始版本，只保留进化后的插件库，再开始搜索。两轮后，复用库的解决率达到 69%，同期使用初始库为 65%；从进化后的框架继续搜索，三轮达到 70%。

这项后续搜索在先前留出的 100 道任务上进行，考察的是迁入新一轮优化后，已有插件能否加快搜索。它与前文冻结框架、直接更换模型的实验，共同提供了不同层面的复用证据。

局限与结论：可积累的机制，仍有适用条件

作者指出，实验基于固定任务集和有限轮次；任务分布不断变化时，长期进化以及持续扩大的插件库管理仍待探索。跨模型、跨领域的迁移也依赖具体任务与求解模型，问答实验中的收益差异已经体现了这一点。

单插件验证还存在结构性限制：某些机制需要同时调整其他插件或工作流，单独替换时未必有效，因而可能在局部筛选阶段被遗漏。论文将更长任务上的优化、更大跨度的迁移，以及插件与工作流的联合优化列为后续方向。

PluginRSI 给出的路径，是将轨迹分析落到可执行、可比较的机制上，再通过共享库保留、组合和复用。一次任务产生的反馈，由此能够参与塑造后续多轮框架，而有效经验也有了比单个程序版本更独立的存续方式。