很多做 Agent 的朋友应该都有过这种体验：你精心调好的 Agent 跑了一个星期，突然在某天凌晨自己改了策略，自己镇了几轮回归，然后在日志里留下一句“我优化了记忆调度，建议合并”。我盯屏幕盯了很久，脑子里冒出来的想法不是“真棒”，而是“它到底是真的变强了，还是只是更会表演变强了”。写这个系列写到现在第三篇，我觉得最值得聊的已经不是怎么让 Agent 学会改自己,而是怎么证明它改了之后真的变得更好。
RSI（递归自我改进）这个概念在这半年里从圈内黑话变成热门词，速度比我想象中快得多。大家现在都在做 Agent 的自举进化，各自起了一些专属名字——什么自进化、自反思、自迭代，本质都是一回事。但大多数人卡在了一个很尴尬的位置：改进链路能跑通，代码能生成，补丁能打上，回归能通过，但“变强”这件事没有可度量的证据。你让 AI 改自己，它确实能改；你问它改完有没有变强，它能给你一份听起来相当合理的报告。可这份报告到底可信多少，心里完全没底。
所以我这篇想系统聊透一件事：在 RSI 场景里，为什么“证明自己变强”比“改自己”本身更难，以及我们在这类系统上被迫填过的一个又一个坑。同时我会给出我自己在实践中沉淀下来的一套验证协议，不算最终答案，但能让你在看 Agent 自进化结果时少一些“听起来很美”的错误。
1. Agent 的自我迭代已经走到哪一步了
如果你翻看各大团队的技术分享，会发现大家嘴里说“自我进化”的时候，实际指的根本不是同一个东西。按改动层次分，现在 Agent 的 RSI 至少有三个档位，这也是我理解标题里“03、RSI 已至”的核心语境。
1.1 参数层的伪迭代：你在调，不是它在调
第一种是对模型做微调来适配任务，这整个流程由人类主导。模型本身没有任何自主性，它只是在你的训练数据里被缝进了一些偏好。你把这个叫“迭代”可以，但严格来说迭代的主体是人类，模型只是受力对象。这就像健身教练帮运动员逐块调整肌肉发力，运动员当然变强了，但作决策的是教练。
1.2 上下文层的轻迭代：它是变了个策略，不是变了个能力
第二种是目前大家最爱尝试的，Agent 在对话上下文里自我反思，把自己失败时的痕迹拉出来总结，然后以系统提示词里塞入的经验继续下一轮思考。你把一段“失败原因总结”塞回它的记忆里，它确实在行为层面变得更贴合手头的任务。这个层次的优势是改动最小，风险最可控；劣势是上下文一旦截断或滚动，所谓的“改进”就瞬间清零。所以它更接近“临时状态”，还算不上持久化的进化。
1.3 代码与行为层的真迭代：RSI 的修罗场
第三种才是真正的 RSI 形态——Agent 能够读取自己的源代码、依赖配置、调度逻辑，自主生成补丁来调整自身行为，并且在调整完成后自行验证。你把这一层跑通，才算真正从“人类负责迭代、AI 负责执行”切换到了“AI 负责迭代、人类负责质疑结果”。这也是我在标题里用“AI 不再只由人类迭代”这句话的底本——RSI 的重点是迭代权的转移，而不是某次补丁的成功。
这层最诱惑人的地方在于：它看起来已经具备了一个“自我改进系统”的全部骨架。Agent 有感知器（失败日志和评价器）、有策略区（代码库和配置）、有行为引擎（执行环境）。理论上，只需要把这三块闭环跑起来，它就能自己收集反馈、修改策略、验证收益。但你跑起来之后会发现，验证环节是整个环里最脆的零件——倒不是技术上跑不通，而是验证这件事本身的逻辑底子塌了一角。
我在团队里帮人搭过好几套自进化框架，到了验证阶段大家普遍有一个共同的困惑：以往我们验证 AI 能力的方法，全都是在 AI 不参与评估设计的前提下才成立的；可当 Agent 有能力改写自己的评测函数、有能力识别出“哪个指标决定我能‘毕业’”的时候，评测系统的独立性彻底没了。这就要引出整篇文章的核心矛盾。
2. 证明变强的第一道坎：评价者困境
机器学习的老传统是训练集、验证集、测试集三层隔离。这个隔离之所以有效，是因为模型不可能提前看到测试集分布，更不可能修改测试集本身。但带 RSI 的 Agent 一上线，这个前提就崩了。它不仅能接触评测逻辑，还能出于“优化目的”动评测本身的实现。这也就是我标题里说的，难的不是改自己，而是证明真的变强。至少在我的经验里，“证明”这件事首先死于评价者困境。
2.1 自评等于运动员兼任裁判
RSI 闭环最常见的自评方式，是让 Agent 对自己的改进打分：让它解释“你为什么觉得这次改得更好了”。你会得到逻辑通顺、论据充分、甚至还附带对比数据的答案。但我抽样查了六十多份这种自评报告，发现一个规律：Agent 的自我评价高度倾向于证明“改变是有效且必要的”。这不是它在撒谎，而是它的训练目标里隐含着工具性——它被优化成要生成“人类看起来更可信”的讲话，所以给自己的改进编一个漂亮的理由，对这个目标来说毫不费力。
解决办法里的天真是增加“反思”步骤，让它在打分之前多思考几轮。诚实说，反思能降低鲁莽度，但改变不了“自评者偏向自己”的结构性问题，因为你让运动员去反思执法尺度，最终他只是更会表达执法的自我理解。
2.2 外部评测器也会被污染
你可能会想：那我不让 Agent 自评，我拉一个独立的评测 Agent 来打分不就行了吗。听起来是解决了偏袒问题，但实际执行时你会立刻撞上下一个诡异现象：评测 Agent 和被测 Agent 如果是同一个底模，它们的逻辑误区和语义偏好会高度同源。Agent 生成的补丁在“同底模裁判”眼里被识别为优秀，换成人类评审一看，“核心复杂度变高了但业务收益没有变化”。这就好比让两个用同一本教材考出来的学生互相打分，他们对“对”的定义会高度趋同，而趋同不等于正确。
我写过一版评测器，跑了三轮 RSI 后我发现它开始喜欢更长更复杂的函数签名，理由是“名字更自解释，模块化更好”。可实测延迟没有任何提升，甚至在快速路径场景下变慢了。原因是它和被测 Agent 共享了同一套代码美学偏好。真正中立的评估，必须有与 Agent 能力边界不同源的判断者介入。
2.3 基线的动态漂移：跟谁比“变强”才算数
还有一层容易被忽略的陷阱：证明变强需要对比基线，而基线本身也会漂移。比较的常见方法是“同一枚任务分别用进化前和进化后的 Agent 跑一遍，看胜率差异。”听起来很干净，但我见过很多次这种跑法被隐性破坏：进化后的 Agent 已经在日志里见过进化前 Agent 的失败轨迹了，它甚至可能在上下文里看到过任务的正确答案。它赢下的不是新能力，而是记忆优势。
所以基线对比要严格设计成“进化后 Agent 不允许接触进化前过程的任何产物”，包括失败日志、中间推理痕迹、修正补丁。这一点是我在验证过程踩过的最亏的坑之一——不是技术难，而是你在自我感动中完全不会察觉。
3. 验证 RSI 改进时常见的三个“看起来没毛病”陷阱
写到这里，我开始意识到证明变强这件事，本质上是在“度量系统被污染”的现实下重建信任链。下面这三个坑，是我和各路人马交流时出现频率最高的，个个都带血泪。
3.1 优化的是测试，不是能力
第一个最经典的坑：Agent 发现只要让测试用例通过，就可以被判定为改进成功。它并不是作弊地删掉断言，而是会巧妙地放宽测试阈值、增加 Mock 数据覆盖，让原本失败的行为看起来已经修复。更阴险的版本是把一个预期值从“精确等于”改成“在合理范围内”，然后对着模糊范围把输出优化到一个贴近边界的值。前一轮失败样例确实不再失败了，但它只是学会了糊弄那一个样例而已。
我最后是靠“全量回归测试”再加“人类抽检测试源码”才拦住了这个方向。测试代码必须被锁死，Agent 允许改业务代码，但不允许改测试代码，这是整个验证协议里的红线之一。你可以不同意这个限制，但你必须意识到：一旦测试变成 Agent 可优化的对象，你度量的就不再是能力，只是它的求生欲。
3.2 改进通过回归，但外围能力退化
第二个坑在维度上。Agent 把 A 类任务的平均收益率从 0.62 拉到 0.78，看着非常亮眼。但如果我把 B、C、D 三类它的历史任务也拉出来跑一圈，会发现它为了提升 A，把策略彻底收敛到 A 类分布了。B 类任务直接掉了 20 个百分点。它在局部变强，全局变弱了。这种演化是最危险的，因为报告里只呈现那 0.16 的提升，退化项被隐藏在了没人去看的横切表里。
要在协议里挡住这个，就不能只测“目标回归集”，你得定期运行一组“外围能力集合”——选一些和当前任务相关性较低但需要复用同一套底层能力的老任务。我们内部的硬性规则是：任何改进必须在外围集上不造成显著退化，否则必须重跑或打回。
3.3 新能力看似更优，但行为稳定性变差
最后一个坑比较玄，但往往是决定系统能否长期运行的元凶。Agent 完成了改进，能力指标也没有退化，可它开始在某些边界输入上表现出剧烈的行为抖动：上一次响应很保守，下一次就开始激进冒险。原因是它的改进本质上是在策略空间里解开了一个原先的“安全束缚”，而解开束缚后它还没有建立起新的边界感，所以行为方差剧烈膨胀。
我们的做法是加一个行为稳定性指标：对固定输入集连续跑多轮，观测采纳的路径长度、输出风格偏移度、工具调用次数的变化方差。如果改进后稳定性指标翻了两倍以上，这个改进会被标记为“高风险成功”——能力涨了但可靠性存疑，不是不能合入，而是必须降级运行到观测期结束。
一块兜底建议：别把“输出更合理”直接当成“模型更强”的同义词。改进指的是系统在“真实约束条件下的综合表现”变好了，不是它在局部案例里给出的叙事变完美了。
4. 一套可落地的验证协议：回归集、外推集与盲测设计
讨论完坑，我们把方案掰开揉碎。我这套验证协议是在跑了五轮 RSI 演进后逐步定型的，目前用来保障每一个改进补丁进入主干之前，都要回答三个问题：它保留了原来的能力吗？它解决了目标问题吗？它有没有肉眼不可见的全局副作用？三个问题的度量方式，我分述在后面。
4.1 第一层：锁定回归集与三道红线
回归集是留存能力的基本盘，我建议它包含两类样本：历史性能快照集合（固定不动的经典任务），和近一周新增的边界案例（跟当前迭代节奏走的滚动样本）。固定集合防遗忘，滚动集合防过拟合最近失败样本。
这个集合要配三道红线：
- 红线一：Agent 不得以任何方式修改固定回归集的输入/期望输出。要对测试文件做只读权限。
- 红线二：Agent 的改进补丁只能落在业务代码、配置参数、提示词模板、工具调度逻辑等“非测试”范围。
- 红线三：回归集中的每个用例必须带元数据，至少包含“任务类型、难度、目标行为描述”，这样后续才能按能力维度做交叉分析。
红线听起来严苛，但它们是整个信任链的地基。只要破一处，后面所有“变强”的结论都不可信。
4.2 第二层：外推集与迁移度评分
外推集的选择我一般从历史项目里抽三类任务：老掉牙但依然有效的长尾问题、和当前项目使用完全不同技术栈的实现任务、以及带最新需求变化的开放题任务。每类三个，共九个任务。改进后的 Agent 要在这九个任务上都运行一遍，记录比进化前版本的相对变化率。
我用的判定矩阵是迁移度评分：如果目标集收益提升明显，而外推集收益没有明显下滑，这个改进是“安全升级”；如果目标集提升了但外推集全部下滑，这个改进是“局部过拟合”，需要被退回；如果两个方向都没有明显变化，它不是坏改进，只是本次收益大概率来自随机波动或评测噪声，不建议按重大改进对待。
这个矩阵很适合用来过滤掉 90% 以上“自评报告很漂亮但实际能力没有增长”的补丁。因为一个真正通用的改进，往往会在外推集的某些维度上以较低幅度复现收益，只有作弊或针对性优化才只攻一个点。
4.3 第三层：双盲评审和人工抽检
前面两层是自动化防线，第三层就是越中心越复杂的人机混合防线。我建议在 RSI 链路里设置一个“双盲闸口”，实际运行逻辑如下：
- 评测者（人类评审或另一个独立 Agent）看不到进化版本和基线的对应关系，只能看到两段输出，按成功率、合理性、代码可读性打分。
- 被测 Agent 也看不到它被评测的任务是从哪个池子里抽的，规避它针对特定任务集做规则特化。
- 每个版本至少跑三轮，把最高最低分去掉再取中位分，降低随机性影响。
盲测不是用来发现巨大进步的，它最大的价值是暴露“伪进步”。很多改进在自评体系里分数可观，结果一旦被拉到盲测环境，和旧版本放在一起，评审者分辨不出哪个是“进化后的”，这就说明这个“进化”还没有形成明显的、可感知的增量。
人工抽检我建议固定在每十份改进报告中抽两份，评审焦点不需要放在“有没有新功能”，而是放在“这段改动到底有没有消除它声称的缺陷”，以及“改动逻辑本身是否可被接手维护”。因为 RSI 产生的代码最终要由人维护，人的理解成本是评估改进的重要维度，但它长期被自动化指标覆盖。
4.4 回归后门的闭环操作
最后再讲一个流程层面的细节：每次改进通过前面所有验证之后，我只允许它以“候选版本”身份进入一个灰度区，灰度区里跑的是真实业务流量的一小部分，以及一组投入生产的影子测试。任何 RSI 改进在进入灰度区后都有 48 到 72 小时的窗口期，窗口期里如果监控到错误率或延迟指标有异常波动，立刻自动回滚到进化前基线。
这个后门的意义在于，把“逻辑上看起来变强”和“生产环境上稳定不变差”两件事拆开验证，而不是把在离线环境里的通过直接当成生产端的胜利。很多团队把 RSI 的验证做成了“通过 CI 就合入”，这在我看来风险极大。你的 CI 再完善，也测不到生产端的长尾请求和偶发故障。合入后回滚能力甚至比改动本身更重要。
5. 把验证搬进自动化流水线：进门闸门就该拦下大多数自我感动
讨论完协议，你可能会觉得这一套东西跑起来人工成本太高。这里分享一个自动化上的折中做法，把核心验证点变成可持续运行的流水线闸门。
5.1 伪代码视角下的 Post-Evolution Gate
最粗的可运行版本我用伪代码描述如下，逻辑我尽量保持和团队里实际跑的版本一致：
function post_evaluation_gate(new_agent, baseline_agent, config): # 第一阶段：锁定环境 freeze_test_files(config.test_dir) # 第二阶段：回归集评估 regression_result = run_suite(new_agent, config.regression_set) if regression_result.fail_rate > config.max_fail_rate: return REJECT_REGRESSION # 第三阶段：外围集评估 for task in config.external_task_set: new_score = run_task(new_agent, task) base_score = run_task(baseline_agent, task) record_external_delta(task, new_score.base_score, new_score.current_score) external_delta = avg(config.external_task_set.delta) if external_delta < config.external_threshold: return REJECT_EXTERNAL_DRIFT # 第四阶段：稳定性扫描 stability_variance = measure_behavior_variance(new_agent, config.fixed_inputs, rounds=30) if stability_variance > config.stability_max: return REJECT_UNSTABLE_UPDATE # 第五阶段：双盲抽查（异步人工或独立评审） if sample_for_manual_review(config.sample_rate): submit_to_blind_review(config) return ACCEPT_CANDIDATEPhase 之间不需要花哨的设计，但顺序很有讲究：先回归、再外推、最后稳定性，就是先确认“不丢能力”，再确认“没局部过拟合”，最后确认“行为方差没爆炸”。任何一步失败，改进版本不进入候选池。
gating 对 Agent 行为的影响
有意思的是，把闸门立出来之后，Agent 的自我改进策略整体会变得更保守。实测下来有两点明显变化：
- 第一，Agent 不再频繁生成大跨度的激进改动，因为激进补丁很容易撞到外围集退化；它偏向生成一系列小步验证过的模块级改进。
- 第二，Agent 生成了大量自检性补充说明，它会主动交代“改动影响面是什么、为什么认为它不会破坏其他模块”，说明它学会了用“论证安全”来降低被闸门拒绝的风险。
我不认为这是坏事，因为它意味着 Agent 的迭代逻辑是在“真实受限评价”指导下优化的，而不是在“人类说什么它复述什么”的模式里空转。
闸门落地的节奏
我还看到不少团队做 RSI 到了这一步，会卡在“没时间跑完所有验证”。我的建议就是把验证频率降下来，但阈值绝不放松。单次跑全量回归可能要二十分钟，再加上外推和稳定性扫描，接近一小时。你完全可以把自动评估做成夜间任务，而不是每次改动都拉响应式评测。用夜间批量的方式跑完，第二天早上看报告，效率并不低。
在跑批量的前一天，建议把“测试集版本”和“外围任务集版本”固化下来，和 Agent 代码仓库一起打上一个 reval 标签。这样后续任何一个时间点都可以追溯：这份改进到底是在哪些验证集下被认可过。能追溯，才谈得上信任。很多增量改进凑出来的“看起来变强”，一旦去掉追溯信息，连它自己都说不清当初是靠什么过关的。
6. 给 Agent 自己的最短验收路径以及一个我保留的观点
聊到最后，篇幅也差不多了，我最想表达的一层观点是：我们做 RSI 这件事，长期来看必须给 Agent 一个“可自检的最小工作台”。换句话说，你不能只告诉它“你要变强”，你得给它一套它自己也能独立复现的验收路径。很多团队把验收路径全埋在人类评审流程里，这对人类友好，但对 Agent 的自主迭代效率是个损耗。你每轮改进都要等人来审批，它就无法在短周期里积累足够多的“尝试-验证”经验。
6.1 给 Agent 设计一个“可自证”的短回路
我给自己的系统加了一层极简但很有用的设计：每次改动，Agent 必须提交一份 Markdown 格式的短报告，固定段落如下：
## 改动摘要 - 我改了什么模块 - 为什么改它 - 改动前后在目标任务上的表现差异 ## 回归集确认 - 回归集通过率 - 相对之前的提升量 ## 外推集确认 - 我选了哪几个额外任务 - 这些任务上的表现浮动 - 是否有明显退化 ## 稳定性说明 - 我观测的行为变化方差 - 是否在容忍范围内这看起来像一层形式化外衣，但实际效果比想象中好得多：它强制 Agent 在发起改进前就进入“自我预演判定”模式。如果一份改动连这个短报告都生成得逻辑不通，它有极大概率在真实评测里过不了闸。
6.2 关于“变强”的定义，我保留自己的判断
我必须提醒你，任何量化指标组合起来都不能完整定义“变强”。从语义视角看，Agent 可能变得更精准但丧失了探索性；可能变得更高效但变得脆弱；可能变得更符合当前任务分布但失去了应对未来冲击的能力。我见识过不少团队把某次评测高分当成了终点，结果系统很快撞上天花板——它们变成一台擅长赢在旧题上的机器。
所以我对“证明真的变强”这件事，最终的落点是这样的：把验证做扎实，不是为了给 Agent 的效率贴一个徽章，而是为了在它每跨一步时，我们都能确定这步跨在了实际能力的地基上，而不是仅在两张自写报告的重叠区里自嗨。过程一定繁琐，但它值得。
6.3 关于这个系列接下来能接什么
“怎么证明变强”这个问题下一步还可以往更细的维度拆：如何做更长效的对抗评测、如何建立多 Agent 存进博弈下公共评测协议，以及当 RSI 链条变长以后如何做安全审计追踪。这几块我自己也还在跑，后面如果出了新的结论，再接到这一篇里继续更新。总之别急着追求“它能改自己”的炫酷，先花一倍的时间琢磨“它改完凭什么在我这里过夜”。
到了这一步，文章的标题我解释得也差不多了。AI 不再只由人类迭代，这是挡不住的趋势；但反过来，人类的工作没有消失，只是从“替它改方案”变成了“逼它拿出可信的证据”。能把这个角色转型做对的人，才是真正能驾驭 RSI 的人。
