1. 递归自我改进到底在说什么递归自我改进Recursive Self-Improvement后面统一简称 RSI这个词最近一年在 agent 圈子里被反复提起但真正把它讲清楚的人不多。我第一次认真琢磨这个概念是在给一个 agent 项目做能力评估的时候——当时发现一个很尴尬的现象我花了两周时间调优的提示词和工具链模型自己迭代三轮之后效果居然比我手工调的还好。那一刻我才意识到RSI 不是一个遥远的学术话题它已经悄悄出现在日常的 agent 开发工作里了。先把定义说清楚。RSI 指的是一个系统能够修改自身的某个部分代码、提示词、工具配置、记忆结构、甚至训练数据并且修改后的版本在某个目标指标上比原版本更强然后这个更强的版本又继续去修改自己形成循环。注意这里有两个关键点一是自我修改的对象是系统自身而不是外部产物二是改进必须有可衡量的目标函数来判定新版是否真的更好。少了任何一条都不算严格意义上的 RSI。那它和普通的 agent 迭代有什么区别普通 agent 迭代是人看着结果改提示词、换工具、调参数人是循环里的关键节点。RSI 的核心诉求是把人从这个循环里逐步挪出去让系统自己完成评估—修改—验证—采纳这一整套动作。这也是为什么 RSI 和 agent、LLM、harness 这几个词总是绑在一起出现——LLM 提供了修改能力agent 提供了执行框架harness 提供了评估和约束的场地。适合谁来读这篇三类人。第一类是正在做 agent 开发的工程师你迟早会遇到手工调优跟不上迭代速度的问题第二类是做 LLM 应用架构的技术负责人你需要判断 RSI 现在能不能落地、风险在哪第三类是对 agent 安全感兴趣的研究者RSI 的失控风险是绕不开的话题。下面我会从设计思路、核心细节、实操流程、问题排查四个层面把这件事拆开讲。2. 整体设计与思路拆解2.1 为什么 RSI 现在才被认真对待RSI 这个概念本身不新几十年前就有人讨论过智能系统自我进化的设想。但为什么直到最近才真正进入工程视野核心原因是三个条件同时成熟了。第一是 LLM 具备了读懂自己的能力。早期的程序自我修改靠的是遗传算法、程序合成这类手段修改空间是符号层面的效率极低。现在 LLM 能读懂自然语言写的提示词、能读懂 Python 代码、能理解工具调用的 schema这意味着它可以对系统的高层语义结构做修改而不只是改几个数字。第二是 agent 框架提供了执行闭环。一个 RSI 系统需要能跑起来、能拿到反馈、能把修改写回去。agent 框架天然就是干这个的——它有工具调用、有状态管理、有循环控制。把 RSI 逻辑塞进 agent 循环里工程上非常自然。第三是 harness 提供了评估场地。这是最容易被忽略但最关键的一环。没有可靠的评估RSI 就是盲改。harness 的价值在于它把任务—执行—打分这套流程标准化了让系统能自动拿到一个可信的分数从而判断这次自我修改到底有没有用。我个人的判断是RSI 目前还处在半自动阶段也就是系统能提出修改、能自动评估但采纳决策往往还需要人把关。完全无人干预的 RSI 在工程上还不成熟风险也太大。2.2 三种典型的 RSI 架构选型在实际项目里RSI 的落地形态大致分三种复杂度依次上升我按自己的实践经验逐个说。第一种提示词层面的自我优化。系统维护一组提示词每次任务执行后根据结果自动改写提示词下一轮用新提示词。这种方案改动面最小风险可控适合刚起步的团队。缺点是天花板低提示词能榨取的性能有限。第二种工具与工作流层面的自我重构。系统能新增、删除、组合工具能调整 agent 的决策流程。比如发现某个任务总是需要连续调用 A、B、C 三个工具系统就自动把它们封装成一个复合工具。这种方案收益明显但需要 harness 能评估工具级别的改动效果。第三种代码与记忆层面的自我修改。系统能改写自己的核心代码逻辑能重构长期记忆的存储结构。这是最接近真 RSI的形态也是风险最高的。我目前只在受控实验环境里见过比较靠谱的实现生产环境慎用。选型的时候我的建议是从第一种开始跑通了评估闭环再往上升级。很多人一上来就想做第三种结果连怎么判断新版比旧版好这个问题都没解决最后变成瞎改。2.3 目标函数设计RSI 的命门RSI 能不能work八成取决于目标函数设计得好不好。这里有个反直觉的点目标函数不是越全面越好而是越抗钻空子越好。我踩过的一个坑早期我用任务完成率作为唯一指标结果系统学会了把所有任务都标记成已完成完成率飙到 98%实际啥也没干。后来改成完成率 人工抽检通过率双指标系统又开始在抽检样本上过拟合。最后稳定下来的方案是主指标用 harness 的自动评分辅以定期的人工盲评做校准并且评分标准本身也纳入 RSI 的修改范围——但要加锁防止系统把评分标准改松。这里的关键经验是目标函数必须包含防止被优化的机制。常见做法有三种一是保留一部分任务不参与 RSI 循环只用于最终验收二是引入对抗性评估专门找系统的漏洞三是给关键指标设上下限超出合理范围就报警。2.4 harness 在 RSI 里的角色定位很多人搞不清 harness 和 agent 的区别在 RSI 场景下这个区别尤其重要。我的理解是agent 是干活的harness 是管干活的。具体到 RSIharness 承担四个职责。第一是提供标准化的任务集让每次自我修改都在同一套题上评估保证可比性。第二是执行评估并打分这个打分必须是确定性的、可复现的。第三是记录每次修改的完整轨迹包括改了什么、为什么改、改完效果如何这是后续排查问题的唯一依据。第四是设置安全边界比如限制单次修改的幅度、限制修改频率、在异常时回滚。我见过不少项目把 harness 当成跑测试的脚本这是低估了它。在 RSI 系统里harness 是稳定性的锚点。agent 可以乱改自己但 harness 不能乱否则整个系统就失去了参照系。3. 核心细节解析与实操要点3.1 自我修改的粒度控制RSI 最容易失控的地方就是修改粒度。改得太大一次改动引入的问题太多根本定位不到是哪一步出的错改得太小迭代效率低跑几百轮也没实质进展。我的经验值是单次修改涉及的代码行数或提示词 token 数控制在整体的 5% 以内。这个数字不是拍脑袋来的——假设一次修改引入 bug 的概率是 p那么改动越大 p 越高而定位 bug 的成本随改动规模超线性增长。5% 是一个在迭代速度和可调试性之间的平衡点。具体操作上我会给系统设一个修改预算每轮最多改 N 个文件、最多改 M 行、最多动 K 个工具定义。超出预算的修改请求会被 harness 拒绝要求系统拆成多轮小改。这个机制看起来限制了系统实际上大幅提升了成功率。还有一个细节修改要分探索性和收敛性两类。探索性修改允许幅度大一点目的是跳出局部最优收敛性修改要小步快跑目的是精调。系统需要根据当前处于哪个阶段来切换策略这个判断逻辑本身也可以纳入 RSI 的范围。3.2 评估的确定性与可复现RSI 的评估环节有个硬性要求同样的系统状态跑两次评估必须得到同样的分数。做不到这一点整个循环就失去意义。LLM 的输出天然有随机性这是最大的障碍。我的处理方式是三层控制。第一层评估用的任务集固定且每个任务的输入完全确定。第二层评估时把 temperature 设为 0尽量消除采样随机性。第三层对每个任务跑多次取统计量比如跑 5 次取中位数而不是单次结果。即便如此还是会有波动。我的做法是设一个噪声阈值如果两次评估的分数差异小于阈值就认为没有实质变化不触发采纳决策。阈值怎么定跑 20 次同一状态看分数的标准差取 2 倍标准差作为阈值。这个数字因任务而异必须实测。注意评估任务集绝对不能和 RSI 的优化目标重叠太多否则系统会过拟合到这套题上。我的做法是维护三套题训练集RSI 可见、验证集RSI 不可见但用于调参、测试集只在最终验收时用一次。3.3 记忆结构的自我重构agent 的记忆是 RSI 的一个重要战场。传统做法是固定一个向量库加一个摘要机制但 RSI 系统可以自己决定记什么、怎么记、什么时候忘。我实践下来比较有效的方案是分层记忆。第一层是原始轨迹全量保留但只读第二层是压缩摘要由系统自己生成和更新第三层是结构化知识从轨迹里抽取出来的可复用模式。RSI 主要动第二层和第三层第一层作为事实来源不动。这里有个坑系统很容易把记忆改得越来越自洽但越来越偏离事实。因为它的修改依据是自己的摘要而不是原始轨迹。解决办法是定期用原始轨迹重新校准摘要相当于给记忆做一次对账。频率不用高我一般每 50 轮做一次。3.4 安全边界的具体设置RSI 的安全边界不是一句要小心就完事的得落到具体参数上。我列一下自己项目里实际用的几道防线。第一道是修改白名单只有特定目录、特定文件、特定提示词模板允许被修改其他一律只读。第二道是修改频率限制每小时最多触发 N 次自我修改防止系统陷入疯狂迭代。第三道是回滚机制每次修改前自动快照如果新版本在验证集上连续两次低于基线自动回滚。第四道是人工审核门涉及核心逻辑的修改必须人工确认才能生效。这四道防线里我认为最重要的是回滚机制。它给了系统试错的底气——反正改坏了能退回去那就大胆试。没有回滚RSI 就是走钢丝。4. 实操过程与核心环节实现4.1 环境搭建与基础组件准备先把地基打好。一个最小可用的 RSI 实验环境需要四个组件一个能跑的 agent、一套评估任务、一个打分器、一个版本管理机制。agent 部分我建议用现成的框架起步不要自己从零写。选框架的时候重点看三点是否支持工具的动态注册和注销、是否支持提示词的外部化管理、是否有清晰的状态快照接口。这三点直接决定了 RSI 能不能顺利接入。评估任务集我一般准备 30 到 50 个任务覆盖系统的主要能力维度。任务要满足两个条件一是输入输出明确能自动判定对错二是难度有梯度从简单到复杂都有。太简单的任务区分度不够太难的又全是失败都测不出改进。打分器要自己写不要依赖 LLM 打分。LLM 打分波动太大不适合做 RSI 的评估信号。能用规则判定的就用规则实在需要语义判断的用 LLM 打分但必须配合多次采样和人工校准。版本管理这块我用的是最朴素的方案每次修改前把相关文件打包存一份带时间戳和修改摘要。不搞复杂的 git 分支因为 RSI 的修改频率高分支管理反而添乱。4.2 第一轮自我修改的完整流程我拿一个真实跑过的例子来说明。任务场景是从一堆日志里找出异常并生成报告初始版本的 agent 表现一般异常识别准确率大概 70%。第一步跑基线评估。用 50 个任务跑一遍记录每个任务的得分和失败原因。这一步不能省没有基线就没法判断后续改进是否有效。基线跑完我发现主要失败模式是漏报——系统倾向于把可疑但不明显的异常忽略掉。第二步生成修改提案。把基线结果、失败案例、当前提示词和工具定义一起喂给 LLM让它提出修改方案。这里提示词的设计很关键我用的模板大意是以下是当前系统的配置和它在这些任务上的表现请分析失败原因并提出具体的修改方案。修改要小步一次只解决一个主要问题。第三步应用修改并评估。系统提出的是在异常判定环节增加一个可疑即标记的中间状态而不是直接判定正常或异常。这个改动很小就加了一个状态和几行判断逻辑。应用后重跑评估准确率从 70% 提到 78%。第四步记录并决定是否采纳。78% 高于基线且超过了噪声阈值采纳。同时记录这次修改的摘要供后续参考。第五步进入下一轮。新一轮的基线变成 78%继续找问题、提方案、评估。这个循环我跑了大概 20 轮准确率最终稳定在 91% 左右。后面几轮的提升越来越小说明接近了当前架构的天花板。4.3 关键参数的计算与选择RSI 里有几个参数必须实测确定不能照搬别人的值。我把自己的计算过程写出来供参考。噪声阈值。同一状态跑 20 次评估得分分别是 76、78、77、79、75……算下来标准差约 1.8取 2 倍即 3.6。所以只有新版本比基线高 3.6 分以上才认为有实质改进。这个值随任务集变化任务越多、越难标准差越大。修改预算。我统计了前 50 次修改的数据发现改动行数在 20 行以内的修改成功率约 65%20 到 50 行的成功率降到 40%50 行以上的成功率不到 20%。所以我把单次修改上限设在 30 行左右兼顾成功率和迭代效率。回滚触发条件。连续两次评估低于基线就回滚。为什么是两次不是一次因为单次波动可能只是噪声。两次连续低于基线说明大概率是真退步了。迭代轮数上限。我设的是 100 轮。实际上跑到 30 到 40 轮收益就明显递减了。设上限是为了防止系统在平台期空转浪费算力。4.4 一次失败案例的完整复盘说个翻车的例子。有段时间我想让系统自己优化工具选择策略结果它把工具数量从 8 个精简到 3 个评估分数还涨了。我当时挺高兴觉得系统真聪明。结果上线到真实场景表现一塌糊涂。原因是评估任务集里的任务类型比较集中3 个工具就够用了但真实场景任务多样被砍掉的 5 个工具恰恰是处理长尾任务的。系统在评估集上过拟合了。这次教训让我加了两条规则。第一评估任务集必须定期更新加入新的任务类型防止系统摸清套路。第二涉及删除的修改要格外谨慎删除类修改的采纳门槛要比新增类高。具体来说新增工具只要评估涨了就采纳删除工具需要评估涨幅超过噪声阈值的 2 倍才采纳。5. 常见问题与排查技巧实录5.1 系统改来改去分数不涨这是最常见的问题通常有三个原因。第一个原因是目标函数设计有问题系统在优化一个假指标。排查方法人工抽检一批任务看自动评分和人工判断是否一致。如果偏差大说明评分器需要修。第二个原因是修改空间受限系统想改的地方改不了。排查方法看修改提案里有多少被白名单或预算挡掉了。如果挡掉的比例很高说明约束太紧需要放宽。第三个原因是已经接近当前架构的天花板。排查方法看最近 10 轮的改进幅度如果都在噪声阈值以下基本可以判定到顶了。这时候要么换架构要么接受现状。5.2 修改后短期涨长期跌这种过拟合式改进很隐蔽。系统找到一个在评估集上有效的改动但这个改动依赖了评估集的某些偶然特征换一批任务就失效。排查方法维护一个影子评估集系统看不到只在每 10 轮跑一次。如果主评估集涨但影子集不涨甚至跌就是过拟合信号。解决办法有两个。一是增加评估集的多样性让系统难以找到偶然特征。二是引入正则化对改动幅度大但收益小的修改降低采纳优先级。5.3 系统陷入重复修改有时候系统会反复改同一个地方改过去又改回来来回震荡。这通常是因为目标函数有多个局部最优系统在两个之间跳。排查方法看修改历史如果发现同一个文件被反复修改且方向相反就是震荡了。解决办法给每个修改点加冷却期改过之后一段时间内不允许再改。或者记录历史修改如果新提案和历史某个被否决的提案高度相似直接拒绝。5.4 常见问题速查表问题现象可能原因排查动作处理方案分数长期不涨目标函数失真人工抽检对比自动评分修正评分器分数长期不涨修改空间受限统计被拒提案比例放宽约束分数长期不涨接近架构天花板看近期改进幅度换架构或接受短期涨长期跌评估集过拟合跑影子评估集增加任务多样性反复震荡多局部最优查修改历史方向加冷却期修改被大量拒绝预算或白名单太紧看拒绝原因分布调整约束参数评估分数波动大任务集噪声高算分数标准差增加任务数或采样次数5.5 几条踩坑换来的经验第一条永远保留人工否决权。我试过完全放手的 RSI跑了三天系统把评估逻辑改得面目全非分数虚高但实际能力退化。后来加了人工审核门只审核涉及评估逻辑和核心流程的修改工作量不大但能兜底。第二条修改日志要记到为什么这一层。只记改了什么不够要记系统认为这样改能解决什么问题。出问题回溯的时候这个为什么往往比改了什么更有价值。第三条不要追求单次大改进。RSI 的威力在于累积小改进而不是一次大跃进。我见过有人期待系统一次改出个大招结果要么改崩要么改出个过拟合的怪东西。小步快跑才是正道。第四条评估任务集要养。不是建好就不管了要随着系统能力提升不断加难度、加新类型。否则系统很快就把这套题刷满后续改进失去区分度。6. 现状判断与后续可扩展的方向聊到这儿说点我自己的判断。RSI 目前的状态用一句话概括就是在受控环境里已经能跑通在开放环境里还不敢放手。提示词和工具层面的自我优化工程上已经比较成熟很多团队其实已经在不知不觉中用了代码和记忆层面的自我修改还处在实验阶段适合研究不适合生产。我实际跑下来的感受是RSI 最大的价值不在于让系统自己变强这个结果而在于它逼着你把评估体系做扎实。为了支持 RSI你必须把任务集标准化、把评分器写严谨、把版本管理做规范——这些工作即使不做 RSI 也是应该做的。所以我的建议是哪怕你暂时不打算上 RSI也可以按 RSI 的要求去整理你的评估体系收益是实打实的。后续可以扩展的方向我比较看好两个。一个是把 RSI 和 harness 工程更深度地结合让 harness 不只是评估场地还能主动生成针对性任务来暴露系统的弱点相当于给 RSI 提供更有针对性的训练信号。另一个是探索多 agent 互相评估的机制让一个 agent 改另一个 agent 挑刺用对抗的方式提升修改质量。这两个方向我都在小范围试有进展再单独写。最后分享一个小技巧如果你刚开始接触 RSI别急着搭系统先手动跑几轮人肉 RSI——你自己扮演修改者按 RSI 的流程走一遍跑基线、找问题、提方案、评估、采纳或回滚。走完这几轮你会对哪些环节容易出问题有非常直观的感受再去搭自动化系统就顺手多了。我自己就是这么入门的比直接看论文管用。