1. 看似成功的进化
一个团队给 Agent 加了自进化机制，跑了三个月。评测集分数从 61% 升到 74%，团队很满意。
接入真实用户之后，投诉没有减少。
逐条看失败案例，三类现象。
规则被压缩掉了。 新加的一条规则在长任务里被摘要掉，模型在后期不再遵守。前几轮还遵守，第十轮之后就不提了。
指标涨了但问题没解决。 某些任务分数升了，但升的原因是模型更愿意给"看起来完整"的答案。问题本身还在。
规则互相冲突。 不同时期加的两条规则在同一个场景下给出相反指引，模型在不同轮次给出不同做法。
三类现象有一个共同点：分数在涨，能力未必在涨。这就是 RSI 评估要处理的核心难题。
2. 单一分数为什么必然误判
上一节的三类现象说明：分数上涨与能力上涨是两件事，而单一分数无法区分它们。
三种混杂会让分数失真，各自的成因不同。
写得好但用不上。 更新器产出了一条完全正确的规则，但任务模型在合适场景没有加载它。分数不变，问题在检索或目录说明。
用得上但守不住。 规则被加载了，模型在中途偏离。分数可能部分上升，问题在规则的写法（没有可判定的约束）或任务长度（长任务里规则被压缩掉）。
守住了但没泛化。 在提炼时见过的那批任务上有效，换一批就无效。分数在评测集上上升，实际使用无改善。
三种混杂的共同点：它们都表现为「分数涨了但没解决问题」，而修的位置完全不同——第一种改检索，第二种改写法，第三种改证据来源。
3. 两种能力必须分开测
三种混杂指向一个结论：RSI 里有两件事，必须分开测。
更新能力：从轨迹中产生有价值的持久修改。衡量的是「更新器好不好」。
受益能力：任务 Agent 在后续运行中找到、激活并正确使用这些修改。衡量的是「产物能不能被用上」。
为什么必须分开：一个 Skill 可能写得完全正确，但任务模型没有在合适场景加载它，或加载后无法长期遵循。两种情况都会让最终成绩看起来「没有进化」，但原因完全不同。
用端到端分数反推更新器好坏，会把三种失败混成一种。
分开测的做法：固定任务模型，换不同的更新器，看产出的提案质量；固定更新器，换不同的任务模型，看产物的激活与遵循。前者测更新能力，后者测受益能力。
有一条实证支持这个区分：在模型替换实验里，这两种能力与基础模型能力的关系并不相同。基础模型强，受益能力明显上升；更新能力不随基础模型强度线性上升。
这条结论的实践含义：换一个更强的模型能改善「用得上」，但不能改善「写得好」。后者要靠更新器的设计与证据质量。
3.1 两种能力各自的失败长相
分开测之后，两种失败长得不一样，修的方向也不一样。
| 能力 | 失败长相 | 典型原因 | 修的位置 |
|---|---|---|---|
| 更新能力 | 提案质量差、过拟合、与旧规则冲突 | 证据太少、只看到幸存案例 | 观察粒度与提炼判据 |
| 受益能力 | 产物正确但从不被加载，或加载后偏离 | 目录描述太宽或太窄、规则不可判定 | 目录写法与规则写法 |
第一种失败在离线评估里就看得见——提案在未见轨迹上无效。第二种失败要到在线才看得见——它需要真实任务触发加载。
这个差别决定了修复周期：更新能力的问题可以在一次整理周期内发现并修好；受益能力的问题需要等真实流量跑出足够样本。
3.2 常见的误判
「加了一条规则但分数没变」这个现象，通常被归因为「规则没用」。按两种能力拆开，有三种可能：
规则本身无效——更新能力的问题，改证据。 规则有效但从没被加载——激活问题，改目录描述。 规则被加载但没被遵守——遵循问题，改规则写法或任务长度。
三种的验证方式不同：第一种看提案在未见轨迹上的表现；第二种看加载次数与调用次数的比值；第三种看长任务里的遵守情况。
不拆开就只能猜。而猜的常见结果是「再加一条更明确的规则」，那只是把第三种失败变成第三种失败加第一种失败。
4. 四层指标
四层指标逐层收紧，每层配一个假阳性与它的检验方法。
| 层 | 指标 | 回答什么 | 假阳性 | 检验方法 |
|---|---|---|---|---|
| 1 | 提案有效率 | 更新器是否提出有价值的修改 | 提案对生成它的轨迹有效 | 放到未见过的轨迹上评估 |
| 2 | 产物激活率 | 是否在正确场景加载 | 分数涨了但不是因为它 | 有产物与无产物两组对照 |
| 3 | 遵循成功率 | 加载后是否按新规则执行 | 短任务看不出偏离 | 构造长任务，查压缩后遵守情况 |
| 4 | 保留集增益 | 是否改善了未参与进化的任务 | 保留集与训练集重叠 | 检查重叠度，查多久未用于决策 |
四层之外还有五个横向指标，它们不回答「进化的哪一环好不好」，回答「整体有没有变坏」。
| 指标 | 观测什么 | 退化表现 |
|---|---|---|
| 回退 | 新经验与已有经验是否冲突 | 原本能通过的案例开始失败 |
| 泛化 | 在测试集未覆盖场景的效果 | 只在提炼过的场景有效 |
| Token 效率 | 完成任务的平均消耗 | 每轮成本上升而质量不变 |
| 安全性 | 规则、隐私、拒绝行为是否漂移 | 拒绝率下降而越权率上升 |
| 长期工程质量 | 维护复杂度、架构一致性、向后兼容 | 规则集难以理解，改动互相牵连 |
第三个指标容易被忽略。一个提案可能让准确率提升一个百分点，代价是每次任务多两次模型调用——这个交换在短期划算，在长期会挤占预算。
第五个指标最难量化，但有一条可操作的近似：规则集的理解成本。具体测法是让一个没参与过这项工作的人读一遍规则集，然后回答「某条具体规则为什么存在」。答不出来说明规则集已经失去了可维护性。
4.1 第一层：提案有效率
假阳性最常见的形式是过拟合：三条轨迹支持一条规则，看起来证据充分，实际上只是这三条恰好有共性。
检验方法：把提案放到生成它时没见过的轨迹上评估。如果增益消失，说明提案过拟合。
一个具体的量化：如果一条规则在 3 条轨迹上有效、在 20 条新轨迹上无效，它的有效率是 13%，应当拒绝。
4.2 第二层：产物激活率
假阳性的形式是归因错误：分数涨了，但同时上线的还有另一个改动。
检验方法：单独回放「有产物」与「无产物」两组，其余条件相同。
这一层的指标本身也值得看：工具被调用的次数与该工具被加载的次数的比值。比值低说明加载了但没被用（目录描述太宽），比值高说明加载即用。
4.3 第三层：遵循成功率
假阳性的形式是任务长度不足：一条「失败后先查环境」的规则，在任务只有两步时看不出差别；在二十步的长任务里，模型可能在中途就忘了。
检验方法：构造长任务用例，检查规则在整个任务周期内的遵守情况，特别是压缩发生后的遵守情况。
这一层最容易被跳过，因为构造长任务用例的成本高。但它是唯一能发现「规则被压缩掉」这一失效的指标。
4.4 第四层：保留集增益
假阳性是保留集与训练集重叠。这是最常见也最致命的——如果保留集里的任务在提炼时被看过，它就不再是保留集。
检验方法两条：保留集在冻结前只用于评测，不参与任何调优决策；定期检查保留集与训练集的文本重叠度。
第二条的实操：抽 50 条保留集任务，与最近三个月的提炼材料做文本比对。重叠超过 10% 说明保留集已被污染。
5. 逐维度评什么
四条指标与五个横向指标说明「测什么层面」。具体到一个任务，还要决定评哪些维度。
三层验证展开成七个可逐项评分的维度，是这类系统里最完整的一张表。
| 维度 | 所属层 | 验证问题 | 主要证据 |
|---|---|---|---|
| 任务结果 | 结果层 | 核心诉求是否解决 | 最终环境状态、工具结果 |
| 规则遵从 | 过程层 | 是否违反政策、权限或必要流程 | 规则库、动作轨迹 |
| 隐私范围 | 过程层 | 是否泄露不应提供的信息 | 回复文本、数据访问记录 |
| 事实可靠性 | 跨两层 | 陈述是否有知识或工具结果支持 | 引用来源、工具返回 |
| 承诺与行动一致 | 过程层 | 声称完成的操作是否真实发生 | 回复与工具日志对照 |
| 表达质量 | 质量层 | 是否自然简洁，避免模板化 | 对话全文、量表 |
| 合规变通 | 质量层 | 原方案不可行时是否找到允许的替代 | 目标、规则与后续动作 |
四个设计点。
事实可靠性横跨两层。 能与工具返回逐一比对的部分由代码核验，其余交给量表。这个拆分避免了「整项都由模型判」带来的偏差。
承诺与行动一致单独成维。 它与任务结果是两件事：环境状态全对、但告诉用户的金额错了，任务结果这一维通过，这一维失败。分开才能发现这类失败。
合规变通只在质量层。 它评的是「原方案不可行时有没有找到替代」，不评最终是否解决。把它放在质量层，是为了避免「没解决就一定差」的简单判断。
七个维度不一定全用。 一个只做数据查询的 Agent 不需要「合规变通」；一个不做对外承诺的 Agent 不需要「承诺与行动一致」。选维度的依据是「这类失败在这个场景里是否可能发生」。
6. 回放作为评估环境
外层搜索（改工作流、改框架代码、改优化器）的评估成本很高：每个候选都要重跑 Agent 与评估器。回放机制是为了把这项成本降下来。
做法与两个成立条件在前面几节出现过，这里补它不能做什么，因为那决定了它能被信任到什么程度。
它只能比较分支、顺序、并行批次与停止时机。它不能证明在旧树上得分更高的策略能迁移到新任务——回放只是历史重组，不是世界模型。
这个限制值得强调，因为「在回放上分数很高」很容易被误读成「策略更好」。回放的优势是便宜，代价是它只覆盖历史里走过的路径。一条从未被探索过的分支，在回放里永远得不到分数。
7. 三类失效的诊断
三类的症状、成因与识别方法各不相同，但有一个共同点：它们都不表现为「分数下降」。
7.1 实现漂移
症状：原方案一旦变难，Agent 逐渐退回训练数据里更熟悉、但已经偏离原假设的做法。分数可能还涨了，因为它换成了更容易拿分的做法。
成因：目标函数没有覆盖「必须按这个方案做」，只覆盖了「结果要对」。
识别方法：对比早期与后期的动作序列，看是否出现系统性的方法替换。一个具体信号是工具使用分布的变化——如果某个关键工具的使用频率在几轮迭代后明显下降，说明方法被替换了。
7.2 认识论过度乐观
症状：信号还只是噪声，系统已开始解释结果、打补丁、宣布发现。失败与阴性结果被忽略。
成因：更新循环只看到幸存案例——失败的尝试没有被记录，所以归纳时只看到「成功的那些有什么共性」。
识别方法：检查失败案例是否被记录与聚合。如果日志里只有成功案例，这一条几乎必然发生。
7.3 隐性判断力不足
症状：Agent 能跑实验，但不知道哪个基线真正重要、哪个异常值得追踪、何时应该放弃假设。
成因：这类判断难以写成规则，也难以用分数衡量。
识别方法：人工审阅若干条完整的探索轨迹，看它是否在明显该放弃时继续投入。一个可量化的近似指标是「无效尝试占总尝试的比例」。
8. 安全约束与失效后果
四类措施，各自对应一类风险。
| 措施 | 对应风险 | 失效后果 |
|---|---|---|
| 结论与证据分离 | 结论无依据 | 无法追溯，错了不知从哪改 |
| 保留负面结果 | 只看到幸存方案 | 反复探索已证伪的路径 |
| 维护搜索多样性 | 收敛成单一模板 | 遇到新情况无备选 |
| 人在更高层介入 | 方向性错误 | 越做越偏，且无人察觉 |
结论与证据分离。 对引用、数字、方法与结论分别记录证据来源，最终输出只是证据图的一种呈现。它提高可追溯性，不保证结论有价值。
保留负面结果。 失败实验、被拒提案、停止原因都写入日志。否则进化模块只看到幸存方案，会反复探索已经证伪的路径。
维护搜索多样性。 不只保留当前得分最高的一条链。备选池需要保留若干暂时低分但类型不同的分支，避免所有方案收敛成同一个容易拿分的模板。
让人在更高层介入。 人的作用不止是在危险动作前点批准，还包括定义问题、审查评价标准、解释反常结果、决定何时停止。
第四条常被简化成「人工审批」，但审批只覆盖单次动作。真正的判断发生在更上层：这个方向值不值得做、这个指标定得对不对、这个异常是噪声还是信号。
9. 三道隔离
上面的措施处理的是「进化方向是否正确」。还有一类风险处理「一次错误如何变成长期风险」：网页、邮件与工具输出里的注入内容若被提炼成经验，会跨会话反复生效；自动搜索到的恶意依赖若被封装成工具，影响会从一次沙盒运行扩散到所有后续任务；一个有缺陷的验证器会持续批准看似进步、实际退化的版本。
三道隔离分别对应这三条路径。
9.1 证据与指令隔离
原始网页、工具输出及其模型摘要都属于不可信证据，不能当作指令执行，也不能直接纳入长期能力。
有一点必须说清：模型归纳只是把输入转成便于处理的形状，它达不到净化的效果。一段被归纳过的注入文本仍然是注入。
可执行的规则是三条：按固定结构提取主张、原文位置与采集时间；保留原文与来源；提取出的字符串绝不作为指令执行。
还有一条关于置信度：模型给出的置信度只是未经验证的估计，不能作为批准依据。把它当依据等于让被审查者自己决定是否通过审查。
待发布内容要经过确定性的结构校验、允许列表与来源检查，再以版本化的合并请求提交；独立的审阅方对照原始证据审查变更；高风险内容上线前还要人工批准。
9.2 待验证与正式能力隔离
新知识、提示词、Skill、程序与参数都先进入不可服务真实流量的待验证区。
新生成的代码与外部依赖还要额外经过沙盒、权限检查、供应链扫描与行为测试。全部通过后，才能服务真实流量。
这道隔离的价值在于它把「验证」变成了物理约束，不再依赖流程约定。只要待验证区不可服务真实流量，验证不通过的东西就不可能生效——不需要依赖任何人记得去检查。
9.3 安全机制不可自我修改
业务 Agent 可以改提示词、Skill、知识库、工具，但不能改批准自身更新的验证器、测试用例、发布判据、审计日志与稳定版本备份。
理由很直接：如果它可以改，那么只需降低判据或删除失败用例，就能把退化伪装成进步。这条比前两条更重要——前两条防止外部内容进入，这一条防止系统自己拆掉防线。
判定「什么算安全机制」的标准是：任何参与判断「这次更新能不能上线」的东西。包括判据本身、判据用的数据、判据产生的记录。
10. 不该做自进化的判据
三条硬判据，任何一条成立就应当放弃自动进化。
评价信号来得很慢或不唯一。 开放式研究、战略规划、复杂产品设计属于这一类。此时 Agent 可能把流程执行得很完整，却只是稳定地产出「像成果的东西」。自动进化会把这种稳定当成进步。
没有可回滚的发布机制。 如果一次错误的更新无法撤销，自动化的收益不值得承担风险。
失败案例无法被稳定记录。 如果系统只记得成功，归纳必然有偏。
一条弱判据：如果改动的实际执行者是人（每次更新都要人工改一段提示词），那么「自进化」只是把人的工作换了个说法。此时更值得优化的是人的工作效率。
11. 四个必须同时成立的能力
「持续进化」常被当成一个整体判断。拆开看，它至少包含四个能力，缺任何一个都不能算成立。
| 能力 | 含义 | 失效表现 |
|---|---|---|
| 记住 | 把这次的经验留下来 | 每次任务从零开始 |
| 迁移 | 把经验用到相似但不同的场景 | 只在完全相同的任务上有效 |
| 更新 | 用新规则覆盖或淘汰旧规则 | 继续使用已废止的规则 |
| 保持 | 更新后不破坏原有能力 | 修了一处坏了三处 |
四种失效的检测方式不同。第一种看有没有写入；第二种看跨场景的表现；第三种看是否还引用已被推翻的内容；第四种看保留集。
第三种的检测最容易被跳过，因为它需要读内容，看分数发现不了。一条可操作的做法：定期抽一条已废止的规则，看系统是否还会引用它。
第四种与第一种相反：一个从不更新的系统不会有保持问题，因为它没有变化。所以「保持」这项指标只在有更新时才需要看。
12. 开放式任务为什么不能靠换模型解决
前面的判据适用于有明确成功条件的任务。开放式研究、战略规划、复杂产品设计不同，而且不能靠换一个更强的模型彻底解决。
一个可参照的实测：四次从研究想法走向论文的端到端尝试，三次在实现或评估阶段失败，只有一次走完整条流水线。
三类问题反复出现。
实现漂移。 原方案一旦变难，就逐渐退回训练数据里更熟悉、但已偏离原假设的普通实现。这个失效的特征是「分数可能还涨了」，因为它换成了更容易拿分的做法。
认识论上的过度乐观。 信号仍可能只是噪声，系统却开始解释结果、添加补丁并宣布发现。失败与阴性结果更容易被忽略。
隐性判断力不足。 能运行实验，但不知道什么基线真正重要、哪个异常值得追踪、何时应该放弃假设。
三类问题的共同点是：它们都不表现为「分数下降」。这正是开放式任务难的地方——错误的方向上也能稳步产出看起来完整的东西。
可用的应对在证据与监督结构上，与模型能力无关：结论与证据分离、保留负面结果、维护搜索多样性、让人在更高层介入。四条与第 8 节一致。
13. 五步体检顺序
给一套 RSI 系统做体检，按这个顺序。
第一步，查日志完整性。 失败案例有没有被记录。这一项不过，后面都不用做——因为进化的方向从一开始就有偏。
第二步，查保留集独立性。 它是否真的独立于调优过程。做法是看它有多久没被用于决策，以及它与训练集的重叠度。
第三步，分开测两种能力。 固定任务模型测更新能力，固定更新器测受益能力。
第四步，查激活率与遵循率。 产物有没有被加载、加载后有没有被遵守。这两项能定位到「写得不好」还是「用不上」。
第五步，查长任务。 规则在压缩后是否还遵守。这一项最容易被忽略，也最容易在真实使用中暴露。
五步之中，前两步是前提，后三步是诊断。跳过前提直接看分数，会得到「指标很好」但实际无效的结论。
14. 一条从分数到原因的路径
拿到一组分数之后，判断该改哪里的顺序：
| 现象 | 可能原因 | 先查什么 |
|---|---|---|
| 分数不变，产物已生成 | 激活率低 | 目录描述与检索命中 |
| 分数部分上升 | 遵循率低 | 规则可判定性与任务长度 |
| 分数上升但线上无改善 | 保留集被污染 | 重叠度与使用记录 |
| 分数上升但某族下降 | 提案过拟合 | 分任务族看，别只看总分 |
| 分数下降 | 规则冲突 | 新增规则是否与旧规则矛盾 |
第四条最容易被总分掩盖。一个具体的检查方式：每次发布后按任务族出一张对比表，任一族下降超过 10 个百分点就单独看，不管总分如何。
这张表的作用是把「分数」转成「可执行的动作」。没有它，团队看到分数变化只能猜；有了它，每个现象都对应一个先查的位置。