中科院自动化所与美团等发布RSI综述：Agent如何靠经验变强

从 Prompt 优化一路走到 Harness 进化，RSI 的发展脉络被重新梳理。要弄清 Agent 怎样把经验变成持续改进的能力，可以借助三个问题和七步生命周期。设想一个编程 Agent 在调用 API 时报错，它发现接口参数已经更新，试了几轮，问题终于修好。

可换成下一个任务，它还会不会再踩同一个坑？这回的修复能不能留下来，变成一条规则、一段记忆或者一项技能？碰上新的问题，以往的经验又能不能帮它更快定位原因、给出更管用的改法？这些疑问，恰好落在 Agent 递归自我改进（Recursive Self-Improvement，RSI）的研究范围内。

近日，中国科学院自动化研究所和美团牵头，联合山东大学、中国人民大学、中科院微电子所、上海交通大学、理想汽车等多家单位，发布了一份 LLM Agent 递归自我改进综述。论文标题为 When, Where, and How Experience Becomes Structure: Mechanisms for Recursive Self-Improvement in LLM Agents。

• 论文链接：https://openreview.net/forum?id=X8epsNeCZk

综述沿着 Prompt 优化、Memory 进化、Skill 进化和 Harness 进化四条主线，考察 Agent 借助交互经验改变自身的路径。研究团队挑出 40 项代表性工作，绘出研究全景，又对其中 20 项研究的具体更新闭环做了对照分析，把散落在不同方向的方法收进同一套框架：

该在什么时机动手改？改哪一部分？经验又怎样才能沉淀为可验证、能长期沿用的改进？

01 模型权重不动，Agent 照样能攒下本事

Agent 执行任务时会留下不少痕迹：工具调用的记录、执行的结果、用户的纠正，还有失败之后的修补过程。这些材料既能为下一次行动提供依据，也能用来改动 Agent 自身的某些组成部分。

比如，把一条反复被验证有效的约束写进 Prompt；把用户新给的信息存到 Memory；把跑通的操作流程整理成 Skill；再或者针对反复出现的失败，去调整 Harness 里的工具接口和检查逻辑。

即便执行任务的大模型权重一直没变，随着这些外部组件被更新，Agent 的行为也可能变好。综述重点讨论的正是这类机制，同时也分析了一部分结合模型训练的做法。

而「递归」又多提了一层要求：保留下来的经验和组件，要能参与后续修改的诊断、生成或筛选。比如上一次修复的记录，可以帮系统定位下一次失败；已经攒下的更新经验，也能帮它挑出更管用的修改策略。

研究问题因此又往前推了一步：不光要看 Agent 是不是更会完成任务，还要看它能不能更有效地改进自己。

02 三个问题，看清 Agent 自进化的要害

经验怎么变成长期管用的指令、记忆、流程和运行规则？论文围绕这一点提出三个彼此关联的问题。

When：什么时候更新，什么时候先不动？

任务失败、新信息到来、工具接口发生变化，都可能触发更新。不过一个修改值不值得留下，还得再查一查；它在后续任务里的表现，则决定是继续用、再改一遍，还是就此停用。

Where：毛病出在哪儿，该动哪个组件？

同一次失败，原因未必相同。可能是指令没讲明白，可能是信息过期了，也可能缺了操作步骤，或者运行机制本身就允许 Agent 跳过必要的检查。到底该改哪里，得拿执行证据说话。

这四类组件是按内容在执行中起的作用来划分的，彼此能配合着用。比如同一条 API 规则，写进指令也行，放进记忆里检索也行，封装成调用流程也行，还能变成调用前的参数校验。那么，经验里的修改怎么提炼出来，又怎么验证、怎么留下？这对应 How 这一环。

执行日志得先分析，才能变成适用范围清楚的规则或流程。候选的修改还要过效果检验：目标问题修没修好、原来会的能力有没有被影响，这些都要看，然后再定怎么并进后续运行。

论文图 1｜When、Where、How：经验如何成为 Agent 的结构。

03 四条进化主线，研究走到了哪一步？

四类组件给 Agent 提供了不一样的改进位置。顺着各自的脉络看下去，研究关注点从生成候选内容，慢慢扩到用反馈来修订、选择和长期维护。论文图 4｜Prompt、Memory、Skill 与 Harness 的代表性研究全景。

Prompt 优化：从搜索更好的指令，到改进指令的生成方式

围绕 Prompt 的优化，重心已经挪过三次。最早要回答的问题很直接：能不能自动找到一条比人写的更好的指令？早期做法是大量生成候选指令，放到任务上评测，留下得分最高的那版，说白了就是在指令空间里做搜索。

后来研究者意识到，光靠打分排序并不够。失败案例里的具体反馈如果能用上，修改指令会更有针对性。于是一类新方法出现了：先从错误中生成文字批评或梯度信号，再据此修订指令。反馈的来源也不再局限于简单的正确／错误，编译报错、执行轨迹这类更丰富的结构化信号都被纳入进来。

更新的进展把优化对象又推进了一层。优化的不只是「给任务 Agent 的指令」，还包括「负责生成指令的那个 Agent」自身的提示词——先让优化器学会怎样更好地改指令，再用这个改进过的优化器去提升目标 Agent。这条主线由此逐步深入两个层面：任务指令怎么变得更有效，以及产生新指令的方式怎么得到改进。

Memory 进化：从记住过去，到管理经验的有效性

Agent 与环境交互越多，积累的信息就越多，但并非所有信息都该被同等对待——记忆机制的演进回应的正是这个实际问题。

起初，记忆要解决的是容量问题：上下文窗口装不下全部历史，信息得存到外部，再按需取回。再往后，系统开始从成功和失败的经历中提炼可复用的经验规则，而不只是存原始记录。

记忆条目一多，新问题就冒出来了：信息之间可能互相矛盾，同一条事实也可能已经过期。比如用户搬家之后，配送任务该用新地址，可查询过去的居住信息时旧地址仍然需要。这就不只是覆盖旧记忆那么简单，而是要管理信息适用于谁、在什么时间有效。近期研究开始给记忆建立关联结构、标记时效、支持增删改查。

更进一步的问题是：一条记忆被检索出来，不代表它真的有用。最新工作尝试根据后续任务的实际反馈，动态调整对记忆效用的估计，让检索选择参考真实使用效果，而不是只看语义相似度。

走到这一步，Memory 的进化已经覆盖了内容、组织方式，以及经验如何被选中和使用。

Skill 进化：从复用一次成功，到维护一套可用的能力

Skill 的作用，是把经验整理成能够挑选、能够执行的操作流程。适用条件、输入、步骤、结果要求，一般都得写清楚，这样 Agent 遇到相似任务时才好复用。最早的做法很直接：Agent 做完一个任务，就把成功的操作序列存成一段可执行程序，下回碰到类似任务直接调出来用。这解决的是「如何复用一次成功」。

可技能库一旦用起来，麻烦就跟着来了。单项技能本身可能就不完善——少了某个步骤、没处理边界情况，或者环境一变就失效。近期的研究开始从成功和失败的执行轨迹里提炼修复建议，对已有技能持续修订。技能越积越多之后，系统还得应付重复、冲突和选择困难。一次失败，可能出在选错了技能，可能出在技能缺了关键步骤，也可能出在执行时跳过了步骤，这三种情况得分开诊断、分别处理。

于是有方法开始训练独立的技能管理者，让它专门学什么时候增加、修订或淘汰技能。还有研究用移除实验来判断某项技能是否仍在起作用：暂时把它删掉，再看表现怎么变。

说到底，Skill 进化既要管单项技能的质量，也要管整个技能库能不能一直保持可用。

Harness 进化：让 Agent 的运行框架也能接受反馈

Harness 是什么？可以把它看成组织模型、工具、上下文、执行状态和检查机制的运行框架。信息怎么进入模型、工具怎么被调用、出错之后怎么接着走、什么条件下才算可以交付结果，都由它决定。

已有研究显示，执行接口怎么设计，对 Agent 的行为影响很大——同一个模型换到不同的 Harness 下，表现可能差得很远。不过 Harness 向来靠工程师手工设计和调优。近期工作的关键进展是：把 Harness 本身也变成经验驱动的修改对象。

举个例子就很清楚：Agent 改完代码后如果经常跳过测试，系统可以在 Harness 里自动加一条完成检查——当前补丁对应的测试全部通过，才允许报告完成。这一步动的不是 Agent 的指令或记忆，而是它的运行规则。

要做到这一点，得形成闭环：从失败轨迹中提出针对性的 Harness 修改，用回归测试筛出候选方案，再依据后续轮次的实际效果决定保留还是回滚。更进一步，一些方法还把成功的修改经验存下来，供改进器在之后的修改中参考过去的有效策略。

这样一来，研究就从「改善任务执行的框架」，往「改善产生下一次修改的过程」又推进了一步。

04 七步生命周期，一次报错怎么变成能复用的改进？

论文把经验转化为更新的过程拆成七种分析功能，组合起来就是一套生命周期框架，用来对比不同方向的更新机制。

拿 API 参数变更这个例子来说，这七步各自起什么作用？

1. Collect｜收集：把任务、调用参数、接口报错和执行结果都存下来，给后面的分析留依据。Evaluate｜评估：看这次调用有没有达成目标，把失败结果和相应反馈挑出来。Diagnose｜诊断：找出原因，比如指令里还在用旧字段，同时判断该动哪些组件。

4. Abstract｜提炼：从具体错误里抽出一条能复用的规则，像「不同 API 版本要用不同字段」。Update｜更新：把规则落成候选的 Prompt、Memory、Skill 或 Harness 修改。Verify｜验证：试新版调用能不能成功，还要看旧版合法调用是否依然有效，排查回归问题。

7. Consolidate｜整合保留：挑出有依据的修改，记下适用条件和版本信息，留给后续任务和更新使用。

Evaluate 评估的是已有执行，Verify 验证的是候选修改。一个帮系统弄明白发生了什么，另一个帮它判断改动管不管用。

这七步给分析和设计更新闭环提供了共同语言，具体系统可以合并环节、反复执行，也可以省掉其中几步。论文比较了 20 个更新闭环，不同方法在诊断、验证和保留决策上的差别也由此显现。

论文图 2｜四类组件与七步生命周期，以及保留经验对后续执行和改进的作用。

05 持续进化，难在后面的每一轮

Agent 跑得越久，攒下的经验越多，任务、工具和模型也在变。综述接着点出了几个待解的问题。

头一个是跨组件归因。一次工具调用失败，可能同时牵扯过期记忆、缺失步骤和不够完善的参数检查，系统得弄清各组件各自起了什么作用，再决定要不要协调更新。

另一个是长期维护。眼下有效的规则，接口一升级可能就失效；曾经好用的技能，也可能慢慢和其他技能重复。要持续进化，就得处理合并、修订、退役和回滚，这些维护成本省不掉。

独立验证同样绕不开。任务分数涨了，只能证明这次改动在当前设定下行得通。要讲清楚继承来的经验确实让后面的改进更管用，就得在起点、任务、反馈和算力预算都一致的条件下，比较有这批经验和没这批经验时各自产生的后续修改，再拿没参与候选筛选的任务去测效果。

从 Prompt 到 Harness，该综述梳理出 Agent 借助经验改写自身的若干条路子，并给出一套能把这些路子放在一起比对的共同框架。

什么时候动手改、改哪个位置、怎么改，由三个问题划定；一段经验怎样变成可验证、可复用、还能接着修订的系统组件，则靠七步生命周期来跟踪。

Agent 能不能一直进化，说到底看每轮更新沉淀下了什么，这些东西能不能帮到后面的任务，又能不能给下一轮改进垫上更靠谱的依据。

作者信息

论文第一署名单位为中国科学院自动化研究所，具体为复杂系统认知与决策重点实验室范国梁课题组。

第一作者戴思齐，系中国科学院自动化研究所复杂系统认知与决策重点实验室博士生。

共同第一作者兼项目负责人阮景晴，为美团高级算法工程师。

通讯作者兼项目负责人张斌，任中国科学院自动化研究所复杂系统认知与决策重点实验室助理研究员。

参与单位包括中国科学院自动化研究所、美团、山东大学、华中科技大学、中国科学院计算技术研究所、理想汽车、中国人民大学、南洋理工大学、上海交通大学和中国科学院微电子研究所。