最近在追谷歌新放出来的那篇关于自我改进的论文时，看到 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. 为什么需要 Harness：Agent 自改进失控问题
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$ 可以调小一点。论文里边做消融实验也验证了这一点：$\lambda=0$ 时表现最差，$\lambda$ 过大时改进效果微弱，存在一个中间最优区间。
4.3 消融实验与实现细节背后的工程直觉
虽然没有一一列出每个消融实验的原始数值，但从工程角度看，有几个消融结论是顺理成章的：去掉能力保持正则后，任务成功率可能短暂上升，但能力保持集分数会快速下降；去掉行为一致性正则后，指令遵循类违规明显增多；去掉结构简洁正则后，Prompt 长度快速膨胀。
这些结论其实都在告诉我们一件事：RRSI 里的“正则化”不是一个单一技巧，而是一组相互配合的约束机制。只用其中一种，效果都会打折。这有点像你开车下坡时既要踩刹车控制车速，又要握方向盘控制方向，还要留意仪表盘防止过热——单独一个都不够。
5. 实操落地：在自己的 Agent 上搭一个轻量 RRSI Harness
5.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_id=f"round-{round_idx+1}", system_prompt=new_prompt, tools_config=baseline.tools_config, eval_score=0.0, reg_score=0.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 框架给了一个非常务实的解法：不要相信模型的自我判断，用确定性的代码，加上合适的正则化约束，把每一次递归改进都锁在安全边界内。如果你的项目也正在做智能体自动优化，建议从这篇论文的思路里借一个轻量版本跑一跑，尤其把能力保持集和回滚机制先搭起来，它不会让你每轮都“改飞”，但能保证你永远不会摔到爬不起来。
