1. 从自我改进到可控自我改进RRSI 要解决的真问题智能体领域这两年最不缺的就是新概念。每隔几周就会冒出一个新词声称能让智能体自己变强。但真正做过智能体落地的人都知道一个能自我改进的系统最大的风险从来不是改不动而是改飞了——它在某一轮迭代里突然找到了一个捷径指标飙升然后下一轮直接崩盘。RRSIRegularized Recursive Self-Improvement正则化递归自我改进这个方向之所以值得单独拿出来聊就是因为它正面回应了这个痛点。先把 RRSI 拆开看。Recursive Self-Improvement指的是智能体利用自身的输出、反馈或评估结果去修改自己的提示词、策略、工具调用逻辑甚至子模块结构然后在新版本上继续产生数据、继续改进形成一个递归闭环。Regularized则是给这个闭环加约束防止它在递归过程中偏离原始目标、过拟合短期反馈、或者把能力收敛到一个脆弱的局部最优。而Harness在这个语境里指的是承载这套机制的工程外壳——它负责调度、记录、评估、回滚、约束注入是让自我改进从论文里的公式变成可运行系统的关键一层。很多人第一次接触 Harness 这个词会困惑觉得它和 Agent 框架是不是一回事。这里必须说清楚Agent 框架解决的是智能体怎么跑起来Harness 解决的是智能体怎么被约束着、被观测着、被安全地迭代。前者是发动机后者是测试台加安全带加行车记录仪。你可以用一个很成熟的 Agent 框架把智能体跑得很顺但如果没有 Harness 这一层你根本不知道它每一轮改进到底改了什么、为什么改、改完之后是不是还认得原来的任务。RRSI 的核心价值在于它把自我改进从一个开放式的、容易失控的过程变成了一个带正则项约束的优化过程。这个思路其实不新鲜机器学习里早就有正则化防止过拟合但把它搬到智能体的递归迭代上并且用 Harness 工程化地实现出来是这篇工作真正有意思的地方。它适合谁来读我认为三类人最该关注一是正在做智能体长期迭代、被越改越差折磨过的开发者二是负责智能体质量与安全的工程同学三是想理解自我改进到底该怎么落地、而不是停留在概念层面的人。接下来的内容我会围绕 RRSI 的机制拆解、Harness 的工程职责、正则化到底在约束什么、以及实际落地时会踩的坑一层层展开。不堆公式重点讲清楚为什么这么设计和你复现时要注意什么。2. RRSI 的递归闭环每一轮到底发生了什么2.1 递归自我改进的基本循环要理解 RRSI先得把递归这两个字落到实处。一个典型的 RRSI 循环大致是这样一条链路当前版本的智能体在任务集上运行产生轨迹trajectory、结果和中间反馈。评估模块对这些轨迹打分得到本轮的性能信号。改进模块基于性能信号生成对智能体本身的修改提案——可能是提示词调整、工具选择策略变化、子任务分解方式变化甚至是新增一个校验步骤。修改提案经过正则化约束的筛选只有满足约束的才被接受。接受后的新版本成为下一轮的起点回到第 1 步。这个循环看起来简单但真正难的是第 3 步和第 4 步。第 3 步难在改什么智能体可以改的东西太多了提示词、温度、工具集、记忆结构、规划粒度如果没有任何引导改进模块很容易陷入盲目试错。第 4 步难在凭什么接受这个改动如果只看本轮指标那几乎必然会过拟合——智能体可能只是学会了在当前这批任务上取巧换一批任务就原形毕露。我见过不少团队自己搭的自我改进系统本质上就是让模型自己写一版新提示词跑一遍分高了就留下。这种做法在头几轮往往效果惊人因为模型确实能发现一些人类没注意到的表述优化。但跑到第五轮、第六轮问题就来了提示词越来越长、越来越具体、越来越像在背答案泛化能力断崖式下跌。这就是没有正则化的典型症状。2.2 为什么递归会放大风险递归这个词本身就意味着误差会被累积和放大。单轮改进里一个不起眼的小偏差经过多轮迭代后可能被放大成系统性偏移。举个具体的例子假设某一轮改进模块发现在回答前先输出一段免责声明能略微提升评估分数因为评估器对谨慎措辞有偏好。这个改动本身无害但它被接受后下一轮的改进模块会在这个基础上继续优化可能演变成输出大量免责声明再下一轮变成用免责声明替代实质回答。三轮之后智能体的核心能力已经被侵蚀但每一轮的局部指标可能都是上升的。这种指标上升、能力下降的背离是递归自我改进最危险的失败模式。它不像崩溃那样显眼而是温水煮青蛙。RRSI 里的正则化本质上就是给这个过程装一个偏离检测器让系统在每一轮都能感知到自己离原始目标有多远而不是只盯着当前分数。2.3 Harness 在循环中的位置把 Harness 放进这个循环里看它的职责就清晰了。Harness 不是改进算法本身而是承载整个循环运行的基础设施。它至少要负责四件事轨迹记录完整保存每一轮智能体的输入、输出、工具调用、中间状态这是后续评估和改进的数据基础。评估调度组织评估任务可能包括自动指标、模型评审、人工抽检并把结果结构化。约束注入在改进提案被接受前施加正则化约束拦截那些局部得分高但偏离目标的改动。版本管理维护每一版智能体的快照支持回滚和对比确保任何一轮改动都可追溯、可撤销。这四件事里约束注入是 RRSI 区别于普通自我改进系统的关键。没有它Harness 就只是一个自动化跑分工具有了它Harness 才成为可控自我改进的执行者。提示如果你正在自建类似的系统先把轨迹记录和版本管理做扎实。很多团队一上来就急着做自动改进结果出了问题连上一版长什么样都找不回来排查成本极高。3. 正则化到底在约束什么三个维度的拆解3.1 约束一与原始目标的一致性第一个也是最核心的约束是改进后的智能体不能偏离原始任务目标。这里的目标不是指某一条具体指令而是指智能体被设计出来要解决的那类问题的本质。比如一个代码审查智能体它的原始目标是发现代码中的真实缺陷而不是让开发者满意或输出足够多的评论。在 RRSI 里这个约束通常通过一个参考分布或参考行为来度量。具体做法是保留一个锚定版本通常是人工精心设计的初始版本或某个稳定版本在每一轮改进后比较新版本和锚定版本在核心任务上的行为差异。如果差异超过阈值即使新版本分数更高也要被拦截或降权。这个思路和弹性网正则化里既要拟合又要保持系数简洁的逻辑是相通的——你既要让智能体变强又要让它别变得面目全非。一致性正则化机制在这里的作用就是给变强设一个方向而不是让它自由漂移。3.2 约束二改进幅度的平滑性第二个约束是单轮改进的幅度不能太大。这一点很多人会忽略觉得改得越多越好。但递归系统里大步长是灾难的源头。原因很简单如果一轮改动太大你根本无法判断到底是哪个改动带来了收益也无法预测下一轮会往哪走。更糟的是大改动往往意味着智能体跳到了一个全新的行为区域而这个区域可能根本没有足够的评估数据支撑。RRSI 通常会用类似改动预算的机制来限制单轮修改的规模。比如限制提示词改动的 token 数、限制被修改的模块数量、或者要求改动必须是局部可解释的。这背后的逻辑和优化里用小学习率保证稳定收敛是一回事。慢一点但每一步都可控在递归系统里远比一步到位重要。3.3 约束三评估信号的多样性第三个约束针对的是评估本身。如果评估信号单一智能体很容易找到针对这个信号的作弊路径。RRSI 的做法是强制评估信号多样化比如同时使用自动指标、模型评审、以及一组留出任务held-out tasks来交叉验证。这里有个很实用的经验留出任务集必须定期轮换。我见过团队用一套固定的留出集跑了半年结果智能体在留出集上的表现越来越好但真实场景表现停滞不前——因为它已经把留出集也记住了。留出集一旦被间接优化就失去了正则化作用。轮换机制能保证评估信号始终带有新鲜度让改进模块无法针对特定样本取巧。把这三个约束放在一起看RRSI 的正则化其实是在三个维度上同时施加压力方向上不偏离目标步长上不激进评估上不单一。任何一个维度缺失递归过程都会变得脆弱。约束维度约束对象缺失后的典型症状常见实现手段目标一致性改进方向指标上升但核心能力退化锚定版本对比、行为差异度量改进平滑性单轮幅度无法归因、行为跳变改动预算、局部可解释要求评估多样性评估信号针对评估器取巧多信号交叉、留出集轮换4. Harness 工程实现从论文到能跑的系统4.1 轨迹数据结构的设计取舍Harness 的第一块硬骨头是轨迹数据的结构设计。论文里通常一笔带过但实际做的时候这个决定会影响后面所有环节。轨迹要记多细记太细存储和查询成本爆炸记太粗改进模块拿不到足够信息。我的经验是分层记录顶层记录任务标识、最终结果、总耗时、总成本中层记录每一步的动作类型和关键参数底层记录完整的原始输入输出。改进模块平时只看顶层和中层需要深挖时才下钻到底层。这样既控制了日常开销又保留了排查能力。另一个容易踩的坑是时间戳和版本号的耦合。轨迹必须和产生它的智能体版本严格绑定否则你根本不知道某条轨迹是哪个版本跑出来的。我建议在轨迹里同时记录版本号和该版本的哈希值双保险。曾经有个项目因为版本号复用导致改进模块把两个不同版本的轨迹混在一起分析得出了完全错误的结论排查了整整两天。4.2 评估调度的并发与成本控制评估是 Harness 里最烧钱的部分。每一轮改进都要在任务集上重新评估如果任务集大、评估器又是大模型成本会迅速失控。RRSI 的工程实现里评估调度必须做两件事并发化和采样化。并发化好理解就是把评估任务拆开并行跑。但要注意并发评估会带来结果一致性问题——同一个任务在不同并发批次里可能因为评估器的随机性得到不同分数。解决办法是固定评估器的随机种子或者对每个任务做多次评估取统计量。采样化则更关键。不需要每轮都在全量任务集上评估。可以用分层采样保证每轮评估覆盖核心任务类别但具体样本可以轮换。这样既控制了成本又天然实现了前面说的评估信号多样性。采样比例可以根据改进幅度动态调整改动大时多采样改动小时少采样。4.3 约束注入的拦截点设计约束注入放在哪里是个架构问题。放在改进提案生成之后、接受之前是最直接的做法。但更稳妥的设计是双拦截点一是在提案生成时做软约束引导改进模块往合规方向走二是在接受前做硬约束拦截越界提案。软约束可以通过在改进模块的提示词里明确列出约束条件来实现让模型在生成提案时就考虑边界。硬约束则是独立的校验逻辑不依赖模型自觉。两者缺一不可只有软约束模型可能忘记只有硬约束会产生大量被拒提案浪费算力。注意硬约束的阈值不要设得太死。我见过把一致性阈值设得极严的系统结果几乎所有改进提案都被拒递归循环直接停滞。阈值应该允许一定的探索空间宁可放过一些边缘提案也不要让系统失去改进能力。4.4 版本回滚与灰度验证RRSI 的递归特性决定了任何一轮改动都可能成为后续所有改动的基石所以版本管理必须支持快速回滚。但回滚不是简单的退回上一版因为上一版可能也是有问题的那一版。更合理的做法是维护一条版本谱系记录每个版本的来源、改动内容和评估结果回滚时可以选择回到任意一个历史节点。灰度验证是另一个实用手段。新版本不要直接全量替换而是先在一部分任务上运行观察一段时间再决定是否推广。这能有效拦截那些在评估集上表现好但真实场景翻车的改动。灰度期间要重点监控的不是分数而是行为分布的变化——比如工具调用频率、输出长度分布、错误类型分布这些比单一分数更能反映智能体的真实状态。5. 实操中真正会踩的坑5.1 改进模块的自我强化偏见这是我在实际项目里遇到的最隐蔽的问题。改进模块本身也是模型它有自己的偏好。如果它偏好某种风格的改动比如喜欢加长提示词那么经过多轮迭代智能体会系统性地往那个风格漂移而这种漂移和任务需求无关纯粹是改进模块的偏见。识别这个问题的办法是统计多轮改动的特征分布。如果发现改动集中在某一类操作上而这类操作并没有对应的性能收益那基本就是偏见在作祟。缓解手段包括在改进模块里引入多样性激励或者定期用不同的改进策略做对照实验。5.2 评估器的疲劳与漂移评估器如果是模型它自己也会疲劳——长时间评估同类任务后评分标准会不自觉漂移。今天给 8 分的回答一周后可能给 7 分不是因为回答变差了而是评估器的参照系变了。这种漂移会直接污染改进信号。应对办法是定期用固定锚点样本校准评估器。准备一组标准答案和对应分数每隔一段时间让评估器重新评一遍如果分数偏离基准超过阈值就说明评估器需要重新校准或更换。这个机制看起来笨但极其有效。5.3 递归深度与收益递减递归自我改进不是越深越好。实践中收益通常在前几轮最明显之后迅速递减而风险和成本却持续上升。我建议设置一个递归深度上限并且监控每轮的边际收益。当连续几轮的边际收益低于某个阈值时主动停止递归转入人工介入或策略调整。这个上限没有标准答案取决于任务复杂度和评估成本。但有个经验值可以参考如果连续三轮的改进幅度都小于第一轮的 10%基本可以判断进入了平台期继续递归性价比很低。5.4 约束与能力的权衡最后这个坑最哲学也最实际约束越强系统越安全但改进空间越小。RRSI 的正则化如果做得太保守智能体就只能在初始版本附近小修小补失去了自我改进的意义如果太宽松又会失控。这个平衡点没有公式可算只能通过实验找。我的做法是分阶段调整约束强度。早期放宽约束让系统快速探索积累改进经验中期收紧约束稳定行为后期维持中等约束做精细化优化。这种动态调整比固定阈值更贴合实际需求。6. 把 RRSI 思路用起来几个可落地的切入点不一定要完整复现论文里的系统RRSI 的几个核心思路可以拆开用在现有项目里。第一给你的智能体加一个锚定版本对比机制每次改动后自动对比新旧版本在核心任务上的行为差异差异过大就告警。这个成本很低但能拦住大部分改飞的情况。第二把评估信号多样化别只依赖一个指标至少加一个留出集和一个行为分布监控。第三给改进设预算限制单轮改动的规模让每一步都可归因。我个人在实际操作中的体会是RRSI 最大的启发不是某个具体算法而是它把自我改进当成一个需要被约束的优化过程来对待。这个视角一旦建立起来很多之前觉得玄学的问题——比如为什么智能体越改越差、为什么指标和体验背离——都会变得可分析、可干预。递归自我改进这条路肯定还要走很久但至少现在我们有了一个更清醒的框架去讨论它该怎么走。