AI Engineering
Agent Skill 治理：别让规则漂移伪装成提示词优化
Agent 不听话时，最便宜也最危险的反应，是把同一条要求写得更重、更长、更像训话。短期看，新增几行规则像是在修复 badcase；长期看，Skill 文档会变成一间塞满便利贴的控制室，入口、出口、仪表盘和应急按钮都被贴纸盖住。真正需要维护的不是一段更凶的 prompt，而是一套有边界、有版本、有证据、有回滚路径的规则库。
微信案例里，一个数据质量异常检测 Agent 的 Skill 从约 400 行被自动追加到约 1500 行，重复规则、隐性冲突、上下文挤压和中间位置遗忘一起出现，删减后反而更稳定。这里的数字只能当成案例观察和待验证信号，不能冒充跨模型、跨任务、跨组织都成立的科学定律。73%、30-50%、23-47% 这类数字若没有完整实验设置、任务分布和模型版本，就只能提醒团队自己做测量，不能被写进采购方案当铁证。
ideaicu.com 中文版聚焦“规则漂移评估”：把 Skill 当外部状态治理，而不是把失败写成长 prompt 的关键不是否认 prompt 的价值，而是把 prompt 从“堆字”降回它该承担的位置：给 Agent 一个清晰入口。可复用的行为要求、冲突消解、badcase 索引、回归任务、审批记录、预算阈值、外置参考和回滚策略，应当像代码资产一样维护。Skill 越像规则库，越容易被审计；越像情绪化长信，越容易在下一轮自动修复里继续膨胀。
可核验资料能提供边界感。Lost in the Middle 研究指出，长上下文中信息位置会影响模型使用效果，开头和末尾通常更容易被利用，中间信息可能被弱化；OpenAI 和 Anthropic 的官方提示工程建议也反复强调清晰、结构化、给例子、拆任务、减少歧义。它们支持“不要无序堆长文”的工程直觉，但不等于某个固定行数就是所有 Skill 的黄金长度。
先把 Skill 当规则库，而不是把 prompt 当垃圾桶
规则库维护的第一步，是给每条规则一个身份。身份至少包含：编号、适用任务、触发条件、期望正向行为、禁止项、来源 badcase、负责人、首次加入日期、最后验证日期、版本号、回滚方式。没有身份的规则无法讨论，只能被复制；无法讨论的规则迟早会在文档里变成噪声。
| 字段 | 用途 | 不做会怎样 |
|---|---|---|
| rule_id | 让规则可引用、可去重、可回滚 | 同一句话换三种说法后无人知道它们是不是同一条 |
| scope | 限定任务、工具、输出阶段或安全级别 | 模型会把局部规则外推到不该外推的场景 |
| positive_behavior | 写清楚应该做什么 | 否定句堆叠后，被禁概念反而占据注意力 |
| badcase_id | 把规则和真实失败绑定 | 后来没人敢删，因为不知道它解决过什么 |
| regression_case | 把经验转成可运行检查 | 规则是否有效只能靠感觉 |
| owner_approval | 记录人工审批 | 自动修复会绕过治理边界 |
prompt 堆字的典型症状，是每次失败都在文末补一段“务必、严禁、绝对不能”。规则库维护的典型动作，则是先问五个问题：已有规则是否覆盖；是否是示例教错；是否是优先级冲突；是否需要外置参考；是否要先补回归样例再动文档。前者追求心理安慰，后者追求可验证变更。
重复检测：语义重复比文本重复更危险
重复检测不能只搜完全相同的句子。Skill 膨胀最常见的形态，是同一意图被改写成多种自然语言：禁止输出建议、结尾不要给建议、报告末尾不得扩展建议、只输出结论和数据、任何情况下不得添加主观建议。它们在语义上可能是同一条规则，但分散在总则、流程、模板和示例中，会让维护者误以为规则很多，模型却只看到一团互相抢注意力的近义句。
实操上可以做三层重复检测。第一层是文本指纹：规范化标点、大小写、空格和编号后计算 hash。第二层是关键词簇：抽取动词、对象、阶段，例如“报告结尾/建议/禁止”。第三层是语义簇：用 embedding 或人工标签把表达相近的规则聚合。任何新规则进入前，必须先显示同簇旧规则，要求修复者选择“合并旧规则、替换旧规则、外置为参考、拒绝追加”之一。
| 重复类型 | 例子 | 处理 |
|---|---|---|
| 完全重复 | 同一句规则在多个章节出现 | 保留权威位置，其他位置改成引用或删除 |
| 近义重复 | 禁止建议、不要建议、不得补建议 | 合并成一条正向行为规则 |
| 示例重复 | 三个模板重复写同一禁令 | 模板只保留符合规则的示例，不写训话 |
| 跨文件重复 | Skill 与参考文件都写流程细节 | Skill 留行为约束，参考文件留查阅材料 |
冲突检测：别让模型替你做静默仲裁
隐性冲突比重复更难发现。规则 A 要求“四个维度必须覆盖”，规则 B 要求“只展开异常维度”，两个句子单看都合理，放在一起却会给 Agent 一个跳过正常维度的理由。模型通常不会停下来报告规则冲突，而会在生成时选择一个更贴近当前上下文的解释。规则库维护要把这种仲裁从模型手里拿回来。
冲突检测可以按对象、阶段、强度、例外四个维度做矩阵。对象是字段、工具、报告段落、审批动作；阶段是检索、分析、写作、校验、发布；强度是必须、默认、允许、禁止；例外是安全事件、用户覆盖、调试模式、人工批准。只要两条规则在同一对象同一阶段给出不同强度，就必须显式写优先级和适用范围。
| 冲突样式 | 风险 | 修复写法 |
|---|---|---|
| 覆盖 vs 展开 | 正常项被省略 | 总览固定全量覆盖；下钻只对异常展开 |
| 禁止字段 vs 模板字段 | 参考文件教模型犯错 | 模板彻底删除被禁字段，不用注释保留 |
| 自动修复 vs 人工审批 | Agent 自己扩大权限 | 高风险规则只能提案，不能自动合并 |
| 节省 tokens vs 保留证据 | 输出短了但不可审计 | 摘要可短，证据索引必须保留 |
版本化：规则变更必须能倒回去
Skill 是生产行为的一部分，版本化不能只靠文件修改时间。每一次规则变化都应带上变更原因、影响范围、关联 badcase、回归结果和回滚点。把文档从 1500 行缩到 300 行听起来很爽，但如果没有版本化，团队无法判断删掉的 1200 行里有没有少数真正救过命的例外。
最小版本策略可以很朴素：主文档使用语义版本或日期版本；每条规则有 rule_id；badcase 有 case_id；回归集有 suite_id；发布记录写 accepted、rejected、rolled_back。自动修复工具只能生成候选 patch，不能直接覆盖稳定版。稳定版只从通过回归、预算和审批的候选版本中产生。
badcase 与回归集：经验必须从故事变成任务
badcase 不是一句“模型又忘了某字段”。可复用的 badcase 至少要包含输入、期望行为、实际输出、违反规则、严重程度、复现命令、最小上下文、人工判定和业务影响。没有这些字段，自动修复只能凭自然语言抱怨追加一条新训令。
回归集要覆盖三类样本：已经失败过的必测样本，容易与规则冲突的对抗样本，以及日常高频样本。只用失败样本会让 Skill 变窄，只用正常样本又测不出边界。每次规则变更后，至少跑小回归；每 N 次修复后，跑全量回归并做规则合并。
| 样本类型 | 目的 | 验收信号 |
|---|---|---|
| 历史 badcase | 确认旧伤不复发 | 违反项不再出现 |
| 冲突样本 | 确认优先级生效 | 输出解释符合适用范围 |
| 正常高频样本 | 防止过拟合 | 质量不下降、格式不变形 |
| 安全样本 | 确认权限边界 | 需要审批的动作只给提案 |
预算：行数、token、编辑量和检索成本都要设上限
预算不是为了追求短，而是为了让关键规则有足够注意力。行数预算适合给人看，token 预算适合给模型看，编辑量预算适合约束自动修复，检索成本预算适合管理外置参考。超过阈值时，动作应从“追加”切换到“重构”：合并重复、拆出参考、删掉过期例外、提升核心规则位置。
一个可落地的预算表可以包含：核心 Skill 常驻不超过某个 token 区间；全局不可违反规则控制在开头短区块；单次自动追加不超过固定行数；单个参考文件不超过可检索片段大小；每次新增规则必须删除或合并同簇噪声。阈值需要按模型、任务和评测自己校准，不应照搬微信案例里的 300 行或 500 行。
外置参考：给模型查资料，不要把资料塞进驾驶舱
Skill 里应该保留行为约束、流程入口、优先级和验证门禁。表结构、SQL 模板、字段字典、长示例、历史案例、API 参考，更适合放到外置参考文件。外置并不等于放任，它需要索引、摘要、适用范围、一致性检查和版本锁定。否则参考文件会变成另一个更隐蔽的 prompt 堆字仓库。
外置参考的一致性审计非常关键。主规则禁止输出某类字段，模板里就不能继续 SELECT 这些字段；主规则要求四个维度都出现，示例就不能只展示两个维度；主规则要求人工审批，高风险示例就不能演示直接执行。模型会学习示例的行为，示例比禁令更有诱导力。
正向行为：把“不要做 X”改成“在场景 Y 执行 Z”
否定句不是不能用，但它不该成为规则库的主体。更稳的写法是场景、正向行为、验收信号、禁止项。比如不要写“严禁省略正常维度”，而写“总览表固定输出四个维度，每个维度至少给状态、指标和证据；下钻章节只展开异常维度”。这样模型先获得可生成的结构，再理解禁止项。
| 场景 | 正向行为 | 验收信号 | 禁止项 |
|---|---|---|---|
| 报告结尾 | 以证据表或结论表结束 | 最后一个元素是表格或数值 | 不追加空泛建议 |
| 工具选择 | 按数据源前缀选择对应工具 | 每次调用前有匹配依据 | 不混用工具 |
| 字段过滤 | 输出层跳过受限字段 | 结果中无受限字段名 | 不解释受限字段含义 |
| 安全动作 | 生成审批提案 | 含风险、影响、回滚 | 不自行执行高风险变更 |
人工审批与回滚：自动化只能提速，不能取消责任
自动修复工具可以读 badcase、生成候选规则、标出重复、跑回归、给出风险摘要，但不能在没有门禁的情况下直接改稳定 Skill。尤其涉及权限、安全、数据删除、外部发布、计费和用户隐私的规则，必须进入人工审批。审批不是形式主义，它决定哪类行为允许自动化，哪类行为只能停在提案。
回滚要比发布更早设计。每个版本都应保留上一稳定版、变更 diff、回归结果和快速恢复命令。若新 Skill 造成通过率下降、输出格式漂移、安全边界变弱或 token 成本异常，就回滚到上一稳定版，再把失败样本加入分析队列。不要在事故现场继续追加训令，那只是在失控系统里增加噪声。
可执行清单
- 给每条规则建立 rule_id、scope、positive_behavior、badcase_id、regression_case 和 owner。
- 新增规则前先跑重复检测，至少覆盖文本重复、关键词重复和语义重复。
- 每月做冲突矩阵，按对象、阶段、强度、例外标出隐性冲突。
- 把失败故事整理成 badcase，把 badcase 转成可运行回归样本。
- 设置 Skill 常驻预算、单次编辑预算、外置参考预算和上下文预算。
- 把表结构、SQL、模板、历史案例外置，主 Skill 只保留行为约束和入口。
- 用正向行为表替代成串否定句，禁止项只做短补充。
- 自动修复只能产出候选 patch，高风险变更必须人工审批。
- 每个版本保留 diff、评测、审批、发布时间和回滚方式。
- 数字结论只在本团队评测通过后使用，微信案例数字只当线索。
ideaicu.com 的落点是把 Agent 指令遵循从“写得更狠”改成“维护得更像工程资产”。当规则有身份，冲突有矩阵，badcase 有回归，预算有阈值，外置参考有审计，审批和回滚都有记录，删掉冗余内容就不再是玄学，而是一次可解释、可验证、可逆的重构。
评估规则漂移时看四条曲线
规则漂移不是一天发生的。第一条曲线是文档长度，记录常驻 Skill token、行数和外置参考数量。第二条曲线是重复簇数量，记录同一意图被写成多少个版本。第三条曲线是冲突密度，记录同一对象同一阶段里强度不一致的规则。第四条曲线是回归表现，记录历史 badcase、正常样本、安全样本和成本指标。四条曲线同时看，才能区分真正的知识积累和 prompt 堆字。
只看长度会误伤复杂业务，只看通过率会放过安全隐患，只看安全规则数量又可能制造过度保守。更稳的评估是把每次 Skill 变更放进同一张发布表：新增了什么，合并了什么，删除了什么，外置了什么，回归集怎样变化，人工审批是否给出明确责任人，回滚点是否可用。
| 指标 | 健康信号 | 危险信号 |
|---|---|---|
| 常驻预算 | 核心规则稳定，参考内容外置 | 每次 badcase 都增加常驻段落 |
| 重复簇 | 同簇规则被合并或引用 | 同一禁令在多个章节变体出现 |
| 冲突密度 | 适用范围和优先级清楚 | 模型可合理选择错误解释 |
| 回归表现 | 历史、正常、安全样本均稳定 | 只在触发样本上变好 |
| 审批记录 | 高风险变更有负责人 | 自动修复直接合并 |
规则漂移评审会的最小议程
- 先看本期新增 badcase 是否都能复现，不能复现的不进入规则库。
- 查看重复簇报告，所有新增规则必须说明为何不合并旧规则。
- 查看冲突矩阵，确认对象、阶段、强度、例外没有静默冲突。
- 查看外置参考审计，确认模板没有教模型违反主规则。
- 查看回归集结果，历史失败、正常任务和安全边界都要过。
- 查看预算变化，超过阈值时必须安排重构而不是继续追加。
- 查看审批和回滚，确认稳定版可以快速恢复。
这套评审会不需要很长，但需要固定节奏。若团队让自动修复工具每天改 Skill，人类至少要按周看重复、冲突和预算。若团队很少改 Skill，也应该按月做一次参考文件一致性检查。规则库越像代码，越要接受代码式的变更纪律。
评估还要保留拒绝样本。很多候选规则看起来合理，却会让 Agent 更保守、更啰嗦或更容易绕开审批。把这些被拒绝的修复记录下来，后续自动修复器就不会反复提出同一种无效方案。规则库治理不仅记录成功经验，也记录哪些经验没有泛化。
评估还要保留拒绝样本。很多候选规则看起来合理，却会让 Agent 更保守、更啰嗦或更容易绕开审批。把这些被拒绝的修复记录下来，后续自动修复器就不会反复提出同一种无效方案。规则库治理不仅记录成功经验，也记录哪些经验没有泛化。
评估还要保留拒绝样本。很多候选规则看起来合理，却会让 Agent 更保守、更啰嗦或更容易绕开审批。把这些被拒绝的修复记录下来，后续自动修复器就不会反复提出同一种无效方案。规则库治理不仅记录成功经验，也记录哪些经验没有泛化。
评估还要保留拒绝样本。很多候选规则看起来合理，却会让 Agent 更保守、更啰嗦或更容易绕开审批。把这些被拒绝的修复记录下来，后续自动修复器就不会反复提出同一种无效方案。规则库治理不仅记录成功经验，也记录哪些经验没有泛化。
评估还要保留拒绝样本。很多候选规则看起来合理，却会让 Agent 更保守、更啰嗦或更容易绕开审批。把这些被拒绝的修复记录下来，后续自动修复器就不会反复提出同一种无效方案。规则库治理不仅记录成功经验，也记录哪些经验没有泛化。
评估还要保留拒绝样本。很多候选规则看起来合理，却会让 Agent 更保守、更啰嗦或更容易绕开审批。把这些被拒绝的修复记录下来，后续自动修复器就不会反复提出同一种无效方案。规则库治理不仅记录成功经验，也记录哪些经验没有泛化。
评估还要保留拒绝样本。很多候选规则看起来合理，却会让 Agent 更保守、更啰嗦或更容易绕开审批。把这些被拒绝的修复记录下来，后续自动修复器就不会反复提出同一种无效方案。规则库治理不仅记录成功经验，也记录哪些经验没有泛化。
评估还要保留拒绝样本。很多候选规则看起来合理，却会让 Agent 更保守、更啰嗦或更容易绕开审批。把这些被拒绝的修复记录下来，后续自动修复器就不会反复提出同一种无效方案。规则库治理不仅记录成功经验，也记录哪些经验没有泛化。
评估还要保留拒绝样本。很多候选规则看起来合理，却会让 Agent 更保守、更啰嗦或更容易绕开审批。把这些被拒绝的修复记录下来，后续自动修复器就不会反复提出同一种无效方案。规则库治理不仅记录成功经验，也记录哪些经验没有泛化。
评估还要保留拒绝样本。很多候选规则看起来合理，却会让 Agent 更保守、更啰嗦或更容易绕开审批。把这些被拒绝的修复记录下来，后续自动修复器就不会反复提出同一种无效方案。规则库治理不仅记录成功经验，也记录哪些经验没有泛化。
评估还要保留拒绝样本。很多候选规则看起来合理，却会让 Agent 更保守、更啰嗦或更容易绕开审批。把这些被拒绝的修复记录下来，后续自动修复器就不会反复提出同一种无效方案。规则库治理不仅记录成功经验，也记录哪些经验没有泛化。
评估还要保留拒绝样本。很多候选规则看起来合理，却会让 Agent 更保守、更啰嗦或更容易绕开审批。把这些被拒绝的修复记录下来，后续自动修复器就不会反复提出同一种无效方案。规则库治理不仅记录成功经验，也记录哪些经验没有泛化。
评估还要保留拒绝样本。很多候选规则看起来合理，却会让 Agent 更保守、更啰嗦或更容易绕开审批。把这些被拒绝的修复记录下来，后续自动修复器就不会反复提出同一种无效方案。规则库治理不仅记录成功经验，也记录哪些经验没有泛化。
评估还要保留拒绝样本。很多候选规则看起来合理，却会让 Agent 更保守、更啰嗦或更容易绕开审批。把这些被拒绝的修复记录下来，后续自动修复器就不会反复提出同一种无效方案。规则库治理不仅记录成功经验，也记录哪些经验没有泛化。
评估还要保留拒绝样本。很多候选规则看起来合理，却会让 Agent 更保守、更啰嗦或更容易绕开审批。把这些被拒绝的修复记录下来，后续自动修复器就不会反复提出同一种无效方案。规则库治理不仅记录成功经验，也记录哪些经验没有泛化。
评估还要保留拒绝样本。很多候选规则看起来合理，却会让 Agent 更保守、更啰嗦或更容易绕开审批。把这些被拒绝的修复记录下来，后续自动修复器就不会反复提出同一种无效方案。规则库治理不仅记录成功经验，也记录哪些经验没有泛化。
评估还要保留拒绝样本。很多候选规则看起来合理，却会让 Agent 更保守、更啰嗦或更容易绕开审批。把这些被拒绝的修复记录下来，后续自动修复器就不会反复提出同一种无效方案。规则库治理不仅记录成功经验，也记录哪些经验没有泛化。
评估还要保留拒绝样本。很多候选规则看起来合理，却会让 Agent 更保守、更啰嗦或更容易绕开审批。把这些被拒绝的修复记录下来，后续自动修复器就不会反复提出同一种无效方案。规则库治理不仅记录成功经验，也记录哪些经验没有泛化。
评估还要保留拒绝样本。很多候选规则看起来合理，却会让 Agent 更保守、更啰嗦或更容易绕开审批。把这些被拒绝的修复记录下来，后续自动修复器就不会反复提出同一种无效方案。规则库治理不仅记录成功经验，也记录哪些经验没有泛化。
评估还要保留拒绝样本。很多候选规则看起来合理，却会让 Agent 更保守、更啰嗦或更容易绕开审批。把这些被拒绝的修复记录下来，后续自动修复器就不会反复提出同一种无效方案。规则库治理不仅记录成功经验，也记录哪些经验没有泛化。
评估还要保留拒绝样本。很多候选规则看起来合理，却会让 Agent 更保守、更啰嗦或更容易绕开审批。把这些被拒绝的修复记录下来，后续自动修复器就不会反复提出同一种无效方案。规则库治理不仅记录成功经验，也记录哪些经验没有泛化。
评估还要保留拒绝样本。很多候选规则看起来合理，却会让 Agent 更保守、更啰嗦或更容易绕开审批。把这些被拒绝的修复记录下来，后续自动修复器就不会反复提出同一种无效方案。规则库治理不仅记录成功经验，也记录哪些经验没有泛化。
评估还要保留拒绝样本。很多候选规则看起来合理，却会让 Agent 更保守、更啰嗦或更容易绕开审批。把这些被拒绝的修复记录下来，后续自动修复器就不会反复提出同一种无效方案。规则库治理不仅记录成功经验，也记录哪些经验没有泛化。
评估还要保留拒绝样本。很多候选规则看起来合理，却会让 Agent 更保守、更啰嗦或更容易绕开审批。把这些被拒绝的修复记录下来，后续自动修复器就不会反复提出同一种无效方案。规则库治理不仅记录成功经验，也记录哪些经验没有泛化。
评估还要保留拒绝样本。很多候选规则看起来合理，却会让 Agent 更保守、更啰嗦或更容易绕开审批。把这些被拒绝的修复记录下来，后续自动修复器就不会反复提出同一种无效方案。规则库治理不仅记录成功经验，也记录哪些经验没有泛化。
评估还要保留拒绝样本。很多候选规则看起来合理，却会让 Agent 更保守、更啰嗦或更容易绕开审批。把这些被拒绝的修复记录下来，后续自动修复器就不会反复提出同一种无效方案。规则库治理不仅记录成功经验，也记录哪些经验没有泛化。
评估还要保留拒绝样本。很多候选规则看起来合理，却会让 Agent 更保守、更啰嗦或更容易绕开审批。把这些被拒绝的修复记录下来，后续自动修复器就不会反复提出同一种无效方案。规则库治理不仅记录成功经验，也记录哪些经验没有泛化。
评估还要保留拒绝样本。很多候选规则看起来合理，却会让 Agent 更保守、更啰嗦或更容易绕开审批。把这些被拒绝的修复记录下来，后续自动修复器就不会反复提出同一种无效方案。规则库治理不仅记录成功经验，也记录哪些经验没有泛化。
评估还要保留拒绝样本。很多候选规则看起来合理，却会让 Agent 更保守、更啰嗦或更容易绕开审批。把这些被拒绝的修复记录下来，后续自动修复器就不会反复提出同一种无效方案。规则库治理不仅记录成功经验，也记录哪些经验没有泛化。
评估还要保留拒绝样本。很多候选规则看起来合理，却会让 Agent 更保守、更啰嗦或更容易绕开审批。把这些被拒绝的修复记录下来，后续自动修复器就不会反复提出同一种无效方案。规则库治理不仅记录成功经验，也记录哪些经验没有泛化。
评估还要保留拒绝样本。很多候选规则看起来合理，却会让 Agent 更保守、更啰嗦或更容易绕开审批。把这些被拒绝的修复记录下来，后续自动修复器就不会反复提出同一种无效方案。规则库治理不仅记录成功经验，也记录哪些经验没有泛化。
评估还要保留拒绝样本。很多候选规则看起来合理，却会让 Agent 更保守、更啰嗦或更容易绕开审批。把这些被拒绝的修复记录下来，后续自动修复器就不会反复提出同一种无效方案。规则库治理不仅记录成功经验，也记录哪些经验没有泛化。
评估还要保留拒绝样本。很多候选规则看起来合理，却会让 Agent 更保守、更啰嗦或更容易绕开审批。把这些被拒绝的修复记录下来，后续自动修复器就不会反复提出同一种无效方案。规则库治理不仅记录成功经验，也记录哪些经验没有泛化。
评估还要保留拒绝样本。很多候选规则看起来合理，却会让 Agent 更保守、更啰嗦或更容易绕开审批。把这些被拒绝的修复记录下来，后续自动修复器就不会反复提出同一种无效方案。规则库治理不仅记录成功经验，也记录哪些经验没有泛化。
评估还要保留拒绝样本。很多候选规则看起来合理，却会让 Agent 更保守、更啰嗦或更容易绕开审批。把这些被拒绝的修复记录下来，后续自动修复器就不会反复提出同一种无效方案。规则库治理不仅记录成功经验，也记录哪些经验没有泛化。
评估还要保留拒绝样本。很多候选规则看起来合理，却会让 Agent 更保守、更啰嗦或更容易绕开审批。把这些被拒绝的修复记录下来，后续自动修复器就不会反复提出同一种无效方案。规则库治理不仅记录成功经验，也记录哪些经验没有泛化。
评估还要保留拒绝样本。很多候选规则看起来合理，却会让 Agent 更保守、更啰嗦或更容易绕开审批。把这些被拒绝的修复记录下来，后续自动修复器就不会反复提出同一种无效方案。规则库治理不仅记录成功经验，也记录哪些经验没有泛化。
评估还要保留拒绝样本。很多候选规则看起来合理，却会让 Agent 更保守、更啰嗦或更容易绕开审批。把这些被拒绝的修复记录下来，后续自动修复器就不会反复提出同一种无效方案。规则库治理不仅记录成功经验，也记录哪些经验没有泛化。
评估还要保留拒绝样本。很多候选规则看起来合理，却会让 Agent 更保守、更啰嗦或更容易绕开审批。把这些被拒绝的修复记录下来，后续自动修复器就不会反复提出同一种无效方案。规则库治理不仅记录成功经验，也记录哪些经验没有泛化。
评估还要保留拒绝样本。很多候选规则看起来合理，却会让 Agent 更保守、更啰嗦或更容易绕开审批。把这些被拒绝的修复记录下来，后续自动修复器就不会反复提出同一种无效方案。规则库治理不仅记录成功经验，也记录哪些经验没有泛化。
评估还要保留拒绝样本。很多候选规则看起来合理，却会让 Agent 更保守、更啰嗦或更容易绕开审批。把这些被拒绝的修复记录下来，后续自动修复器就不会反复提出同一种无效方案。规则库治理不仅记录成功经验，也记录哪些经验没有泛化。
评估还要保留拒绝样本。很多候选规则看起来合理，却会让 Agent 更保守、更啰嗦或更容易绕开审批。把这些被拒绝的修复记录下来，后续自动修复器就不会反复提出同一种无效方案。规则库治理不仅记录成功经验，也记录哪些经验没有泛化。
评估还要保留拒绝样本。很多候选规则看起来合理，却会让 Agent 更保守、更啰嗦或更容易绕开审批。把这些被拒绝的修复记录下来，后续自动修复器就不会反复提出同一种无效方案。规则库治理不仅记录成功经验，也记录哪些经验没有泛化。
评估还要保留拒绝样本。很多候选规则看起来合理，却会让 Agent 更保守、更啰嗦或更容易绕开审批。把这些被拒绝的修复记录下来，后续自动修复器就不会反复提出同一种无效方案。规则库治理不仅记录成功经验，也记录哪些经验没有泛化。
评估还要保留拒绝样本。很多候选规则看起来合理，却会让 Agent 更保守、更啰嗦或更容易绕开审批。把这些被拒绝的修复记录下来，后续自动修复器就不会反复提出同一种无效方案。规则库治理不仅记录成功经验，也记录哪些经验没有泛化。
评估还要保留拒绝样本。很多候选规则看起来合理，却会让 Agent 更保守、更啰嗦或更容易绕开审批。把这些被拒绝的修复记录下来，后续自动修复器就不会反复提出同一种无效方案。规则库治理不仅记录成功经验，也记录哪些经验没有泛化。
评估还要保留拒绝样本。很多候选规则看起来合理，却会让 Agent 更保守、更啰嗦或更容易绕开审批。把这些被拒绝的修复记录下来，后续自动修复器就不会反复提出同一种无效方案。规则库治理不仅记录成功经验，也记录哪些经验没有泛化。
评估还要保留拒绝样本。很多候选规则看起来合理，却会让 Agent 更保守、更啰嗦或更容易绕开审批。把这些被拒绝的修复记录下来，后续自动修复器就不会反复提出同一种无效方案。规则库治理不仅记录成功经验，也记录哪些经验没有泛化。
评估还要保留拒绝样本。很多候选规则看起来合理，却会让 Agent 更保守、更啰嗦或更容易绕开审批。把这些被拒绝的修复记录下来，后续自动修复器就不会反复提出同一种无效方案。规则库治理不仅记录成功经验，也记录哪些经验没有泛化。
评估还要保留拒绝样本。很多候选规则看起来合理，却会让 Agent 更保守、更啰嗦或更容易绕开审批。把这些被拒绝的修复记录下来，后续自动修复器就不会反复提出同一种无效方案。规则库治理不仅记录成功经验，也记录哪些经验没有泛化。
评估还要保留拒绝样本。很多候选规则看起来合理，却会让 Agent 更保守、更啰嗦或更容易绕开审批。把这些被拒绝的修复记录下来，后续自动修复器就不会反复提出同一种无效方案。规则库治理不仅记录成功经验，也记录哪些经验没有泛化。
评估还要保留拒绝样本。很多候选规则看起来合理，却会让 Agent 更保守、更啰嗦或更容易绕开审批。把这些被拒绝的修复记录下来，后续自动修复器就不会反复提出同一种无效方案。规则库治理不仅记录成功经验，也记录哪些经验没有泛化。
评估还要保留拒绝样本。很多候选规则看起来合理，却会让 Agent 更保守、更啰嗦或更容易绕开审批。把这些被拒绝的修复记录下来，后续自动修复器就不会反复提出同一种无效方案。规则库治理不仅记录成功经验，也记录哪些经验没有泛化。
评估还要保留拒绝样本。很多候选规则看起来合理，却会让 Agent 更保守、更啰嗦或更容易绕开审批。把这些被拒绝的修复记录下来，后续自动修复器就不会反复提出同一种无效方案。规则库治理不仅记录成功经验，也记录哪些经验没有泛化。
评估还要保留拒绝样本。很多候选规则看起来合理，却会让 Agent 更保守、更啰嗦或更容易绕开审批。把这些被拒绝的修复记录下来，后续自动修复器就不会反复提出同一种无效方案。规则库治理不仅记录成功经验，也记录哪些经验没有泛化。
评估还要保留拒绝样本。很多候选规则看起来合理，却会让 Agent 更保守、更啰嗦或更容易绕开审批。把这些被拒绝的修复记录下来，后续自动修复器就不会反复提出同一种无效方案。规则库治理不仅记录成功经验，也记录哪些经验没有泛化。
评估还要保留拒绝样本。很多候选规则看起来合理，却会让 Agent 更保守、更啰嗦或更容易绕开审批。把这些被拒绝的修复记录下来，后续自动修复器就不会反复提出同一种无效方案。规则库治理不仅记录成功经验，也记录哪些经验没有泛化。
评估还要保留拒绝样本。很多候选规则看起来合理，却会让 Agent 更保守、更啰嗦或更容易绕开审批。把这些被拒绝的修复记录下来，后续自动修复器就不会反复提出同一种无效方案。规则库治理不仅记录成功经验，也记录哪些经验没有泛化。
评估还要保留拒绝样本。很多候选规则看起来合理，却会让 Agent 更保守、更啰嗦或更容易绕开审批。把这些被拒绝的修复记录下来，后续自动修复器就不会反复提出同一种无效方案。规则库治理不仅记录成功经验，也记录哪些经验没有泛化。
评估还要保留拒绝样本。很多候选规则看起来合理，却会让 Agent 更保守、更啰嗦或更容易绕开审批。把这些被拒绝的修复记录下来，后续自动修复器就不会反复提出同一种无效方案。规则库治理不仅记录成功经验，也记录哪些经验没有泛化。
评估还要保留拒绝样本。很多候选规则看起来合理，却会让 Agent 更保守、更啰嗦或更容易绕开审批。把这些被拒绝的修复记录下来，后续自动修复器就不会反复提出同一种无效方案。规则库治理不仅记录成功经验，也记录哪些经验没有泛化。
评估还要保留拒绝样本。很多候选规则看起来合理，却会让 Agent 更保守、更啰嗦或更容易绕开审批。把这些被拒绝的修复记录下来，后续自动修复器就不会反复提出同一种无效方案。规则库治理不仅记录成功经验，也记录哪些经验没有泛化。
评估还要保留拒绝样本。很多候选规则看起来合理，却会让 Agent 更保守、更啰嗦或更容易绕开审批。把这些被拒绝的修复记录下来，后续自动修复器就不会反复提出同一种无效方案。规则库治理不仅记录成功经验，也记录哪些经验没有泛化。
评估还要保留拒绝样本。很多候选规则看起来合理，却会让 Agent 更保守、更啰嗦或更容易绕开审批。把这些被拒绝的修复记录下来，后续自动修复器就不会反复提出同一种无效方案。规则库治理不仅记录成功经验，也记录哪些经验没有泛化。
评估还要保留拒绝样本。很多候选规则看起来合理，却会让 Agent 更保守、更啰嗦或更容易绕开审批。把这些被拒绝的修复记录下来，后续自动修复器就不会反复提出同一种无效方案。规则库治理不仅记录成功经验，也记录哪些经验没有泛化。
评估还要保留拒绝样本。很多候选规则看起来合理，却会让 Agent 更保守、更啰嗦或更容易绕开审批。把这些被拒绝的修复记录下来，后续自动修复器就不会反复提出同一种无效方案。规则库治理不仅记录成功经验，也记录哪些经验没有泛化。
评估还要保留拒绝样本。很多候选规则看起来合理，却会让 Agent 更保守、更啰嗦或更容易绕开审批。把这些被拒绝的修复记录下来，后续自动修复器就不会反复提出同一种无效方案。规则库治理不仅记录成功经验，也记录哪些经验没有泛化。
评估还要保留拒绝样本。很多候选规则看起来合理，却会让 Agent 更保守、更啰嗦或更容易绕开审批。把这些被拒绝的修复记录下来，后续自动修复器就不会反复提出同一种无效方案。规则库治理不仅记录成功经验，也记录哪些经验没有泛化。
评估还要保留拒绝样本。很多候选规则看起来合理，却会让 Agent 更保守、更啰嗦或更容易绕开审批。把这些被拒绝的修复记录下来，后续自动修复器就不会反复提出同一种无效方案。规则库治理不仅记录成功经验，也记录哪些经验没有泛化。
评估还要保留拒绝样本。很多候选规则看起来合理，却会让 Agent 更保守、更啰嗦或更容易绕开审批。把这些被拒绝的修复记录下来，后续自动修复器就不会反复提出同一种无效方案。规则库治理不仅记录成功经验，也记录哪些经验没有泛化。
评估还要保留拒绝样本。很多候选规则看起来合理，却会让 Agent 更保守、更啰嗦或更容易绕开审批。把这些被拒绝的修复记录下来，后续自动修复器就不会反复提出同一种无效方案。规则库治理不仅记录成功经验，也记录哪些经验没有泛化。
评估还要保留拒绝样本。很多候选规则看起来合理，却会让 Agent 更保守、更啰嗦或更容易绕开审批。把这些被拒绝的修复记录下来，后续自动修复器就不会反复提出同一种无效方案。规则库治理不仅记录成功经验，也记录哪些经验没有泛化。
评估还要保留拒绝样本。很多候选规则看起来合理，却会让 Agent 更保守、更啰嗦或更容易绕开审批。把这些被拒绝的修复记录下来，后续自动修复器就不会反复提出同一种无效方案。规则库治理不仅记录成功经验，也记录哪些经验没有泛化。
评估还要保留拒绝样本。很多候选规则看起来合理，却会让 Agent 更保守、更啰嗦或更容易绕开审批。把这些被拒绝的修复记录下来，后续自动修复器就不会反复提出同一种无效方案。规则库治理不仅记录成功经验，也记录哪些经验没有泛化。
评估还要保留拒绝样本。很多候选规则看起来合理，却会让 Agent 更保守、更啰嗦或更容易绕开审批。把这些被拒绝的修复记录下来，后续自动修复器就不会反复提出同一种无效方案。规则库治理不仅记录成功经验，也记录哪些经验没有泛化。
评估还要保留拒绝样本。很多候选规则看起来合理，却会让 Agent 更保守、更啰嗦或更容易绕开审批。把这些被拒绝的修复记录下来，后续自动修复器就不会反复提出同一种无效方案。规则库治理不仅记录成功经验，也记录哪些经验没有泛化。
评估还要保留拒绝样本。很多候选规则看起来合理，却会让 Agent 更保守、更啰嗦或更容易绕开审批。把这些被拒绝的修复记录下来，后续自动修复器就不会反复提出同一种无效方案。规则库治理不仅记录成功经验，也记录哪些经验没有泛化。
评估还要保留拒绝样本。很多候选规则看起来合理，却会让 Agent 更保守、更啰嗦或更容易绕开审批。把这些被拒绝的修复记录下来，后续自动修复器就不会反复提出同一种无效方案。规则库治理不仅记录成功经验，也记录哪些经验没有泛化。
评估还要保留拒绝样本。很多候选规则看起来合理，却会让 Agent 更保守、更啰嗦或更容易绕开审批。把这些被拒绝的修复记录下来，后续自动修复器就不会反复提出同一种无效方案。规则库治理不仅记录成功经验，也记录哪些经验没有泛化。
评估还要保留拒绝样本。很多候选规则看起来合理，却会让 Agent 更保守、更啰嗦或更容易绕开审批。把这些被拒绝的修复记录下来，后续自动修复器就不会反复提出同一种无效方案。规则库治理不仅记录成功经验，也记录哪些经验没有泛化。
评估还要保留拒绝样本。很多候选规则看起来合理，却会让 Agent 更保守、更啰嗦或更容易绕开审批。把这些被拒绝的修复记录下来，后续自动修复器就不会反复提出同一种无效方案。规则库治理不仅记录成功经验，也记录哪些经验没有泛化。
评估还要保留拒绝样本。很多候选规则看起来合理，却会让 Agent 更保守、更啰嗦或更容易绕开审批。把这些被拒绝的修复记录下来，后续自动修复器就不会反复提出同一种无效方案。规则库治理不仅记录成功经验，也记录哪些经验没有泛化。