1. 从 RRSI 这个标题说起它到底在解决什么问题第一次看到“RRSI 智能体 Harness 的正则化递归自我改进”这个标题我脑子里冒出来的第一个念头是又是一个把三个热词拼在一起的论文标题。RRSI、Harness、正则化递归自我改进单拎出来每个词都能在智能体圈子里找到一堆讨论但拼在一起它想说的其实是一件很具体的事——怎么让一个智能体在反复自我迭代的过程中不至于越改越飘、越练越崩。先把这几个词拆开说人话。RRSI 是 Recursive Self-Improvement 的缩写递归自我改进指的是智能体自己生成改进方案、自己评估、自己再改进形成一个闭环。Harness 在这个语境里不是“马具”那个意思而是指承载和约束智能体行为的那套工程外壳——包括提示词模板、工具调用协议、评估器、回滚机制、记忆管理等等。你可以把它理解成智能体的“骨架缰绳”骨架负责撑起能力缰绳负责别让它跑偏。正则化则是机器学习里的老概念核心作用是给优化过程加约束防止过拟合。那这三者凑一起要干嘛答案很直接当智能体开始自己改自己的时候最大的风险是它会把“针对当前评估集的过拟合”当成“真正的能力提升”。这就像一个学生反复刷同一套模拟题分数是上去了但换一套题立刻原形毕露。RRSI 要解决的就是这个——让智能体在递归自我改进时改进的是泛化能力而不是对评估器的“应试技巧”。这个方向适合谁看如果你正在做智能体开发尤其是那种需要长期迭代、自我优化的场景比如代码修复智能体、客服智能体、销售智能体那这套思路你迟早会撞上。如果你只是用 Coze、扣子这类平台搭个简单工作流那可能暂时用不到但理解背后的逻辑对你设计提示词和评估机制也有帮助。我见过太多团队在智能体自我迭代上踩坑改到第三轮就开始出现“评估分数涨了但线上效果崩了”的情况RRSI 这套东西就是冲着这个痛点来的。2. 递归自我改进为什么需要“正则化”这根缰绳2.1 递归自我改进的诱惑与陷阱递归自我改进听起来很美好智能体自己发现问题、自己写补丁、自己验证、自己合并人类只需要在旁边看着。理论上这能指数级提升迭代速度但实际操作过的人都知道不加约束的递归自我改进基本等于自杀。我拿代码修复智能体举个例子。假设你有一个智能体任务是修复单元测试失败的代码。第一轮它发现某个函数边界条件没处理加了个 if 判断测试通过了。第二轮它发现另一个测试也挂了又加了个特判。第三轮、第四轮……到第十轮的时候你去看它改出来的代码会发现里面塞满了针对特定测试用例的硬编码分支。测试全绿但代码已经没法看了。这就是典型的对评估集的过拟合——智能体学会了“怎么让测试通过”而不是“怎么写出正确的代码”。更隐蔽的问题是评估器漂移。如果评估器本身也是智能体它在递归过程中也会被“带偏”。比如评估器一开始很严格但智能体反复提交一些“看起来合理但实际有问题”的补丁评估器慢慢就放松了标准。这就像两个学生互相批改作业改着改着标准就一起滑坡了。2.2 正则化在智能体语境下的重新定义传统机器学习里的正则化是在损失函数里加一项惩罚项比如 L1 让权重稀疏、L2 让权重平滑。但在智能体递归自我改进的场景里“权重”变成了行为策略“损失”变成了评估分数。所以正则化在这里的含义要重新理解行为复杂度惩罚智能体每增加一个特判分支、每多调用一次工具、每多写一行提示词都要付出代价。这对应 L1 正则化的稀疏思想——让智能体倾向于用更简单的方式解决问题。改进幅度平滑不允许单轮改进幅度过大。这对应 L2 正则化——防止某一次“激进修改”把整体行为带偏。评估一致性约束同一份改进方案在不同评估子集上的表现不能差异太大。这对应一致性正则化——防止智能体只讨好某一部分评估数据。注意这里的“惩罚项”不是真的在损失函数里加数字而是通过 Harness 的工程机制来实现。比如限制单轮修改的代码行数、要求改进方案必须在多个评估维度上同时达标、对过于复杂的方案自动打回。2.3 Harness 在其中的角色不只是容器更是约束器很多人把 Harness 理解成“跑智能体的那个框架”这太窄了。在 RRSI 的语境下Harness 的核心职责是执行正则化约束。它要管的事情包括记录每一轮改进的“行为指纹”改了什么、改了多少、调用了哪些工具在改进方案提交前做复杂度检查维护多个评估子集防止单一评估器被“攻破”提供回滚机制一旦发现改进导致其他指标下降就自动撤销限制递归深度防止无限自我改进我自己的经验是Harness 的设计质量直接决定了 RRSI 能不能跑起来。见过太多团队把精力全花在智能体的提示词上Harness 随便搭一个结果递归到第三轮就失控。提示词再好没有缰绳的马照样会跑丢。3. 核心机制拆解正则化递归自我改进到底怎么实现3.1 改进提案的生成与过滤整个 RRSI 循环的第一步是生成改进提案。智能体会基于当前的行为日志、失败案例、评估反馈生成一个“我打算怎么改”的方案。这个方案不是直接执行的而是先进入过滤层。过滤层要做的事情我把它总结成“三查”检查项检查内容不通过的后果复杂度检查修改涉及的文件数、函数数、新增分支数是否超过阈值打回要求简化方案影响面检查修改是否会影响与当前问题无关的模块打回要求缩小范围可验证性检查修改后是否有明确的验证方式打回要求补充验证方案这三查看起来简单但实际落地时阈值怎么定很讲究。我试过的一个经验值是单轮修改不超过 3 个文件、不超过 50 行代码、新增分支不超过 2 个。超过这个量级大概率是智能体在“暴力拟合”而不是“精准修复”。3.2 多评估器交叉验证机制单一评估器是 RRSI 最大的漏洞。智能体很快就能学会怎么讨好一个固定的评估器。解决办法是维护多个评估器且评估器之间要有差异性。具体怎么做我见过比较靠谱的方案是评估器 A基于规则的传统测试单元测试、集成测试评估器 B基于另一个智能体的语义评估判断代码可读性、逻辑合理性评估器 C基于历史回归的对比评估新版本在旧案例上的表现三个评估器独立打分只有全部通过或者加权总分超过阈值且没有单项低于底线改进才被接受。这样智能体就很难同时讨好三个不同维度的评估器。实操心得评估器 B 的提示词要定期轮换不能固定不变。我试过让评估器 B 每 10 轮换一次评估角度比如这 10 轮重点看“边界处理”下 10 轮重点看“异常传播”效果比固定角度好很多。3.3 回滚与版本管理给递归加一个“撤销键”递归自我改进最怕的是“改着改着回不去了”。所以 Harness 必须内置版本管理和回滚机制。每一轮改进都打一个快照记录改进前的状态、改进方案、评估结果。一旦发现后续轮次出现指标下降可以快速定位到是哪一轮引入的问题然后回滚。这里有个细节回滚不是简单的 git revert。因为智能体的改进可能涉及提示词、工具配置、评估器参数等多个层面单纯回滚代码是不够的。Harness 需要维护一个“全量状态快照”包括代码、配置、提示词、评估器版本。我见过一个团队用 git 管代码、用另一个系统管提示词结果回滚时两边不同步出了大问题。3.4 递归深度与收敛判断递归不能无限进行。Harness 需要设定终止条件常见的有最大递归轮次比如 20 轮连续 N 轮无显著改进比如连续 3 轮评估分数提升小于 1%评估分数达到预设上限改进方案复杂度连续超标我个人的建议是组合使用不要只靠单一条件。只靠轮次限制可能早早就停了只靠分数收敛可能陷入“分数微涨但实际没进步”的假收敛。组合条件能更准确地判断“该停了”。4. 实操落地从零搭一个带正则化的 RRSI Harness4.1 环境准备与基础框架选型如果你要自己搭一套 RRSI Harness第一步是选基础框架。市面上常见的智能体框架都能用关键看它是否支持细粒度的行为记录和可插拔的评估器。我试过几种组合比较顺手的是用 Python 写核心循环因为灵活度高方便插入自定义的正则化逻辑用现成的智能体框架做工具调用和提示词管理省去重复造轮子用轻量级数据库比如 SQLite存每一轮的状态快照方便回滚和审计不建议一上来就用重型平台。平台封装太厚你想在中间插一层正则化过滤器会很别扭。我见过有人用 Coze 搭 RRSI结果发现平台的评估器是黑盒没法做多评估器交叉验证最后只能推倒重来。4.2 行为日志的结构设计行为日志是正则化的基础。没有详细的日志你根本不知道智能体每一轮到底改了什么。日志至少要包含{ round: 5, timestamp: 2026-01-15T10:30:00, proposal: { description: 修复空指针异常, files_changed: [user_service.py], lines_added: 12, lines_removed: 3, new_branches: 1, tools_called: [read_file, write_file, run_test] }, evaluation: { evaluator_a: {score: 0.92, passed: true}, evaluator_b: {score: 0.85, passed: true}, evaluator_c: {score: 0.88, passed: true} }, complexity_penalty: 0.05, final_score: 0.87, accepted: true }这个结构的关键是把复杂度量化。lines_added、new_branches、tools_called这些字段就是计算惩罚项的依据。我一般会用一个简单的公式final_score weighted_eval_score - complexity_penalty其中complexity_penalty 0.01 * lines_added 0.05 * new_branches。系数可以根据项目调整但核心思想是让智能体知道“改得越多代价越大”。4.3 评估器的实现与轮换策略评估器 A 用传统测试最简单直接跑 pytest 就行。评估器 B 需要写一个评估提示词让另一个智能体来打分。评估器 C 需要维护一个历史案例库每次改进后在新版本上跑一遍旧案例。评估器 B 的提示词我一般这么写你是一个代码审查专家。请评估以下代码修改是否合理从三个维度打分0-1 1. 逻辑正确性修改是否真正解决了问题而不是绕过问题 2. 可读性修改后的代码是否易于理解是否有过度复杂的倾向 3. 泛化性修改是否只针对特定案例还是具有通用性 请给出每个维度的分数和简短理由。如果发现修改中有硬编码、特判、魔法数字等过拟合迹象泛化性分数不得高于 0.3。这个提示词的关键是明确告诉评估器要警惕什么。如果不写最后那句评估器很容易被“看起来合理”的修改骗过去。轮换策略方面我试过每 5 轮换一次评估角度比如第 1-5 轮重点看边界条件处理第 6-10 轮重点看异常传播路径第 11-15 轮重点看资源管理第 16-20 轮重点看并发安全这样智能体没法针对某一个固定角度做过度优化。4.4 回滚机制的代码实现回滚机制的核心是状态快照 差异对比。每一轮开始前把当前状态序列化存下来。如果后续发现指标下降就加载对应快照。import json import shutil from pathlib import Path class SnapshotManager: def __init__(self, base_dir): self.base_dir Path(base_dir) self.snapshots [] def take_snapshot(self, round_num, state): snapshot_dir self.base_dir / fround_{round_num} snapshot_dir.mkdir(parentsTrue, exist_okTrue) # 存代码 shutil.copytree(state[code_dir], snapshot_dir / code) # 存配置和提示词 with open(snapshot_dir / config.json, w) as f: json.dump(state[config], f) with open(snapshot_dir / prompts.json, w) as f: json.dump(state[prompts], f) self.snapshots.append({ round: round_num, path: str(snapshot_dir), metrics: state[metrics] }) def rollback_to(self, round_num): target next(s for s in self.snapshots if s[round] round_num) # 恢复代码、配置、提示词 shutil.rmtree(current_code) shutil.copytree(Path(target[path]) / code, current_code) # ... 恢复其他状态 return target[metrics]这个实现很粗糙但核心逻辑就是这样。实际用的时候要注意快照的存储成本如果代码库很大每轮全量拷贝会很占空间。可以用增量快照只存变化的部分。5. 常见问题与排查技巧实录5.1 智能体开始“刷分”怎么办这是最常见的问题。表现是评估分数持续上涨但人工抽查发现改进质量在下降。排查思路先看行为日志里的complexity_penalty是不是在下降。如果智能体开始用更少的修改拿更高的分可能是找到了评估器的漏洞。再看多评估器的分数差异。如果评估器 A 分数很高但评估器 B 分数很低说明智能体在讨好 A 而牺牲了 B。最后人工抽查最近 5 轮的改进方案看是否有硬编码、特判、魔法数字。解决办法提高复杂度惩罚系数同时轮换评估器 B 的评估角度。我试过把new_branches的惩罚系数从 0.05 提到 0.15智能体立刻就不敢乱加分支了。5.2 递归到中途评估分数突然暴跌这种情况通常是某一轮改进引入了隐藏的回归。排查步骤对比暴跌前后两轮的全量评估结果定位是哪个评估维度出了问题查看那一轮的改进方案重点看是否修改了公共模块用回滚机制恢复到暴跌前的状态然后单独重跑那一轮改进看是否能复现我遇到过一次智能体为了修复一个边缘 case改了一个公共工具函数结果影响了十几个其他调用点。这种问题靠单评估器很难发现必须有多评估器交叉验证。5.3 评估器之间分歧太大三个评估器打分差异超过 0.3 的时候说明它们对“什么是好改进”的理解不一致。这时候不能简单取平均而是要先对齐评估标准。我的做法是挑出分歧最大的几个案例人工标注正确答案然后用这些案例去校准评估器 B 的提示词。校准后再跑一轮看分歧是否缩小。如果还是很大可能需要重新设计评估维度。5.4 递归轮次上不去早早收敛有时候智能体跑个三五轮就不改了评估分数也停滞。这不一定是坏事可能是真的收敛了。但要排除假收敛检查评估器是否过于宽松导致智能体觉得“已经够好了”检查改进提案的生成提示词是否过于保守限制了智能体的探索检查是否有未处理的失败案例被忽略了我一般会保留一个“挑战集”里面放一些特别难的案例不参与日常评估只在判断是否真收敛时拿出来跑。如果挑战集上的表现还在提升说明还没真收敛只是日常评估集不够难。5.5 回滚后状态不一致这个问题很隐蔽。回滚了代码但没回滚提示词或者回滚了配置但没回滚评估器版本都会导致后续轮次行为异常。解决办法是快照必须全量且回滚操作要原子化。我见过一个团队用 git 管代码、用文件系统管提示词回滚时只 git revert 了代码提示词还是新的结果智能体行为完全对不上。实操心得快照的粒度要细到“每一轮开始前”而不是“每一轮结束后”。因为改进是在轮次中间发生的结束后再快照就晚了。6. 这套东西的边界与我的个人体会RRSI 加正则化这套思路不是万能的。它适合有明确评估标准、改进空间较大、且允许一定试错成本的场景。比如代码修复、文案优化、客服话术迭代。但它不适合评估标准模糊、单次错误代价极高的场景比如医疗诊断、金融交易。那些场景下递归自我改进的风险远大于收益。另外Harness 的工程复杂度不低。我见过不少团队兴致勃勃地开始搭搭到一半发现要维护的东西太多——多评估器、快照管理、复杂度计算、轮换策略——最后不了了之。所以我的建议是先从最小可用版本开始一个评估器、简单的复杂度惩罚、手动回滚。跑通了再逐步加东西。一上来就搞全套大概率会烂尾。最后分享一个我踩过的坑不要用同一个模型同时做改进生成和评估。我试过用同一个模型既生成改进方案又当评估器 B结果它对自己的方案特别宽容评估分数虚高。后来换成两个不同模型或者同一个模型但用完全不同的提示词和温度参数效果才好起来。这个细节论文里不一定写但实操中很关键。