删掉冗余 Skill 后 Agent 更听话：反馈回路、规则库维护与重构指南 2026

把 Skill 文档越修越长，通常不是因为团队真的需要更多规则，而是因为每次失败都被当成一次新的写作机会。一个 badcase 出现，大家就在末尾补一句；两个 badcase 连在一起，就补一段；三四次之后，原本该用版本、回归和审批管理的东西，开始像临时告示栏一样堆在一起。文本看上去更认真，Agent 却更难分辨哪些是主规则，哪些是补丁，哪些只是旧版本留下的回声。

这次的案例很典型：一个数据质量异常检测 Agent 的 Skill 从大约 400 行被自动追加到大约 1500 行，结果不是更稳，而是更容易发生规则打架、重复覆盖和注意力稀释。这里的行数只能算个案，不是放之四海而皆准的结论；它真正说明的是，文档膨胀本身会制造新的失败模式。若没有完整实验设置、模型版本、输入分布和评分方法，任何比例数字都只能用来提醒团队做自己的测量，不能直接拿去当定律。

所以这篇文章不把 Skill 当成“提示词的长稿”，而把它当成一套外部规则系统：有来源、有边界、有审批、有回滚。只要自动修复还在继续运行，规则库就一定会出现漂移，唯一的问题是你要不要提前把漂移看见、记住、限制住。真正可维护的不是一句更重的话，而是一组能被去重、能被回归、能被撤销的条目。

一、先承认：自动修复天生会放大经验债

自动修复工具最容易犯的错，是把“修好一次”理解成“写下一次”。它看到失败，就把当前判断塞进文档，仿佛加字越多，Agent 越不可能再犯。可现实里，很多错误并不是因为规则太少，而是因为规则之间的优先级不清，或者某条局部修复把更高层的规则挤出了上下文。于是每次修补都像在墙上再贴一张纸，最后不是纸不够，而是墙看不见了。

更麻烦的是，自动修复通常缺少记忆的纪律。它不知道某条限制是否已经存在，只是把“看起来像新知识”的句子重复塞进去；它不知道这条句子是不是上次事故留下的临时禁令，也不知道它和另一个段落是不是同一意图的不同表述。这样一来，经验债就会被翻译成规则债，规则债再变成文档债，最后团队只剩下一个感觉：文件越来越长，但系统越来越脆。

正确的反馈回路必须先问清楚，失败到底该写进哪里。该写进 badcase 库的，就不要急着写进主文档；该写进回归集的，就不要用自然语言重述三遍；该写进运行手册的，就不要把它伪装成核心规则。把信息放回正确的位置，往往比继续堆新段落更有效。

二、400 到 1500 行不是“变强”，而是信号变乱

很多团队第一次看到这类案例时，会把“从 400 行到 1500 行”误读成“知识更完整了”。其实未必。行数暴涨常常意味着三件事同时发生：一是老规则没有被识别出来就被重复写入；二是局部修复覆盖了局部失败，却没有收敛到统一的优先级；三是更多例外被放进正文，导致主规则和边缘情况的界线越来越模糊。看起来像积累，实际上是噪声把秩序包住了。

这类膨胀最危险的地方，不在于文件大，而在于人会开始相信“这么长一定有它的道理”。于是没人敢删，删的时候也不敢删得干净，因为每一段看起来都像是从某个失败里长出来的。结果是，真正在起作用的规则被埋在中间，真正该回收的临时修补却被当作正式约束供着。一个靠自然语言维护的系统，最怕的就是把“有痕迹”误认为“有价值”。

所以在治理上，行数只能当成警报，不该当成成绩。你需要看的是：重复率有没有升高，冲突数有没有上升，规则被引用的密度有没有失衡，某个 badcase 是否被多次改写成近义句。只要这些信号在变差，单纯增加长度就不是修复，而是继续堆积风险。

三、先做规则盘点，再谈任何重写

一份可维护的 Skill，第一步不是扩写，而是盘点。盘点的意思不是粗略扫一遍，而是给每条规则都挂上身份：它解决什么问题，什么时候生效，和谁冲突，来源是什么，最后一次验证是什么时候，谁批准它进入正文，什么时候可以回收。没有身份的规则，迟早会在自动修复里被当成新信息再次写进来。

我通常会把规则拆成五类：主规则、例外规则、格式规则、工具规则、回滚规则。主规则负责定义默认行为；例外规则只处理明确边界；格式规则只管输出形态；工具规则描述调用动作；回滚规则决定出了问题怎么退。把这五类混在一起，Agent 就会把“应该怎么做”和“什么时候不要这样做”搅成一锅。分开之后，很多冲突会自动浮出来，不需要靠更多文字去压住它们。

分类	该写什么	不该写什么	常见风险
主规则	默认策略、优先顺序、完成标准	临时例外、回归测试细节	被大量补丁淹没
例外规则	有限场景、触发条件、失效条件	无限扩展的“如果可能”	范围漂移
格式规则	输出顺序、字段、长度限制	业务判断本身	和主规则抢位置
工具规则	允许调用的工具、失败处理	业务结论	把工具当成答题器
回滚规则	版本切换、撤回条件、审批要求	解释历史道理	无法恢复到已知稳定态

四、坏例子要进回归集，不要只进说明文

很多修复之所以会再次失败，是因为 badcase 只被写成了故事，没有被写成测试。故事能让人记住一次事故，但不能自动提醒系统下次避开同样的坑。回归集的价值就在于把事故翻译成判断：输入长什么样、触发条件是什么、正确输出应该遵守哪一条规则、最小通过标准是什么。只有这样，规则才不是“感觉上更严谨”，而是“真的能拦住同类错误”。

回归集不该只是失败样本的仓库，它更像是规则库的体检表。一个 badcase 进来之后，要做三件事：先判断它属于知识缺失、规则冲突还是工具误用；再决定应该增加正向行为、修正优先级还是拆开范围；最后把这个样本留在回归集中，避免下次自动修复再把它改写成另一段相似的话。这样做的目的不是写得更漂亮，而是让规则变化可见、可查、可挡。

如果回归集只收集“曾经错过”的样本，团队就会越来越被动。更好的做法是加入“本来就该会”的样本，以及“边界上容易犹豫”的样本。前者用来维持基本能力，后者用来维持稳定边界。没有这两类样本，自动修复永远在追着事故跑，永远在补昨天的洞。

五、规则预算是防膨胀最便宜的刹车

规则预算不是一个学术概念，而是一个非常实用的止损线。你可以给正文、例外、工具说明、回滚说明分别设置上限，也可以给每次自动修复设置“最多新增几条、最多修改几处、最多引入几类冲突”的预算。预算的目的不是限制聪明，而是阻止系统在没有审核的情况下越长越胖。对自然语言文档来说，默认增长就是风险，除非它已经通过审查证明值得增长。

预算一旦设置，就要允许它拒绝看起来“很合理”的补充。很多临时补丁单看都对，放在一起就把主规则压扁了。预算的存在，就是强迫修复流程先做减法，再做加法。先删重复、再合并同义、再外置参考、最后才考虑新增正文。只要预算还在，自动修复就不会因为“多加一点也无妨”而失控。

预算最好和指标绑定。比如：重复段落数不能上升，冲突对不能增加，正文长度超过阈值后必须证明新增内容可回归，外部参考数量的增长必须伴随正文缩短。这样，增长就不再是单向奖励，而是和质量绑定的成本。

六、正向行为比“不要做什么”更有用

最容易失败的规则，往往都是纯否定式的：不要重复、不要猜测、不要扩写、不要乱下结论。它们短期看上去很明确，长期却会让 Agent 只记住“有很多禁区”，却不知道正确路线在哪里。更有效的做法，是把每条禁令翻成可执行的正向行为，例如“遇到不确定时先列出已知和未知”“有冲突时优先引用较新的主规则”“输出前先检查回归样本是否命中”。

正向行为还应该和场景配套。面对数据类任务，可以要求先确认输入字段、再确认缺失策略、再确认异常阈值；面对写作类任务，可以要求先确认结构、再确认证据、再确认语气；面对工具类任务，可以要求先确认权限、再确认失败返回、再确认回滚入口。正向行为越具体，Agent 越少靠猜。越少靠猜，规则就越少需要靠“再加一句”来兜底。

真正好的规则，不是看起来很狠，而是看起来很能做事。它告诉 Agent 下一步该去哪里，而不是只告诉它不要踩哪里。

七、参考文件必须一致，不然正文永远修不完

很多 Skill 变得混乱，不是正文写错了，而是正文和参考文件开始说不同的话。主文档说一套，外部 README 说另一套，示例文件又保留旧接口，最后自动修复工具只能在多个来源之间摇摆。结果不是把问题修好，而是把冲突藏到不同文件里。维护参考文件一致性，本质上是在减少“到处都能找到一个看似正确的说法”的机会。

做法上，正文应该明确引用哪份参考负责哪一类内容：主规则看正文，参数格式看 schema，边界策略看运行手册，历史事故看 badcase 库，回归清单看测试目录。只要这些边界不清，修复就会在不同文件之间来回搬家，表面上像治理，实际上只是换地方堆字。把职责写清楚之后，哪怕正文短一点，系统也更容易稳定。

参考一致性的另一个价值，是让删减变得安全。只要外部文件承担了细节，正文就可以把位置让给真正重要的原则。没有这个前提，所有删减都会被认为“会不会漏掉某个例外”，于是大家只好继续加字。长期看，外部参考越清晰，正文越能保持克制。

八、人工审批不是拖慢，而是最后一道语义闸门

自动修复最危险的地方，不在于它能写，而在于它会写得太顺。几秒钟就能塞进几段话的系统，很容易在没有人确认的情况下把临时判断变成正式规则。人工审批的作用，就是在这一步把“能写进去”变成“值得写进去”。它不是反自动化，而是给自动化一个边界。

审批不该只看语法和格式，还要看四件事：这条规则是不是重复、是不是和已有规则冲突、是不是会把适用范围扩大、是不是已经有回归样本可以验证。只要其中一项说不清，就先退回，不要急着上线。很多团队之所以会被文档膨胀反复折磨，就是因为他们把审批做成了签字动作，而不是判断动作。

如果人手有限，审批也可以分层：小修只看局部冲突，中修要看回归集，大修要看版本和回滚，涉及安全边界的修复则要增加第二人复核。分层的好处是，不让所有修复都享受同等重量的流程，同时也避免重要变更被“例行通过”带过去。

九、版本和回滚要先设计，再去改正文

一个没有版本意识的 Skill，迟早会陷入“改好了但不知道从哪一步开始改坏”的困境。版本管理的价值不是留档，而是让你知道哪个状态经过验证、哪个状态只是候选、哪个状态一旦出问题可以立刻退回。对自动修复来说，版本标签就是最便宜的安全绳。

回滚路径尤其不能省。正文被整理得再漂亮，也不能假设下一次修复一定成功。你要先想清楚：如果这次删掉了十段重复描述，但三天后发现某类边界场景又开始漏判，回滚的是哪一版，是整个文档，还是某个规则簇，还是某个外部参考。只要回滚路径不明，所谓“更整洁”就可能只是“更难恢复”。

好的版本策略通常很朴素：每次改动保留 diff，记录变更原因，关联 badcase 与回归结果，写清楚谁批准，必要时保留可一键恢复的上一版。这样做并不浪漫，但它让自动修复真正变成可治理的工程流程，而不是每天刷新一次的长文接力赛。

十、一个更稳的修复顺序，应该长什么样

如果把这套流程压缩成一个顺序，我会这样排：先收集 badcase，再判断类型；先查重复，再查冲突；先试外置参考，再决定是否改正文；先补回归样本，再发起审批；最后才写入版本并设置回滚点。这个顺序看上去慢一些，但它把最容易扩散的风险放到了最前面，把最容易写错的动作放到了最后面。

反过来看，很多失败修复都走了相反的路：先写正文、再找理由、再补例外、再补解释、再补解释的解释。那样的结果不是稳定，而是每次事故都往上叠一层新语言。你以为是在修系统，其实是在把维护难度往后挪。真正能长期工作的反馈回路，必须允许“这次先不改正文，只加回归样本”成为一个合格答案。

如果团队能接受这一点，Skill 文档就不会继续被自动修复拖成一篇越来越长的备忘录。它会慢慢回到应该有的位置：少量、清晰、可测、可删、可退。

十一、落地时最值得盯的不是长度，而是秩序

长度只是结果，秩序才是原因。你要看的不是今天比昨天多了多少行，而是今天是否比昨天更容易判断哪些规则是主干、哪些是边角、哪些已经过期、哪些必须保留。只要秩序在，短一点也能用；只要秩序乱了，再长也没用。

这也是为什么我不建议把 Skill 文档当成一次性 prompt 工程。一次性 prompt 写完就跑，出错就改字；规则库则需要盘点、分类、评估、审批、回归、版本化和回滚。前者追求立刻见效，后者追求长期可维护。只有后者，才能抵御自动修复带来的持续膨胀。

如果你现在已经遇到类似问题，最先做的不是再写一段“务必遵守”，而是给当前规则做一次账本化整理：删掉重复、标注冲突、把 badcase 拉进回归、给新增规则设预算、补上审批和回滚。只要这一步做对，Agent 往往会比你想象中更安静。