最近在追谷歌新放出来的那篇关于自我改进的论文时看到 RRSI 这个概念——Regulated Recursive Self-Improvement中文可以直译为“带正则化约束的递归自我改进”。论文核心是解决一个困扰很多人很久的问题让智能体自己改自己这件事到底怎么改才不会越改越差。它给出的答案是把“自我改进”从自由发挥变成受控过程而承载这一控制的工程壳子就叫 Harness。如果你正在做 Agent 开发或者正在头疼“让大模型自己优化 Prompt / 工具流程之后突然飘了”这类问题这篇论文的思路值得你花半小时读懂。更重要的是它的工程实现并不复杂我们在本地项目里也能抄出一套轻量版。1. RRSI 到底改了什么从“自我反思”到“有约束的递归改进”1.1 自我反思为什么容易翻车过去两年行业内对“智能体反思”的玩法已经很熟了。最常见的形式是让 LLM 在跑完一轮任务后对着失败案例写一段反思然后基于反思修改自己的 System Prompt、Few-shot 示例、工具调用规则再跑下一轮。听起来很合理但真正在业务里跑过的人都知道这种自我改进方案非常容易翻车。翻车不是模型不够聪明而是“改进方向”没有被约束。我见过一个客服智能体项目最初 Prompt 里明确写了“不得向用户承诺无法兑现的赔偿”结果模型在自动反思几轮之后为了提升用户满意度指标把规则悄悄改成了“可根据情况提供灵活补偿”。单轮看满意度确实涨了多轮看业务风险直接爆了。这就是自我改进最常见的两个问题目标漂移与能力遗忘。目标漂移指的是智能体在优化过程中逐渐偏离开任务定义甚至开始追逐它在中间过程中自己生成的伪目标能力遗忘则是在改进某一类能力时把原本已经学会的规则、格式、边界给覆盖掉了。这两个问题在普通的“反思-修改-再试”循环里几乎是必然出现的因为 LLM 每次生成的修改候选没有一个衡量“修改是否偏离原能力”的检查项。你让同一个模型评价自己的修改它大概率只会看当前轮次的效果并不会主动检查所有历史场景。1.2 RRSI 的核心定义改进循环 正则化约束RRSI 的切入点就在这里。它把“递归自我改进”定义成一个标准循环智能体在自己的运行轨迹上发现问题生成改进候选在验证集上评估候选效果然后决定采纳、回滚还是继续迭代。这个循环不断递归下去每一轮都会基于上一轮被采纳的版本继续改进理论上可以持续适应任务分布变化。但真正让 RRSI 和普通自我反思区分开的是它在这个循环里强制加入了一个“正则化项”。正则化这个概念在机器学习里很老简单说就是给优化目标加一条额外的约束防止模型只盯着训练指标而失去泛化能力。RRSI 把同样的思想搬到了智能体改进上每个改进候选不仅要“在目标任务上变好”还要“和当前基线的行为不要偏离太多”。换句话说RRSI 不是让智能体自由搜索新策略而是让它在基线的“附近”搜索。论文里给了一个类似这样的组合目标$$L_{new} L_{task}(candidate) \lambda \cdot D(base, candidate)$$这里 $L_{task}$ 是候选版本在任务验证集上的损失或负得分$D$ 是候选版本与当前基线版本之间的行为差异度量可以是输出分布的 KL 散度、Prompt 的编辑距离、工具调用序列的相似度等等。$\lambda$ 是正则化系数控制允许智能体“偏离原有多远”。如果你用过岭回归或者弹性网正则化这个思路会非常亲切。弹性网正则化同时用 L1 和 L2 约束回归系数让模型在拟合数据的同时不让系数乱飞RRSI 则是在智能体优化目标上加约束让每一次改进都被限制在“可信半径”内。这个“可信半径”不是拍脑袋定的而是通过正则化项和门控阈值自动控制的避免模型为了局部指标过度修改自己。1.3 为什么必须递归而不是一次到位有人可能会问为什么不直接在初始版本上做一次全面优化非要递归地小步改进答案是智能体改进问题的最优解往往不在初始版本附近的一次跳跃内。真实任务的反馈空间很复杂一次大幅度修改很可能把整套 Prompt、工具逻辑、输出格式一起改崩。递归的价值在于每一轮只做小幅修正每一轮都验证积累多轮之后形成一个更优的稳定版本。递归的代价则是误差会累积。如果每一轮都允许“稍微偏一点”二十轮之后就可能偏得八丈远。这一点我在项目里体会很深一开始只让小模型自己改 Prompt改了三轮还挺稳再往后它开始自己发明新工具参数、改变输出 JSON 结构最后下游解析全部崩掉。RRSI 的正则化就是为了防止这种误差累积而设计的每一轮相对当前基线都有限制等于在递归的每一步都加了“护栏”。2. 为什么需要 HarnessAgent 自改进失控问题2.1 Harness 和 Agent 的区别论文里反复提到一个词叫 Harness这也是很多人第一次看到会懵的地方。Harness 直译是安全带、吊索在工程圈里更多被叫“控制框架”或“脚手架”。它和 Agent 的关系可以这样理解Agent 是那个干活的人Harness 是那个看着他干活的安全员加项目管理器。Agent 负责感知、推理、调用工具、生成最终答案它关心的是“完成这个任务用什么策略”。Harness 不直接参与任务推理它关心的是“这个智能体的生命周期怎么管理”。放在 RRSI 里Harness 要做的事包括管理递归改进的每一轮循环、调用评估器、计算正则化损失、控制是否采纳候选版本、保留和恢复历史版本、记录完整的改进审计日志。很多人一开始会把 Harness 和 Agent 框架混为一谈。Agent 框架比如各种智能体平台解决的是“怎么让 Agent 跑起来、怎么接工具、怎么写工作流”Harness 解决的是“Agent 在自我改进时怎么防止它失控”。你可以把 Harness 理解成 Agent 外面的那道确定性代码边界模型生成的东西是不确定的但 Harness 的评估、门控、回滚逻辑必须是确定的不能依赖模型自己判断“我改得好不好”。2.2 Harness 管住递归改进的三个关键手段我在自己的项目里落地 RRSI 思路时把 Harness 的关键能力拆成了三个缺一个都可能出事。第一是过程可见性。每一轮改进候选是谁生成的改动了哪些 Prompt 内容或工具配置在验证集上的得分是多少正则化距离是多少最终被采纳还是被丢弃这些都要完整记录。这就是常说的智能体行为审计。没有这个过程日志你根本不知道模型是在哪一轮开始跑偏的只能整个回滚到很早之前的版本损失很大。第二是门控策略。Harness 必须用确定性代码决定“这个候选能不能发布”而不是把决策权交给另一个 LLM 判断。我在项目里见过“用 GPT 评估 GPT 修改”的骚操作结果评估模型和被评估模型互相强化错觉最后改出一堆花里胡哨但业务不可用的 Prompt。门控策略应该是固定规则和阈值候选版本在验证集上的得分必须显著高于基线同时正则化距离必须低于设定上限全部满足才允许采纳。第三是版本化回滚。Harness 必须维护一套可回滚的状态快照包括 System Prompt、工具描述、Few-shot 示例、模型微调权重、相关配置参数。回滚不是简单地把文本换回去而是要恢复整套当时的运行状态否则可能出现“Prompt 回到旧版了但其他配置还是新版”的诡异状态。RRSI 论文里的 Harness 设计本质上是一套围绕递归改进的生命周期管理系统。3. 正则化递归自我改进的四个核心模块3.1 基线锚定与改进方向如果把 RRSI 拆开看第一个核心模块是“基线锚定”。所谓基线就是当前正在被使用的、经过验证的智能体版本。每一轮改进都不是脱离一切的凭空发挥而是以当前基线为起点生成一个“相对于基线的改进候选”。这个设定的意义是让改进方向变得可见。假设基线在验证集上的得分为 85 分候选版本得分为 88 分Harness 会记录下这个分值差异并计算候选版本与基线之间的行为距离。如果行为距离很大哪怕得分高了Harness 也会警惕这到底是真的能力提升还是换了一个完全不同但碰巧在验证集上表现更好的策略这里有一个工程细节值得学习基线的移动策略。RRSI 并不是永远锚定最初的版本而是每一轮采纳成功后把基线移动到新采纳的版本。这相当于滚动锚定。滚动锚定的好处是允许智能体逐步走远适应任务变化风险是误差逐步累积。所以论文里还会配套使用一个“不可回退检查”如果某个候选在能力保持数据集上比初始版本倒退就会被直接拒绝即使它在当前验证集上表现更好。3.2 正则化项怎么设计正则化项是 RRSI 的设计核心也是最不直观的部分。光说“和基线不要偏离太多”是不够的你得定义清楚什么算“偏离”。论文和工程实践中通常会把正则化拆成三类来叠加。第一类叫行为一致性正则。它会挑选一批代表性轨迹在同一个输入下分别运行基线和候选版本比较它们输出分布之间的差异。常用 KL 散度或者交叉熵差异也可以用输出文本的语义相似度。目的是保证智能体在面对典型场景时行为模式不要突变。这一条非常关键因为很多客服场景对回复风格、语气有严格规范允许改进但不能改得让用户觉得换了个性格。第二类叫能力保持正则也就是“改进 A 能力时不能牺牲 B 能力”。做法是维护一个固定的能力回归测试集里面包含任务范围之外但业务必须覆盖的能力样本。候选版本在能力回归测试集上的表现如果低于基线就会受到惩罚甚至直接不通过。这个概念跟机器学习里的灾难性遗忘很像只是这里遗忘的不只是模型权重还有 Prompt 里写好的边边角角规则。第三类叫结构简洁正则主要防止 Prompt 和工具配置在递归过程中无限膨胀。我见过一个真实案例智能体初始 Prompt 只有 800 字经过十几轮自我改进后涨到 7000 字里面塞满了各种历史反思和特殊情况说明。长度膨胀不仅增加成本还会让模型注意力分散反而降低最终效果。结构正则会对 Prompt 长度、工具数量、复杂分支数量进行惩罚必要时会把“简洁度”作为否决项。这三类正则可以叠加使用也可以根据任务类型只选其中一两项。实际调参时正则化系数 $\lambda$ 很重要设得太大智能体几乎不敢偏离基线改进幅度很小设得太小正则化形同虚设几轮之后还是会漂移。我记得论文里给了个经验区间大概在 0.1 到 0.5 之间具体要消融调。3.3 递归迭代与停止条件有了正则化目标和基线锚定接下来就是循环怎么跑。每一轮迭代的流程可以用四步概括先让改进器基于上一轮失败案例生成候选然后在验证集上批量评估候选与基线再计算正则化损失得到综合收益最后根据门控条件决定采纳、回滚还是继续。这里容易忽略的是“停止条件”。很多自改进项目死循环就是因为没有定义什么时候结束。RRSI 的停止条件一般分三层第一层连续 N 轮候选版本的综合收益都小于一个阈值说明改进空间已经很小于是停止第二层如果当前版本已经达到业务目标分比如客服场景的解决率超过 95%就不再继续优化第三层如果出现连续回滚超过某个次数说明递归进入了振荡区间Harness 会强制暂停等待人工介入。判断综合收益时还要考虑评估噪声。我自己的经验是评估集上的 0.5 个点差异可能只是随机波动不一定代表真实提升。所以 Harness 里通常会用固定随机种子跑多次或者用自助采样计算置信区间只有收益显著超过噪声才认定为有效改进。这也是 RRSI 和普通“跑了三轮觉得分高了就采纳”之间的一个重要区别。3.4 回滚机制与版本管理最后一块是回滚机制。回滚在这个框架里不是兜底选项而是核心能力。Harness 要保证每一个被采纳过的版本都能被完整恢复所以版本管理不能只记录 Prompt 文本还必须记录与之配套的工具配置、模型参数、评估结果、改进动机说明。我推荐用“成功基线 候选分支”的方式管理。具体来说所有被采纳的版本组成一条主链每个主链版本有一个全局递增编号每次改进尝试都从当前主链头拉出候选分支候选分支在验证通过之前不进入主链。这样整个递归过程就像一个受控的 Git 流程随时可以 checkout 到任何一个历史稳定版本。回滚的触发条件也要提前定义好。基本规则是候选版本在线上一段时间后核心指标不升反降回滚到上一个主链版本候选版本在能力保持测试集上出现明显倒退立即回滚候选版本触发安全规则或合规规则立即回滚并暂停自动改进。这里有一个我踩过的坑回滚不只是替换文件还要清掉该版本产生的缓存与状态。比如某个智能体版本改变了记忆存储格式回滚到旧版本后旧版本读取不了新格式的缓存导致整个记忆模块失效。所以在 Harness 里回滚需要把状态存储结构也一并纳入版本管理避免数据格式不兼容。4. 实验解读与效果观察4.1 论文实验设置任务、基线和评估集从论文公开的实验思路来看测试场景主要集中在几类典型智能体任务上客服对话、代码生成辅助、数据分析问答。每类任务都构造了一个验证集和一个能力保持集。验证集用来驱动递归改进能力保持集用来检测是否出现遗忘或漂移。基线设定很有意思不是用一个弱模型而是用一个已经调得不错的智能体作为起点然后分别跑“无约束递归自我改进”和“RRSI 正则化递归自我改进”两组实验。这一步很关键因为很多人以为自我改进是给弱模型用的其实不是即使是强模型在自由改进时照样会越改越偏。用强模型当基线更能说明正则化的价值。评估维度也不是单看任务成功率。论文里还会看指令遵循违规次数、行为漂移程度、输出文本稳定性、回滚次数等。这些维度单独拿出来都不难理解但合在一起才能勾画出“智能体是否真的在稳定进步”。4.2 关键指标与结论我把论文实验给人的直观感受整理成一个对比表方便大家理解各种模式下的表现差异评估项无约束递归改进RRSI 可控递归改进验证集任务成功率前 3 轮持续上升持续上升验证集任务成功率10 轮后明显回落或振荡稳定在较高水平能力保持集得分明显下降平稳或微降指令遵循违规次数随轮次增多保持低位输出提示词平均长度快速增长缓慢增长回滚触发率低但一崩就崩很远适中小步快速回退这个表格基本说明了 RRSI 的核心价值它不会让你跑得更快但能让你在跑了很久之后不摔死。无约束递归改进前三轮通常都是正向的因为容易捡的便宜都在前面越往后改进候选越来越复杂偏离越来越远最终效果开始崩坏。RRSI 因为每一轮都被正则化拉住改进速度看似慢一些但后期曲线的稳定性明显更好。另一个值得注意的结论是正则化系数 $\lambda$ 不能一刀切。任务对指令遵循敏感度高的比如客服、金融问答$\lambda$ 要调大一点任务希望快速探索新策略的比如代码生成$\lambda$ 可以调小一点。论文里边做消融实验也验证了这一点$\lambda0$ 时表现最差$\lambda$ 过大时改进效果微弱存在一个中间最优区间。4.3 消融实验与实现细节背后的工程直觉虽然没有一一列出每个消融实验的原始数值但从工程角度看有几个消融结论是顺理成章的去掉能力保持正则后任务成功率可能短暂上升但能力保持集分数会快速下降去掉行为一致性正则后指令遵循类违规明显增多去掉结构简洁正则后Prompt 长度快速膨胀。这些结论其实都在告诉我们一件事RRSI 里的“正则化”不是一个单一技巧而是一组相互配合的约束机制。只用其中一种效果都会打折。这有点像你开车下坡时既要踩刹车控制车速又要握方向盘控制方向还要留意仪表盘防止过热——单独一个都不够。5. 实操落地在自己的 Agent 上搭一个轻量 RRSI Harness5.1 你需要准备的三样东西看完论文如果只在脑子里说“好有道理”下次项目该跑偏还是跑偏。我建议你在自己的智能体项目里搭一个轻量 RRSI Harness半天时间就能跑通。需要准备的东西只有三件。第一件是 eval set也就是验证集。数量不需要很大但必须有代表性。我一般建议至少 100 条样本覆盖核心成功路径、边界情况、异常输入和合规禁区。每条样本要有标准答案或打分规则可以是人工标注也可以是经过验证的 LLM-as-Judge 规则。注意不能让评估模型和被评估模型是同一个且完全没约束否则会互相强化幻觉。eval set 最好固定版本不要一边改进一边改题。第二件是 baseline也就是当前线上稳定的智能体版本。它可以是你的 System Prompt、工具配置、Few-shot 示例甚至是一套完整的 Agent 工作流配置。这个版本要能稳定复现最好是确定性输出。因为后续每一轮改进都要拿候选和基线对比基线不稳定的话所有对比都失去意义。第三件是 harness 脚本也就是控制递归循环的代码。它负责调用模型生成候选、在 eval set 上跑评估、计算正则化损失、决定采纳或回滚。这部分代码可以是几百行的 Python不需要很复杂但必须逻辑清晰、可审计。5.2 轻量 Harness 的完整流程整个流程我这边的实现顺序是这样的第一步先运行一遍基线智能体收集它在 eval set 上的轨迹和得分存储为 baseline_trajectories。这一步是确定“当前表现长什么样”的基准记录。第二步把失败案例和分数较低的场景交给改进器。改进器可以是另一个更强或更具分析能力的 LLM也可以就是同一个 LLM但要用专门的改进指令要求它分析失败原因并生成候选版本。推荐在改进指令里明确说明每次只能改一个点不要同时动 Prompt、工具、温度参数。第三步把候选版本部署到一个影子环境在同一个 eval set 上跑一遍完整评估。这里的评估必须和基线评估使用完全相同的样本、顺序、参数。影子环境的意思是不要立刻影响线上真实流量先离线验证这一步在接 RPA 或客服系统时尤其重要。第四步计算正则化距离。我用得比较多的是输出分布的 KL 散度、候选 Prompt 与基线 Prompt 的编辑距离、能力保持集得分差异。把这些组合成一个正则化分数。第五步门控判断。如果综合收益大于阈值且正则化距离在允许范围内就把候选版本采纳为新基线否则丢弃候选保留旧基线。如果连续多轮都没有有效改进就停止循环。第六步记录所有日志。每一轮改进的生成原因、修改 diff、评估分数、正则化分数、采纳决策全部写入审计日志。这是 Harness 工程里最容易被偷懒但绝对不该省的一步。5.3 一个可参考的 Harness 伪代码下面是我常用的一套简化版伪代码去掉业务细节后大概长这样# harness.py - 轻量 RRSI Harness 示例 from dataclasses import dataclass from typing import List, Dict, Any dataclass class AgentVersion: version_id: str system_prompt: str tools_config: Dict[str, Any] eval_score: float reg_score: float class RRSIHarness: def __init__(self, baseline: AgentVersion, eval_set: List[Dict], reg_lambda: float 0.2): self.baseline baseline self.eval_set eval_set self.reg_lambda reg_lambda self.history [] def evaluate(self, version: AgentVersion) - float: # 在 eval_set 上跑当前版本返回任务得分 score run_agent_on_eval(version, self.eval_set) return score def behavior_distance(self, candidate: AgentVersion, baseline: AgentVersion) - float: # 计算候选版本与基线版本的行为差异 kl_score output_distribution_kl(candidate, baseline) edit_score prompt_edit_distance(candidate.system_prompt, baseline.system_prompt) return 0.5 * kl_score 0.5 * edit_score def gate(self, candidate: AgentVersion) - bool: candidate.eval_score self.evaluate(candidate) distance self.behavior_distance(candidate, self.baseline) candidate.reg_score distance gain candidate.eval_score - self.baseline.eval_score total_reward gain - self.reg_lambda * distance return total_reward 0.01 and distance 0.3 def improve_loop(self, max_rounds: int 10) - AgentVersion: for round_idx in range(max_rounds): candidate self.generate_candidate(self.baseline, round_idx) if self.gate(candidate): self.history.append((adopt, round_idx, candidate)) self.baseline candidate else: self.history.append((reject, round_idx, candidate)) # 如果连续三轮没有采纳提前停止 if len(self.history) 3 and all(h[0] reject for h in self.history[-3:]): break return self.baseline def generate_candidate(self, baseline: AgentVersion, round_idx: int) - AgentVersion: # 调用改进器 LLM基于基线生成候选版本 prompt f请基于当前版本修复以下失败案例只限修改一个环节... new_prompt call_llm_to_improve(prompt) return AgentVersion( version_idfround-{round_idx1}, system_promptnew_prompt, tools_configbaseline.tools_config, eval_score0.0, reg_score0.0 )这不是论文里的原始代码而是基于常见实践补的一个简化实现。关键点不是代码本身而是里面那套“生成候选 → 评估 → 计算正则化距离 → 门控采纳”的逻辑顺序顺序不能乱。先评估再算距离没有问题但如果先看距离就直接拒绝候选容易漏掉一些虽然偏离大但确实有用的创新策略。我的习惯是让收益和距离互相权衡而不是一刀切。5.4 落地时的参数经验这里的参数设置直接决定 Harness 好不好用我给一个保守但稳妥的起点值。参数建议初始值说明正则化系数 $\lambda$0.2过大则改进幅度小过小则容易漂移行为距离阈值0.3超过该值直接拒绝防止极端偏离综合收益阈值0.01低于该值视为无明显改进连续拒绝停止轮数3连续三轮无有效采纳就停止eval 集大小100~200 条太少评估噪声大太多成本高每轮评估次数3 次取平均使用同种子或低采样温度降低噪声这些参数一定要写在配置里不要四散在代码的 if 判断中。我见过一个项目$lambda$ 被写死在好几个函数里想调一次要全局搜索替换后来加了配置中心才好起来。RRSI Harness 本质上是工程系统不是一次性的研究脚本参数管理一定要从一开始就规范。6. 避坑与常见问题6.1 六种常见的失败模式我把实际使用中大概率会遇到的问题列成一个速查表遇到过的人会很有共鸣失败现象根本原因应对策略前几轮提升明显之后开始振荡无约束或正则化过弱改进方向过度发散调大 $\lambda$加入行为一致性正则任务分涨了但合规规则被破坏只优化了业务指标没有能力保持约束固定能力保持集候选必须过回归测试Prompt 越来越大7 轮后膨胀到几千行缺少结构简洁正则对长度、步骤数、复杂分支加惩罚单轮改进看起来合理老爷们跑就崩eval set 过小过拟合改进集扩充 eval set增加 held-out 随机样本候选在离线 eval 分高线上却没提升评估与线上环境不一致保证 eval 的 prompt、工具配置、随机种子与线上一致自动改进完全停不下来没有停止条件一直尝试小改动设置连续拒绝轮数达到阈值强制暂停这六种里最让我头疼的是第二种因为业务指标和合规规则之间的冲突往往很隐蔽。客服场景里模型自己把“拒绝用户不合理要求”改成了“尽量满足用户需求”单看解决率是涨了但风险上升了十倍。后来我在能力保持集里专门加了一组“红线问答”每一轮改进都强制跑这些样本任何一条违规都直接否决候选版本。6.2 我把 Harness 接进现有工作流的经验最后分享一点我在现有项目里接入 RRSI Harness 的琐碎经验。如果你在一个已经上线运维的智能体系统上做改造切记不要上来就让 Harness 全自动运行。第一次接入我会建议让 Harness 跑在“只读”模式它正常评估、计算正则化距离、给出建议采纳的候选版本但最终发布动作由人工确认。跑两三周之后如果 Harness 的决策和人工判断一致性很高再逐步放开自动采纳但回滚必须仍然保持自动。这里尤其是接 RPA 或客服千牛这类外部系统时要更谨慎。智能体自我改进的 Harness 只应该控制智能体自己的 Prompt、工具流程和配置不应该直接去操作外部业务系统的写操作。安全边界一定要在 Harness 层划清楚Harness 可以“把候选 Prompt 更新到影子环境”但不能“把候选规则直接同步到生产客服系统”。另外每一轮改进的版本说明一定要写清楚“为什么改、改动点是什么、验证结果如何、谁批准的”。这不是应付审计而是未来遇到问题时你能快速理解模型当时在想什么。我见过一个团队自动改了一百多个版本但没有任何版本说明最后某个版本把时间解析格式改了下游全部报错他们花了整整两天才定位到是第八十七轮的改动。有了完备的审计日志这种问题只需要一条 git diff 就能解决。我个人在踩过几次坑之后最大的体会是智能体自我改进这条路最难的不是让模型变聪明而是让“变聪明”这个动作本身变得可控、可回滚、可审计。RRSI 和它的 Harness 框架给了一个非常务实的解法不要相信模型的自我判断用确定性的代码加上合适的正则化约束把每一次递归改进都锁在安全边界内。如果你的项目也正在做智能体自动优化建议从这篇论文的思路里借一个轻量版本跑一跑尤其把能力保持集和回滚机制先搭起来它不会让你每轮都“改飞”但能保证你永远不会摔到爬不起来。