给AI智能体换零件：当工具箱变成了插件商店

你有没有遇到过这种情况：团队里某个同事干活特别靠谱,你想把他的工作方法复制给其他人,结果发现根本说不清楚他到底做对了什么。是他用的工具顺手,还是他思考问题的角度特别,还是他写的文档模板好用?一股脑儿全都搅在一起,想学也学不会,想优化也不知道从哪儿下手。

现在把这个问题搬到AI智能体身上,规模直接放大了一百倍。

当下最火的AI智能体,比如帮你写代码、查资料、操作电脑的那些,表现好不好,很大程度上不取决于背后的大语言模型有多聪明,而取决于围在模型外面的那套"操作系统"。

这套系统有个专门的名字。

agent harness：围绕大语言模型搭建的一整套运行框架,负责定义和组织智能体能用到的工具、角色设定、处理流程等各种机制,直接决定了同一个模型在实际任务里表现得聪明还是笨拙

你可以把它想象成给一个很有天赋但没有经验的新员工配的工作手册加装备包。模型是那个员工的脑子,harness则是公司发给他的电脑、权限、SOP文档和同事协作规范。脑子再好,装备和流程跟不上,照样干不好活。

过去两年,研究者们发现一件挺有意思的事:与其费劲去重新训练模型,不如想办法优化这套harness,效果立竿见影,而且成本低得多。于是"harness优化"成了一个专门的研究方向。但这篇来自中国科学技术大学和美团的论文,点出了这个方向里一个一直被忽视的大坑。

这个坑到底有多深,我们得先说说现在大家都是怎么优化harness的。

当"优化"变成"重写",好点子全被埋了

现在主流的做法,是让一个负责"优化"的AI(论文里叫proposer,也就是提议者)去看整个harness的完整代码实现,根据这套系统跑任务时的表现反馈,直接对代码动手改写。改好了就评测一下,效果好就留着,效果不好就继续改。这套循环跑个几十轮,理论上harness应该越改越强。

proposer*：一个独立于被优化对象的智能体,专门负责审查当前harness的实现代码和执行记录,然后提出修改方案或全新的候选版本

Darwin-Godel Machine和Meta-Harness这两个代表性工作,走的都是这条路子。听起来挺合理,但论文作者指出这里面藏着两个致命问题。

第一个问题是机制互相缠绕,导致创新能力被锁死。

想象一下,你的harness里同时有一个负责理解任务的"角色设定"、一个负责执行命令的"工具"、一套"记忆系统"用来存储过往经验。这些东西全部写在同一份代码里,环环相扣。proposer想要单独试验一个新的记忆机制好不好使,根本没法把它从整个系统里摘出来单独验证,只能连带着整个harness一起改,一起测。

这就好比你想知道换一个新品牌的轮胎能不能提升赛车圈速,但赛车队的规矩是每次测试必须同时换轮胎、换变速箱、换空气动力学套件,一股脑全部换完再上赛道。如果圈速变快了,你根本不知道是轮胎的功劳还是变速箱的功劳。如果变慢了,你也不知道该骂谁。结果就是,车队测来测去,最后往往只会在已经验证过的几种组合里打转,不敢真正去试那些没被验证过的新组件,因为试错成本太高,风险太大。论文原话是说,这种做法会让优化反复收敛到相似的设计上。

第二个问题更让人心疼:好不容易发现的好点子,会被后续的改写直接盖掉。

设想proposer在第5轮迭代里,灵光一现想到了一个特别巧妙的错误处理机制,当轮测试效果拔群。但到了第6轮,proposer针对另一个问题又做了一次大改写,这次改写的代码版本里没保留住第5轮那个巧妙设计,它就这么悄无声息地消失了。整个优化过程里好点子就像沙滩上的字,潮水(下一轮重写)一来就被冲没了,没有机制能把它们攒起来,变成以后随取随用的经验资产。

这两个问题叠加在一起,结果就是优化越往后跑,越容易陷入原地打转的窘境。研究者们管这个现象叫"探索受限"和"经验无法沉淀"。

插件化:把"一锅粥"拆成"一盘菜"

既然问题出在"什么都揉在一起改",那解法自然就浮出水面了:把harness拆开,拆成一个个独立的、能单独验证、能单独保存的零件。

这就是这篇论文提出的PluginRSI的核心思路,RSI是Recursive Self-Improvement的缩写,也就是递归自我改进的意思。

PluginRSI*：一种让智能体harness通过插件化重构、独立改进、并在共享插件库里持续累积可复用机制的递归优化算法

具体怎么拆呢?论文把每一个harness表示成两部分的组合:一堆插件,外加一个负责调度这些插件的"工作流"。

plugin（插件）：harness里某个具体机制的独立可执行实现,比如一个角色设定、一个工具、一套记忆系统或者一个技能模块,通过标准化接口和其他部分解耦

workflow（工作流）：决定插件在什么时候被调用、调用的先后顺序、以及插件之间信息如何流转的调度逻辑

每一个插件由两部分组成:一份YAML格式的配置文件,规定了这个插件的输入输出长什么样、要用什么样的提示词、评判标准是什么;再加上一段真正干活的Python代码。四大类插件覆盖了角色、工具、技能、记忆这几个维度,角色负责渲染提示词告诉模型该扮演什么身份,工具负责执行具体操作比如跑命令行、查文件、提交代码补丁,技能负责提供可加载的操作指引和配套资源,记忆负责存储和检索任务过程中积累的证据。

这种拆分带来的最大好处是什么?

每个插件现在都可以单独改、单独测,而不用牵动整个系统。

这就好比你把一台复杂机器的设计,从"焊死的整体结构"改成了"乐高积木模式"。想试试新的发动机行不行,直接拔出来换一个,其他部件原封不动,立刻就能知道新发动机到底提升了多少性能。如果继续用焊死的思路,你永远只能做"整体推翻重来",永远测不出单个零件的真实贡献,也永远没法把这个优秀零件原封不动地搬到下一台机器上继续用。

有了插件化的基础,PluginRSI的优化流程分成了两步走,一步负责"挖好点子",一步负责"拼好整体"。

第一步:插件变异,专挑薄弱环节下手

这一步叫plugin mutation(插件变异),目标是在保持harness其他部分不变的情况下,针对某一个具体的插件做改进尝试。

具体做法是,每一轮优化会同时生成N个变异分支(论文设置N为8),每个分支拿到一个独立抽样的小批量任务(论文设置每批20个任务)去测试。这个小批量任务的构成很讲究,一半是当前harness已经能解决的任务,一半是解决不了的任务,各占10个。

为什么要刻意凑这个一比一的比例?

因为只看解决不了的任务,proposer容易设计出只会修补当前漏洞的"补丁型"改动,看不出这个改动会不会把原本能做对的任务搞砸。只看已经做对的任务,又没法发现新的提升空间。混着看,proposer才能同时兼顾"治病"和"不添新病"两个目标。

拿到这批任务和当前harness在这批任务上的执行记录后,proposer会挑出其中一个插件,针对观察到的问题设计一个改进版本。这个新版本会替换掉原来的插件,其余部分原封不动地保留,然后放到同一批任务上重新跑一遍,对比前后的得分。只要新版本的得分超过了原版本,这个改进过的插件就会被收进一个共享的插件库里,留着以后用。

这个筛选机制其实挺朴素,就是"有没有用,拿数据说话",没用的直接扔,有用的才留。论文的附录里给出了几个被实际挖掘出来的插件案例,挺能说明问题。比如有一个针对代码修复场景的"角色"插件,原来的指令只是泛泛地说"尽量做小的修改",变异之后的版本明确要求模型去判断"这次修改涉及的最小一段持久化状态变更范围是什么,把防护和清理逻辑放在这个范围里,而不是整个函数"。这个改动在一个真实的Django代码库任务里,把原本会错误地给整个视图函数加事务保护的解法,收窄成了只给真正出问题的批量写入循环加保护,任务直接从做错变成了做对。

另一个例子是记忆插件的改进。原来的版本是每次都把存下来的执行记录按关键词相关性排序,返回最匹配的几条,但这样做的问题是容易反复返回模型已经看过的信息,造成重复噪音。变异之后的版本加了去重逻辑,并且只返回之前从没推送过的新证据,相当于把"反复唠叨旧事"改成了"只汇报新进展"。这种改进在实际测试里,把原本19个任务里只能对10个的解法,提升到了对14个。

第二步:整体重组,把挖到的好点子真正用起来

光是挖出好插件还不够,因为好插件得被实际组装进一个连贯的系统里才能发挥作用。这一步叫harness recomposition(harness重组)。

在这一步,proposer会同时参考两份信息:当前这一版harness在完整验证集上的表现,以及刚才那一轮插件变异阶段收集到的各种尝试结果,包括成功的和失败的。基于这些信息,proposer从已经积累起来的插件库里挑选一批插件,重新设计调度这些插件的工作流,决定插件该在什么时候被调用、信息该怎么在插件之间传递。这个阶段,插件本身的实现代码是不动的,动的是"选哪些插件"和"怎么安排它们协同工作"这两件事。

重组完成之后,新拼出来的harness会在完整的验证任务集上跑一遍评测,只有当它的表现超过了目前为止最好的版本,才会被确立为新的当前最优解,进入下一轮迭代。

这个"变异挖掘加整体重组"的两步循环,跟生物进化里"基因突变"加"自然选择"的逻辑有点像,但更贴切的类比可能是科研团队的运作方式。你可以把插件库想象成一个实验室的共享材料库:每个课题组(变异阶段)分头做小规模实验,验证某个新试剂或新方法好不好用,好用的东西会被记录进实验室共享的标准流程文档里。然后项目负责人(重组阶段)定期回顾这些实验记录,决定下一版产品该采用哪些经过验证的材料和流程,重新设计整条生产线。如果没有这个共享材料库,每个课题组的发现只能留在自己手里,团队永远在重复踩坑,永远拼不出一条真正高效的生产线。

论文里给出了一张清晰的算法流程图,整个循环会重复T轮(主实验里设置为15轮),每一轮都先做插件变异再做整体重组,最终返回在验证集上表现最好的那一版harness。

效果到底怎么样:三大类任务全面验证

说了这么多设计思路,真正要紧的还是效果。论文在三类很有代表性的任务上做了测试。

第一类是SWE-bench Verified,这是一个专门考验AI修复真实软件缺陷能力的基准测试,题目都来自Django、SymPy、Sphinx这些知名开源项目的真实历史问题。论文把500道题拆成400道用于优化调参的"见过的题"和100道完全不参与优化过程的"没见过的题",专门用来检验优化出来的harness是不是真有本事,还是只是记住了训练集的套路。

结果显示,用GPT-5.6 Terra作为优化器优化出来的harness,在没见过的100道题上拿到了65%的解决率,比表现最好的对照方法Meta-Harness高出10个百分点。用Kimi-K3作为优化器,则达到了69%,比Meta-Harness高6个百分点。这两个数字特别值得注意的地方在于,"没见过的题"上的提升幅度,居然比"见过的题"上的提升幅度还要大。这意味着PluginRSI挖掘出来的改进不是针对具体题目的投机取巧,而是真正具备普遍适用性的机制改良。

第二类是Terminal-Bench-2.1,考验的是在命令行环境里完成各种操作任务的能力。PluginRSI拿到了69.5%的见过题解决率和73.3%的没见过题解决率,相比Meta-Harness的64.4%和66.7%,提升幅度在没见过的题上同样更明显。

第三类是跨越数学、金融、法律、医学等八个不同领域的问答任务。这类任务上的提升稍微温和一些,PluginRSI把没见过领域的平均准确率从56.8%提升到58.8%。论文坦诚地解释了原因:不同知识领域所需要的解题策略差异很大,数学推理里挖出来的好技巧,未必能直接套用到法律问题上,这种跨领域迁移本身就是一个更难的问题。

这里有个特别有意思的现象值得多说两句:当用一个模型优化出来的harness,直接拿去给另一个完全不同的模型使用,而不做任何额外调整,效果居然基本上还能保持。用GPT-5.6 Terra优化出来的harness,直接套到Kimi-K3和GLM-5.2上使用,依然比它们各自单独优化出来的baseline高出好几个百分点。这说明PluginRSI挖出来的那些机制改良,针对的更多是"怎么组织信息、怎么安排流程"这种通用层面的问题,而不是针对某个模型脾气量身定制的小花招。

更少的试错次数,找到更强的方案

还有一个指标特别能说明问题,就是优化效率。

研究者们画了一张优化过程的曲线图,横轴是累计调用求解模型的次数(论文里称为solver rollouts,也就是实际执行任务的总次数),纵轴是当前找到的最优harness的解决率。PluginRSI的曲线很快就冲到了一个Meta-Harness在整个实验预算里都没能达到的高度,而且这个"见过的题上表现好"和"没见过的题上表现好"是同步提升的,没有出现明显的脱节。

Meta-Harness则表现出一种令人担忧的模式:见过的题上的分数慢慢爬升,但没见过的题上的分数却忽上忽下,始终没能稳定在一个高位。

这个现象背后的解释其实挺直白。Meta-Harness每次都是整体重写,相当于每一次尝试都是一次豪赌,赌对了就提升,赌错了可能把之前好不容易积累的优点也带偏了。PluginRSI因为把好机制单独存进了插件库,即便某一轮的整体重组方案不够好,之前验证过的那些优秀插件依然安全地待在库里,不会跟着一起陪葬。这就好比炒股,一种策略是每次把全部身家押在一只新股票上,涨跌全凭运气,另一种策略是把已经验证靠谱的持仓留着,只拿一小部分资金去试新标的。后者显然更稳健,也更容易积累复利。

拆开来看,每个零件到底贡献了多少

研究者们没有满足于"整体效果好",还专门做了一系列拆解实验,想搞清楚究竟是插件库、插件变异,还是整体重组,各自贡献了多少。

结果挺出人意料的:单纯给Meta-Harness配一个插件库,但不改变它原来那种整体重写的优化逻辑,效果提升非常有限,甚至在个别指标上还略有下降。这说明光有一个存放好东西的仓库是不够的,关键还得有一套机制,能持续往仓库里塞有价值的东西,还得有一套机制能把仓库里的东西真正用起来组装成更好的整体。

另一方面,把PluginRSI里原本自带的那75个初始插件全部去掉,只留4个最基础的插件从零开始优化,最终效果居然跟保留初始插件库相差无几,没见过的题上的分数只掉了1到2个百分点。这个结果说明PluginRSI这套"变异加重组"的循环机制本身就很有生命力,就算不借助任何先验的人类经验,也能凭自己的力量摸索出一整套不错的组合,这比单纯依赖一个事先准备好的素材库更让人安心,毕竟真实世界里不见得总有这么一份现成的好素材可用。

但如果把变异阶段或者重组阶段单独去掉一个,效果就掉得很明显了。去掉变异阶段,没见过题目上的解决率从69%掉到57%,去掉重组阶段则掉到59%。这说明这两步缺一不可,挖掘局部改进和整体协调编排,解决的是完全不同的两个问题,一个负责发现好点子,一个负责把好点子真正用对地方,少了任何一个环节,整套系统的威力都要大打折扣。

库越滚越大,系统也越来越复杂

论文还跟踪记录了插件库随着优化轮次推进不断生长的过程。从一开始的75个插件,经过15轮迭代,膨胀到了132个,四大类插件(角色、工具、技能、记忆)都有新成员加入。

与此同时,PluginRSI拼出来的harness代码量也在稳步增加,到最后一轮达到了大约1300行Python代码,相比之下Meta-Harness的代码量始终徘徊在400行左右。更有意思的是,这1300行代码里绝大部分增量来自插件本身的实现细节,而真正负责调度的工作流代码始终保持在300行以下。

这个数据传递出一个挺关键的信号:系统变得越来越强大、越来越复杂,但负责"指挥"的那部分代码却始终保持精简。这正是插件化架构想要达到的效果,复杂性被妥善地封装进了各个独立的插件内部,而顶层的协调逻辑始终保持清晰可控。这就像一家公司业务规模扩张了十倍,但只要组织架构设计得当,CEO桌上的管理手册并不需要跟着变厚十倍,因为具体的专业复杂度被下放到了各个专业部门内部去消化。

旧库新用:经验能不能真正"带得走"

最后一个实验特别打动人,研究者们想验证的是,这套经过长期优化积累起来的插件库,能不能拿去加速一次全新的优化过程。

他们设置了三种对照:从最初的harness、空插件库开始优化;从同样最初的harness出发,但配上已经进化成熟的插件库;以及继续沿用已经进化过的harness和插件库接着往下优化。

结果显示,用进化成熟的插件库去配最初的harness,只经过两轮优化就达到了69%的没见过题目解决率,而不借助这个库从零开始优化,同样两轮下来只能到65%。更惊人的是,这个"借库起步"的表现,已经逼近了"持续沿用进化版"方案跑满三轮才能达到的70%。

这说明这个插件库里沉淀下来的,是真正能够脱离具体某一版harness、独立发挥价值的通用经验。这跟人类技能传承的道理其实一模一样:一个老师傅的手艺,如果能被拆解成一套套可以单独传授的具体技法,新徒弟学起来就会比从零摸索快得多,即便徒弟用的工具、所在的车间跟老师傅当年完全不是同一套配置。如果这套手艺永远锁在老师傅个人的直觉和肌肉记忆里,没法拆解传授,那每一代新人都得从头走一遍漫长的摸索弯路。

写在后面

读完这篇论文,我最大的触动是它其实在回应一个比"怎么优化AI智能体"更普遍的问题:复杂系统的改进,到底应该靠"推倒重来"还是靠"局部迭代加知识沉淀"。

论文里那个关于代码行数的数据让我印象很深,进化后的系统有1300行代码,但负责调度的部分始终控制在300行以内。这其实暗示了一种值得警惕的直觉陷阱:我们很容易以为系统变强就意味着核心逻辑变得更复杂,但这篇论文展示的恰恰相反,核心逻辑可以一直保持精简,真正的复杂度被转移并封装进了一个个独立的、可替换的模块里。这和软件工程里"高内聚低耦合"的老道理是一回事,只是这次被用来指导AI系统自己改进自己。

还有一个细节值得单独说一下,就是那个"一半成功一半失败"的任务采样策略。这个设计看着很小,但它暗示了一件事:给AI做反馈的时候,过于片面的信号(只告诉它哪里错了,或者只告诉它哪里做对了)其实都不如混合信号有效。这跟人类学习的道理也挺像,只盯着自己的失败复盘,容易变得畏手畏脚,只看自己的成功案例,又容易盲目自信,两者都得看,进步才扎实。

这篇论文也留了一些问题没有解答。比如插件库会不会无限膨胀下去,到了几千个插件的规模,怎么去管理和检索这个库,论文里没有细说。再比如不同任务领域之间的经验迁移为什么效果有限,这个"隔行如隔山"的问题到底能不能被进一步打破,也是个值得深挖的方向。

如果一个AI系统真的能像这篇论文展示的那样,把自己拆解成一个个可复用的零件,不断攒经验、不断自我重组,那它和一个真正在工作中成长的人类专家,到底还差多远的距离?

Q&A

Q1：PluginRSI是什么？

A：PluginRSI是一种让AI智能体harness通过插件化重构实现自我优化的算法,它把智能体的工作框架拆分成独立插件和调度它们的工作流,通过局部改进和整体重组两个阶段循环迭代,把发现的好机制积累进共享插件库里供后续反复复用。

Q2：PluginRSI和之前的Meta-Harness、Darwin-Godel Machine等方法有什么区别？

A：之前的方法把整个harness当作一个整体去重写,不同机制互相缠绕难以单独验证,好的局部改进也容易在下一轮重写中被覆盖丢失。PluginRSI把各个机制拆成独立插件,能单独测试、单独保留,挖到的好东西会被存进共享库里持续积累,不会因为后续整体改写而丢失。

Q3：PluginRSI优化出来的harness换到别的模型上还好用吗？

A：论文实验显示效果基本能保持。比如用GPT-5.6 Terra优化出的harness直接套到Kimi-K3和GLM-5.2上,没见过的任务解决率依然比这两个模型各自单独优化的方案高出好几个百分点,说明挖出来的改进多是通用层面的机制优化,不依赖具体某个模型。