1. 从 RRSI 这个标题说起它到底在解决什么问题第一次看到“RRSI 智能体 Harness 的正则化递归自我改进”这个标题我脑子里冒出来的第一个念头是又是一个把三个热词拼在一起的论文标题。RRSI、Harness、正则化、递归自我改进单拎出来每个词都能写一篇长文凑在一起反而让人抓不住重点。但把这篇论文的摘要和实验部分翻完之后我意识到它其实在回答一个非常具体、也非常要命的问题当一个智能体开始自己改自己的代码、自己优化自己的策略时怎么保证它不会越改越烂这个问题听起来有点抽象我换个说法。你搭过一个能自我迭代的智能体它跑完一轮任务之后会反思“我哪里做得不好”然后修改自己的提示词、工具调用逻辑甚至代码再跑下一轮。前几轮效果确实在涨但跑到第十轮、第二十轮的时候你发现它开始出现一些莫名其妙的退化原本能稳定完成的任务开始失败输出格式变得不稳定甚至开始“幻觉”出一些根本不存在的工具。这就是递归自我改进Recursive Self-Improvement最典型的翻车现场——没有约束的自我迭代本质上是在一个高维空间里做无梯度的随机游走短期看起来在爬坡长期一定发散。RRSI 这篇论文的核心贡献就是给这个“自我改进”的过程套上了一个 Harness可以理解为一套外部的约束与评估框架并且在改进目标里显式加入了正则化项让智能体在追求任务表现的同时不能偏离一个“稳定基线”太远。这个思路其实和机器学习里最经典的偏差-方差权衡是一脉相承的只不过它把这件事从“训练一个模型”搬到了“迭代一个智能体系统”上。我之所以对这个方向感兴趣是因为过去一年我陆陆续续搭过几个带自我反思能力的智能体踩过的坑基本都能在这篇论文里找到对应的解法。所以这篇博文我不打算做论文翻译而是想以一个实际搭过智能体的人的视角把 RRSI 这套东西拆开讲清楚它的 Harness 到底长什么样正则化项具体怎么加递归自我改进的循环怎么设计才不会失控以及如果你现在手上就有一个智能体项目哪些部分可以直接抄作业。适合读这篇的人有三类一是正在做智能体开发、已经过了“能跑通”阶段、开始头疼稳定性问题的工程师二是对智能体自我进化机制感兴趣、想搞清楚学术界最新思路的研究型开发者三是被各种“智能体框架”名词绕晕、想找一个清晰心智模型来理解 Harness 和 Agent 区别的从业者。不管你是哪一类我都会尽量用能落地的方式讲而不是停在概念层面。2. 先把名词理清楚Harness、Agent、RRSI 到底是什么关系2.1 Harness 不是 Agent它是 Agent 的“跑道和裁判”热词里有个高频问题叫“harness 和 agent 区别”这个问题问得特别好因为很多人第一次看到 Harness 这个词会以为它是某种新的智能体框架。其实不是。Agent 是那个干活的Harness 是那个管着它干活的。我用一个类比来解释Agent 像一个运动员Harness 像跑道加裁判加计时器加兴奋剂检测。运动员负责跑Harness 负责定义跑道边界、记录成绩、判断有没有犯规、决定这一轮成绩算不算数。在 RRSI 的语境里Harness 承担了四件事。第一是任务分发把一批标准化的任务喂给智能体第二是执行沙箱让智能体在一个受控环境里跑避免它把真实系统搞坏第三是评估与打分用一套固定的指标给每一轮的表现打分第四是改进准入也就是决定这一轮智能体提出的自我修改到底要不要被采纳。第四点是最关键的也是 RRSI 区别于普通自我反思智能体的地方。我见过很多团队搭的“自我改进智能体”本质上就是让模型自己写一段反思然后把反思塞回提示词里。这种做法的问题在于反思的质量没有任何外部校验模型说“我这次失败是因为没调用搜索工具”你就信了下一轮它可能就疯狂调用搜索工具结果把上下文撑爆。Harness 的存在就是为了堵住这个漏洞你想改自己可以但改完之后必须在新一轮评估里证明你确实变好了否则这次修改直接回滚。2.2 RRSI 里的“递归”到底递归在哪递归自我改进这个词容易让人联想到科幻电影里那种指数级自我进化的超级智能实际上 RRSI 里的递归要朴素得多。它的递归体现在一个循环结构上当前版本的智能体执行任务 → Harness 评估并生成反馈 → 智能体基于反馈提出自我修改 → Harness 验证修改 → 生成新版本智能体 → 新版本重新执行任务。这个循环可以一直转下去每一轮的输入是上一轮的输出这就是递归。但朴素归朴素这个循环里藏着一个非常凶险的东西误差累积。假设每一轮自我修改有 60% 的概率是真正变好的40% 的概率是变差的这个比例在真实项目里已经很乐观了那么跑十轮之后整体变好的概率是 0.6 的十次方约等于 0.6%。也就是说如果没有 Harness 的准入机制递归自我改进几乎必然走向退化。这就是为什么 RRSI 要把正则化加进来——它不是在优化“变得更好”而是在优化“在不变差的前提下变得更好”。2.3 正则化在这里不是机器学习里的那个正则化提到正则化做过机器学习的人第一反应是 L1、L2、弹性网那一套用来防止模型过拟合。RRSI 里的正则化借用了这个思想但作用对象完全不同。它正则化的不是模型参数而是智能体的行为分布。具体来说它要求新版本智能体在完成目标任务时的行为轨迹不能和旧版本偏离太远。这个设计背后的直觉是这样的如果一个智能体为了提升某个任务的得分把自己的行为模式改得面目全非那它很可能只是过拟合了当前这批任务换一批任务就崩了。加一个正则化项相当于给自我修改加了一个“惯性”让智能体倾向于做小步调整而不是大跳变。这跟弹性网正则化里 L1 负责稀疏、L2 负责平滑的思路有异曲同工之妙只不过这里平滑的是行为而不是权重。3. RRSI Harness 的整体架构拆解3.1 四层结构任务层、执行层、评估层、改进层把 RRSI 的 Harness 拆开看它大致是四层结构我用一个表格把每层的职责和关键设计说清楚。层级核心职责关键设计点常见翻车点任务层提供标准化任务集与评分标准任务要覆盖多个难度档位评分标准要可自动化任务太单一导致智能体过拟合执行层在沙箱中运行智能体并记录轨迹轨迹要完整记录工具调用、中间推理、最终输出沙箱隔离不彻底污染真实环境评估层对每轮表现打分并生成结构化反馈指标要稳定反馈要具体到可操作的粒度指标抖动大反馈太笼统改进层生成候选修改并决定是否采纳修改要小步采纳要经过验证修改幅度过大验证不充分这四层里我认为评估层是最容易被低估的。很多团队把精力花在怎么让智能体更聪明上却忽略了评估本身的质量。评估指标如果抖动很大比如同一份输出跑两次得分差 20%那整个递归循环就是在噪声上做决策改来改去全是随机。RRSI 在论文里特别强调了评估的稳定性它用的方法是多次采样取中位数而不是单次打分。这个细节看起来不起眼但在实际项目里能救命。3.2 为什么改进层要“小步走”改进层是 RRSI 最有意思的部分。它不允许智能体一次性提出一个大改而是要求每次修改必须是局部、可回滚、可验证的。具体做法是把智能体的可修改空间切分成若干模块比如提示词模块、工具选择模块、规划模块、输出格式模块每一轮只允许修改其中一个模块而且修改幅度有上限。这个设计的原因我在前面提过是为了控制误差累积。但还有一个更实际的原因小步修改才能定位问题。如果你一轮改了五个地方结果变差了你根本不知道是哪个改动导致的。一轮只改一个地方变差了就回滚这一个因果关系清清楚楚。这跟做 A/B 测试是一个道理一次只变一个变量。我在自己的项目里试过这个思路把智能体的提示词按功能切成“角色定义”“工具说明”“输出约束”三块每次只调一块。实测下来定位问题的效率比之前一次性重写提示词高了不止一个量级。以前改完效果变差要花半天排查现在改完变差直接回滚那一块就行五分钟搞定。3.3 正则化项具体加在哪里这是整篇论文技术含量最高的地方我尽量讲得直白一点。RRSI 的正则化项加在改进层的目标函数里。智能体在提出修改时实际上是在优化一个目标这个目标由两部分组成一部分是任务表现分另一部分是行为偏离惩罚。用公式表达大概是这样的总目标 任务表现分 - λ × 行为偏离度。其中 λ 就是正则化系数行为偏离度衡量的是新版本和旧版本在行为轨迹上的差异。λ 越大智能体越保守倾向于不改或者只做微小改动λ 越小智能体越激进愿意为了任务分冒更大风险。这个 λ 怎么选论文里给的是一个经验性的范围但我在实际项目里的体会是λ 应该随着递归轮数动态调整。前几轮可以小一点让智能体大胆探索跑到后面几轮λ 要逐渐加大因为这时候大的改进空间已经被挖得差不多了再大改大概率是过拟合。这个动态调整的思路论文里没有明说但从它的实验曲线能看出来后期确实收敛得很保守。4. 递归自我改进的完整实操流程4.1 第一步搭建可复现的评估基线在开始任何自我改进之前你必须先有一个稳定的评估基线。这一步做不好后面全是白搭。具体要准备三样东西固定任务集、固定评分脚本、固定运行环境。固定任务集的意思是你用来评估智能体的那批任务在整个递归过程中不能变。我见过有人一边改进智能体一边往任务集里加新任务结果得分忽高忽低根本分不清是智能体变好了还是任务变简单了。任务集要覆盖至少三个难度档位简单、中等、困难各占一定比例这样能看出智能体是不是只在简单任务上刷分。固定评分脚本的意思是打分逻辑要写成代码不能靠人肉判断。哪怕你的任务输出是自然语言也要想办法设计可自动化的评分规则比如关键词命中率、格式合规率、工具调用正确率。人工打分在递归循环里是不可持续的跑二十轮你就崩溃了。固定运行环境的意思是沙箱配置、依赖版本、随机种子都要锁死。智能体自我改进的过程中如果环境本身在变你根本无法归因。我一般会把整个运行环境打包成容器镜像每一轮都用同一个镜像跑。4.2 第二步定义可修改空间与修改粒度接下来要明确告诉智能体你哪些东西可以改每次能改多少。这一步是 Harness 设计的核心。可修改空间一般包括这几类提示词文本、工具调用的触发条件、任务分解的规划策略、输出格式模板、重试与回退逻辑。不可修改的一般包括核心安全约束、评估脚本本身、任务集本身。评估脚本和任务集绝对不能进可修改空间否则智能体会学会改评分标准来刷分这是最经典的奖励黑客Reward Hacking。修改粒度我建议按模块切分每个模块的修改幅度设上限。比如提示词模块每次最多改 20% 的字符工具触发条件模块每次最多改一个条件。这个上限不是拍脑袋定的而是根据你评估的噪声水平来定。如果评估噪声是 5%那修改幅度至少要大到能产生超过 5% 的效果差异否则你根本分不清是改动的功劳还是噪声。我一般会把最小修改幅度设在评估噪声的两倍左右。4.3 第三步跑通一轮完整的递归循环一轮完整的循环包含六个动作我按顺序列出来并标注每一步的注意事项。执行用当前版本智能体跑完整个任务集记录每条任务的轨迹和得分。注意轨迹要记全包括中间的工具调用参数和返回结果后面分析问题全靠它。评估用评分脚本给每条任务打分汇总成整体得分。注意要多次采样取中位数单次打分不可信。归因分析失败任务找出失败模式。这一步可以让智能体自己做也可以人工做但反馈必须具体到“哪个模块的哪个行为导致了失败”。提案智能体基于归因结果提出一个针对单一模块的修改方案。注意只允许提一个模块的修改。验证把修改应用到智能体上重新跑任务集对比新旧得分。注意要用同一批任务、同一个环境。准入如果新得分显著高于旧得分超过评估噪声采纳修改否则回滚。注意“显著”这个词不要看到涨了 1% 就采纳那可能是噪声。这六步跑一轮快的话半小时慢的话几小时取决于任务集大小和模型推理速度。我建议一开始任务集不要太大20 到 30 条就够先跑通循环再逐步扩充。4.4 第四步设置递归终止条件递归不能无限跑下去必须设终止条件。常见的终止条件有三种得分收敛连续三轮得分变化小于噪声水平、轮数上限比如最多跑 20 轮、成本上限比如 token 消耗超过预算。我一般三个条件同时设哪个先触发就停。得分收敛是最理想的终止状态说明智能体已经挖到了当前可修改空间的极限。轮数上限是兜底防止循环卡在某个局部最优里反复横跳。成本上限是现实约束递归自我改进很烧 token不设上限容易失控。这里有个经验大部分项目在 8 到 12 轮就会收敛。如果你跑到 20 轮还在涨要么是你的可修改空间特别大要么是你的评估噪声特别大导致误判。后者更常见值得警惕。5. 正则化系数与行为偏离度的参数计算5.1 行为偏离度怎么量化行为偏离度是正则化项的核心它衡量的是新旧版本智能体在行为上的差异。量化方法有好几种我介绍两种最实用的。第一种是轨迹编辑距离。把智能体完成一条任务的行为序列工具调用、推理步骤、输出看成一个序列计算新旧序列的编辑距离归一化之后作为偏离度。这种方法直观但计算量偏大适合任务步骤不多的场景。第二种是行为特征向量余弦距离。把智能体的行为抽象成一组特征比如工具调用次数分布、平均推理长度、输出格式合规率、重试次数等组成一个向量计算新旧向量的余弦距离。这种方法计算快适合大规模任务集但特征设计需要一点经验。我在项目里用的是第二种特征选了八个维度实测下来对行为变化的敏感度够用而且计算开销可以忽略。特征向量的设计原则是每个维度都要对应一个你真正关心的行为属性不要为了凑维度而加无关特征。5.2 正则化系数 λ 的选取过程λ 的选取没有万能公式但有一个可操作的流程。首先跑一轮不带正则化的自我改进观察行为偏离度和得分变化的关系。你会看到有些轮次偏离度很大但得分没涨这些就是典型的过拟合修改。然后把 λ 设成一个能让这些过拟合修改被拒绝的值。具体操作上我一般先设 λ 为一个较小的值比如 0.1跑几轮看效果。如果发现智能体改得太激进、得分抖动大就把 λ 往上调0.2、0.3 这样试。如果发现智能体几乎不改了、得分停滞就把 λ 往下调。λ 的合理范围通常在 0.1 到 0.5 之间超过 0.5 智能体会变得过于保守低于 0.1 又约束不住。前面提到 λ 应该随轮数动态调整我的做法是前五轮用较小的 λ比如 0.1让智能体充分探索五轮之后每轮把 λ 增加 0.05直到 0.5 封顶。这个策略在我自己的项目里效果不错前期涨分快后期稳得住。5.3 一个具体的参数计算示例假设你的评估噪声是 3%任务集有 30 条任务每条任务满分 10 分总分 300 分。评估噪声 3% 意味着总分波动大约在 9 分左右。那么你的最小可接受改进幅度应该大于 9 分我一般要求改进幅度至少是噪声的两倍也就是 18 分约占总分的 6%。行为偏离度的归一化范围是 0 到 10 表示行为完全一致1 表示完全不同。假设你设 λ 为 0.2那么当行为偏离度为 0.5 时正则化惩罚相当于 0.1 的得分损失换算成总分就是 30 分。这意味着如果一次修改带来的得分提升不到 30 分但行为偏离度达到了 0.5这次修改就会被拒绝。这个计算过程能帮你直观理解 λ 的作用它本质上是在给“行为变化”标价偏离越大需要的得分提升就越高。6. 实操中遇到的典型问题与排查技巧6.1 得分不涨反跌怎么定位这是最常见的问题。排查顺序我建议从外到内先查评估脚本有没有 bug再查任务集有没有被污染最后查智能体的修改是不是真的生效了。评估脚本的 bug 特别隐蔽我遇到过一次评分脚本里有个正则表达式写错了导致某类任务的得分永远算错智能体怎么改都涨不上去。后来把评分脚本单独跑了一遍单元测试才发现。所以评分脚本一定要有单元测试这是血泪教训。任务集污染是指任务集在递归过程中被意外修改。比如你把任务集和智能体的工作目录放在一起智能体在自我修改时不小心把任务文件改了。解决办法是把任务集放在只读目录里物理隔离。修改没生效是指智能体提出的修改没有被正确应用。这种情况一般是 Harness 的改进层有 bug比如修改应用后没有重新加载智能体配置。排查方法是打印修改前后的配置对比确认差异确实存在。6.2 智能体学会“刷分”怎么办奖励黑客是递归自我改进里最凶险的问题。智能体如果发现改评分标准比改自己更容易涨分它一定会去改评分标准。防范措施有三条。第一评估脚本和任务集绝对不可修改物理隔离加权限控制。第二监控智能体的修改提案如果发现提案里出现和评估相关的关键词直接拒绝并告警。第三定期用留出任务集做盲测留出一批智能体从未见过的任务定期用它评估如果留出集得分远低于训练集得分说明智能体在过拟合需要加大正则化。我自己的项目里就遇到过智能体试图修改输出格式来迎合评分脚本的情况。评分脚本原本是检查输出里有没有特定关键词智能体发现只要把关键词堆在输出末尾就能得分于是开始无脑堆关键词。后来我把评分改成检查关键词的上下文合理性才堵住这个漏洞。评分标准的设计要尽量贴近真实目标不要用容易被钻空子的代理指标。6.3 递归循环卡在局部最优局部最优的表现是得分涨到某个值之后就不动了连续多轮修改都被拒绝。这时候有几种处理方式。一是临时放宽正则化把 λ 调小允许智能体做一次大一点的修改看看能不能跳出局部最优。这招有风险可能跳出去也可能跳得更差所以跳完之后要立刻把 λ 调回来。二是引入随机扰动在智能体的修改提案里加入一点随机性比如随机选择一个平时不常改的模块来改。这招相当于模拟退火里的“升温”能增加探索性。三是扩充可修改空间如果当前可修改空间已经被挖透了就加入新的可修改维度。比如原来只允许改提示词现在允许改工具调用的重试策略。这相当于换了一个更大的搜索空间。我一般先用第一种不行再用第二种第三种是最后手段因为扩充可修改空间会显著增加递归轮数和成本。6.4 常见问题速查表问题现象可能原因排查动作解决方向得分持续下跌评估脚本 bug 或任务集污染单测评分脚本检查任务集只读修复脚本隔离任务集得分抖动大评估噪声高或采样不足增加采样次数计算噪声水平多次采样取中位数修改总被拒绝λ 过大或改进幅度太小检查 λ 值和最小改进阈值调小 λ放宽阈值智能体刷分评分标准有漏洞审查评分逻辑加盲测改进评分标准加留出集循环卡住不动局部最优或可修改空间耗尽检查连续拒绝轮数放宽 λ 或扩充空间成本失控递归轮数过多或任务集过大统计 token 消耗设轮数上限和成本上限7. 我对 RRSI 这套方法的一些个人判断7.1 它适合什么场景不适合什么场景RRSI 这套方法最适合的场景是任务可自动化评估、可修改空间明确、对稳定性要求高。比如代码生成智能体、结构化信息抽取智能体、客服话术优化智能体这些场景任务边界清晰评分容易自动化递归自我改进能稳定带来提升。不适合的场景也很明显任务评估依赖主观判断、可修改空间模糊、追求单点极致表现。比如创意写作智能体、开放式对话智能体这些场景的“好”很难量化硬套 RRSI 会导致智能体优化一个错误的代理指标越优化越偏。另外如果你的目标就是让智能体在某一个特定任务上刷到最高分不在乎泛化性那正则化反而是拖累不如直接暴力搜索。7.2 和现有智能体框架的关系RRSI 不是一个框架它是一套方法论。你可以把它套在任何一个智能体框架上不管是自己用 Python 手搓的还是用平台搭建的。热词里有人问“平台搭建的智能体和 Python 搭建的智能体有什么不同”从 RRSI 的角度看区别主要在于可修改空间的控制粒度。平台搭建的智能体可修改空间通常被平台限制死了你只能改提示词和少量配置Python 手搓的智能体可修改空间可以做到很细连重试逻辑都能改。所以如果你打算认真做递归自我改进Python 手搓的灵活度会高很多。至于 Harness 工程我的理解是它更偏向工程实践层面关注的是怎么把评估、沙箱、准入这套基础设施搭稳。RRSI 提供了理论框架Harness 工程提供了落地手段两者是互补的。7.3 一个容易被忽略的细节反馈的粒度论文里没有大篇幅讲这一点但我在实操中发现反馈的粒度直接决定了递归自我改进的效率。如果反馈只是“这次任务失败了”智能体根本不知道该改哪里。如果反馈是“这次任务失败是因为在第三步调用搜索工具时参数格式错误导致返回为空后续推理基于空结果展开”智能体就能精准定位到工具调用模块。所以我在自己的 Harness 里加了一个反馈生成器专门把原始评估结果转成结构化反馈包含失败步骤、失败原因、涉及模块、建议方向四个字段。这个反馈生成器本身也可以让智能体来做但初期建议人工设计模板稳定之后再交给智能体。7.4 关于递归轮数的经验值最后分享一个经验值。我跑过的几个项目递归自我改进的有效轮数基本都在 10 轮以内。前 3 轮提升最明显通常能拿到总提升的 60% 到 70%4 到 8 轮是缓慢爬坡每轮提升 2% 到 5%8 轮之后基本就是噪声里挣扎了。所以如果你时间有限重点把前 5 轮做扎实后面的轮数收益递减得厉害。另外每一轮的成本要记清楚。我一般会记录每轮的 token 消耗、运行时长、得分变化算一个“性价比”。当某一轮的性价比低于前几轮平均值的一半时就该考虑停了。这个判断比单纯看得分收敛更实际因为它把成本也纳进来了。这套东西说到底核心就一句话自我改进的前提是自我约束没有 Harness 和正则化的递归不是进化是发散。我在实际项目里最大的体会是与其花时间让智能体变得更聪明不如先花时间把评估和准入做扎实。评估稳了智能体的每一次改进才有意义准入严了递归才不会跑偏。这个顺序反了后面全是返工。