8阶段Loop+3层评测+5维AND门控：Skill自进化机制全拆解

1. 这套“自进化”机制到底在解决什么问题

第一次看到“让Skill自己训练自己”这个说法，我脑子里蹦出来的第一个念头是：又是一个把“自动化”包装成“自进化”的概念货。但把标题拆开看——8阶段Loop、3层评测、5维AND门控——这三个数字组合在一起，指向的其实是一个非常具体、非常工程化的东西：一套让技能模块（Skill）在无人值守的情况下持续迭代、自我筛选、自我淘汰的闭环系统。

先说清楚这里的“Skill”指什么。在当下的智能体（Agent）开发语境里，Skill通常指一个封装好的、可被调用的能力单元——可能是一段提示词模板、一个工具调用链、一个特定任务的执行策略，或者一个微型的推理流程。你可以把它理解成智能体的“肌肉记忆”：遇到某类输入，就触发某套固定动作。问题在于，这类能力单元一旦写死，就会迅速老化。输入分布变了、上游模型换了、业务场景迁移了，原本好用的Skill就开始掉链子。传统做法是人工定期复盘、手动改提示词、重新跑测试集，费时费力且滞后。

这套机制要解决的核心痛点就三个字：迭代慢。人工介入的迭代周期以天甚至周为单位，而输入分布的变化可能以小时为单位。标题里“自己训练自己”的本质，不是让模型去改模型权重（那叫微调，成本高得多），而是让Skill在运行过程中自动生成候选变体、自动评测、自动决定是否替换旧版本。8阶段Loop是迭代的骨架，3层评测是筛选的标尺，5维AND门控是最终放行的闸机。三者缺一不可：没有Loop就没有候选，没有评测就无法比较，没有门控就会把退化版本放进来。

这套东西适合谁参考？我认为有三类人值得细看。第一类是正在做智能体工程化的开发者，手里已经有一批Skill在跑，但苦于维护成本；第二类是做提示词工程或评测体系的技术同学，想了解怎么把“人工调优”变成“系统自筛”；第三类是对自动化闭环感兴趣的产品或技术负责人，需要判断这套思路的落地边界在哪里。如果你只是偶尔写两个提示词玩玩，这套机制属于杀鸡用牛刀，但如果你维护着几十上百个Skill，那这套东西的价值就出来了。

我先把结论摆在这里：这套机制真正的难点不在“Loop怎么转”，而在“评测怎么设计”和“门控怎么定阈值”。Loop是体力活，评测是脑力活，门控是良心活——门控太松，退化版本混进来；门控太紧，好东西永远上不了线。下面我按自己的理解，把这套系统从设计思路到落地细节完整拆一遍。

2. 整体架构拆解：为什么是8、3、5这三个数字

2.1 8阶段Loop的设计逻辑与阶段划分

8阶段Loop是整个系统的发动机。为什么是8个阶段而不是5个或10个？我的理解是，这个数字对应的是“一次完整的技能迭代生命周期”所必须经历的最小闭环。少于8个，某些环节会被合并，导致职责不清；多于8个，又会引入冗余的等待和交接成本。基于常见的自动化迭代实践，我把它还原成下面这8个阶段：

1. 触发采集：监控Skill的运行指标（成功率、延迟、用户反馈信号），当指标跌破基线时触发迭代。
2. 失败归因：对触发样本做聚类分析，判断是输入分布漂移、提示词歧义，还是工具调用失败。
3. 候选生成：基于归因结果，生成N个Skill变体（改提示词、换示例、调参数、增删步骤）。
4. 沙箱预跑：候选变体在隔离环境中跑小批量样本，快速淘汰明显不可用的。
5. 全量评测：通过预跑的候选进入3层评测体系，拿到多维评分。
6. 门控裁决：5维AND门控对评分做联合判定，决定是否晋级。
7. 灰度发布：晋级版本以小流量上线，观察真实环境表现。
8. 归档回写：无论成败，把本次迭代的样本、变体、评分、结论写回知识库，供下轮参考。

这8个阶段里，我认为最容易被低估的是第2阶段“失败归因”和第8阶段“归档回写”。很多人做自动化迭代，上来就生成候选，结果候选方向全错，白跑一轮。归因做得好，候选生成才有靶子。而归档回写决定了系统能不能“越跑越聪明”——如果每轮迭代都是无记忆的，那它只是个自动跑批工具，谈不上自进化。

提示：8阶段不是严格串行的。触发采集和归档回写可以常驻后台，归因和候选生成可以并行，沙箱预跑和全量评测可以流水线化。真正需要串行的只有“门控裁决→灰度发布”这一步，因为发布动作有副作用。

2.2 3层评测的分层依据与职责边界

3层评测是这套系统的标尺。为什么分3层？因为单一评测维度必然有盲区：只看准确率会漏掉稳定性，只看稳定性会漏掉成本，只看成本会漏掉用户体验。3层的划分逻辑，我倾向于按“评测的置信度和成本”来切：

第一层的职责是“别让垃圾浪费后面的算力”，所以它必须快、必须便宜，哪怕误杀一些边缘候选也认了。第二层是主力评测，覆盖核心业务指标，这一层的样本集质量直接决定系统上限。第三层是“压力测试”，专门喂边界输入、对抗输入、长尾输入，看候选在极端情况下会不会崩。

这里有个实操心得：三层评测的样本集必须物理隔离，不能有重叠。我见过有团队图省事，三层用同一套样本的不同子集，结果候选在第一层表现好是因为样本简单，到第三层还是那批样本的变体，评测就失去了区分度。正确的做法是三层样本从不同来源、不同时间段、不同分布里抽，确保每层测的是不同的东西。

2.3 5维AND门控的维度选择与联合判定

5维AND门控是最后的闸机。AND的意思是：五个维度全部达标才放行，任何一个不达标就拦下。这跟“加权平均”是两种哲学——加权平均允许“一好遮百丑”，AND门控则要求“没有短板”。为什么选AND？因为Skill是生产环境里的能力单元，一个维度崩了就是事故，不能用其他维度的优秀来补偿。

五个维度我建议这样选（具体可按业务调整，但逻辑相通）：

• 效果维度：核心任务成功率不低于基线，且置信区间下界不能低于阈值。
• 稳定性维度：多次运行的方差在可接受范围内，不能时好时坏。
• 成本维度：单次调用的token消耗或延迟不能显著高于旧版本。
• 安全性维度：不能触发预设的禁忌行为或输出越界内容。
• 兼容性维度：不能破坏下游依赖该Skill的其他模块。

AND门控的阈值设定是良心活。设太松，退化版本混进来；设太紧，迭代永远通不过。我的经验是：新系统上线初期，阈值先松后紧。先让系统跑起来，积累几十轮迭代数据，看清各维度的实际分布，再回头收紧阈值。一上来就卡死，系统会陷入“永远在评测、永远不发布”的死循环。

3. 核心细节解析：每个环节的实操要点与坑

3.1 候选生成阶段：多样性比数量更重要

候选生成看起来简单——改改提示词、换换示例不就完了？实操下来，这里是最容易出问题的地方。常见错误是“生成一堆高度相似的变体”，比如只改了个别措辞，本质上是同一个东西。这样的候选集在评测阶段会集体通过或集体失败，浪费算力且学不到东西。

我的做法是按“变异维度”分组生成：一组只改提示词结构（比如从指令式改成示例式），一组只改示例选择策略（比如从固定示例改成动态检索示例），一组只调执行参数（比如重试次数、超时阈值），一组做步骤增删。每组生成2-3个候选，确保候选集在“变异空间”里是分散的。这样即使某组全军覆没，其他组还有希望，而且归因时能看清“哪类变异有效”。

另一个坑是候选生成没有约束。不加约束的话，生成器可能产出语法都不通的提示词，或者引入不存在的工具调用。所以候选生成后必须过一道“静态校验”：语法检查、工具白名单检查、长度检查。这道校验很便宜，但能挡掉大量低级错误。

3.2 评测样本集的构建与防泄漏

评测样本集是整套系统的地基。地基不牢，上面盖什么都是歪的。构建样本集时我踩过三个坑：

第一个坑是样本分布偏移。用历史日志抽样本，抽出来的全是“过去常见”的输入，但触发迭代的恰恰是“新出现的”输入。所以样本集里必须有一部分来自近期触发失败的样本，比例我一般控制在30%左右。

第二个坑是标注质量参差。评测需要标准答案，但标准答案本身可能有错。我的处理是：核心样本双人标注+分歧仲裁，边缘样本单人标注但标记置信度，低置信度样本在评测时降权。

第三个坑是样本泄漏。候选生成时如果参考了评测样本，那评测就失效了。所以生成器和评测集之间必须有硬隔离——生成器只能看“训练池”，评测只能用“测试池”，两个池子定期轮换但绝不重叠。

注意：样本集要定期“保鲜”。我一般每两周做一次样本审计，把已经不再代表当前分布的旧样本淘汰，补充新样本。样本集不更新，评测就会慢慢失真，系统会对着过时的标尺自我感觉良好。

3.3 灰度发布与回滚机制的设计

灰度发布是“门控通过”之后的最后一道保险。门控再严，也是在离线环境判的，真实环境总有意外。灰度发布的核心参数是流量比例和观察窗口：初始流量我一般设5%，观察窗口设24小时或累计1000次调用（取先到者）。观察期内监控的指标和门控五维一致，任何一维触发告警就自动回滚。

回滚机制必须做到“一键且无损”。所谓无损，是指回滚后旧版本能立刻接管，且灰度期间产生的数据不丢失。这就要求新旧版本在接口层面完全兼容，状态存储要能双写或做版本隔离。我见过有系统回滚时因为状态格式不兼容导致下游报错，那还不如不灰度。

另一个细节是灰度期间的样本采集。灰度流量里的真实输入是宝贵的评测素材，要专门落库，标注后补充进评测样本集。这样系统跑得越久，样本集越丰富，评测越准，形成正循环。

4. 实操过程还原：从零搭一套最小可用闭环

4.1 环境准备与基础组件选型

搭这套系统不需要什么特殊基础设施，一台能跑批处理的机器加一个对象存储基本就够。我的最小可用配置是这样的：

• 调度层：用现成的任务调度工具（比如基于cron的轻量调度器），负责按8阶段编排任务。不建议一上来就上重型工作流引擎，8个阶段的依赖关系用配置文件描述足够了。
• 执行层：容器化运行每个候选变体，确保隔离。每个候选一个容器，跑完即销毁，避免状态污染。
• 存储层：对象存储放样本集和候选产物，关系型数据库放评测结果和迭代记录。迭代记录的表结构要设计好，至少包含：迭代ID、触发原因、候选列表、各层评分、门控结论、发布时间、回滚标记。
• 监控层：简单的指标采集加告警即可，重点监控成功率、延迟、成本三个曲线。

选型上我的原则是“能用现成的绝不自己造”。这套系统的价值在评测和门控的设计，不在基础设施。把精力花在刀刃上。

4.2 一次完整迭代的现场记录

拿一个虚构的“文本分类Skill”举例，还原一次真实迭代。假设监控发现该Skill在“长文本输入”上的成功率从92%跌到85%，触发迭代。

阶段1-2（触发与归因）：拉取近500条失败样本，聚类后发现70%集中在“输入超过2000字且包含多个并列主题”的场景。归因结论：原提示词对长文本的多主题处理指令不够明确。

阶段3（候选生成）：按变异维度生成8个候选。A组（提示词结构）3个：增加“先分段再分类”的显式指令、增加“多主题时取主主题”的规则、两者都加。B组（示例策略）3个：增加长文本示例、增加多主题示例、动态检索相似示例。C组（参数）2个：调高最大输出长度、增加一次自检重试。

阶段4（沙箱预跑）：每个候选跑50条样本。结果A组3个全部通过预跑，B组2个通过，C组1个通过，共6个进入全量评测。

阶段5（三层评测）：第一层快速筛查淘汰2个（一个在简单样本上就退化了），剩4个。第二层标准评测淘汰1个（成本超标30%），剩3个。第三层深度评测淘汰1个（对抗样本上稳定性不达标），剩2个。

阶段6（门控裁决）：2个候选过5维AND门控。候选X五维全过；候选Y在兼容性维度卡在阈值边缘（下游模块对输出格式敏感），被拦下。

阶段7（灰度发布）：候选X以5%流量上线，观察24小时。期间成功率回升到91%，延迟持平，无告警。

阶段8（归档回写）：记录本次迭代全过程，特别标注“长文本多主题”场景的归因结论和有效变异方向，供下轮参考。同时把灰度期间采集的200条真实长文本样本标注后补入评测集。

这一轮下来，从触发到全量发布大约36小时，其中大部分时间花在评测和灰度观察上，人工介入只有归因结论的确认和门控阈值的复核。

4.3 关键参数的计算与设定过程

几个关键参数不能拍脑袋，得有计算依据。

灰度流量比例：设初始比例为p，观察窗口内期望采集样本数为n，则p = n / (日均调用量 × 观察天数)。假设日均调用1万次，想采1000条样本观察1天，p = 1000/10000 = 10%。我一般取计算值的一半作为保守起点，即5%，不够再逐步加。

门控阈值：以效果维度为例，设旧版本成功率基线为b，新版本评测成功率点估计为s，样本量为n，则标准误se = sqrt(s(1-s)/n)。门控要求s - 1.96×se ≥ b × 0.98（允许2%的容差）。这个公式的意思是：新版本成功率的95%置信下界，不能低于旧版本基线的98%。这样既考虑了统计波动，又留了容差空间。

评测样本量：第二层评测的样本量n，要满足“能区分2%的差异”。粗略公式n ≈ 16 × p(1-p) / δ²，其中p是预期成功率，δ是希望检测的最小差异。p=0.9、δ=0.02时，n ≈ 16×0.09/0.0004 = 3600。实际我会取这个值的1/3到1/2，因为完全严格统计显著会让迭代周期太长，工程上取“方向正确+幅度可信”即可。

5. 常见问题与排查技巧实录

5.1 迭代陷入死循环：永远在评测，永远不发布

这是最常见的病。症状是系统跑了很多轮，但门控通过率极低，或者通过了也不敢发。根因通常有两个：阈值设太紧，或者评测样本太难。

排查思路：先看各维度的评分分布，如果大部分候选在某一维度上集中卡在阈值附近，说明该维度阈值不合理，需要放宽或重新校准。再看评测样本的通过率，如果旧版本自己在评测集上的通过率都只有70%，说明样本集偏难，需要补充中等难度样本。

我的处理办法是设一个“熔断机制”：连续10轮迭代门控通过率为零，自动触发阈值复核流程，人工介入调整。同时保留一个“保底通道”：如果某候选在效果维度显著优于基线（比如提升超过5%），即使其他维度卡边缘，也允许进入灰度，但灰度流量减半、观察期加倍。

5.2 评测结果与线上表现不一致

离线评测说好，上线就翻车。这个问题的根因几乎总是“评测集不代表性”。排查时我会做两件事：一是对比评测集和线上真实输入的分布（按长度、主题、格式分桶对比），找出偏差最大的桶；二是把线上翻车的样本捞出来，看它们在评测集里有没有对应物。

解决方法是建立“评测集-线上”的反馈回路：每次灰度或全量发布后，把线上表现和离线评分做相关性分析，相关性低的评测维度要重新设计。我一般要求效果维度的离线-线上相关性不低于0.7，低于这个值就说明评测集需要大修。

5.3 候选生成同质化严重

前面提过，这里展开说排查方法。把一轮迭代的所有候选做文本相似度聚类，如果聚成1-2个大簇，说明同质化严重。根因通常是生成器的“变异指令”太笼统，或者生成器本身能力不足。

处理办法：给生成器喂“变异模板库”，每个模板明确指定变异维度和变异幅度，比如“将指令式提示词改写为示例式，示例数量3-5个”。模板库要定期更新，把历史上有效的变异模式沉淀进去。另一个技巧是引入“强制多样性”：生成N个候选后，计算两两相似度，超过阈值的强制重新生成。

5.4 常见问题速查表

5.5 几个不写在文档里的避坑心得

第一个心得：别在周五下午发布灰度。灰度观察期需要人盯着，周末出问题响应慢。我现在的规矩是灰度只在周一到周三启动，观察期跨一个工作日。

第二个心得：门控阈值要写进配置，不要写死在代码里。阈值一定会调，写死在代码里每次调都要发版，太痛苦。配置化之后，调阈值就是改个数字，五分钟生效。

第三个心得：归档回写要存“负样本”。大部分人只记成功的迭代，失败的迭代一笔带过。但失败迭代里的归因结论和无效变异方向，对下轮避免重复踩坑价值极大。我的归档表里专门有一列“本轮排除的变异方向”，下轮生成候选时先排除这些方向。

第四个心得：评测集的标注者要轮换。同一个人标久了会产生“标注惯性”，对某类样本的判断越来越松或越来越紧。我一般每两个月轮换一次标注分工，并做交叉校验。

6. 这套机制的边界与我的实际体会

这套8阶段Loop、3层评测、5维AND门控的组合，说到底是一套“工程化的自我迭代框架”。它的能力边界很清晰：它能处理的是“Skill层面的策略优化”，也就是提示词、示例、参数、步骤编排这些可枚举、可评测的变异。它处理不了的是“能力层面的跃迁”——比如一个Skill原本就不会做某类任务，靠变异是变不出来的，那需要的是新增Skill或换底层模型。

我在实际搭这套东西的过程中，最大的体会是：系统的智能程度，取决于评测体系的设计水平，而不是Loop的自动化程度。Loop再顺滑，评测不准，系统就是在高效地生产垃圾。反过来，评测设计得好，哪怕Loop是半自动的、需要人工点一下确认，系统也能持续产出有价值的迭代。所以如果你要动手做类似的东西，我的建议是把70%的精力花在评测样本集和门控阈值上，30%花在Loop编排上。

另外一点体会是关于“自进化”这个词的祛魅。这套机制跑起来之后，系统确实会越跑越顺——样本集越来越丰富、变异模板库越来越厚、阈值越来越准。但这种“进化”是有天花板的，天花板就是评测体系的上限。它更像是一个不知疲倦的实习生，在明确的评价标准下持续微调，而不是一个能自己定义方向的专家。认清这一点，你对它的预期就不会跑偏，落地时也不会因为“它怎么没自己变聪明”而失望。

最后分享一个我最近在试的扩展方向：把“归档回写”阶段的历史迭代记录做成检索库，候选生成时先检索“类似归因结论下哪些变异方向有效”，用历史经验给生成器做提示。初步跑下来，候选的有效率有提升，但提升幅度还不稳定，样本量还不够下结论。这个方向后续如果有更扎实的数据，再单独整理一篇。