Self-Improving Agent技术路线与落地实践:从模型自进化到生命周期学习

发布时间:2026/9/9 8:54:24
Self-Improving Agent技术路线与落地实践:从模型自进化到生命周期学习 前一阵子密集读了两篇关于 Self-Improving Agent 的综述文章不是翻目录式快读而是一行行标注、来回对照着看的那种读法。读完最大的感受是这个方向的论文已经多到必须靠综述来整理脉络但如果你只是零散刷论文很容易被各种名字绕晕——Self-Instruct、Reflexion、SPIN、Voyager、ExpeL、RLAIF……它们其实都在回答同一个问题一个 Agent 能不能不用人标数据靠自己的经验越用越好这就是 Self-Improving Agent 的核心命题。这篇文章打算把两篇综述的读法、核心分类、关键技术点和实践落地经验一次性理清楚。适合两类读者一类是刚接触 Agent 方向、想快速建立全景认知的同学另一类是自己已经在搭 Agent 流程、想让系统具备自我改进能力的工程师。看完你至少能回答三个问题Self-Improving Agent 的组成模块是什么最常用的技术路线有哪些以及如果自己要动手搭一个最小闭环应该从哪里开始。1. Self-Improving Agent 到底在解决什么问题为什么突然这么热1.1 一句话定义不靠人工标注Agent 从自己的经验里变强传统 Agent 是静态的。Prompt 写好后模型参数固定工具调用逻辑固定它每次执行任务都在消耗工程师预置的能力不会因为做过一次任务就变得更好。Self-Improving Agent 要打破的就是这件事它把经验变成可被利用的资产在完成任务的过程中收集数据、获得反馈、沉淀记忆再通过这些反馈来更新自己的策略、技能甚至模型权重。换句话说它把开发-部署-失效-重新开发的循环压缩成了部署-执行-改进-再执行的自动化循环。为什么这件事突然变得可行核心是两个能力被大模型解锁了。第一LLM 本身能生成大量多样化数据解决了数据从哪来的问题第二LLM 可以做裁判解决了谁来判断好坏的问题。以前要做强化学习或者迭代训练得请人工标注成千上万条偏好数据成本高、周期长。现在大模型可以自己生成候选答案再自己打分、自评、过滤然后用过滤后的数据继续训练自己。这就是 Self-Improving Agent 在工程上能够跑起来的最底层原因。1.2 理解自改进前先分清三件事我读第一遍综述时被绕晕是因为没分清三件容易被混在一起的事改进什么、反馈从哪来、用什么机制更新。改进什么决定了整个系统的设计粒度。可以改进模型权重那是传统训练路线可以改进 Prompt 和上下文策略成本极低也可以改进外部记忆库和技能库让 Agent 在跨任务时积累可复用的能力。反馈从哪来更是关键维度自生成数据里的隐性偏好算反馈环境里的可执行结果比如代码跑通没跑通、工具返回报错没报错也是反馈多 Agent 互相评审还是反馈。最后是更新机制是走梯度更新的 SFT/DPO还是走上下文注入的 Reflection或者写外部记忆库三种路线的成本、速度和稳定性差别非常大。这两篇综述最值钱的地方是各自给出了一套分类法把几十种方法归置到这几个维度下面。你把两套分类法对照着看这个方向的整体地图基本就清楚了。2. 两篇综述两种切法从模型侧和从 Agent 侧怎么看自改进2.1 第一篇综述模型侧的自进化核心是数据-奖励-训练循环第一篇综述的主线是从模型能力切入的它把自改进理解成一个大模型自我进化的过程。作者沿着数据生成-评估反馈-训练机制-推理增强这条链做分类我按这个框架把它提到的核心方法归了归类。数据生成类方法最典型的是 Self-Instruct先用一小批种子指令让模型生成大量候选指令再过滤清洗拿这批数据反哺训练。评估反馈这条路主流做法有 RLAIF用 AI 反馈代替人类反馈和 Self-Rewarding LM——模型既生成答案又给自己的答案打分再把打分结果做成偏好对去训练。训练机制这边SPIN 是让当前模型生成数据、再由下一版模型踩着上一版的输出往前走把训练变成了模型和自己对弈的过程。推理增强类则更像免训练优化Reflexion 就是典型模型每失败一次把失败原因写成反思文本下一轮带着反思再试。这类综述给人的整体印象是自改进被抽象成了一条自我造数据、自我评价、自我训练的流水线。好处是方法论统一很多方法可以跨任务复用代价是它不太关心 Agent 在真实环境里长长的交互轨迹大部分工作都集中在文本生成类任务上比如指令遵循、数学推理、代码生成。2.2 第二篇综述Agent 侧的生命周期学习核心是记忆-技能-环境第二篇综述的切法完全不一样。它不把讨论焦点放在模型权重怎么更新上而是把 Agent 看成一个在环境里长期存活的系统关注它如何在一生中积累经验。这篇综述把方法按 Agent 架构模块来分记忆模块、技能模块、规划模块、工具使用模块各自都可以被自我改进。记忆模块的代表是 ExpeL 这类经验学习框架Agent 把成功轨迹抽取成经验存入数据库新任务来了先检索相关经验再行动。技能模块最出名的案例是 Voyager它在游戏环境里不断把验证有效的操作序列抽象成技能函数存进技能库后边面对类似场景直接调用。规划模块的自改进则体现在任务拆解上比如 Agent 发现自己拆解的子任务顺序不对就在下一次规划时调整策略。工具使用模块更好理解Agent 调工具报错了能否从错误信息里学到正确用法这就是最朴素的自我改进。第二篇的关注点从模型变得更强转移到了Agent 在它的生命周期里变得更聪明。它更重视环境反馈和交互轨迹也更重视跨任务的经验复利。代价是这套框架非常重涉及记忆、检索、技能抽象、环境接口一堆工程问题很多方法还处在实验室阶段。2.3 两篇放在一起读共识和分歧都很明显我把两条路线的核心差异整理成了表格对照着看会非常直观对照维度第一篇模型侧自进化第二篇Agent 侧生命周期学习关注单元模型权重、推理策略记忆、技能库、规划策略、工具使用反馈来源自生成数据、模型自评为主环境反馈、工具返回、自我反思更新粒度往往跨大量样本做一轮训练单任务多次试错 跨任务长期积累时间尺度以训练周期为单位以任务与生命周期为单位典型方法Self-Instruct、RLAIF、SPIN、STARReflexion、Voyager、ExpeL、AgentTuning 路线主要风险数据坍缩、奖励黑客、评估虚高灾难性遗忘、技能迁移难、反馈稀疏两篇的共同结论三个第一可靠的评估器是自改进能否成立的关键不管你是自评还是用环境反馈裁判崩了一切都白搭第二要警惕生成数据的多样性坍缩模型如果只在自我重复的数据里打转几轮之后能力不升反降第三自改进带来的安全性和可控性问题被严重低估一个会自己改策略的 Agent行为漂移后谁能及时发现这是个悬而未决的大问题。分歧也很清楚。模型侧路线相信参数变强则 Agent 变强Agent 侧路线则强调能力沉淀在记忆、技能和流程里更可控、更可解释。这两条路线不是二选一实际做产品的人基本都是混合着用用记忆和反思做轻量在线改进用定期微调做重量离线升级。3. 自改进闭环的五块核心拼图缺一块都转不起来把两篇综述的方法论抽干了看任何 Self-Improving Agent 系统都逃不过这五块积木自生成数据、评估器、更新机制、记忆系统、环境和任务设计。下面逐个拆我把为什么这么做也一并说清楚。3.1 自生成数据种子质量决定天花板自改进的一切起点是模型自己造数据。Self-Instruct 的做法是准备几十条高质量种子指令让模型按这些种子的风格扩展出成千上万条新指令再自己采样回答。实操里最常见的坑是种子数据质量不行生成的指令和答案会迅速退化到一个很低的质量水平上而且这种退化是有累积效应的——第一轮生成的脏数据进入第二轮训练只会产生更脏的数据。所以我的建议是种子数据宁少勿滥。20 条精心设计、覆盖各个难度梯度的种子远好过 200 条随便凑的种子。生成时把随机性拉高。采样温度调到 0.8 以上多做几次采样再过滤而不是只生成一次就收。过滤不是走过场。用长度过滤、去重、困惑度过滤、自评过滤每层过滤都有自己的作用。这里最容易被忽视的是多样性。很多人只盯着生成数据的质量分结果几轮下来所有数据都长成相似的句式、相似的推理路径。自改进本质上是在一个由自己生成的数据分布上迭代如果这个分布迅速坍缩模型就会在窄分布里过度自信泛化能力反而下降。3.2 评估器整个闭环的裁判也是最容易崩的一环自改进闭环里谁来打分比怎么训重要得多。评估器选错后面全是白干。目前主流评估器有三类。第一类是程序化评估最典型的是代码任务里的单元测试、数学任务里校验最终答案这类评估最可靠但覆盖面窄。第二类是规则评估比如过滤非法格式、检查关键词、算分数区间简单直接但容易被钻空子。第三类是 LLM-as-judge让一个大模型当裁判给输出打分覆盖面最广但也是最容易出问题的一环。LLM 裁判的毛病我踩过的就有好几种它倾向于给自己的输出类型打高分self-preference bias倾向于给长答案打高分verbosity bias还会在连续打分几十条之后出现严重的分数漂移。应对办法也不复杂能上程序化校验的地方坚决用程序化校验LLM 裁判要多模型投票、盲评、随机打乱顺序最好再给一个对照样例做锚定。凡是评测标准写得含糊的任务判分结果基本都不可复用。3.3 更新机制梯度、上下文、记忆三种路线怎么选有了高质量数据和可靠评估接下来就是用什么方式更新自己。三条路线各有适用场景更新机制更新对象成本适用场景典型做法梯度更新模型权重高需要算力和数据工程离线批处理追求深度能力提升SFT、DPO、SPIN、RLVR上下文更新对话上下文低即时生效在线学习单次任务内快速试错Reflexion 反思笔记、注入新样例记忆写入外部记忆/技能库低但需要检索配合跨任务长期积累经验库、技能函数库选哪条路线本质上是成本和质量之间的取舍。梯度更新上限最高但你要凑一个批次的数据、要盯着训练防止坍缩、要设计验证集周期是小时到天级。上下文更新胜在快失败了下一次尝试立刻带上反思信息但知识只在上下文窗口里存活没法变成长期能力。记忆写入则像是中间路线经验被持久化到外部不占权重也不占上下文靠检索把相关经验调出来。我的经验是刚起步做自改进先别急着上权重训练。先用上下文反思 记忆写入把闭环跑通验证数据质量和评估器可靠再考虑把积累下来的高质量数据拿去微调。直接上梯度的坑是模型快速记住了自己上次的错答案在训练分布上表现飙升一换任务分布立刻打回原形。3.4 记忆系统跨任务经验如何沉淀两篇综述里第二篇对记忆的强调远超第一篇。原因很好理解一个 Agent 完成了任务 A如果经验只留在那次会话里任务 B 不会从中获得任何好处那这就算不上真正的自我改进只是单任务内修修补补。记忆系统要分两层来看。短期经验层存的是具体某次任务的轨迹、错误、反思粒度细、检索靠相似度长期技能层存的是抽象出来的可复用能力比如 Voyager 里的技能函数、ExpeL 里的跨任务经验总结。写入机制也比想象中讲究不是所有成功轨迹都值得存只存那些有信息增量的经验也不是所有反思都该入库入库前最好再做一次质量过滤。检索比写入更容易被忽略。经验库如果只管写不管读Agent 在新任务里检索不到相关经验等于白存。我见过不下三个项目死在记忆写了一堆但没人接得住上。检索策略至少要包含相似度阈值设置、过期策略、以及检索结果在 Prompt 里的排布方式这几项不调记忆写的越多反而越干扰主任务。3.5 环境和任务设计课程学习与自对弈的价值第五块拼图是任务层面的设计也是大部分文章最不重视、却最能拉开效果差距的部分。自改进的学习信号来自任务执行。如果任务永远是同一批 Prompt模型学到的是记忆而不是能力如果任务难度一开始就拉满模型永远失败反思积累不起来。所以不少系统性更强的研究工作会引入课程学习先易后难当前模型在某个难度区间达到阈值之后再推进到更难的任务。这跟人练题是一个道理全都是拔高题只会挫败基础题做对了要及时给甜头。还有一类设计叫自对弈AlphaGo 是这条路的祖师爷语言模型里的 SPIN 也是这个思路。自对弈的价值在于它让学习信号永远不枯竭——模型打败旧的自己要生成新数据新数据再训练出新模型理论上可以无限滚下去。但要清醒地认识到自对弈对评估器的要求极高评估一旦有偏向对弈就会往错误的方向无限加强。4. 从论文到实践5步搭一个最小可用的自改进循环综述读得再多不如动手跑一个最小闭环。我建议选代码生成或者数学推理这类自带程序化评估器的任务起步因为这类任务评估信号硬不依赖 LLM 裁判的主观判断最适合验证自改进这个机制本身是否成立。4.1 最小闭环的五步设计整体流程我固定成五步定任务和评估标准 - 准备种子数据集 - 让模型生成候选 - 评估和过滤 - 更新模型或写入记忆。跑完一轮之后用一块从未参与生成和评估的留出测试集来验证效果。选种子数据时我习惯按难度分成三档每档 10 到 20 条。训练集足量但不大避免过拟合到种子分布上。评估标准在开始之前就要写清楚代码任务就是单元测试用例数学任务就是最终答案校验规则和通过条件都要提前冻结。4.2 核心循环的伪代码与逐行解读下面这段伪代码是我每次搭自改进流程时的脚手架框架无关换成你最顺手的训练或编排框架都能落地# self_improve_loop.py —— 伪代码按需替换为实际框架调用 from statistics import mean def self_improvement_round( model, # 当前模型或 Agent 主流程 seed_prompts, # 经过难度分档的种子任务列表 judge, # 评估器程序化校验 / LLM judge update_fn, # 更新策略SFT/DPO 或写记忆库 num_samples8, temperature0.85, keep_ratio0.3, ): # 1. 候选生成每个种子任务采样多条保证多样性 candidates [] for prompt in seed_prompts: outputs model.generate(prompt, nnum_samples, temperaturetemperature) for out in outputs: candidates.append({prompt: prompt, response: out}) # 2. 评估打分优先走程序化评估否则用 judge for item in candidates: item[score] judge.score(item[prompt], item[response]) # 3. 过滤只保留高分段样本宁可少而精 candidates.sort(keylambda x: x[score], reverseTrue) kept candidates[: max(1, int(len(candidates) * keep_ratio))] # 4. 更新两条路线可二选一也可组合 update_fn.finetune([(k[prompt], k[response]) for k in kept]) # 路线 A权重更新 update_fn.write_memory([k for k in kept if k[score] threshold]) # 路线 B写经验库 return { kept: len(kept), avg_score: mean([k[score] for k in candidates]), } # 每轮结束之后务必用 held_out_test() 验证泛化而不是只看自评分数这段代码最核心的设计决策有三处。第一采样数拉高到 8偏低会把低质量输出漏进来第二过滤比例 keep_ratio 设在 0.3 左右高了质量没保证低了多样性受损第三评估和更新解耦评估器可以随时替换成更强版本不影响循环整体结构。4.3 怎么判断改进真的发生了自改进最迷惑人的地方在于训练集上的分数上升可能是假的。可能模型只是记住了正确答案的格式或者记住了种子数据里的特定模式换一批同分布但没见过的题又不行了。我的验证习惯是三件事。第一冻结一块留出测试集任何训练数据都碰不到它每轮结束都跑一遍记录分数曲线。第二除了准确率还要看多样性指标比如输出之间的相似度防止模型退化成复读机。第三做一个消融对比拿同样数量的随机数据做一轮普通训练和自改进循环做一轮训练对比如果差距不大说明自改进流程里某个环节出了问题不是流程本身有效。4.4 成本与数据管理的实操提醒自改进循环的隐性成本比想象中高。每个种子任务采样 8 条100 个种子任务就是 800 条生成再加上 LLM 裁判打分一轮下来 API 账单不低。我的处理办法是分批运行而不是一次性全量跑每批 20 个任务观察分数曲线稳定后再扩大LLM 裁判的调用尽量缓存同一个 Prompt 的同一次输出不要重复打分另外所有生成数据都要带版本号记录是哪一轮、哪个模型、什么温度下产生的没有元数据的自改进数据后期排查问题根本查不动。5. 实测中常见的6个坑以及排查思路实录自改进方向论文里写得都很美实际跑起来问题一个接一个。我把踩过和围观过的经典问题整理成速查表方便你直接对着排查。现象可能原因排查思路处理办法多轮训练后输出越来越单一生成数据多样性坍缩计算生成数据的相似性指标调高采样温度、扩充种子任务、引入外部负例LLM 裁判分数虚高和留出集成绩对不上裁判存在 self-preference / 长度偏差抽样人工复核打分记录换盲评、多模型投票、能程序化就程序化训练集分数涨留出集不涨甚至降数据污染 / 过拟合到训练分布检查训练数据是否泄漏进留出集训练与评估数据严格隔离扩大留出集难度更新之后旧能力明显退化灾难性遗忘对比更新前后在旧任务上的表现混合一部分旧数据回放或改用 LoRA 局部更新Agent 交互很长却只有最终成败信号反馈过于稀疏检查轨迹日志是否可以拆分子目标引入过程奖励按子目标完成度打分连续多轮改进幅度趋近于零系统到了能力天花板检查过滤后保留的数据量是否过少换更难的任务分布或升级评估器精度我想展开讲三个最典型的问题因为它们的排查链路比较长。第一个是数据坍缩。自改进数据是模型自己生成的如果过滤标准过分苛刻几轮之后幸存的数据只剩下最标准、最安全的那些样本多样性迅速流失。排查方法很直接把每轮保留数据抽 100 条出来算一下它们的 n-gram 重合度或者直接用 self-BLEU 这类指标。对策是在过滤阶段对低分但新颖的样本做额外保留给多样性一个保底。第二个是裁判和真实效果的背离。LLM 裁判打分高不代表能力真的提升。我经历过一个案例裁判给长答案高分模型在学习之后开始疯狂堆砌废话程序化指标没受影响但人工阅读体验极差。排查时要对比裁判分数和程序化指标一旦两者相关性掉下来优先怀疑裁判有系统性偏置而不是怀疑模型。第三个是反馈稀疏这在 Agent 类任务里尤其常见。长任务执行几十步只有最后一步告诉你成没成中间的反思根本无从写起。我的处理办法是在任务的中间节点埋日志每完成一个子目标就记录一次中间结果然后把中间结果也纳入评估范围。稀疏反馈是自改进落地到真实业务场景时最普遍的拦路虎这个坑躲不开只能靠工程手段摊薄。6. 最后聊几句读综述的个人心得这两篇综述我建议不要按顺序从头读到尾而是先读引言的分类框架图再跳到开放问题那一节最后才回来看具体方法。综述最大的价值不是罗列方法而是帮你建立一套坐标系。读的时候带着三个问题会高效得多这套分类法能否把我手里的业务问题放进去方法的评估设置跟我的真实场景差多远作者的边界条件有没有我忽略掉的东西我个人这两年做 Agent 工程最大的体会是不要一上来就追求完全自动化的自改进系统。先用最笨的方式把一个单任务的改进闭环跑通任务固定、评估固定、只改一个变量。等你亲眼看到训练曲线在第二轮第三轮确实因为自己造的数据而上涨再逐步放开任务范围、引入记忆、引入多反馈源。自改进的威力是逐步显现的但它的坑是跳着踩的。最后分享一个小技巧把两篇综述的参考文献表下载下来按被引次数排序挑前面的 30 篇精读你就等于同时拥有了两套精读课程。综述是别人的地图论文才是真正的地形两者配合着走这个方向你基本就不会迷路了。