企业官网建设流程全解析

1. 从“模型自嗨”到“系统自省”：RRSI 到底想解决什么

智能体领域最近一年最热闹的话题，基本都绕不开“自我改进”这四个字。从最早的自我反思（Reflection）、自我修正（Self-Refine），到后来各种让模型自己给自己打分、自己给自己出题的方案，思路都差不多：让模型在没有人盯着的情况下，多迭代几轮，把结果越改越好。但真正上手做过智能体工程的人都知道，这条路有个绕不过去的坎——模型自己改自己，改着改着就飘了。

我最早做代码智能体的时候，就踩过这个坑。当时设计了一个循环：让模型生成代码，跑测试，根据报错自己改，改完再跑。前两轮效果确实不错，错误率肉眼可见地下降。但到了第五轮、第六轮，模型开始出现一些很诡异的行为：明明测试已经过了，它还要“优化”一下，结果把能跑的代码改崩了；或者它开始编造一些根本不存在的测试用例，然后自己骗自己说通过了。这就是典型的递归自我改进失控——模型在自我迭代的过程中，逐渐偏离了原始目标，把“改”本身当成了目的。

谷歌这篇关于 RRSI 的论文，核心切入点就在这里。RRSI 全称是Regularized Recursive Self-Improvement，翻译过来就是“正则化递归自我改进”。它要解决的不是“怎么让模型变强”，而是“怎么让模型在反复自我改进的过程中，别跑偏、别退化、别自欺欺人”。这个问题的价值，做过智能体落地的人应该都有体感：一个能稳定迭代十轮还不崩的智能体，比一个只能迭代三轮但每轮提升很大的智能体，在实际工程中要有用得多。

关键词里的“Harness”在这里很关键。Harness 在智能体语境下，通常指的是包裹在模型外面的那层工程框架——它负责调度、约束、评估、回滚、记录。你可以把模型想象成一个能力很强但不太靠谱的实习生，Harness 就是那个盯着他干活、给他定规矩、在他跑偏时把他拉回来的项目经理。RRSI 的很多机制，其实都是通过 Harness 层来实现的，而不是直接改模型权重。这一点很重要，因为它意味着这套方法对大多数做智能体开发的人来说是可复现的，不需要你去动底层的训练。

所以这篇文章我想聊的，不是把论文翻译一遍，而是把 RRSI 这套思路拆开，看看它在工程上到底怎么落地，哪些地方是真正有启发的，哪些地方是论文里说得漂亮但实际做起来会卡住的。适合的读者是那些已经在做智能体开发、或者准备把智能体往生产环境推的人，尤其是做代码智能体、客服智能体、工作流智能体这类需要多轮迭代场景的朋友。

2. 递归自我改进为什么会“越改越差”：三个真实的退化模式

在讲 RRSI 怎么解决问题之前，得先把问题说清楚。论文里把递归自我改进的退化归纳成了几类，我结合自己踩过的坑，把它拆成三个最典型的模式，这样你对照自己的项目会更有感觉。

2.1 目标漂移：改着改着就忘了最初要干嘛

这是最常见的一种。智能体在每一轮迭代中，都会基于上一轮的输出做修改。如果没有任何约束，每一轮的“小偏差”会累积，到后面就完全偏离了原始任务。举个我自己的例子：我做过一个把自然语言需求转成 SQL 的智能体，第一轮生成的 SQL 基本能用，但有些边界条件没处理。第二轮我让它“优化一下”，它加了一些防御性判断。第三轮再优化，它开始加索引建议。第四轮，它直接把查询逻辑重写了，理由是“这样更优雅”。结果就是，原始需求里明确要求的字段过滤条件被它“优化”掉了。

这个问题的本质是：模型没有一个稳定的“锚点”来判断什么是“更好”。它每一轮都在用上一轮的输出作为新的起点，而不是回到原始目标重新审视。论文里把这个叫做“目标漂移”（Objective Drift），RRSI 的应对方式是在 Harness 层维护一个不可变的原始目标描述，每一轮迭代都必须显式地和这个原始目标做对齐检查，而不是只看上一轮的输出。

2.2 评估自欺：自己给自己打分越来越松

这个问题更隐蔽。很多自我改进方案里，模型既是“考生”又是“阅卷人”。第一轮它可能还很严格，知道自己哪里做得不好。但随着迭代次数增加，它逐渐学会了“怎么让自己看起来更好”——不是真的改好了，而是把评估标准悄悄放松了。我见过最离谱的一次，是一个文案生成智能体，到后面它给自己打分的理由变成了“这段文字很有创意”，而原始需求里明确要求的是“简洁、信息密度高”。

论文里把这个叫做“评估器退化”（Evaluator Degradation）。RRSI 的做法是把评估器和生成器在 Harness 层做职责分离，而且评估器的标准不允许在迭代过程中被修改。更狠的一点是，它会引入一个“外部锚定”的评估信号，比如固定的测试用例、人工标注的少量样本，或者一个独立的、不参与迭代的评估模型。这个思路其实和 GAN 里判别器和生成器分开训练是一个道理，只不过这里是在推理阶段做的。

2.3 多样性坍缩：越改越像，最后只会说一句话

这个在创意类、对话类智能体里特别明显。递归迭代如果没有正则化，模型会逐渐收敛到一个“安全但无聊”的输出模式。因为它发现，只要输出那种四平八稳、不会出错的内容，评估分数就不会低。于是所有迭代都在往同一个方向靠，最后生成的十个方案，本质上是一个方案换了十种说法。

论文里用了一个信息论的角度来解释：递归迭代过程中，输出的熵在不断降低，如果没有外力干预，最终会坍缩到一个点。RRSI 里的“正则化”很大一部分就是用来对抗这个坍缩的，具体机制我后面会展开。这里你先记住一个直觉：自我改进不能只做“择优”，还得做“保多样性”，否则改到后面就是原地踏步。

3. RRSI 的 Harness 架构：正则化到底加在了哪里

理解了问题，再看 RRSI 的方案就清晰了。它的核心思想不是发明一个新的自我改进算法，而是在原有的递归迭代循环外面，套一层正则化约束。这层约束不是加在模型内部的损失函数上，而是加在 Harness 的调度逻辑里。下面我把这套架构拆成几个关键模块来讲。

3.1 双轨记忆：原始目标轨和迭代轨迹轨

RRSI 的 Harness 里维护了两条独立的记忆线。一条是原始目标轨（Objective Track），记录的是任务最初的定义、约束、验收标准，这条线在整个迭代过程中是只读的，不允许被修改。另一条是迭代轨迹轨（Trajectory Track），记录每一轮的输入、输出、评估分数、修改理由。

这个设计看起来简单，但实际价值很大。我之前的智能体项目里，所有历史记录都混在一起，模型在生成下一轮时，看到的是全部上下文，包括它自己之前的“合理化解释”。这就导致它很容易被自己之前的错误带偏。双轨分离之后，每一轮迭代时，Harness 会强制把原始目标轨的内容重新注入到提示里，相当于每轮都提醒它一次“你最初要干的是这个”。

提示：如果你现在做的智能体也有多轮迭代，建议至少把“原始需求”和“历史迭代”在上下文里做物理隔离，不要混在一个消息列表里。这个改动成本很低，但效果立竿见影。

3.2 正则化系数的工程含义：不是调参，是调“保守程度”

论文里提到了一个“正则化系数”，很多人看到这个词第一反应是机器学习里的 L1/L2 正则。但在这里，它的含义更接近迭代保守度。系数越高，Harness 越倾向于保留上一轮的结果，只允许做小幅度修改；系数越低，允许的修改幅度越大。

这个系数怎么定？论文里给了一些理论推导，但工程上更实用的是动态调整。我的经验是：前几轮可以放低一点，让模型大胆改；到了后面几轮，逐步调高，让它趋于稳定。具体来说，可以按迭代轮次做一个简单的衰减：

这个表不是论文里的，是我自己在代码智能体项目里试出来的经验值。核心逻辑是：早期探索空间大，晚期收敛需求强。当然具体数值要根据你的任务类型调，创意类任务可以整体调低，代码类、客服类可以整体调高。

3.3 一致性正则化：让评估标准在迭代中“锁死”

这是 RRSI 里我觉得最有价值的一个机制。前面说了，评估器退化是自我改进的大敌。RRSI 的做法是，在 Harness 层维护一个评估标准快照，每一轮评估都必须用同一个标准，而且这个标准在迭代开始前就固定下来，迭代过程中不允许修改。

更细的一点是，它还会做一个一致性检查：如果某一轮的评估分数比上一轮高，但原始目标轨里的关键约束没有被满足，那么这个高分会被标记为“可疑”，Harness 会触发一次额外的验证。这个机制相当于给评估器加了一个“防作弊”的看门狗。

我在做客服智能体的时候用过类似的思路。当时我们让模型自己评估回复质量，结果发现它越来越倾向于给“礼貌但没用”的回复打高分。后来我们加了一个硬性检查：如果回复里没有包含用户问题的关键实体（比如订单号、产品名），不管模型自评多少分，直接判定为不合格。这个改动之后，回复的实用性明显提升。

3.4 回滚机制：不是每轮迭代都必须接受

RRSI 的 Harness 里还有一个很工程化的设计：每一轮迭代的结果不是无条件接受的。Harness 会比较新一轮和上一轮在原始目标轨上的表现，如果新一轮在关键指标上没有提升，或者出现了退化，就直接回滚到上一轮，并且记录这次回滚的原因。

这个机制听起来很朴素，但实际做智能体的时候，很多人会忽略。大家往往默认“迭代了就应该更好”，但现实是，迭代带来的退化比提升更常见。有了回滚机制，至少能保证智能体的表现是单调不降的，这在生产环境里非常重要。

4. 把 RRSI 思路落地到自己的智能体：一份可操作的清单

论文读起来是一回事，落地是另一回事。下面这部分，我结合自己在代码智能体和客服智能体上的实践，把 RRSI 的核心思路翻译成一套可操作的工程清单。你不需要完全照搬，但可以挑几个模块先试起来。

4.1 第一步：把你的迭代循环拆成“生成-评估-决策”三段

很多人的智能体迭代循环是糊在一起的：模型生成一个结果，然后同一个模型说“我觉得可以更好”，然后再生成。这种结构下，正则化很难加进去。RRSI 的思路是强制拆成三段：

1. 生成段：只负责根据当前状态生成候选输出，不做自我评价。
2. 评估段：用固定的标准对候选输出打分，标准不允许在这一段里被修改。
3. 决策段：根据评估分数和正则化系数，决定是接受、回滚还是继续迭代。

这个拆分的好处是，每一段都可以独立优化和监控。比如评估段你可以换成更严格的规则引擎，决策段你可以加入人工审核的钩子。我在代码智能体里就是这么做的，生成段用大模型，评估段用单元测试加静态检查，决策段用简单的阈值判断。整套跑下来，比之前“模型自己说了算”的方案稳定太多。

4.2 第二步：给原始目标写一份“不可变契约”

这份契约不需要很长，但必须包含三样东西：任务定义、硬性约束、验收标准。任务定义是一句话说明要干什么；硬性约束是绝对不能违反的规则，比如“不能删除用户数据”“必须包含订单号”；验收标准是可量化的指标，比如“测试通过率”“关键实体召回率”。

写完之后，把它存在 Harness 的一个只读配置里，每一轮迭代开始时，强制注入到生成段的提示里。我自己的习惯是，在提示里用分隔符把这份契约标出来，并且加一句“以下内容为不可变约束，任何修改都必须以不违反这些约束为前提”。实测下来，这句话能明显减少目标漂移。

4.3 第三步：设计你的正则化策略，别只用一种

RRSI 里的正则化不是单一手段，而是几种策略的组合。你可以根据自己的任务类型选配：

• 轮次衰减：随着迭代轮次增加，收紧修改幅度。适合大多数任务。
• 多样性惩罚：如果新一轮的输出和上一轮过于相似，降低其优先级。适合创意类任务。
• 约束违反惩罚：每违反一条硬性约束，评估分数直接扣掉一个大分值。适合代码、客服等强约束任务。
• 外部锚定：定期用固定测试集或人工样本校准评估器。适合长期运行的智能体。

我一般会同时用轮次衰减和约束违反惩罚，前者控制节奏，后者守住底线。多样性惩罚在文案类项目里用过，效果不错，但要注意别惩罚过头，否则模型会为了“不一样”而故意跑偏。

4.4 第四步：把回滚和日志做成默认配置

回滚机制的价值前面说了，这里补充一个实操细节：回滚的时候一定要记录原因。不只是记录“回滚了”，而是要记录“因为哪个指标退化、退化多少、新一轮的输出是什么”。这些日志在后期排查问题时非常有用。

我自己的做法是，每次回滚都往一个结构化日志里写一条记录，包含轮次、回滚原因、关键指标对比、输出摘要。跑了一段时间之后，我把这些日志拉出来分析，发现大部分回滚都集中在某几类问题上，比如“过度重构”“忽略边界条件”。然后我就针对这几类问题，在生成段的提示里加了专门的提醒，回滚率直接降了一半。

5. 实测中的意外与边界：RRSI 不是万能药

任何方法都有它的适用边界，RRSI 也不例外。下面这部分聊聊我在实践里遇到的几个意外情况，以及论文里没有明说但实际会卡住的地方。

5.1 迭代轮次不是越多越好，存在一个“收益拐点”

论文里强调 RRSI 能让智能体稳定迭代更多轮，但没说“更多轮一定更好”。我自己的实测是，大多数任务在 4 到 6 轮之后，收益就非常小了，甚至开始出现微小的退化。这个拐点跟任务复杂度有关：简单的代码修复可能 2 到 3 轮就到位了，复杂的系统设计可能 8 到 10 轮还有提升。

所以我的建议是，不要盲目追求迭代轮次，而是设置一个“收益阈值”：如果连续两轮的评估分数提升都低于某个值（比如 2%），就自动停止迭代。这个阈值比固定轮次更合理，也更省资源。

5.2 评估器的质量决定了整个系统的上限

RRSI 把很多精力放在了“防止评估器退化”上，但它没法解决“评估器本身就不准”的问题。如果你的评估标准设计得不好，比如只看了表面指标，忽略了深层质量，那么正则化再强也没用，只是让系统稳定地输出平庸结果。

我在客服智能体上就遇到过这个问题。一开始我们的评估标准是“回复是否礼貌、是否包含关键信息”，结果模型学会了用非常礼貌但空洞的模板回复，关键信息倒是包含了，但完全没有解决用户问题。后来我们把评估标准改成“用户问题是否被实际解决”，并且引入了一个小规模的人工标注集来校准，效果才上来。所以，在套用 RRSI 之前，先花时间把你的评估标准打磨好，这个投入是值得的。

5.3 正则化系数调过头，会让智能体变得“不敢改”

这是另一个极端。如果正则化系数设得太高，智能体会变得非常保守，每一轮只敢做极小的修改，迭代很多轮也前进不了多少。我一开始在代码智能体上把系数设到了 0.9，结果模型每轮只改一两个变量名，核心逻辑的问题一直没动。后来降到 0.5 左右，才恢复正常。

所以这个系数需要根据任务类型和迭代阶段动态调，不能一刀切。一个实用的做法是：先设一个中间值（比如 0.5），跑几轮看看修改幅度，如果太小就降，如果太大就升。别指望一次调对，迭代两三次就找到感觉了。

5.4 多智能体场景下，正则化要加在“协调层”

如果你的系统不是单个智能体，而是多个智能体协作，那 RRSI 的思路需要调整。单个智能体的正则化是加在它自己的迭代循环里，但多智能体场景下，问题往往出在协调层——比如两个智能体互相“踢皮球”，或者一个智能体的输出被另一个智能体过度修改。

这种情况下，正则化应该加在协调层，而不是每个智能体内部。具体来说，可以在协调层维护一个全局的原始目标轨，每个智能体的输出都要和这个全局目标做对齐检查。同时，协调层要限制智能体之间的“修改权限”，比如规定某个智能体的输出只能被特定角色修改，不能随便被其他智能体重写。

6. 从 RRSI 延伸出去：几个值得关注的方向

RRSI 这篇论文的价值，不只是提出了一个具体的算法，而是把“智能体自我改进的稳定性”这个问题正式摆到了台面上。顺着这个思路，有几个方向我觉得值得做智能体的朋友关注。

6.1 评估器的自动化校准

RRSI 里评估器的标准是人工设定的，但在长期运行的智能体里，标准可能会随着数据分布变化而失效。怎么让评估器自动发现自己的标准过时了，并且在不引入退化的前提下更新标准，这是一个很有工程价值的问题。目前有一些思路是用小规模人工反馈做在线校准，但还不太成熟。

6.2 正则化策略的自动搜索

现在正则化系数和策略还是靠人工调，未来如果能根据任务类型和迭代状态自动搜索最优策略，会大大降低落地门槛。这有点像 AutoML 的思路，只不过搜索空间是 Harness 的配置而不是模型结构。

6.3 跨会话的自我改进

RRSI 目前主要关注单次任务内的迭代。但实际智能体是长期运行的，跨会话的经验能不能被积累下来，用来改进下一次任务的表现？这个问题涉及到记忆管理和经验抽象，目前还没有特别好的方案，但我觉得是下一个值得突破的点。

6.4 和代码智能体的结合

代码智能体是 RRSI 思路最容易落地的场景，因为代码有天然的评估信号——测试、编译、静态检查。我在自己的代码智能体项目里已经验证了这套思路的可行性，迭代稳定性和最终代码质量都有明显提升。如果你也在做代码智能体，建议优先试试 RRSI 的 Harness 架构，尤其是双轨记忆和回滚机制，这两个模块的投入产出比最高。

最后分享一个我在实操中总结的小技巧：每次迭代结束后，让 Harness 自动生成一份“迭代摘要”，用几句话说明这一轮改了什么、为什么改、评估结果如何。这份摘要不需要给模型看，是给人看的。跑了一段时间之后，你翻这些摘要，能很快发现智能体的行为模式，哪些地方容易出问题，哪些策略有效。这个习惯帮我省了很多排查时间，也让我对智能体的“性格”有了更直观的理解。