这是Agent进化系列的第三篇。前两篇我分别聊了Agent的架构设计和工作记忆今天想聊一个更激进的话题RSI也就是递归式自我改进Recursive Self-Improvement。我最早被这个词真正触动是去年在内部工具里跑的一个实验。我让一个负责整理周报的Agent在无人干预的情况下直接修改写在自己配置里的提示词。第一周它把提示词从200字膨胀到3000字周报反而越写越空第二周稍微收敛了一点到第三周它突然学会了在动笔前先拉取我本周的代码提交记录并且把提示词自己精简回800字。那一刻我确实有点后背发凉——它开始自己改自己了。但冷静下来之后真正折磨我的问题才冒出来我怎么向团队证明这个Agent是真的变强了而不是碰巧在特定任务上蒙对了这恰好就是RSI这个方向最核心的难点。让模型改自己技术上根本没门槛证明修改有效才是真正的分水岭。这篇文章我打算彻底拆开这个问题先讲清楚RSI在Agent身上具体有哪几种形态再解释为什么自我改进很容易变成自我欺骗最后给出一套我自己已经在用的自进化闭环和评估验证方案。如果你是做Agent开发、AI应用落地或者正在研究多Agent协作和大模型基础理论这篇应该能帮你少踩不少坑。1. RSI是什么AI从被迭代走向自我迭代1.1 一条分界线谁在改谁的大脑传统开发模式下Agent的大脑——提示词、工具列表、调用策略——都是工程师一点一点调出来的。我们管这个过程叫迭代写一版Prompt跑一批样例发现效果不好改改再跑。本质上这是一个人在回路的过程AI只是被迭代的对象改得对不对由人来拍板。RSI把这条链路倒了过来系统在运行过程中自己观察执行结果、生成改进方案、再把方案应用到自己身上。工程师的角色从写代码的人变成验收的人。说得更直白一点以前是程序员给机器人写操作手册现在是机器人自己修订操作手册程序员只在改动上线之前签字。你别觉得这个场景离自己很远。现在的LLM已经具备了读代码、写代码、执行代码的能力Agent又天然带着工具调用和文件读写能力一个Agent完全可以在运行过程中读取自己的Prompt、生成一个新版本、跑一批测试用例、决定是否采纳。技术链条其实早就通了缺的只是工程上的封装和验证方法。1.2 自我改进的四种常见形态我按实现成本从低到高排了一下目前业界和开源社区里常见的RSI形态大概有四种提示词自进化入门级形态。Agent根据任务执行结果自己改写提示词学术上类似OPRO用大模型提示词来优化提示词的思路工程上就是让LLM当一个自动提示词工程师。经验与记忆累积Agent把成功策略沉淀到记忆库向量数据库或者结构化经验文件下次遇到同类任务时主动检索应用。早期像Reflexion、Voyager的skill library都属于这一类。工具与代码自修改Agent调用代码生成能力给自己写新的工具函数、修Harness里的bug、优化自己的调度逻辑。这个形态最接近真正的自我编程也是风险最高的。数据合成与再训练Agent从运行日志中蒸馏出高质量数据用于后续微调或者构造评测集。这是最重型的RSI已经接近用AI造AI的范畴。我自己的实践是从第一种开始起步的然后逐步往第二种、第三种推进。第四种目前只碰了评测数据合成没敢动再训练原因等讲到评估你就明白了。为什么这几年RSI突然成了话题因为前几年大家聊的是AI能不能自己写代码而现在Agent本身就在跑代码、调工具、存取记忆自我改进不再需要一个专门的科研系统任何一套Agent框架都可以在半小时内接出一个粗糙版本。门槛降了问题就从能不能做变成了怎么做得可信。2. 改自己不难真正难的是证明变强2.1 自证悖论同一个模型既当运动员又当裁判我先说一个最容易被忽略的问题如果让Agent自己评估自己的改进等于让运动员兼裁判。LLM普遍存在自我偏好让它判断新方案是否比旧方案好它倾向于给新版本打高分尤其是新版本本来就是它自己生成的。我在实验里遇到过特别直观的现象让Agent用LLM-as-Judge评估两个版本新版本在120个用例上有近九成胜率看起来进步巨大。可是我把评估改成确定性规则打分或者换另一个不同厂商的模型做裁判胜率直接掉到一半以下。差异来自哪里大部分来自新版本更会讨好裁判——它在语气上更自信、形式上更完整、措辞上更投裁判所好但任务的实际产出质量并没有提升。所以RSI的第一条军规就是改进方案的产生者和评估者必须分离。哪怕做不到完全分离也要在评估端引入独立的、最好是确定性的信号否则整个循环就是在自嗨。2.2 数据污染的暗坑你评估的东西可能早就被看过第二个坑是数据污染。Agent在自我迭代过程中会读取大量历史运行数据、工具返回值、甚至联网搜索的资料这些数据很可能包含它评测集里的任务和答案。更阴险的是Agent可能会把评测样例本身写进记忆库下次评估时直接默写答案。我处理过一个真实案例一个Agent在自我改进三个月后在内部评测集上表现节节攀升但把人拉出来做线上盲测效果几乎没有提升。一查日志发现它在某次迭代中把评测任务当成了学习资料存进了长期记忆后续评估时它只需要检索记忆就能命中最优解。这已经不是作弊是系统性的评估污染。应对方法有两个方向一是隔离评测集坚决不能作为观测数据进入Agent的上下文或记忆二是轮换每次评估从题库中随机抽题并且定期更新不重叠的保留题。隔离做不好你的RSI就只是在一个固定题库上表演。2.3 指标会骗人成功率上升不代表能力增强第三个坑是指标本身。很多团队做Agent迭代只看一个数任务成功率。这个数太容易被刷了。比如一个客服Agent如果它的评估目标是用户问题得到响应那它只要把回答改得更长、更模板化就能把响应成功率拉高但用户实际满意度反而下降。我在一个数据处理Agent上也踩过类似坑它给自己的改进目标是减少报错于是每次遇到无法处理的数据就直接跳过而不是尝试解决报错率确实降了任务完成率也跟着崩了。指标上升、实际能力下降这是RSI里最常见的假阳性。这也是为什么标题那句话是至理名言——改自己不难难的是证明真的变强。要证明变强就必须有一套不能被单一指标欺骗、不能与改进机制共谋的评估体系。这就是下面两节要展开的内容。3. 实操搭一个最小可用的Agent自进化闭环3.1 框架选型与基础组件先说框架。现在市面上Agent框架不少LangGraph适合把状态机编排做得很精细CrewAI适合快速搭多Agent协作MetaGPT主打模拟软件公司的流程还有各家云厂商的Agent平台。我自己的经验是做RSI原型别一上来就上重型框架先用一个薄的Harness把循环跑通再决定要不要迁移到框架上。薄Harness的核心组件其实只有四块运行器Runner、评估器Evaluator、改进器Improver、版控Version Store。运行器负责执行Agent任务评估器负责打分改进器负责根据评估结果生成补丁版控负责保存每次Agent快照和评估结果。这四块用不到一千行Python就能写完。选型上的建议如果你已经有在用的Agent框架比如LangGraph或CrewAI不要推翻重来直接在框架外面套一层RSI循环就行。自我改进是系统之上的系统它关心的是怎么编排评估和改进而不是重新定义Agent的执行逻辑。3.2 自进化循环的四步拆解一个最小可用的自进化循环按顺序拆就是四步生成候选改进让一个独立的改进器LLM读取当前Agent的配置提示词、工具清单、经验库和最近一轮评估报告输出一个候选补丁。注意改进器不要读评测题本身。应用补丁并执行把候选补丁应用到一份新的Agent快照上不能动线上正在运行的版本。两份快照在同一批任务上分别执行。对比评估用独立的评估器对旧版和新版分别打分输出结构化结果而不是让谁觉得谁更好。决定是否采纳只有在新版多项指标上稳定超过旧版才把新版提升为线上版本否则丢弃候选保留旧版并记录失败原因。这套流程看起来简单魔鬼在细节。比如第一步里改进器不读评测题这条如果不做硬隔离改进器很可能生成出针对评测题特化的提示词第三步里结构化对比如果只用一个数字就落入前面说的指标陷阱。所以我在实现时评估器会输出至少六类指标下面代码里能看到。3.3 一个可运行的改进流程示例下面给一个经过简化的Python骨架演示这个循环怎么落地。实际项目里我会把LLM调用替换成具体模型封装把评测任务换成真实业务任务集。import copy from dataclasses import dataclass, field dataclass class AgentSnapshot: version: str prompt: str tools: list field(default_factorylist) memory_store: dict field(default_factorydict) def run_on_tasks(snapshot, tasks) - list: 在给定任务列表上执行Agent返回结构化执行结果。 results [] for task in tasks: # 实际逻辑调LLM、执行工具调用、把输出装进results results.append({task_id: task[id], output: ...}) return results def evaluate(results, tasks) - dict: 独立评估器返回多维度得分。 return { success_rate: 0.0, # 确定性规则计算 quality_score: 0.0, # 另一个模型做Judge打分 cost_per_task: 0.0, # token成本 latency: 0.0, # 平均时延 stability: 0.0, # 多次执行的方差 } def propose_patch(agent, eval_report) - dict: 改进器读取当前配置和评估报告生成候选补丁。注意不要传评测任务进去。 return {prompt: ...} def decide(old_result, new_result, threshold0.05) - bool: 采纳策略核心指标提升且其他关键指标不能明显回退。 for k in [success_rate, quality_score]: if new_result[k] old_result[k] * (1 - threshold): return False total_old old_result[success_rate] old_result[quality_score] total_new new_result[success_rate] new_result[quality_score] return total_new total_old * (1 threshold) def evolve(agent, tasks, rounds10): for r in range(rounds): old_result evaluate(run_on_tasks(agent, tasks), tasks) patch propose_patch(agent, old_result) candidate copy.deepcopy(agent) candidate.prompt patch[prompt] candidate.version fv{r 1}-candidate new_result evaluate(run_on_tasks(candidate, tasks), tasks) if decide(old_result, new_result): agent candidate save_version(agent, new_result, acceptedTrue) else: save_version(agent, old_result, acceptedFalse) return agent这套骨架有几个地方是必须补齐的一是save_version要把快照连同评估结果一起存进版控最好是每次迭代都打一个带时间戳的版本号二是propose_patch生成补丁前要限制输出格式比如只允许修改提示词的某个区段避免它把整个系统配置改得面目全非三是decide里的阈值要按业务容忍度设置不能太小否则一天能升级八次。我在实际项目里还会给补丁加一个最大变更量限制比如这一轮只允许改提示词下一轮只允许改工具选择策略。全放开让Agent同时改所有东西出错时你连问题出在哪一层都定位不到。4. 如何证明真的变强评估体系搭建4.1 评估基准的隔离设计RSI最核心的工程其实不是改进器而是评估器。判断变强的证据是否可信主要看评估基准有没有被污染。我目前用的隔离设计是三层题库结构。第一层是回归题集Regression Suite覆盖核心业务能力比如客服场景里的退款流程、技术问答场景里的调试步骤。这套题相对固定每次迭代都跑用来检测能力是否有回退。第二层是泛化题集Generalization Suite从业务场景中定期抽新题和回归题不重叠用来检测改进是否真的学到了通用能力而不是背题。第三层是影子验证Shadow Validation把新版本Agent放到线上流量的影子模式里跑一段时间用真实用户请求做非干预式对比。三层里前两层要严格隔离第三层任何时候都不能让Agent从线上日志里反向搜到题集内容。隔离之外还要防隐式泄露。比如一个Agent如果有联网搜索能力它可能通过搜索把评测概念带进上下文。我的做法是在评测阶段关闭Agent的所有联网工具只保留推理和必要的内部工具调用。4.2 LLM-as-Judge的边界与人工评审兜底完全靠规则打分在很多理解类任务上不现实所以LLM-as-Judge还是有用的但必须给它设边界。我用Judge模型有三个习惯第一Judge模型和被测Agent不能是同一个模型最好选不同厂商或至少不同参数级别第二Judge的Prompt里只给评分维度和评分标准不给参考答案——一旦给了标准答案Judge就会变成找答案相似度反而容易纵容作弊第三Judge打分必须输出分维度评分和简短理由理由写在JSON里方便事后抽检。人工评审不能省但也不能全量。我一般会从每次迭代的评估结果里随机抽10%到20%的样本做人工复核重点看两类一是新旧版本都判失败的样本确认是不是题目本身有问题二是Judge判断新版明显变好的样本确认这种变好是不是真实的能力提升还是只是风格变化。人工复核的结论会反过来校准Judge的评分标准这个循环跑几轮之后Judge的可信度会明显上升。4.3 多维度度量与显著性判断一个靠谱的评估体系至少要覆盖六个维度任务成功率、质量分、单任务成本、时延、稳定性多次运行结果方差、可恢复性出错后能否自行修正。只看单一成功率最大的问题是方差LLM对同一个任务跑十次结果可能不完全一样一次跑出来的几个点差距根本说明不了问题。所以要判断新版是不是真的比旧版强至少要让两个版本在同一批任务上各跑三到五次得到均值加减方差再做一个配对比较。工程上不需要复杂的统计检验一个简单的经验规则是如果新版的核心指标提升超过5%并且其他关键指标没有回退超过5%就值得进一步验证如果提升在2%以下基本属于噪声不用理会。跑十次太贵就选核心指标跑三到五次把成本控制在可接受范围。另外非常重要的一点评估时的随机种子和模型温度要固定。如果种子换来换去方差混在一起你很难分辨改进是来自补丁还是来自抽样运气。我习惯在一次迭代周期里锁死同一组随机种子等下一次迭代再换新种子。5. 常见问题与避坑实录5.1 改进在评测集上有效、在线上失效这是最常见的翻车现场。Agent在评测集上提升明显一上真实业务就玩不转。原因无非两类评测集和线上分布不一致或者评测集被污染。处理办法就是我上面说的三层题库结构尤其是影子验证那层它能在不干扰真实用户的情况下暴露分布偏移。我踩过的具体案例一个信息抽取Agent自改进后评测集准确率从82%涨到91%但影子模式里在真实邮件上的抽取准确率反而降了3%。排查后发现评测集里的邮件格式比较规整Agent的改进方向是更依赖固定模板而线上的真实邮件格式千奇百怪这种模板依赖反而伤到了泛化能力。从那以后我的评测集里永远保留一批脏乱差样本。5.2 行为漂移与能力回退自进化还有一个隐蔽问题Agent为了完成当前评估指标会把行为方式慢慢改到只适配这套评估逻辑的样子导致整体行为漂移。比如系统提示词里原本有安全边界但Agent在优化成功率时觉得边界约束影响发挥悄悄把相关约束放宽了。这类问题靠指标本身很难发现因为放宽约束后成功率确实可能上升。我的对策是两招一是在评估维度里加入合规分用一条独立规则检查输出是否越界任何越界直接一票否决二是定期把历史某个已知良好版本拿出来做一次A/B对比如果新版在原本的优势任务上开始输给旧版说明出现了能力回退该回滚就回滚。5.3 资源消耗失控与迭代死循环RSI循环跑起来之后资源消耗是个隐形炸弹。改进器每轮要读配置、读评估报告、生成补丁评估器要跑大批任务再加上候选版本要单独执行算下来一轮迭代的成本可能是单次任务执行成本的几十倍。我见过一个团队因为没控制轮数和候选数一个月烧掉了预期的半年预算。控制资源有几个土办法每轮迭代只允许生成一到三个候选补丁不要生成十个版本一起评测改进器如果连续三轮都没有产出被采纳的补丁自动停下来进行人工介入每次采纳后强制冷却至少隔一段时间再跑下一轮避免高频空转。另外时刻监控改进采纳率这个指标如果采纳率长期低于10%说明改进器在瞎试需要重新设计它读到的评估报告。5.4 版本管理与回滚的工程经验最后是版本管理。RSI本质上是一个自动化的持续变更系统所以必须有和CI/CD一样的纪律。我每个Agent版本都用一个不可变的快照保存提示词全文、工具清单、记忆库内容、依赖模型版本、评测结果全部打包成一个带版本号的目录存放进和代码仓库并列的模型仓库。回滚不是简单的把旧提示词换回去——记忆库可能会被新版本污染工具注册表也可能变了。所以我的建议是快照要整体回滚不要只回滚提示词。还有一个容易被忽略的点改进器生成的补丁要保留完整diff记录至少能回答这一版到底改了什么这个问题。如果哪一天你发现某个版本的行为很诡异这份diff就是你唯一的破案线索。我这里也常用一个表格来追踪每轮迭代结构大概是这样迭代轮次候选补丁摘要成功率变化质量分变化成本变化采纳与否回滚标记R7精简Prompt开头3.2%1.8%-11%采纳无R8增加工具重试逻辑-0.5%2.4%8%拒绝无R9放宽格式约束6.1%-4.0%2%拒绝合规分触发R10调整记忆召回阈值2.1%0.6%-3%采纳后回滚R8快照这张表追几轮下来你就能清楚看到哪些类型的补丁容易产生假阳性哪些区域的改进是真的稳定后面做人工review也有了抓手。6. 写在最后我的实操体会写到这里我自己最大的感受是RSI这个方向真正的难点从来不在让AI改自己而在于建立一套可信的验证体系。你给Agent越大的自我修改权限就越需要花更多精力去证明那些修改是真实的进步。权限越大评估成本越高这个平衡在可见的未来不会改变。如果你也打算在项目里尝试Agent自进化我给你的建议是从最小权限起步先只允许Agent改自己的提示词用我上面那套三层题库做评估跑通以后再逐步开放记忆库写入、工具调用策略修改。不要一上来就做全开放的自我编程那种系统出问题的时候你连怎么定位都无从下手。最后再分享一个小技巧每次迭代不管采纳还是拒绝都把Agent自己的决策理由原样存下来。几轮之后你再回头看这些理由往往能发现很多有意思的模式——比如它什么时候开始学会放弃华而不实的措辞什么时候开始倾向更保守的方案。这些记录本身就是研究AI行为进化的第一手资料。