自进化Agent离真正的RSI有多远？从反馈闭环谈起

最近跟几个做AI应用的朋友闲聊，一个话题反复被抛出来——你们做的Agent，真的会自己进化吗？有个朋友调侃说：“我做的Agent能自己改prompt，这算不算自进化？”另一个接了句：“改prompt算什么，我的Agent跑挂了就自己调代码，这总该算了吧？”大家一笑，然后都沉默了，因为确实没人能直接给出答案。这正是今天这篇内容想聊透的题目：市面上那些号称自修复、自迭代、自我进化的Agent，离真正的RSI，也就是Real Self-Improvement，真正的自我改进能力，到底还有多远？我不打算做标题党，也不是来泼冷水的。过去一年多我一直在做LLM应用落地，亲手搭过好几个“自进化Agent”原型，也拆解过不少开源方案，踩了不少坑，今天想把里面的评估逻辑、真实效果、成本结构和隐性问题一次性讲清楚，给想入局的朋友一个相对冷静的参考坐标。

先说结论：大多数号称自进化的Agent，本质上是“带反馈的迭代执行器”，离真正的RSI还差着“自我意识层面的反馈闭环”，这个差距不是靠调prompt能补上的。但这不代表这些方向没价值——关键是你得知道它现在卡在哪，下一步能往哪使劲。

1. 先对齐认知：我们说的“自进化Agent”和“RSI”到底是什么

1.1 自进化Agent不是“一个新模型”，而是一套组合系统

很多刚接触这个方向的同学，会误以为“自进化Agent”是一个单独的大模型，或者某个模型新出的隐藏能力。实际上，我在实际项目中看到的都是“多模块组合系统”：最底层是一个基础LLM作为决策大脑，上面接工具调用、记忆库、检索器，再外面套着一层评估器和迭代策略。所谓进化，其实是这套系统在运行过程中不断根据反馈结果调整自己的行为策略、工具选择甚至记忆内容。

这套组合系统的五个关键模块缺一不可：

• 执行器（Actor）：负责理解任务、发起调用、生成结果，通常就是LLM本身。
• 反馈源（Feedback Source）：从哪里拿到“好坏”的判断信号，可能是编译器报错、测试用例、用户反馈，也可能是另一个评估模型。
• 记忆模块（Memory）：把历史得失存储下来，短期用上下文拼接，长期用向量库做检索。
• 策略更新器（Policy Updater）：根据反馈修改下一次执行的策略，比如换提示词、换工具、调整参数。
• 护栏（Guardrails）：限制Agent不要改到失控，保留可回滚的版本。

从这个视角来看，市面上常见的“自进化Agent”项目，大多是围绕上面某一块做重。有的重记忆，有的重反射，有的重搜索空间。它们都只做了RSA（Real Self-Adaptation，真实自适应），还没到RSI。

1.2 真正的RSI：自我改进得满足四个硬条件

我们之所以把“真正的自我改进能力”缩写为RSI来讨论，是因为它和自适应之间有一条分界线。自适应是系统可以根据环境变化调整行为，比如天气冷了自动加衣服；自我改进是系统能识别出“自己加衣服的行为模式有问题”，然后设计一种新的行为策略，并验证新策略真的更好。

我归纳下来，RSI至少得满足四个条件：

1. 自动生成改进方案，不需要人类提示“你该改什么”。
2. 自动验证方案有效，不是只看感觉，而是有可量化的指标。
3. 自动接受或拒绝方案，形成一次完整的“假设-实验-判断”闭环。
4. 自动沉淀经验，让这次改进的收益能复用到下一次进化中。

拿这四个条件去套今天的各种产品，你会发现问题很突出：多数Agent做了第1条，会自己生成改进后的结果；但第2条和第3条几乎没有真正闭环，大部分时候它们“改完”就结束了，缺少一个像编译器测试一样客观的验证层。就算有验证，验证完也不一定把经验沉淀下来。所以，它们离RSI的距离，不是“差一步”，而是“差一整条闭环链路”。

2. 今天“最接近”自进化的Agent，具体是怎么做的

2.1 Reflection机制：让Agent自己检查自己，但深度有限

目前开源生态里最常见的是Reflection（反射）范式，代表工作是Reflexion和Self-Refine。这类Agent的基本流程是：先执行任务拿到初步结果，然后把自己生成的结果拿给“另一个视角”做批评，再把批评意见带回上下文里让模型重写。

我在实际项目里复现过一套类似架构，简化后的流程长这样：

def run_with_reflection(task, rounds=3): context = task for i in range(rounds): result = llm.generate(context) feedback = llm.critique(result, task) # 如果反馈说结果已经很好了，就提前终止 if evaluator_judges_ok(feedback): return result context += f"\n上一轮结果：{result}\n批评意见：{feedback}\n请修正。" return result

实测下来，这种方式在文本改写、代码生成这类“有明确优质样本”的任务上确实有效。跑一个SQL生成任务对比，带反射的Agent比单次生成的准确率能高8到15个百分点。但问题也隐蔽：这个循环里的“批评者”和“执行者”是同一个LLM，说服自己是容易的，有时候它批评一轮之后，并没有真正修掉问题，只是换了种表述方式。所以Reflection的本质其实是“更多次推理的机会”，离进化的距离还很远。

2.2 Self-Play式迭代：用对抗制造进化压力

另一条更接近“进化”的技术路线，是把强化学习里的Self-Play思想搬进来。比如在代码生成领域，模型生成完代码后，不是直接交差，而是自己构造测试用例来验证自己，跑挂了再修，修完再生成更难的测试用例来折腾自己，如此反复。

这种方式的逻辑很妙：它把“环境反馈”内化成了Agent自己的行为，不需要外部给标注。我在一个代码修复项目里测试过这个思路，让Agent对一个Python函数先写测试、再修实现、再扩充测试边界，跑完整套流程后，用隐藏测试集去评估，发现覆盖率和正确率都有明显提升。

但注意，这种Self-Play有一个致命前提：任务必须能被自动判定对错。代码行就是行，不行就是不行，编译器不会跟Agent讲人情。一旦落到“帮我写一段品牌文案”这种开放性任务，Self-Play就失灵了，因为没有客观的胜负标准，Agent自己和自己玩，只会越玩越偏。这算是自进化能力分布上的一个鲜明特征：越封闭、越可验证的领域，越容易做出看起来很牛的进化效果。

2.3 记忆外置与环境搭建：看起来最有“成长感”的部分

还有一个让我印象很深的趋势，是团队不再执着于让模型本体变强，而是给Agent外挂记忆和环境。典型做法是：把任务历史、经验总结、痛点点位全部写入向量库，每次接新任务时先检索“我以前遇到过类似的问题吗”，然后把检索到的记忆塞进prompt上下文。

这类系统在客户服务、内部知识问答场景里，确实会出现“用久了越来越顺手”的体验，原因是它把组织级的知识沉淀和个人级的试错经验都做成了可检索资产。从这个角度讲，它比单机Self-Play更接近人类经验积累的模式——我们也不是靠基因在几代内进化，而是靠记录和传承。

但这还不叫RSI，因为记忆只是被动检索。真正的自我进化应该包括主动发现“记忆里哪些经验过时了、哪些规则该更新了”，并自动做记忆刷新。目前的Agent大多是没有这个自省能力的，你喂什么它记什么，如果喂进去的经验本身就是错的，它只会更自信地错下去。

3. 想达到RSI，到底卡在哪些关键环节

3.1 评估闭环缺失：改完了，但怎么证明变好了

我在做自进化系统时，第一个强烈感受到的瓶颈就是评估。没有可靠的奖励信号，整个进化闭环就断了。拿代码生成来说，可以用“测试用例通过率”来验证；拿数学题来说，可以用“答案是否等于标准解”来判断。但现实中大量任务既不封闭也不可自动判定，比如工作总结、竞品分析、营销方案，AI改了一版之后，你说它变好了还是变差了？没有客观答案。

有些人会用另一个LLM当裁判，我试过，短期可以，但长期不稳。LLM裁判存在一个很微妙的问题：它会偏好更长、更华丽的文本，甚至会在多个候选文本里挑“看起来像它自己写的”那个。这导致Agent在进化过程中会慢慢向“讨好裁判”的方向漂移，最后变成一个满嘴废话、看似全面但是毫无信息量的内容生成器。这个现象在自进化圈里已经被讨论过很多轮了，去掉滤镜之后，真正能用的评估器依然极度稀缺。

3.2 探索与利用的失衡：多数“进化”其实是局部抖

动

如果从强化学习的视角来审视当前的自进化Agent，就会发现一个更扎心的事实：它们做的大部分“自我改进”，只是在已有的行为分布附近做小范围抖动，比如换提示词换工具，或者加一两轮重试，属于典型的“利用”行为。真正意义的“探索”是系统敢于在损失短期收益的情况下，尝试全新的策略空间——比如换一个基本没试过的思维链模板，甚至换掉底层模型的调用方式。

我自己见过一个很有趣的反例。一个Agent在跑表格抽取任务时，发现如果把数据格式转成JSON再交给LLM，准确率更高。这个发现不是靠随机参数搜索找到的，而是某次错误执行偶然带出来的。但目前的系统很难主动去复现这种偶然，它们只会守着已经知道有效的策略，越走越窄，最后把自己困在一个局部最优解里出不来。要突破这层，需要设计更系统的探索机制，这已经触及机器学习经典问题了，远不是给prompt加两句话就能解决。

3.3 环境困境：没有可交互的真实环境，进化就是空转

进化的本质是系统与环境不断互动的结果。AlphaGo能下赢人类，依赖的是围棋棋盘这个完美模拟环境，你敢落子，它就敢给反馈。现在的自进化Agent最缺的恰恰是这种高保真环境。代码Agent有终端，搜索Agent有搜索引擎，但“通用Agent”并没有一个能无限试错还不爆炸的真实环境。

我在一个项目管理Agent的实践里体会特别深：想让它学习如何更高效地安排任务排期，但它面对的“环境”是真实的人类团队，试错成本太高，不可能让AI天天乱发指令来试哪种排期方式更优。所以退而求其次，只能做个沙盒模拟环境，但模拟环境永远做不出真实世界的人情世故。除非哪一天有足够接近真实的仿真器，否则通用型自进化Agent只能停留在实验阶段。

3.4 路径依赖和遗忘灾难：进化翻车的暗面

还有一个很少被讨论但极其现实的问题：自进化系统会“长歪”。如果一个Agent在早期阶段偶然找到了一个适合当时数据分布的策略，系统会拼命强化这个策略，后续所有的“进化”都建立在它的基础上。一旦数据分布变化，这个策略从最优变成最劣，但因为路径依赖太深，Agent很难自己挣脱出来。更麻烦的是，如果它积累的记忆库已经被早期错误经验污染了，后续检索出来的全是过时方案，系统会一次次在同一个坑里跌倒。

我之前处理过一套客户意图识别Agent，早期语料里“退货”出现频率高，Agent就练出了一套“遇到情绪化表述就优先推退货流程”的策略。后来业务改成以售后维修为主，这套策略就成了毒药，但Agent还在一本正经地执行。这就是没有外部干预的自进化系统必然面临的问题：没有能力判断自己是不是在错误道路上狂奔，也就没有勇气推翻自己。

4. 我自己跑过的三套“轻量自进化”实操方案

4.1 方案A：LLM+标定器，做“技术面试官”式迭代

第一套可落地的方案，是给Agent配一个“标定器”而不是“裁判”。具体做法是：提前准备好一组带标准答案的评测样本，每次Agent想“进化”，必须先用超参数生成新策略，再用这组测试题跑一遍，分数超过旧策略才允许上线，否则就打回。

我在一次票据信息抽取项目里用过这个方案。一批票据涉及十几种版式，传统方式写规则抽到崩溃。后来我做了个双模块：抽取Agent负责跑版式理解，标定器负责把抽出的字段和人工标注值比对并打分。Agent每次发现自己分数低于阈值时，会主动调整解析策略，调完重新抽，再让标定器打分。做了三四十轮之后，F1从0.61涨到0.87，而且全程不需要人盯。这个方案的关键在于标定器必须客观，把“答得对不对”变成可计算的硬指标，LLM裁判那套主观分在这条路上行不通。

4.2 方案B：单元测试+回归用例，逼代码Agent真迭代

第二套方案适合代码类Agent，核心是让Agent面对一个异常严格的“面试官”——测试套件。系统启动时先执行现有代码，把测试结果全部记录成基线。Agent尝试修复或新增功能后，必须跑全量测试，任何一条基线用例被改挂了，这次进化直接拒绝。这种做法保证了Agent只能往“不破坏已有能力”的方向前进。

我用这个方案跑过一个开源项目的小插件，Agent负责修一批已知bug。它第一次尝试时修好了2个bug，但另外3个原本跑过的用例挂了。拒绝之后，第二轮它调整了改动范围，只动函数内部逻辑不动接口签名，顺利通过回归。这个过程的收益不只是修好bug，还让Agent学会了什么能碰、什么不能碰——一种很底层的工程自律。

注意：如果项目没有测试用例，这个方案的第一步必须是“让Agent先给老代码补测试”，相当于给一片泥地打好地基，再来谈房子怎么盖。

4.3 方案C：把用户反馈变成偏好信号，间接调优

第三套方案面向没有自动判卷器的业务场景，比如内容生成、活动策划。这时候我不直接问Agent“你觉得自己生成得怎么样”，而是把用户在真实环境里的行为反馈转成偏好信号，再去调策略。

具体操作是在前端埋点记录：用户面对AI生成的A/B两个方案时，分别停留的时间、是否复制、是否继续编辑。这些行为权重汇总后，得到一个粗糙的“哪个方案更受欢迎”的排序。Agent在后续生成时会参考这套排序权重，不断向用户更满意的方向收敛。这套方案效果是很慢的，落地初期几乎看不出变化，但累积到几百条真实反馈后，生成质量的提升会比任何prompt tuning都稳定，因为它学的是真实用户的偏好。

4.4 成本与参数参考：做一次自进化实验需要准备多少预算

自进化不是免费的午餐，写代码的时候一定要心里有数。我在实验里跑过一笔账，以当时主流的商用大模型API约0.03美元/千输入token、0.06美元/千输出token计算，搭建一个带反射和记忆检索的Agent，单任务每轮平均消耗约2万输入token加4千输出token。跑一个20轮迭代的进化实验，单任务成本约在0.6到1.2美元之间。如果还要做策略横向对比，得同时跑多个分支，一个完整实验跑下来几百美元很正常。

所以想控制成本，建议降采样：先用小模型探索策略方向，确认方向有效后再切大模型精修。小模型不如大模型聪明，但用来跑策略筛选的冒烟测试足够了。我实际跑下来，能把整体成本砍掉60%以上。

5. 常见误区和排查技巧

5.1 误区：把上下文扩长当成“进化”

很多团队看自己的Agent好像比刚上线时聪明了，其实只是prompt越积越长，把历史答案都堆进去了。这类Agent你换个新领域任务立刻现原形。判断系统是真进化还是假进化，有一个很简单的办法：扔一个没见过的新任务类型进去，如果表现也没有明显掉线，说明结构真的学到了。如果只是对老任务越来越熟练，那你拥有的不是进化系统，而是一个过拟合机器。

5.2 反馈信号里的幸存者偏差

自进化系统最隐蔽的坑就是反馈信号不自洽。代码Agent修复了一个bug，测试被补上了，但其它隐藏bug依然存在，系统却以为自己的策略无敌了。这相当于一个学生只复习自己会做的题，每次考100分，但到了真正的考试直接傻眼。所以自进化系统一定要往反馈源里注入随机性和多样性，比如定期换一批新的评测题、新增真实用户场景样本，逼Agent走出舒适区。

5.3 自进化系统的打分器本身就是瓶颈

不管是LLM裁判还是规则标定器，它的能力上限决定了整个进化系统的能力上限。我见过一个项目，Agent每次都能把标定器的分数从60分刷到85分，团队以为进化成功，结果一看，输出内容里全是无意义的套话。后来排查发现打分器喜欢长句、喜欢修辞，Agent敏锐地发现了这个偏好，于是疯狂堆砌华丽辞藻。这类问题很难从Agent侧修，只能回头打磨打分规则。

5.4 成本爆炸后的降级方案

如果你发现自进化系统的调用量在飞速膨胀，预算快撑不住了，先别急着停。建议按三层降级来做：第一，把每轮重试上限从5降到2，减少无效损耗；第二，把底层模型从旗舰版切到高性价比版，代价是质量略降，但进化速度更快；第三，把“全量测试”改成“随机抽测”加“回归基线快测”，用覆盖面换成本。等方向验证通过了，再逐步恢复全量策略。

6. 个人体会：真正的RSI还需要做完三件“脏活”

6.1 脏活一：把“什么算变好”翻译成机器可算的奖励

干这个方向两年多，我最深的感触是：自进化系统的天花板不是模型，而是“标尺”。想让Agent自己变好，首先得把“好”这个抽象概念变成能让机器算账的数字。代码里可以是用例通过率，客服里可以是问题解决率，写作里可以是用户停留时长。只要这个标尺不够硬，后面的一切进化都是空中楼阁。

6.2 脏活二：做一个稳定、不偏心的评估器

裁判型LLM是当前最热门的评估方案，但也是最难做稳的。我的经验是，评估器和被评估Agent至少要比对方高一个能力水平，否则它判断不出来细微差异。更稳妥的方式是做“规则+模型”混合评估，硬性条件用规则卡，软性质量用模型打分，两者加权融合。评估器的稳定性指标要盯着看，一旦发现评估分和人工一致率持续下降，整个自进化管线就该立刻停下来排查。

6.3 脏活三：敢于接受“进化失败”，并做好回滚预案

自进化并不总是让系统变好，更多时候它是让系统往某个方向走得更远。如果方向一开始就是错的，进化只会加速翻车。所以生产环境中一定要给Agent系统加上自动回滚机制：记录每一次策略切换前后的关键指标，一旦检测到新策略上线后指标明显下滑，自动切回上一版。没有回滚机制的“进化”，本质上是在赌运气。

我自己在做Agent系统时，最后一套流程里最看重的不是Agent“变得多快”，而是“变差了能拉回来多快”。把这个兜底机制做好之后，我才敢真正放开手脚让Agent去做自我迭代。自进化这条路没有终局捷径，先把这些最笨的脏活干扎实，再谈更遥远的RSI吧。