1. 从 RRSI 说起智能体自我改进的“最后一公里”到底卡在哪智能体这两年火得一塌糊涂从最早的 ReAct 到后来的各种 Agent 框架大家把注意力几乎全放在了“怎么让模型多调几个工具、多走几步推理”上。但真正在一线做过智能体落地的人心里都清楚一个智能体能不能长期稳定地跑下去靠的不是它某一次任务完成得多漂亮而是它能不能在反复执行的过程中不退化、不跑偏、不把自己越改越傻。谷歌这篇关于 RRSI 的论文讨论的正是这个被大多数人忽略的“最后一公里”问题。RRSI 全称是 Regularized Recursive Self-Improvement翻译过来就是“正则化递归自我改进”。名字听着学术但拆开看其实很朴素递归自我改进说的是智能体自己改自己、自己优化自己的提示词或策略正则化说的是给这个自我改进的过程套上一个约束防止它改着改着就发散、过拟合、或者陷入自我强化的幻觉里。而 Harness 这个词是这篇论文里另一个关键概念。在智能体语境下Harness 不是“马具”那个字面意思它指的是一套包裹在模型外面的执行框架——负责管理上下文、调度工具、记录状态、控制循环、注入约束。你可以把它理解成智能体的“外骨骼”模型是肌肉Harness 是骨骼和神经决定这股力气往哪儿使、使多大、什么时候该停。所以这篇论文真正想解决的问题是当智能体具备自我改进能力时如何通过 Harness 这一层的正则化设计让递归改进过程收敛而不是发散。这个问题听起来离普通开发者很远但实际上只要你用过任何带“自动优化提示词”或“自我反思”功能的智能体框架你就已经站在这个问题面前了——只不过大多数框架选择了回避而谷歌选择了正面硬刚。我先把结论放在前面这篇论文的价值不在于提出了某个惊天动地的新算法而在于它把“智能体自我改进的稳定性”这件事从工程直觉上升到了有数学约束的层面。对于正在做智能体开发、尤其是做长周期任务智能体的人来说Harness 这一层的正则化思路是可以直接借鉴到自己的工程实践里的。2. Harness 到底是什么和 Agent 的区别、和框架的关系2.1 Harness 与 Agent 的区别别再混着用了热搜词里有个高频问题“harness 和 agent 区别”。这个问题问得特别好因为很多人确实把这两个概念混为一谈。我试着用一句话说清楚Agent 是“谁在做”Harness 是“怎么做”。Agent 指的是那个具备目标、能感知环境、能决策、能行动的主体。它可以是基于大模型的也可以是基于规则的甚至可以是两者的混合。而 Harness 是承载 Agent 运行的那套工程结构它不负责“想”它负责“管”——管上下文窗口怎么分配、管工具调用怎么串行并行、管失败重试怎么退避、管状态怎么持久化、管循环什么时候该终止。举个生活化的例子。Agent 就像一个司机Harness 就是这辆车本身加上交通规则。司机决定去哪儿、怎么开但车决定了司机能开多快、能不能急转弯、油够不够、刹车灵不灵。你换一个司机换模型车还是那辆车你换一辆车换 Harness同一个司机开出来的效果可能天差地别。这个区分为什么重要因为大多数智能体“不好用”的问题根子不在 Agent 层而在 Harness 层。模型能力已经够强了但 Harness 没设计好导致上下文被污染、工具调用乱序、状态丢失、循环失控。RRSI 这篇论文把 Harness 单独拎出来讲本身就是一种工程视角的回归。2.2 Harness 工程的核心职责拆解既然 Harness 是“管”的那一层那它具体管什么我结合论文思路和实际工程经验把它拆成五个核心职责上下文管理决定每一轮往模型里塞什么、塞多少、按什么顺序塞。这不是简单的截断而是要有优先级、有摘要、有遗忘策略。工具调度管理工具调用的时机、顺序、并发度、超时和重试。工具不是越多越好Harness 要决定什么时候该调、什么时候不该调。状态与记忆维护跨轮次的状态包括任务进度、中间结果、失败记录。没有状态管理的智能体每一轮都是失忆的。循环控制决定递归或迭代什么时候继续、什么时候停、什么时候回退。这是 RRSI 最关心的部分。约束注入把正则化、边界条件、安全规则注入到每一轮的决策中。这就是论文里“正则化”落地的地方。你会发现这五件事没有一件是模型自己能干的全靠 Harness 这层工程结构撑着。所以热搜里那些“harness engineering”“harness 工程之道”的搜索本质上都是在找这套工程结构的实践方法。2.3 为什么 RRSI 必须依赖 Harness 才能成立递归自我改进听起来很美好智能体执行任务反思结果改进自己的策略再执行再改进循环往复越来越强。但如果没有 Harness 这层约束这个循环几乎必然出问题。原因很简单自我改进是一个正反馈过程而正反馈在没有阻尼的情况下一定发散。智能体第一次改进可能让效果提升 10%第二次它基于改进后的结果再改可能提升 15%但第三次它可能就开始“过度拟合”上一次的成功经验把一些偶然因素当成必然规律改着改着就偏了。更糟糕的是如果改进方向本身是错的递归会把错误放大几轮之后智能体的行为可能完全不可控。Harness 在这里的作用就是提供“阻尼”。它通过正则化手段限制每一轮改进的幅度、约束改进的方向、保留历史版本用于回退、在检测到发散趋势时强制收敛。论文里提到的正则化递归自我改进核心就是这套阻尼机制的设计。3. 正则化递归自我改进的核心机制拆解3.1 递归自我改进的基本循环长什么样在讲正则化之前得先把“递归自我改进”这个循环本身说清楚。论文里的描述比较学术我把它翻译成工程语言大概是这么四步执行智能体在当前策略下执行任务产生轨迹和结果。评估对执行结果进行评估得到反馈信号。这个信号可以是任务成功率、可以是人工打分、也可以是另一个模型给的评价。改进基于反馈信号智能体修改自己的策略。策略可以是提示词、可以是工具选择逻辑、可以是规划模板。替换用改进后的策略替换旧策略进入下一轮执行。这个循环跑一轮叫“一次自我改进”跑多轮就是“递归”。听起来很直接但魔鬼全在细节里。比如改进的粒度是多大是改整个提示词还是只改其中一段评估信号可靠吗如果评估本身有噪声改进就会跟着噪声走。替换是直接覆盖还是保留旧版本如果新版本更差怎么办这些问题在没有正则化的朴素递归里几乎无解。而 RRSI 的贡献就是给每一步都加上了约束。3.2 正则化到底正则了什么三个层面的约束论文里“正则化”这个词用得比较宽泛我理解它实际上在三个层面同时施加约束第一层改进幅度约束。每一轮自我改进策略的变化量不能太大。这就像梯度下降里的学习率步子迈太大容易跳过最优点。具体实现上可以限制提示词修改的 token 数量、限制工具配置的变更范围、或者要求改进必须是对旧策略的“增量修补”而非“推倒重来”。第二层改进方向约束。不是所有能提升当前任务表现的改进都是好改进。有些改进会让智能体在特定任务上表现更好但泛化能力下降。正则化要求改进方向必须与“通用能力”保持一致避免过拟合到某类任务。论文里用了一个类似“一致性正则化”的机制要求改进后的策略在历史任务集上也不能退化。第三层改进频率约束。不是每一轮都要改进。如果评估信号置信度低或者当前策略已经接近局部最优强行改进反而有害。正则化机制会判断“这一轮值不值得改”不值得就跳过保持策略稳定。这三层约束叠加起来才让递归自我改进从“大概率发散”变成“有条件收敛”。3.3 为什么说“一致性正则化”是这篇论文最实用的部分热搜词里出现了“一致性正则化机制”这个词在论文里确实是重点。我个人的判断是这是整篇论文里最容易被工程落地、也最实用的部分。一致性正则化的核心思想是改进后的策略不仅要在新任务上表现好还要在旧任务上不掉链子。这听起来像废话但实际操作中智能体自我改进最容易犯的错就是“学了新的忘了旧的”。它可能为了搞定当前这个难题把提示词改得特别针对这类问题结果换一个任务就完全不会了。论文里的做法是维护一个“历史任务缓冲区”每次改进后都要在缓冲区上跑一遍如果旧任务表现下降超过阈值就拒绝这次改进或者回退。这个机制在工程上实现起来并不复杂但效果非常明显。我自己在做的智能体项目里借鉴了这个思路用一个固定的小型回归测试集来卡每次提示词变更稳定性提升了一大截。提示回归测试集不用大10 到 20 个代表性任务就够关键是覆盖不同类型的场景并且每次改进都必须跑一遍不能偷懒。4. Harness 工程落地从论文思路到可运行代码4.1 一个最小可用的 RRSI Harness 结构论文给的是理论框架落到工程上我们需要一个具体的 Harness 结构。我基于论文思路和实际经验设计了一个最小可用的版本核心模块如下class RRSIHarness: def __init__(self, agent, evaluator, regressor, task_buffer): self.agent agent # 执行任务的智能体 self.evaluator evaluator # 评估执行结果 self.regressor regressor # 正则化约束检查 self.task_buffer task_buffer # 历史任务缓冲区 self.strategy_history [] # 策略版本历史 def run_cycle(self, task): # 1. 执行 trajectory self.agent.execute(task, self.agent.current_strategy) # 2. 评估 score self.evaluator.evaluate(trajectory, task) # 3. 生成候选改进 candidate self.agent.propose_improvement(trajectory, score) # 4. 正则化检查 if not self.regressor.check(candidate, self.agent.current_strategy, self.task_buffer): return score # 拒绝改进保持原策略 # 5. 回归验证 if self.regressor.regression_test(candidate, self.task_buffer): self.strategy_history.append(self.agent.current_strategy) self.agent.current_strategy candidate return score这个结构看起来简单但每一行背后都有讲究。比如propose_improvement不能是让模型自由发挥必须给它明确的改进模板和边界regressor.check要同时检查改进幅度和方向regression_test要能快速跑完且结果可比。4.2 改进幅度约束的具体参数怎么定改进幅度约束是正则化的第一道闸门但“幅度”怎么量化论文里没有给死参数需要根据实际场景调。我分享几个我试过的量化方式改进对象幅度量化方式建议阈值说明提示词修改 token 数 / 原 token 数小于 20%超过就拆成多轮小改工具配置变更的工具数量小于 2 个一次只调一个工具规划模板结构变更的节点数小于 30%保留主干只调分支评估权重权重向量的 L2 距离小于 0.1防止评估标准漂移这些阈值不是拍脑袋来的是我在实际项目里反复试出来的。核心原则是宁可小步多走不要大步跳。递归自我改进的轮次可以多但每一轮的变化必须可控。一旦某一轮变化过大后面几轮基本都会在“还债”得不偿失。注意阈值不是固定的任务复杂度越高阈值应该越小。因为复杂任务里一个小改动可能引发连锁反应放大效应比简单任务强得多。4.3 历史任务缓冲区怎么建才有效历史任务缓冲区是一致性正则化的基础但很多人的缓冲区建得不对导致回归测试形同虚设。我踩过的坑主要有三个坑一缓冲区任务太相似。如果 20 个任务全是同一类型的回归测试只能测出“这一类任务有没有退化”测不出泛化能力。正确做法是按任务类型分层采样每类至少 3 到 5 个。坑二缓冲区任务太难或太简单。太难的任务智能体本来就不会改进前后都是零分测不出差异太简单的任务改进前后都是满分也测不出差异。要选那些“当前策略能做对但不太稳”的任务这类任务对策略变化最敏感。坑三缓冲区一成不变。随着智能体能力提升原来的缓冲区任务可能全部饱和失去区分度。需要定期更新缓冲区把已经稳定做对的任务换出去换入新的挑战性任务。我现在的做法是维护一个 30 个任务的缓冲区按难度和类型分成 6 组每组 5 个。每次回归测试跑全部 30 个但只有关键组的分数变化才触发回退。这样既保证了覆盖面又不会因为个别噪声任务误判。5. 实操过程中最容易踩的坑与排查技巧5.1 递归改进不收敛的典型表现与定位方法递归自我改进最怕的就是不收敛。表现有很多种我按严重程度排个序轻度改进几轮后效果停滞不再提升但也不下降。这通常是陷入了局部最优需要引入随机扰动或换评估维度。中度改进几轮后效果开始波动时好时坏。这通常是评估信号噪声太大改进方向被噪声带偏了。重度改进几轮后效果持续下降越改越差。这通常是正则化失效改进幅度过大或方向完全错了。极重度智能体行为变得完全不可预测甚至开始“自说自话”。这通常是递归过程中上下文被污染或者策略历史丢失导致状态混乱。定位方法我总结了一个简单的排查顺序先看评估信号是否稳定再看改进幅度是否超标再看回归测试是否通过最后看策略历史是否完整。大部分问题在前两步就能定位到。5.2 常见问题速查表问题现象可能原因排查方法解决思路改进后旧任务退化过拟合新任务跑回归测试集降低改进幅度加强一致性约束改进多轮无提升陷入局部最优检查改进方向多样性引入随机扰动或换评估维度评估分数波动大评估信号噪声重复评估取均值提高评估置信度阈值策略历史丢失Harness 状态管理缺陷检查持久化逻辑每轮强制保存策略快照递归轮次失控循环终止条件缺失检查终止逻辑设置最大轮次和收敛判据工具调用乱序调度器并发控制问题检查工具依赖图显式声明工具依赖关系这张表里的每一条都是我或者身边同行实际踩过的。尤其是“策略历史丢失”这一条看起来低级但在实际工程里非常常见。很多人只保存当前策略不保存历史版本结果一旦新策略变差想回退都回退不了。5.3 几个反直觉的实操心得第一个心得改进频率不是越高越好。我一开始觉得每轮都改才能快速提升后来发现改太频繁反而导致策略震荡。现在我的做法是设置一个“改进冷却期”连续两轮评估分数没有显著提升才触发一次改进。第二个心得评估器比改进器更重要。很多人把精力花在怎么让模型生成更好的改进方案上但实际瓶颈往往在评估器。评估不准改进就是盲人摸象。我现在会花 60% 的精力在评估器上确保它稳定、可复现、有区分度。第三个心得保留“最差版本”比保留“最好版本”更有用。策略历史里最好版本当然要留但最差版本也要留。因为最差版本能告诉你“哪些方向是死路”避免后续改进重复踩坑。我在策略历史里会标记每个版本的评估分数改进时明确告诉模型“这些方向已经试过且失败了”。6. 从 RRSI 看智能体开发的下一站RRSI 这篇论文没有提出什么颠覆性的新模型或新架构它做的事情更接近“给狂奔的智能体套上缰绳”。但恰恰是这种工程视角的回归对一线开发者最有价值。因为现在智能体的能力已经足够强了瓶颈不在“能不能做”而在“能不能稳定地做、持续地做、越做越好地做”。Harness 这一层的正则化设计本质上是在回答一个工程问题当系统具备自我修改能力时如何保证它不把自己改坏。这个问题不仅存在于智能体领域在自动化运维、持续集成、甚至推荐系统里都有类似的影子。RRSI 给出的答案——幅度约束、方向约束、频率约束、历史回归——是一套可以跨领域借鉴的思路。我自己在实际项目里落地这套思路之后最大的感受是智能体的稳定性不是靠某个单点技术保证的而是靠一整套约束机制共同作用的结果。任何一个约束缺失递归改进都可能变成递归退化。所以如果你正在做智能体开发尤其是做那种需要长期运行、反复优化的智能体我建议你先把 Harness 这层的约束机制搭好再谈能力提升。顺序反了后面全是坑。最后分享一个我最近在试的小技巧在策略历史里给每个版本打一个“置信度标签”置信度高的版本在后续改进中作为基准置信度低的版本只作为参考。这样可以在保留探索能力的同时避免低质量版本污染改进方向。目前看下来这个做法对抑制策略震荡有明显效果具体参数还在调等跑够数据再细说。 智能体自我改进的稳定性挑战：RRSI与Harness正则化机制解析
1. 从 RRSI 说起智能体自我改进的“最后一公里”到底卡在哪智能体这两年火得一塌糊涂从最早的 ReAct 到后来的各种 Agent 框架大家把注意力几乎全放在了“怎么让模型多调几个工具、多走几步推理”上。但真正在一线做过智能体落地的人心里都清楚一个智能体能不能长期稳定地跑下去靠的不是它某一次任务完成得多漂亮而是它能不能在反复执行的过程中不退化、不跑偏、不把自己越改越傻。谷歌这篇关于 RRSI 的论文讨论的正是这个被大多数人忽略的“最后一公里”问题。RRSI 全称是 Regularized Recursive Self-Improvement翻译过来就是“正则化递归自我改进”。名字听着学术但拆开看其实很朴素递归自我改进说的是智能体自己改自己、自己优化自己的提示词或策略正则化说的是给这个自我改进的过程套上一个约束防止它改着改着就发散、过拟合、或者陷入自我强化的幻觉里。而 Harness 这个词是这篇论文里另一个关键概念。在智能体语境下Harness 不是“马具”那个字面意思它指的是一套包裹在模型外面的执行框架——负责管理上下文、调度工具、记录状态、控制循环、注入约束。你可以把它理解成智能体的“外骨骼”模型是肌肉Harness 是骨骼和神经决定这股力气往哪儿使、使多大、什么时候该停。所以这篇论文真正想解决的问题是当智能体具备自我改进能力时如何通过 Harness 这一层的正则化设计让递归改进过程收敛而不是发散。这个问题听起来离普通开发者很远但实际上只要你用过任何带“自动优化提示词”或“自我反思”功能的智能体框架你就已经站在这个问题面前了——只不过大多数框架选择了回避而谷歌选择了正面硬刚。我先把结论放在前面这篇论文的价值不在于提出了某个惊天动地的新算法而在于它把“智能体自我改进的稳定性”这件事从工程直觉上升到了有数学约束的层面。对于正在做智能体开发、尤其是做长周期任务智能体的人来说Harness 这一层的正则化思路是可以直接借鉴到自己的工程实践里的。2. Harness 到底是什么和 Agent 的区别、和框架的关系2.1 Harness 与 Agent 的区别别再混着用了热搜词里有个高频问题“harness 和 agent 区别”。这个问题问得特别好因为很多人确实把这两个概念混为一谈。我试着用一句话说清楚Agent 是“谁在做”Harness 是“怎么做”。Agent 指的是那个具备目标、能感知环境、能决策、能行动的主体。它可以是基于大模型的也可以是基于规则的甚至可以是两者的混合。而 Harness 是承载 Agent 运行的那套工程结构它不负责“想”它负责“管”——管上下文窗口怎么分配、管工具调用怎么串行并行、管失败重试怎么退避、管状态怎么持久化、管循环什么时候该终止。举个生活化的例子。Agent 就像一个司机Harness 就是这辆车本身加上交通规则。司机决定去哪儿、怎么开但车决定了司机能开多快、能不能急转弯、油够不够、刹车灵不灵。你换一个司机换模型车还是那辆车你换一辆车换 Harness同一个司机开出来的效果可能天差地别。这个区分为什么重要因为大多数智能体“不好用”的问题根子不在 Agent 层而在 Harness 层。模型能力已经够强了但 Harness 没设计好导致上下文被污染、工具调用乱序、状态丢失、循环失控。RRSI 这篇论文把 Harness 单独拎出来讲本身就是一种工程视角的回归。2.2 Harness 工程的核心职责拆解既然 Harness 是“管”的那一层那它具体管什么我结合论文思路和实际工程经验把它拆成五个核心职责上下文管理决定每一轮往模型里塞什么、塞多少、按什么顺序塞。这不是简单的截断而是要有优先级、有摘要、有遗忘策略。工具调度管理工具调用的时机、顺序、并发度、超时和重试。工具不是越多越好Harness 要决定什么时候该调、什么时候不该调。状态与记忆维护跨轮次的状态包括任务进度、中间结果、失败记录。没有状态管理的智能体每一轮都是失忆的。循环控制决定递归或迭代什么时候继续、什么时候停、什么时候回退。这是 RRSI 最关心的部分。约束注入把正则化、边界条件、安全规则注入到每一轮的决策中。这就是论文里“正则化”落地的地方。你会发现这五件事没有一件是模型自己能干的全靠 Harness 这层工程结构撑着。所以热搜里那些“harness engineering”“harness 工程之道”的搜索本质上都是在找这套工程结构的实践方法。2.3 为什么 RRSI 必须依赖 Harness 才能成立递归自我改进听起来很美好智能体执行任务反思结果改进自己的策略再执行再改进循环往复越来越强。但如果没有 Harness 这层约束这个循环几乎必然出问题。原因很简单自我改进是一个正反馈过程而正反馈在没有阻尼的情况下一定发散。智能体第一次改进可能让效果提升 10%第二次它基于改进后的结果再改可能提升 15%但第三次它可能就开始“过度拟合”上一次的成功经验把一些偶然因素当成必然规律改着改着就偏了。更糟糕的是如果改进方向本身是错的递归会把错误放大几轮之后智能体的行为可能完全不可控。Harness 在这里的作用就是提供“阻尼”。它通过正则化手段限制每一轮改进的幅度、约束改进的方向、保留历史版本用于回退、在检测到发散趋势时强制收敛。论文里提到的正则化递归自我改进核心就是这套阻尼机制的设计。3. 正则化递归自我改进的核心机制拆解3.1 递归自我改进的基本循环长什么样在讲正则化之前得先把“递归自我改进”这个循环本身说清楚。论文里的描述比较学术我把它翻译成工程语言大概是这么四步执行智能体在当前策略下执行任务产生轨迹和结果。评估对执行结果进行评估得到反馈信号。这个信号可以是任务成功率、可以是人工打分、也可以是另一个模型给的评价。改进基于反馈信号智能体修改自己的策略。策略可以是提示词、可以是工具选择逻辑、可以是规划模板。替换用改进后的策略替换旧策略进入下一轮执行。这个循环跑一轮叫“一次自我改进”跑多轮就是“递归”。听起来很直接但魔鬼全在细节里。比如改进的粒度是多大是改整个提示词还是只改其中一段评估信号可靠吗如果评估本身有噪声改进就会跟着噪声走。替换是直接覆盖还是保留旧版本如果新版本更差怎么办这些问题在没有正则化的朴素递归里几乎无解。而 RRSI 的贡献就是给每一步都加上了约束。3.2 正则化到底正则了什么三个层面的约束论文里“正则化”这个词用得比较宽泛我理解它实际上在三个层面同时施加约束第一层改进幅度约束。每一轮自我改进策略的变化量不能太大。这就像梯度下降里的学习率步子迈太大容易跳过最优点。具体实现上可以限制提示词修改的 token 数量、限制工具配置的变更范围、或者要求改进必须是对旧策略的“增量修补”而非“推倒重来”。第二层改进方向约束。不是所有能提升当前任务表现的改进都是好改进。有些改进会让智能体在特定任务上表现更好但泛化能力下降。正则化要求改进方向必须与“通用能力”保持一致避免过拟合到某类任务。论文里用了一个类似“一致性正则化”的机制要求改进后的策略在历史任务集上也不能退化。第三层改进频率约束。不是每一轮都要改进。如果评估信号置信度低或者当前策略已经接近局部最优强行改进反而有害。正则化机制会判断“这一轮值不值得改”不值得就跳过保持策略稳定。这三层约束叠加起来才让递归自我改进从“大概率发散”变成“有条件收敛”。3.3 为什么说“一致性正则化”是这篇论文最实用的部分热搜词里出现了“一致性正则化机制”这个词在论文里确实是重点。我个人的判断是这是整篇论文里最容易被工程落地、也最实用的部分。一致性正则化的核心思想是改进后的策略不仅要在新任务上表现好还要在旧任务上不掉链子。这听起来像废话但实际操作中智能体自我改进最容易犯的错就是“学了新的忘了旧的”。它可能为了搞定当前这个难题把提示词改得特别针对这类问题结果换一个任务就完全不会了。论文里的做法是维护一个“历史任务缓冲区”每次改进后都要在缓冲区上跑一遍如果旧任务表现下降超过阈值就拒绝这次改进或者回退。这个机制在工程上实现起来并不复杂但效果非常明显。我自己在做的智能体项目里借鉴了这个思路用一个固定的小型回归测试集来卡每次提示词变更稳定性提升了一大截。提示回归测试集不用大10 到 20 个代表性任务就够关键是覆盖不同类型的场景并且每次改进都必须跑一遍不能偷懒。4. Harness 工程落地从论文思路到可运行代码4.1 一个最小可用的 RRSI Harness 结构论文给的是理论框架落到工程上我们需要一个具体的 Harness 结构。我基于论文思路和实际经验设计了一个最小可用的版本核心模块如下class RRSIHarness: def __init__(self, agent, evaluator, regressor, task_buffer): self.agent agent # 执行任务的智能体 self.evaluator evaluator # 评估执行结果 self.regressor regressor # 正则化约束检查 self.task_buffer task_buffer # 历史任务缓冲区 self.strategy_history [] # 策略版本历史 def run_cycle(self, task): # 1. 执行 trajectory self.agent.execute(task, self.agent.current_strategy) # 2. 评估 score self.evaluator.evaluate(trajectory, task) # 3. 生成候选改进 candidate self.agent.propose_improvement(trajectory, score) # 4. 正则化检查 if not self.regressor.check(candidate, self.agent.current_strategy, self.task_buffer): return score # 拒绝改进保持原策略 # 5. 回归验证 if self.regressor.regression_test(candidate, self.task_buffer): self.strategy_history.append(self.agent.current_strategy) self.agent.current_strategy candidate return score这个结构看起来简单但每一行背后都有讲究。比如propose_improvement不能是让模型自由发挥必须给它明确的改进模板和边界regressor.check要同时检查改进幅度和方向regression_test要能快速跑完且结果可比。4.2 改进幅度约束的具体参数怎么定改进幅度约束是正则化的第一道闸门但“幅度”怎么量化论文里没有给死参数需要根据实际场景调。我分享几个我试过的量化方式改进对象幅度量化方式建议阈值说明提示词修改 token 数 / 原 token 数小于 20%超过就拆成多轮小改工具配置变更的工具数量小于 2 个一次只调一个工具规划模板结构变更的节点数小于 30%保留主干只调分支评估权重权重向量的 L2 距离小于 0.1防止评估标准漂移这些阈值不是拍脑袋来的是我在实际项目里反复试出来的。核心原则是宁可小步多走不要大步跳。递归自我改进的轮次可以多但每一轮的变化必须可控。一旦某一轮变化过大后面几轮基本都会在“还债”得不偿失。注意阈值不是固定的任务复杂度越高阈值应该越小。因为复杂任务里一个小改动可能引发连锁反应放大效应比简单任务强得多。4.3 历史任务缓冲区怎么建才有效历史任务缓冲区是一致性正则化的基础但很多人的缓冲区建得不对导致回归测试形同虚设。我踩过的坑主要有三个坑一缓冲区任务太相似。如果 20 个任务全是同一类型的回归测试只能测出“这一类任务有没有退化”测不出泛化能力。正确做法是按任务类型分层采样每类至少 3 到 5 个。坑二缓冲区任务太难或太简单。太难的任务智能体本来就不会改进前后都是零分测不出差异太简单的任务改进前后都是满分也测不出差异。要选那些“当前策略能做对但不太稳”的任务这类任务对策略变化最敏感。坑三缓冲区一成不变。随着智能体能力提升原来的缓冲区任务可能全部饱和失去区分度。需要定期更新缓冲区把已经稳定做对的任务换出去换入新的挑战性任务。我现在的做法是维护一个 30 个任务的缓冲区按难度和类型分成 6 组每组 5 个。每次回归测试跑全部 30 个但只有关键组的分数变化才触发回退。这样既保证了覆盖面又不会因为个别噪声任务误判。5. 实操过程中最容易踩的坑与排查技巧5.1 递归改进不收敛的典型表现与定位方法递归自我改进最怕的就是不收敛。表现有很多种我按严重程度排个序轻度改进几轮后效果停滞不再提升但也不下降。这通常是陷入了局部最优需要引入随机扰动或换评估维度。中度改进几轮后效果开始波动时好时坏。这通常是评估信号噪声太大改进方向被噪声带偏了。重度改进几轮后效果持续下降越改越差。这通常是正则化失效改进幅度过大或方向完全错了。极重度智能体行为变得完全不可预测甚至开始“自说自话”。这通常是递归过程中上下文被污染或者策略历史丢失导致状态混乱。定位方法我总结了一个简单的排查顺序先看评估信号是否稳定再看改进幅度是否超标再看回归测试是否通过最后看策略历史是否完整。大部分问题在前两步就能定位到。5.2 常见问题速查表问题现象可能原因排查方法解决思路改进后旧任务退化过拟合新任务跑回归测试集降低改进幅度加强一致性约束改进多轮无提升陷入局部最优检查改进方向多样性引入随机扰动或换评估维度评估分数波动大评估信号噪声重复评估取均值提高评估置信度阈值策略历史丢失Harness 状态管理缺陷检查持久化逻辑每轮强制保存策略快照递归轮次失控循环终止条件缺失检查终止逻辑设置最大轮次和收敛判据工具调用乱序调度器并发控制问题检查工具依赖图显式声明工具依赖关系这张表里的每一条都是我或者身边同行实际踩过的。尤其是“策略历史丢失”这一条看起来低级但在实际工程里非常常见。很多人只保存当前策略不保存历史版本结果一旦新策略变差想回退都回退不了。5.3 几个反直觉的实操心得第一个心得改进频率不是越高越好。我一开始觉得每轮都改才能快速提升后来发现改太频繁反而导致策略震荡。现在我的做法是设置一个“改进冷却期”连续两轮评估分数没有显著提升才触发一次改进。第二个心得评估器比改进器更重要。很多人把精力花在怎么让模型生成更好的改进方案上但实际瓶颈往往在评估器。评估不准改进就是盲人摸象。我现在会花 60% 的精力在评估器上确保它稳定、可复现、有区分度。第三个心得保留“最差版本”比保留“最好版本”更有用。策略历史里最好版本当然要留但最差版本也要留。因为最差版本能告诉你“哪些方向是死路”避免后续改进重复踩坑。我在策略历史里会标记每个版本的评估分数改进时明确告诉模型“这些方向已经试过且失败了”。6. 从 RRSI 看智能体开发的下一站RRSI 这篇论文没有提出什么颠覆性的新模型或新架构它做的事情更接近“给狂奔的智能体套上缰绳”。但恰恰是这种工程视角的回归对一线开发者最有价值。因为现在智能体的能力已经足够强了瓶颈不在“能不能做”而在“能不能稳定地做、持续地做、越做越好地做”。Harness 这一层的正则化设计本质上是在回答一个工程问题当系统具备自我修改能力时如何保证它不把自己改坏。这个问题不仅存在于智能体领域在自动化运维、持续集成、甚至推荐系统里都有类似的影子。RRSI 给出的答案——幅度约束、方向约束、频率约束、历史回归——是一套可以跨领域借鉴的思路。我自己在实际项目里落地这套思路之后最大的感受是智能体的稳定性不是靠某个单点技术保证的而是靠一整套约束机制共同作用的结果。任何一个约束缺失递归改进都可能变成递归退化。所以如果你正在做智能体开发尤其是做那种需要长期运行、反复优化的智能体我建议你先把 Harness 这层的约束机制搭好再谈能力提升。顺序反了后面全是坑。最后分享一个我最近在试的小技巧在策略历史里给每个版本打一个“置信度标签”置信度高的版本在后续改进中作为基准置信度低的版本只作为参考。这样可以在保留探索能力的同时避免低质量版本污染改进方向。目前看下来这个做法对抑制策略震荡有明显效果具体参数还在调等跑够数据再细说。