1. 递归自我改进到底是什么为什么突然又被翻出来讨论递归自我改进Recursive Self-Improvement后面我统一叫 RSI这个概念其实不新鲜早在上世纪就有学者讨论过——一个系统如果能修改自己的代码或策略并且修改后的版本比原来更强那它下一轮就能改得更好如此循环理论上会进入一个加速上升的曲线。过去这东西更多停留在思想实验层面因为能自己改自己的系统根本不存在。但这两年情况变了大模型加上 agent 这套组合让系统能观察自己的输出、评估自己的表现、然后调整自己的行为这件事第一次变得工程上可落地。于是 RSI 从一个哲学话题变成了一个工程话题。我先把话说清楚现在业界说的 RSI绝大多数并不是模型自己重写自己的权重那种科幻场景而是围绕一个固定基座模型构建一套能自我评估、自我修正、自我迭代的 harness驾驭层/工程外壳。模型本身不动动的是它外面的那圈脚手架——提示词、工具调用逻辑、记忆结构、验证回路、失败重试策略。这个区分特别重要因为很多人一听到 RSI 就想到AI 自己进化然后要么过度恐慌要么过度兴奋其实都跑偏了。真正在发生的事是工程层面的自我改进循环而不是模型层面的自我进化。那为什么现在值得认真聊因为 agent 开发已经从能跑通一个 demo进入到要长期稳定运行的阶段。一个 agent 今天能完成任务不代表明天还能在一个任务上表现好不代表换一批输入还稳。要解决这个问题靠人工一条条调提示词已经跟不上了于是大家自然想到能不能让系统自己发现自己的问题、自己提出修改、自己验证修改有没有效这就是 RSI 在当下语境里的真实需求。它解决的核心问题是迭代速度——人工迭代一轮要几天自动迭代一轮可能只要几十分钟。这篇文章适合谁看如果你正在做 agent 开发、LLM 应用工程化、或者对 harness 这套东西有实际接触那这篇会对你有用。如果你只是听说过 RSI 这个词想搞明白它到底指什么也能看懂我会尽量用工程语言而不是论文语言来讲。下面我会从整体设计思路、核心机制拆解、可落地的实操流程、以及踩坑排查四个大块展开中间会穿插我自己在搭这类循环时的一些真实体会。2. 整体设计思路RSI 循环到底由哪几个环节咬合而成2.1 先想清楚改什么再谈怎么改搭 RSI 循环最容易犯的错是一上来就想让系统自动优化一切。这是不现实的也是危险的。一个可用的 RSI 系统第一步必须明确改进的对象边界。常见的可改进对象有这么几类我按落地难度从低到高排提示词与指令模板改起来最安全效果也最直接回滚成本几乎为零。工具调用策略比如什么时候该调搜索、什么时候该直接答、失败后重试几次、重试时怎么改参数。记忆与上下文组织方式哪些历史该保留、哪些该压缩、检索时怎么排序。验证与评估逻辑用什么标准判断这次输出是好是坏这个标准本身也可以被改进。任务分解与规划策略把一个复杂任务拆成几步、每步的依赖关系怎么定。我的建议是从提示词和验证逻辑这两个入手因为它们改动局部、影响可控、验证快。等你把这套循环跑顺了再逐步把工具策略、记忆结构纳入改进范围。一上来就动规划策略很容易出现改完之后整个 agent 行为漂移你都不知道是哪一步坏的。这里有个关键判断改进对象的可验证性决定了 RSI 能不能成立。如果一个改动你没法在合理时间内判断它是好是坏那这个改动就不该被纳入自动循环。比如让 agent 更有创造力这种目标你很难自动打分那它就不适合做 RSI 的优化目标。反过来让单元测试通过率提升、让工具调用失败率下降这种有明确信号的就非常适合。2.2 评估器是整个循环的心脏我见过太多人把精力全花在怎么让模型生成改进方案上结果评估器做得稀烂整个循环要么原地打转要么越改越差。RSI 循环的质量上限由评估器的质量决定这句话我建议你记下来。评估器一般分三层第一层是硬信号比如代码能不能跑通、测试用不用过、JSON 能不能解析、工具返回是不是成功。这层最可靠优先用。第二层是软信号比如用另一个模型LLM as judge给输出打分判断回答是否切题、是否完整、是否有幻觉。这层便宜但有噪声需要设计好评判标准最好让评判模型输出结构化的分数加理由而不是一个模糊的好/不好。第三层是回归信号也就是这次改动有没有把之前能过的用例搞坏。这层最容易被忽略但恰恰是 RSI 循环能不能长期稳定的关键。没有回归检测的自我改进本质上是在拆东墙补西墙。提示评估器本身也要有防作弊设计。如果让模型自己给自己打分它很容易学会输出看起来很好的东西而不是真正很好的东西。所以硬信号能覆盖的部分尽量别交给模型判断。2.3 harness 在这里扮演什么角色热词里反复出现 harness很多人问 harness 和 agent 到底啥区别。我的理解是agent 是干活的harness 是管着 agent 干活的。agent 负责理解任务、调用工具、产出结果harness 负责给 agent 提供运行环境、注入提示词、管理记忆、捕获输出、执行验证、决定要不要重试、记录整个过程。RSI 循环本质上是harness 在改进自己或者改进 agent 的配置。打个比方agent 是司机harness 是车队的调度系统加车辆本身。RSI 就是让调度系统根据每趟运输的结果自动调整路线规划规则、车辆配置、司机培训手册。司机本人基座模型没变但整个车队的表现变好了。这个类比能帮你理解为什么 RSI 现在可行因为 harness 是代码代码可以被程序修改而模型权重是训练出来的改起来成本极高。把改进目标放在 harness 层是当下最务实的路径。2.4 循环的终止条件必须提前设计一个没有终止条件的自我改进循环要么无限跑下去烧钱要么在某次改动后彻底崩坏。终止条件一般设这么几个收益递减连续 N 轮改进幅度低于阈值就停。预算上限总 token 消耗或总轮次达到上限就停。回归红线任何一次改动导致核心用例失败率超过阈值立即回滚并停止。人工确认点每 K 轮暂停等人看一眼再继续。我个人的习惯是预算上限 回归红线双保险收益递减作为软停止。因为收益递减的判断本身有噪声不能完全依赖它。3. 核心机制拆解让循环真正转起来的几个关键部件3.1 失败样本的采集与归因RSI 循环的燃料是失败样本。没有失败就没有改进方向。所以第一件事是建立一套稳定的失败采集机制每次 agent 运行把输入、中间步骤、工具调用记录、最终输出、评估结果全部落盘。然后定期从里面筛出失败案例。采集容易归因难。一个任务失败可能是提示词没说清、可能是工具返回了脏数据、可能是模型能力不够、也可能是任务本身无解。如果不做归因直接把失败样本丢给模型让它改提示词它大概率会改出一个过拟合到这几个样本、但在其他样本上更差的版本。我的做法是给失败分几类每类走不同的改进路径失败类型典型表现改进方向指令歧义模型理解偏了任务意图改提示词补充约束和示例工具误用该调工具没调或参数错改工具描述和调用策略上下文丢失关键信息没被检索到改记忆组织和检索逻辑能力不足模型确实做不到换模型或拆解任务别硬改提示词任务无解输入本身有问题加输入校验直接拒答把能力不足和任务无解这两类从改进池里剔出去特别重要否则你会花大量精力去优化一个根本优化不了的东西最后得出RSI 没用的错误结论。3.2 改进方案的生成与约束生成改进方案这一步本质上是让一个 LLM 看着失败样本和当前配置提出修改建议。这里有几个实操要点第一给它看的东西要结构化。别把一堆日志原样丢进去先整理成任务描述 期望行为 实际行为 差异点的格式。模型对结构化输入的利用效率远高于原始日志。第二限制改动的粒度。一次只让它改一个维度比如只改提示词里的输出格式约束而不是随便你怎么改。改动越小验证越容易回滚越干净。第三要求它输出理由和预期效果。让模型说明我为什么这么改、我预期哪个指标会变好。这不只是为了可解释性更是为了后面验证时能对照——如果它预期的效果没出现说明它的因果理解是错的这个改动就该被质疑。第四设置改动白名单。明确告诉它哪些部分不能碰比如核心安全约束、必须遵守的输出格式、不能删除的关键指令。这个白名单要写死在 harness 里不能靠模型自觉。3.3 验证回路A/B 对比与回归测试改进方案生成后不能直接上线必须验证。标准做法是A/B 对比用同一批测试用例分别跑旧配置和新配置比较指标。这里有个坑测试用例的分布要和真实使用分布接近。如果你只用失败样本做测试新配置肯定在这批样本上更好但这不代表它在整体上更好——它可能只是过拟合了。所以测试集要包含三部分失败样本看有没有修好、历史通过样本看有没有搞坏、以及一批留出的新样本看泛化。指标设计上我一般看这几个主指标比如任务成功率这是最终目标。成本指标token 消耗、工具调用次数、耗时。有时候成功率涨了 2%但成本翻倍这未必划算。稳定性指标同一输入多次运行的结果方差。方差变大说明改动引入了不确定性要警惕。只有当主指标提升、成本可接受、稳定性没恶化时改动才被接受。这个判断逻辑要写死在 harness 里别让模型自己决定这次改得好不好。3.4 版本管理与回滚RSI 循环会产出大量配置版本没有版本管理就是灾难。我的做法是每次改动生成一个配置快照带唯一 ID 和改动说明。记录每个版本的评估结果形成一条可追溯的曲线。保留一键回滚能力任何版本都能在秒级切回去。定期清理无效版本但保留每个被采纳版本的完整历史。这套东西听起来像 DevOps 里的 CI/CD实际上就是。RSI 本质上是把 CI/CD 的思想搬到了 agent 配置管理上。你要是熟悉持续集成那套理解 RSI 会快很多。注意回滚不只是切配置还要考虑回滚后正在运行的任务怎么办。如果 agent 是长任务中途切配置可能导致状态不一致。稳妥做法是让新配置只对新任务生效老任务跑完再切。4. 可落地的实操流程从零搭一个最小 RSI 循环4.1 环境与依赖准备先说清楚下面这套是我自己搭过的最小可用版本不依赖任何特定商业平台你用任意 LLM API 加一个脚本环境就能跑。核心依赖就三样一个能调用的 LLM 接口用于生成改进方案和做软评估。一个任务执行环境你的 agent 本体能接收配置、跑任务、返回结果。一个存储层存配置版本、运行记录、评估结果用文件系统或轻量数据库都行。目录结构我一般这么组织rsi-loop/ configs/ # 配置版本快照 v001.json v002.json runs/ # 每次运行的记录 2024xxxx-xxx.json evals/ # 评估结果 tasks/ # 测试用例集 fail_cases.json pass_cases.json holdout_cases.json loop.py # 主循环脚本 evaluator.py # 评估器 improver.py # 改进方案生成器这个结构的好处是每一块职责清晰出问题好定位。别把所有逻辑塞一个文件里RSI 循环调试起来很痛苦模块化能救命。4.2 第一步建立基线评估在开始任何自动改进之前先跑一次基线评估。用当前配置把三类测试用例全跑一遍记录所有指标。这个基线是后面所有对比的参照物没有它你根本不知道改动是好是坏。基线评估要注意两点一是样本量要够太少的样本噪声大建议每类至少几十条二是要跑多次因为 LLM 输出有随机性单次结果不可靠我一般同一配置跑 3 次取平均。def run_baseline(config, test_cases, n_repeat3): results [] for _ in range(n_repeat): for case in test_cases: output execute_agent(config, case[input]) score evaluate(case, output) results.append({ case_id: case[id], score: score, output: output }) return aggregate(results)这段逻辑很朴素但它是整个循环的地基。基线跑完你会得到一组数字比如成功率 72%、平均 token 消耗 3400、方差 0.08。记住这组数字。4.3 第二步采集失败并归因跑完基线从结果里筛出失败的用例。然后对每个失败用例做归因。归因这一步我建议半自动先用规则做粗分类比如输出解析失败归到格式问题工具报错归到工具问题剩下的模糊案例再交给 LLM 判断。归因的提示词大概长这样你是一个 agent 失败分析器。下面是一个失败案例 任务输入{input} 期望行为{expected} 实际输出{actual} 中间步骤{trace} 请判断失败的根本原因属于以下哪一类并给出简短理由 1. 指令歧义提示词没说清 2. 工具误用该调没调或参数错 3. 上下文丢失关键信息没检索到 4. 能力不足模型确实做不到 5. 任务无解输入本身有问题 只输出类别编号和理由不要输出其他内容。归因完之后把能力不足和任务无解的案例单独放一边它们不进入改进池。剩下的按类别分组每组的改进方向不同。4.4 第三步生成改进方案针对每一组失败生成改进方案。这里的关键是一次只改一个维度。比如这一轮只处理指令歧义组那就只让模型改提示词别碰工具策略。改进提示词的设计要点你是一个提示词优化器。当前提示词如下 {current_prompt} 以下是一批失败案例它们的共同问题是指令歧义 {fail_cases} 请提出一个修改后的提示词版本要求 1. 只修改与消除歧义相关的部分其他部分保持原样 2. 说明你改了什么、为什么这么改、预期哪个指标会改善 3. 不要删除任何现有的安全约束和输出格式要求 输出格式 修改后的提示词... 改动说明... 预期效果...拿到方案后先做静态检查确认它没删掉白名单里的内容、没引入明显矛盾、格式合法。静态检查过了才进入验证。4.5 第四步A/B 验证与决策把新配置和旧配置在完整测试集上各跑一遍对比指标。这里我用一个简单的决策函数def should_accept(baseline, candidate, thresholds): # 主指标必须提升 if candidate[success_rate] baseline[success_rate] thresholds[min_gain]: return False, 主指标未提升 # 回归不能超红线 if candidate[regression_rate] thresholds[max_regression]: return False, 回归超红线 # 成本不能暴涨 if candidate[avg_tokens] baseline[avg_tokens] * thresholds[max_cost_ratio]: return False, 成本超限 # 稳定性不能恶化 if candidate[variance] baseline[variance] * thresholds[max_var_ratio]: return False, 稳定性恶化 return True, 通过阈值怎么定我的经验是min_gain设 2% 到 5%max_regression设 3% 以内max_cost_ratio设 1.3max_var_ratio设 1.5。这些数字不是绝对的要根据你的任务容错度调整。任务越关键阈值越严。4.6 第五步采纳、记录、进入下一轮验证通过就采纳新配置生成新版本号记录改动说明和评估结果。然后以新配置为新基线进入下一轮。没通过就丢弃把这次尝试记录下来包括失败原因避免下次重复踩坑。整个循环跑起来后你会得到一条改进曲线。正常情况下前几轮提升明显后面逐渐平缓。如果曲线出现剧烈波动说明评估器或测试集有问题要停下来查。实操心得别追求每轮都提升。RSI 循环里大部分改动应该是被拒绝的。如果每轮都通过要么是你的阈值太松要么是测试集太小导致过拟合。健康的循环采纳率大概在 20% 到 40% 之间。5. 常见问题与排查技巧实录5.1 循环原地打转改来改去没提升这是最常见的问题。原因通常有三个一是评估器信号太弱模型根本不知道往哪改二是失败样本太少或太集中改进方案过拟合三是改进粒度太大一次改太多导致效果互相抵消。排查顺序先看评估器把硬信号的比例提上去再看失败样本是不是就那几条反复出现最后看改动粒度是不是一次动了太多地方。我遇到过一次循环跑了十几轮没动静最后发现是评估器里软信号占了大头模型学会了讨好评判模型而不是真正解决问题。把硬信号比例提上来后立刻就有改善了。5.2 改完之后旧用例大面积失败典型的回归问题。根因一般是测试集里历史通过样本覆盖不足或者改进方案动了不该动的地方。解决办法一是扩充回归测试集把线上真实通过的案例持续加进去二是收紧改动白名单把核心逻辑锁死三是引入最小改动原则要求改进方案尽量少动。我现在的习惯是任何改动如果 diff 超过原配置的 30%就自动打回重做。这个粗暴的规则帮我挡掉了很多大改导致崩盘的情况。5.3 成本失控循环烧钱太快RSI 循环的 token 消耗是普通 agent 的好几倍因为每轮都要跑完整测试集加生成改进方案。控制成本的办法测试集分层快速验证用小子集最终决策用全量集。缓存相同输入相同配置的结果可以缓存别重复跑。早停候选配置在小子集上就不达标直接淘汰别跑全量。限制轮次设硬性轮次上限到点就停。我一般把快速验证集控制在 20 条以内全量集 100 条左右。这样一轮循环的成本能压到可接受范围。5.4 改进方案看起来合理但实际没用这种情况往往是因果误判。模型看到失败案例提出了一个听起来对的修改但它对失败原因的理解是错的。比如失败其实是工具返回脏数据导致的模型却以为是提示词没说清改了半天提示词当然没用。对策是强制归因前置先确定失败类型再生成对应类型的改进方案。别让模型跳过归因直接改。另外要求改进方案附带预期效果验证时对照如果预期没实现说明因果链有问题这个改动方向就该被标记为可疑。5.5 多个改进方向互相冲突当你同时优化提示词、工具策略、记忆结构时可能出现A 改动让指标涨B 改动让指标跌AB 一起改反而更差的情况。这是典型的耦合问题。处理办法是串行化一次只优化一个维度其他维度冻结。等这个维度收敛了再动下一个。虽然慢但可控。想并行优化多个维度需要更复杂的实验设计比如正交实验投入产出比在早期不划算。下面这张表是我整理的常见问题速查现象可能原因优先排查项循环无提升评估信号弱/样本集中/粒度大评估器硬信号比例旧用例崩盘回归覆盖不足/改动过大回归测试集、diff 大小成本失控测试集太大/无缓存/无早停分层测试、缓存策略改动无效因果误判归因是否前置方向冲突多维度耦合是否串行优化结果波动大随机性未控制/样本太少重复次数、样本量5.6 关于安全边界的一点个人看法做 RSI 循环有一条线我建议你无论如何都别越过不要让系统自动修改安全约束和核心行为边界。提示词可以自动优化工具策略可以自动调整但什么绝对不能做这类约束必须由人来定、由人来改。原因很简单自我改进循环的优化目标是指标变好而指标永远无法完整表达安全。一旦让系统自己动安全约束它迟早会为了指标而绕过约束。我的做法是把安全约束单独抽出来放在一个循环碰不到的配置层里每次改动只允许动业务逻辑层。这个隔离看起来笨但它能保证无论循环怎么跑底线都在。6. 我对 RSI 现状的一点判断聊了这么多工程细节最后说点我自己的观察。RSI 现在处在一个挺微妙的位置概念上很热但真正跑通完整循环、并且长期稳定产出的团队并不多。大部分还停留在能自动改提示词这个层面再往上走就卡住了。卡住的原因不是技术不够而是评估这件事本身太难。你能自动改的东西取决于你能自动评估的东西而现实中大量有价值的目标是难以自动评估的。所以我的判断是RSI 短期内不会带来什么失控式的飞跃它更像是一个把 agent 工程化水平往上抬一个台阶的工具。它逼着你去把评估做扎实、把版本管理做规范、把失败归因做系统化——这些事就算没有 RSI 也该做RSI 只是给了你一个必须做的理由。至于更远的事比如系统改进自己的改进策略、改进的改进的改进那属于另一个层面的问题现在讨论为时过早。眼下更值得投入的是把一个最小循环跑稳把评估器打磨好把回归测试集养起来。这些基础打牢了后面无论技术怎么演进你都有接得住的能力。我个人在实际搭这套东西的过程中最大的体会是别急着让系统变聪明先让它变得可观测、可回滚、可验证。这三件事做到了自我改进是水到渠成的事做不到再花哨的循环也只是在制造混乱。