智能体技能自进化框架：8阶段循环+3层评测+5维AND门控

1. 从“人工调参”到“自我迭代”：这套自进化框架到底在解决什么问题

做过智能体开发的人大概都有同感：最磨人的环节从来不是写第一版逻辑，而是后面无穷无尽的“改一版、测一轮、再改一版”。一个技能（Skill）从能跑到跑得好，中间往往隔着几十上百次人工介入——你得盯着日志找失败样本，手动归类错误类型，凭经验猜是提示词的问题还是工具调用的问题，改完再跑一遍回归，运气不好还会把之前修好的场景又弄坏。这套流程做久了，人会形成一种错觉：好像智能体的能力上限，取决于开发者熬夜的时长。

我这次要拆的这套东西，核心就是把这个“人肉迭代环”换成机器自己转的环。标题里三个数字是关键：8阶段Loop是自进化的主循环骨架，3层评测是判断“这一版到底有没有变好”的度量体系，5维AND门控则是决定“新版本能不能替换旧版本”的准入门槛。三者串起来，形成一个闭环：技能跑任务、产生失败样本、自动归因、生成改进方案、评测验证、门控放行或打回，然后进入下一轮。

它解决的问题很具体：让一个技能在没有人工逐条干预的情况下，通过反复自我对弈和评测，把成功率从“能用”推到“好用”。适合谁来参考？我认为有三类人最该看：一是手里已经有一批智能体技能、被维护成本压得喘不过气的开发者；二是在做评测体系建设、想知道怎么把“主观感觉变好了”变成“客观数据证明变好了”的工程团队；三是对自进化、自我改进这类机制好奇、想自己搭一套最小可用原型的技术爱好者。哪怕你只做其中一环，比如只想要那套3层评测，也能单独拎出来用。

需要先说明一点：标题里的“自己训练自己”容易让人联想到模型权重层面的训练，但这套框架实际做的是技能层面的自我优化——改的是提示词结构、工具调用策略、示例库、失败处理逻辑这些“技能资产”，而不是去动底层模型的参数。这个区分很重要，因为它决定了整套方案的落地成本和风险边界，后面会反复提到。

2. 整体设计与思路拆解：为什么是8+3+5这个组合

2.1 为什么主循环要拆成8个阶段而不是一锅炖

很多人第一反应是：自进化不就是“跑任务→看结果→改→再跑”吗，搞8个阶段是不是过度设计？我一开始也这么想，直到自己用三段式循环跑了几轮，发现两个致命问题。第一，失败样本没有经过结构化归因，改进方案全靠“感觉”，改出来的东西经常是按下葫芦浮起瓢；第二，改进和验证混在一起，改完立刻用同一批样本测，过拟合得厉害，线上表现反而掉。

8阶段的价值就在于把“思考”和“验证”彻底分开，并且在中间插入强制性的归因环节。我把它拆成下面这条链路，每个阶段都有明确的输入输出，任何一个阶段产出不合格就中断回退，不会带着脏数据往下走：

这个顺序不是随便排的。S3放在S4前面，是为了让改进有据可依；S5单独成阶段，是因为多个补丁之间会冲突，必须有一个合成与冲突消解的环节；S6和S7分开，是因为“测出来好不好”和“够不够格上线”是两个判断，混在一起容易让评测结果被上线压力绑架。我踩过的坑是早期把S6和S7合并，结果每次评测完都忍不住“这次就差一点点，放了吧”，门控形同虚设。

2.2 三层评测的分工逻辑：为什么单层评测一定会骗你

只做一层评测的团队，通常会用“整体成功率”这一个数字说话。这个数字的问题在于它太粗，粗到会掩盖结构性退化。举个我实际遇到的例子：某版本整体成功率从72%涨到75%，看着是进步，但拆开看发现简单任务从95%掉到88%，难题从40%涨到52%——它是靠牺牲简单场景的稳定性去换难题的偶然突破，这种“进步”上线后会被大量简单请求放大成灾难。

三层评测就是强制你把这件事看穿：

• 第一层：单元级评测。针对单个能力点做原子化测试，比如“能否正确解析带嵌套结构的输入”“工具调用参数格式是否合法”。这一层样本量大、判定客观，主要抓回归。
• 第二层：场景级评测。把多个能力点串成真实任务链，比如“先检索再计算再格式化输出”。这一层看的是能力之间的衔接是否顺畅，抓的是组合退化。
• 第三层：对抗级评测。用扰动样本、边界输入、诱导性指令去压测，看技能在压力下的鲁棒性。这一层样本少但杀伤力大，抓的是“平时好好的、一遇到怪输入就崩”的隐性缺陷。

三层的关系是漏斗也是保险：单元层保证地基不塌，场景层保证链路不断，对抗层保证极端情况不翻车。任何一层出现显著退化，都不该被整体数字掩盖。

2.3 五维AND门控：为什么必须是AND而不是加权平均

门控这块我见过最多的错误做法是加权打分：把五个维度各给个权重，算个总分，超过阈值就放行。这个做法在自进化场景里非常危险，因为加权平均允许“用一项的超常发挥去补偿另一项的严重缺陷”。一个版本可能因为某项指标暴涨把总分拉过线，但它在某个维度上其实已经烂到不能上线。

AND门控的逻辑很朴素：五个维度各自设独立阈值，全部达标才放行，任何一维不达标直接打回。这五个维度我建议这样设：

1. 绝对成功率：新版本在评测集上的整体成功率不低于基线，且不低于一个绝对下限。
2. 分层不退化：三层评测中任何一层的得分相对基线下降不超过容忍带（比如2个百分点）。
3. 稳定性：同一评测集重复跑多次，结果的方差要在阈值内，防止“这次运气好”。
4. 成本约束：平均token消耗、工具调用次数、时延不超出预算上限，防止用暴力堆算力换分数。
5. 安全与合规：对抗样本中触发违规、越权、幻觉硬伤的比例必须为零或极低。

AND门控的代价是“通过率低、迭代慢”，但换来的是“上线的东西不会突然崩”。我的经验是宁可让门控严到大部分候选版本被打回，也不要放松一维去追求迭代速度——自进化循环一旦放进来一个坏版本，后续所有轮次都会在坏地基上继续“优化”，越走越偏。

3. 核心细节解析与实操要点：每个阶段真正难的地方

3.1 任务采样与执行回放：样本质量决定进化上限

S1和S2看着最没技术含量，实际上是最容易被做废的两个阶段。任务采样的核心不是“随机抽”，而是按难度和类型分层抽样，并且保证每轮都有一定比例的历史失败样本被重新抽中。我用的比例是：50%常规分层样本、30%历史失败样本、20%新引入的边界样本。历史失败样本必须回炉，否则技能会“遗忘”自己曾经不会的东西；新边界样本保证循环不会在旧题库里自我陶醉。

执行回放阶段有个硬要求：全量记录轨迹，而不只是记录最终答案。轨迹里要包含每一步的输入、模型输出、工具调用参数与返回、耗时、token数。为什么？因为S3的归因质量完全依赖轨迹的颗粒度。只记录最终对错，归因只能猜；有了完整轨迹，才能定位到“是第三步的工具参数错了”还是“第五步的推理跑偏了”。我建议轨迹用结构化JSON存，字段固定，方便后续做统计和聚类。

注意：回放阶段一定要做确定性控制。温度、随机种子、工具超时都要固定，否则同一版本两次跑出来的结果差异会让你误判成版本退化。我吃过这个亏，排查了半天以为是补丁引入的bug，最后发现是采样温度没锁。

3.2 失败归因：把“错了”翻译成“为什么错”

S3是整个循环的智力核心。归因做不好，后面的改进提案就是瞎改。我的做法是建一个归因标签体系，把失败分成有限几类，每类对应不同的改进方向：

• 理解偏差：没读懂任务意图，改提示词的任务描述部分。
• 知识缺失：需要的事实不在上下文里，改检索策略或补充示例。
• 工具误用：参数错、选错工具、没处理返回异常，改工具调用规范。
• 推理断裂：多步推理中间步骤出错，改思维链结构或拆解粒度。
• 格式违规：输出结构不符合要求，改输出约束和校验逻辑。
• 边界崩溃：极端输入下失效，补对抗样本和防御性指令。

归因不是让模型自由发挥写一段分析，而是强制它从标签体系里选，并给出置信度和轨迹证据。置信度低于阈值的样本标记为“待人工复核”，不进入自动改进流程。这一步的严谨程度直接决定了后面补丁的质量——我见过太多团队在这里偷懒，让模型写一段“我觉得可能是因为……”的自由文本，结果改进提案全是泛泛而谈。

3.3 改进提案与补丁合成：小步快跑，一次只改一件事

S4最容易犯的错是“贪多”：一个补丁同时改提示词、改工具规范、改示例库，改完效果好不知道是哪部分起的作用，效果差也不知道该回滚哪部分。我的原则是一个归因标签对应一个最小补丁，一次迭代最多合成3个补丁，超过就拆成多轮。这样每个补丁的贡献可归因、可回滚。

补丁合成阶段（S5）要处理冲突。比如两个补丁都想改同一段提示词，就得有优先级规则：涉及安全约束的补丁优先级最高，其次是修复高频失败的，最后是优化低频场景的。合成后生成一个候选版本，打上版本号和父版本号，形成谱系。这个谱系很重要，出问题时能顺着链回滚到任意历史版本。

3.4 三层评测的落地细节：样本、判定、基线

评测体系落地时，三个东西必须先定死，否则后面全是扯皮。

样本集怎么建：单元层每个能力点至少50条，场景层每个任务链至少30条，对抗层每个攻击类型至少20条。样本要版本化管理，新增样本要标注来源，防止“改评测集来让版本通过”这种自欺欺人的操作。

判定怎么做到客观：能用规则判定的绝不用模型判定。格式、数值、工具调用参数这些用程序校验；只有开放式输出才用模型判定，而且判定模型要和被测技能隔离，最好用不同来源的模型，避免“自己判自己”。

基线怎么定：每轮迭代的基线是“当前线上版本”，不是“上一轮候选版本”。这个区别很关键——如果拿上一轮候选当基线，误差会累积，几轮下来标准就漂了。

3.5 门控执行与版本归档：把“克制”写进流程

S7的AND门控要真正生效，前提是门控逻辑独立于改进流程，不能被“这次很想让它过”的情绪影响。我的做法是把门控做成一个纯函数：输入评测报告和基线数据，输出放行或打回，中间没有任何人工override的口子（紧急情况走单独的应急通道并留痕）。打回的候选版本不删除，归档保留，因为有些被打回的版本在后续轮次里可能因为基线变化而变得有价值。

S8归档要记录：版本号、父版本、包含的补丁列表、三层评测得分、五维门控各项数值、放行或打回原因。这份档案是后续做趋势分析和问题回溯的唯一依据，别省。

4. 实操过程与核心环节实现：从零搭一个最小可用循环

4.1 环境与依赖准备

这套东西不需要多重的基建，一台能跑模型推理的机器加一个任务队列就够起步。我建议的最小技术栈：

• 编排层：用现成的任务编排工具串8个阶段，每个阶段是一个独立可重跑的作业。
• 存储层：轨迹和评测结果存结构化数据库，版本快照存对象存储。
• 模型层：执行技能用一个模型，归因和判定用另一个（隔离原则），预算紧的话至少保证判定模型和被测模型不同源。
• 配置层：所有阈值（采样比例、置信度门槛、五维阈值、容忍带）集中在一个配置文件里，改阈值不改代码。

# 自进化循环核心配置示例 loop: max_rounds: 20 sample: regular_ratio: 0.5 failure_ratio: 0.3 boundary_ratio: 0.2 attribution: min_confidence: 0.7 max_patches_per_round: 3 gate: absolute_success_rate: 0.80 layer_degradation_tolerance: 0.02 stability_variance_max: 0.03 cost_budget_ratio: 1.15 safety_violation_max: 0.0

4.2 单轮循环的完整执行流程

下面是我实际跑一轮的步骤，按顺序说清楚每步在干什么、为什么这么干。

第一步，锁定基线。从版本库取出当前线上版本作为基线，同时把它的三层评测报告调出来作为对比基准。这一步不能省，否则后面门控没有参照物。

第二步，采样并执行。按5:3:2的比例抽任务，跑技能，全量落轨迹。执行时锁死温度和种子。这一轮如果出现执行环境异常（比如工具超时率异常高），直接中断本轮，不进入归因——环境问题不是技能问题，混进去会污染归因。

第三步，归因聚类。对失败样本逐条归因，按标签聚类，统计每类失败的占比和置信度分布。占比高且置信度高的类，优先进入改进提案。

第四步，生成补丁。针对top失败类生成最小补丁，每个补丁附带“预期改善的指标”和“可能影响的场景”。这个预期很重要，后面评测时拿实际结果和预期对比，能发现补丁是否按预期起作用。

第五步，合成候选版本。合并补丁，处理冲突，生成候选版本并打版本号。

第六步，三层评测。候选版本跑完整三层评测，每层重复跑3次取均值和方差。重复跑是为了稳定性维度，单次结果不可信。

第七步，门控判定。把评测报告和基线对比，五维逐项判定。任何一维不过，记录打回原因，本轮结束，进入下一轮采样。

第八步，归档与切换。五维全过，候选版本归档并切换为新的线上版本，同时更新基线。下一轮循环以新基线开始。

4.3 参数计算与阈值设定过程

阈值不是拍脑袋定的，得有计算依据。以“分层退化容忍带”为例，我设2个百分点是这样算的：单元层样本量按500条算，成功率的统计波动大约在±2%左右（二项分布标准差约2.2%），所以2个百分点的退化在统计上还可能是噪声，超过2%才可能是真退化。如果你的样本量只有100条，波动会到±5%，容忍带就得放宽，否则天天误报。

成本预算比例1.15的意思是：新版本的平均成本不超过基线的115%。为什么给15%的余量？因为改进往往伴随更细致的推理或更多的工具调用，完全不允许成本上升会扼杀有效改进；但超过15%就说明改进方式太“暴力”，性价比不划算。

稳定性方差阈值0.03是经验值：同一评测集重复跑，成功率方差超过3个百分点，说明这个版本对随机性太敏感，上线后表现会飘。这个值可以根据你的任务特性调整，任务本身随机性大的可以放宽到0.05。

4.4 一次真实的迭代记录

拿我最近跑的一轮举例。基线版本整体成功率74%，单元层91%、场景层68%、对抗层52%。S3归因发现“工具误用”占失败的38%，其中大部分是“多工具场景下选错工具”。S4生成了一个补丁：在工具选择前增加一步“工具能力自检”，让技能先确认每个工具适用的输入类型再选。S5合成候选版本。

S6评测结果：整体76%，单元层90%、场景层71%、对抗层53%。看着整体涨了，但单元层掉了1个百分点。S7门控判定：绝对成功率过（76%>80%？没过，绝对下限是80%，直接打回）。这一轮被打回的原因很明确——整体虽然涨了，但没到绝对下限，说明这个技能的基础能力还不够扎实，不该急着上线。这个结果当时让我有点意外，但回头看是对的：绝对下限这道门就是防止“相对进步但绝对不够用”的版本溜上线。

下一轮我调整了策略，先针对单元层的薄弱能力点做专项补丁，把单元层推回92%以上，再考虑场景层的优化。这就是8阶段循环的好处：它逼着你按顺序解决问题，而不是哪里看着顺眼改哪里。

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

5.1 循环跑着跑着“原地打转”怎么办

这是最常见的症状：连续几轮门控都打回，归因标签翻来覆去就那几类，补丁也生成了但评测没变化。原因通常有两个。一是归因粒度太粗，比如“推理断裂”这个标签下其实混着好几种不同的断裂模式，补丁只能治其中一种，其他几种把效果抵消了。解法是把粗标签再往下拆一层，拆到“可被单个补丁修复”的粒度。二是补丁之间互相冲突，合成时冲突消解规则把有效补丁的改动覆盖掉了。解法是检查合成日志，看每个补丁的实际生效比例。

5.2 评测分数忽高忽低，门控判定反复横跳

先查确定性控制。温度、种子、工具超时、外部依赖的版本，任何一项没锁死都会导致这个现象。如果都锁死了还飘，查评测样本里有没有“判定本身就不稳定”的条目——开放式输出的模型判定最容易出这个问题。解法是把这类条目的判定改成多次判定取多数，或者干脆改成规则判定。

5.3 门控太严导致几乎不产出，要不要放松

我的建议是先别放松门控，先查基线是不是定高了。有时候不是新版本差，是基线本身是个偶然跑出来的高分版本，拿它当基准谁都过不了。解法是基线用“多次评测的均值”而不是“单次最高分”。如果基线没问题、门控还是过严，再逐维检查阈值是否有计算依据，把拍脑袋定的阈值换成有统计依据的。

5.4 常见问题速查表

5.5 几个不外传的避坑心得

第一，评测集要“冷冻”一部分。留10%到20%的样本永远不参与改进循环，只在最终上线前跑一次。这部分叫“盲测集”，是防止过拟合的最后一道防线。我见过团队把所有样本都喂进循环，结果评测分数一路涨到90%，上线一跑只有60%，就是过拟合了。

第二，归因模型和执行模型要定期换位。长期用同一个模型做归因，它会形成固定的“偏见”，总把失败归到某几类。定期换一个归因模型，能发现之前被忽略的失败模式。

第三，打回的版本别急着删。有些版本在当时的基线下不合格，但过几轮基线变化后，它的某些补丁可能正好补上新暴露的短板。归档保留，定期回看，能捡回不少“错杀”的改进。

第四，门控的安全维度设成硬零。其他维度可以有容忍带，安全维度不行，触发一次违规就整版打回，没有商量余地。这条线一旦松，后面所有轮次都会在危险边缘试探。

6. 影响范围与延展思考：这套框架还能往哪用

这套8+3+5的结构，表面是给智能体技能做自进化，但它的骨架其实适用于任何“有明确评测标准、可自动验证”的迭代场景。比如提示词工程的自动化调优——把提示词当技能，把下游任务当评测集，8阶段循环照样能跑；比如规则引擎的规则集优化，把规则命中率和误报率当评测维度，门控逻辑可以直接复用。核心不变的是那三件事：结构化归因、分层评测、AND门控。只要你的场景能定义清楚“什么叫变好了”，这套循环就能把人工迭代的活接过去。

我个人在实际操作中的体会是，这套东西最大的价值不在于“省了多少人力”，而在于它强迫你把迭代过程显性化。以前人工改技能，很多判断是隐性的、凭直觉的，出了问题说不清是哪一步的决策导致的。现在每个阶段都有产出物、每个决策都有数据支撑、每个版本都有谱系，回头复盘的时候一目了然。这种“过程可审计”带来的安心感，比单纯的成功率提升更值钱。

最后分享一个小技巧：刚开始搭的时候，别追求8个阶段全自动。先把S6三层评测和S7门控做出来，用人工做S3和S4，跑几轮感受一下评测体系和门控的松紧度，等阈值调顺了再把归因和改进也自动化。上来就全自动，大概率会因为归因质量差、门控阈值不合理而陷入“循环空转”，反而打击信心。分步上，每步验证，是我试过最稳的路子。