Agent如何越用越强？中科院自动化所、美团等推出RSI综述
从 Prompt 优化到 Harness 进化，梳理 RSI 的发展趋势，用三个问题、七步生命周期，理解 Agent 如何把经验转化为持续改进。想象这样一个场景：一个编程 Agent 调用 API 时遇到报错，发现接口参数已经更新。经过几轮尝试，它终于修复了问题。但到了下一个任务，它还会不会犯同样的错误？这次修复能否沉
从 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 参数变更的例子，这七步分别承担什么作用？
Collect｜收集：保存任务、调用参数、接口报错和执行结果，为后续分析保留依据。
Evaluate｜评估：判断这次调用是否完成目标，识别失败结果与相关反馈。
Diagnose｜诊断：定位原因，例如已有指令仍在使用旧字段，并判断应修改哪些组件。
Abstract｜提炼：从具体错误中提炼可复用规则，例如「不同 API 版本需要使用不同字段」。
Update｜更新：将规则落实为候选 Prompt、Memory、Skill 或 Harness 修改。
Verify｜验证：测试新版调用能否成功，同时检查旧版合法调用是否仍然有效，排查回归问题。
Consolidate｜整合保留：选择有依据的修改，记录适用条件和版本信息，供后续任务及更新使用。
其中，Evaluate 评估已有执行，Verify 验证候选修改。前者帮助系统理解发生了什么，后者帮助判断改动是否有效。
七步为分析和设计更新闭环提供共同语言，具体系统可以合并、反复执行或省略部分环节。论文对 20 个更新闭环的比较，也展示了不同方法在诊断、验证和保留决策上的差异。
论文图 2｜四类组件与七步生命周期，以及保留经验对后续执行和改进的作用。
05 持续进化，难在后面的每一轮
随着 Agent 长期运行，经验会增加，任务、工具和模型也会变化。综述进一步指出了几个需要解决的问题。
首先是跨组件归因。一次工具调用失败，可能同时涉及过期记忆、缺失步骤和不完善的参数检查。系统需要判断各个组件的作用，确定是否应当协调更新。
其次是长期维护。今天有效的规则，可能在接口升级后失效；曾经有用的技能，可能逐渐与其他技能重复。持续进化需要处理合并、修订、退役和回滚，并付出相应的维护成本。
更关键的是独立验证。任务得分提高，可以说明某项更新在当前设置下有帮助。要进一步说明继承的经验让后续改进更有效，需要在相同起点、任务、反馈与计算预算下，对照有无这些经验时产生的后续修改，并用未参与候选筛选的任务检验效果。
从 Prompt 到 Harness，这篇综述展示了 Agent 从经验中改变自身的多种路径，也给出了比较这些路径的共同视角。
三个问题决定何时改、改哪里、如何改；七步生命周期则帮助追踪，一段经验如何成为能够被验证、复用和继续修订的系统组成部分。
Agent 能否持续进化，最终要看每一轮更新留下了什么，这些内容能否帮助后续任务，以及能否为下一轮改进提供更可靠的依据。
作者信息
第一署名单位：中国科学院自动化研究所（复杂系统认知与决策重点实验室范国梁课题组）。
第一作者：戴思齐，中国科学院自动化研究所复杂系统认知与决策重点实验室博士生。
共同第一作者、项目负责人：阮景晴，美团高级算法工程师。
通讯作者、项目负责人：张斌，中国科学院自动化研究所复杂系统认知与决策重点实验室助理研究员。
研究单位：中国科学院自动化研究所、美团、山东大学、华中科技大学、中国科学院计算技术研究所、理想汽车、中国人民大学、南洋理工大学、上海交通大学、中国科学院微电子研究所。
