技能库刚上线时，维护很简单：上传文件，更新版本，让 Agent 读到新内容。几个月后，库里出现了多个名字相近的技能，脚本与正文不同步，实验组还在使用旧规则，依赖却已经被热更新。此时一次失败，很难说清用户究竟执行了哪一套能力。
技能库的治理单位，最终需要从单份文件走向一次请求实际使用的完整能力快照。 冲突识别、合并、退役和灰度发布都围绕这个对象发生。只给每份 SKILL.md 加一个版本号，无法保证整套运行条件一致。
本文结合 SkillNet 的关系建模、SkillOps 的库维护研究、SkillFlow 的演化记录与 Agent Skills 格式规范，讨论一套可逐步落地的治理方式。库级决策、快照与实验流程是本文的工程设计，不将它们表述为某篇论文已经验证的完整生产架构。
1. 相似不等于重复
两份技能都叫“导出表格”：一份保留公式，一份生成静态值；一份只在本地处理，一份会上传到外部服务。若只比较标题和向量相似度，它们很容易被合并。对用户而言，这些差异却直接决定任务能否被正确、安全地完成。
我会先区分五种关系。这里的分类是工程分析用语，不声称所有研究使用相同定义。
| 关系 | 判断依据 | 对维护的含义 |
|---|---|---|
| 内容重复 | 包内完整内容与资源相同 | 可以考虑统一存储，仍需保留来源与权限 |
| 语义重叠 | 部分目标或步骤相似 | 需要识别各自独有的适用条件 |
| 功能替代 | 同一目标有多种可行路径 | 按环境、成本和权限选择 |
| 条件冲突 | 同一条件下提出不能同时满足的要求 | 需要仲裁或收窄触发范围 |
| 接口不兼容 | 上游产物不满足下游输入要求 | 修接口或明确适配与信息损失 |
关键词碰撞只能提供候选线索。两份技能都提到“医院”，可能分别处理健康咨询与预约操作；两份技能措辞完全不同，也可能对同一个文件提出相反修改。冲突判断需要绑定任务条件、作用对象和版本。
SkillNet 将技能、来源与关系组织到更明确的知识结构中，并讨论任务局部的知识组织。1 对治理系统而言，重要启发是让差异与依赖可检查。关系图并不会自动获得真实性：人工声明、模型推断和执行验证的边，应该记录不同的证据来源。
2. 合并是一项需要验收的变更
合并技能往往被当作文本编辑，但它实际改变了能力边界。两份技能分别通过测试，不代表合并后的版本仍然通过；更长的主文可能让触发条件变得模糊，也可能把两个互斥流程同时暴露给执行器。
一个合理的合并候选，应先回答三个问题：共同主路径是什么，差异条件是否能明确表达，合并后还能否稳定选择正确分支。如果差异依赖复杂权限或完全不同的执行环境，保留两个技能与清晰关系，可能比强行合成一个更好。
图 1：本文建议的库维护流程。减少技能数量不是验收标准。
SkillOps 将库健康与维护操作显式化，讨论合并、修复、退役、验证器和适配器等对象。2 但读它的成绩时必须看清任务：论文部分评测使用高层动作序列匹配，并不等于真实交互环境的端到端成功率。规则化注入的库缺陷，也不能覆盖生产中所有语义冲突。
原研究底稿还核对过公开示例中的接口签名合并：签名由部分前置条件与产物字段构成，并不等于完整操作语义。3 因此，将这个启发式直接用于自动删库有明显风险。两个输入输出相同的实现，仍可能具有不同的成本、许可、工具依赖与失败边界。
我的建议是将相似度和接口签名用于发现候选，把真正的删除或合并交给带有回归验收的变更流程。误合并和误退役应单独计量；它们可能比暂时保留一份冗余材料更难恢复。
低使用率不能单独决定退役
某个技能使用少，可能因为需求少，也可能因为描述不清、路由被其他技能挤占，或者它只在罕见但重要的失败场景中使用。使用频率带有选择偏差，不能直接等同于能力价值。
退役前应检查独有任务覆盖、被依赖情况、替代路径和历史失败。可先停止新增引用并观察，再从新快照中移除；旧快照仍应能够重建。若涉及安全撤回，则另走紧急路径，不能为了实验稳定继续保留已确认风险。
3. 发布对象至少有三层
一份源技能可能包含正文、脚本和资源；为了适配不同模型或执行框架，还可能生成不同运行产物；真正进入一次请求的，则是技能集合、索引、选择策略与相关配置。把这些都压成一个“最新版”指针，很容易出现局部更新。
| 层次 | 应记录什么 | 典型故障 |
|---|---|---|
| 源技能包 | 全部文件、依赖、来源、内容指纹 | 正文变了，脚本仍旧 |
| 目标产物 | 面向模型、工具与环境的适配结果 | 用错环境的编译或配置 |
| 发布快照 | 技能集合、索引、策略及其绑定关系 | 索引召回了快照外版本 |
Agent Skills 规范为包结构与元数据提供共同入口，但格式合法不等于行为兼容，也没有替产品完成灰度、实验与回滚。4 SkillFlow 以版本化变化观察跨任务的技能演化，帮助我们把更新当作可追踪事件；它同样不能被直接称为完整的生产分发协议。5
在一个最小实现里，可以先不引入复杂编译层，但应保证源包不可变，以及请求开始时绑定一份一致快照。后续按需加载正文、脚本与依赖时，继续从该快照解析。这样一次任务不会在执行到一半时突然获得另一套规则。
快照不要求把全部清单塞进模型上下文。它是宿主的可信运行状态，用于加载、审计与复现。模型只需要当前决策所需的信息，不能让它自行修改快照标识来绕过版本约束。
4. 实验基线需要是固定对象
考虑一个简单的教学例子：基线是 A@1 + B@1，实验只想验证 A@2。如果运行时采用“实验与当前基线取并集，然后选择高版本”，当 B@2 被其他流程推全后，实验处理可能悄悄变成 A@2 + B@2。
此时最终差值包含多个变化，不能继续解释为 A@2 的作用。更稳妥的做法，是保存实验开始时的完整基线快照和实验快照。新全局版本出现后，旧实验按既定协议继续，或明确关闭并开启一个新实验；不能静默改变处理。
图 2：固定快照的实验路径。图中不包含静默追随全局最新版的更新。
若线上运行同时产生经验更新，还需要隔离学习状态。实验组生成的新技能不能流入基线组，否则对照条件也在学习实验改动。可以让两组使用冻结库，把学习放到独立训练流；也可以为两组隔离可写状态，但必须把这种学习协议纳入实验定义。
基线前进后的候选更新，则适合三方比较：原始基线、候选差分、当前基线。共同修改同一条件或资源时需要重新验证，不能单纯按版本号较大者获胜。文本没有冲突，也不代表行为没有冲突。
5. 回滚恢复的是版本，不是世界
把发布指针退回旧快照，可以影响后续请求。但已经发出的消息、修改的远端文件和发生的费用，不会随着技能版本回退而消失。因此，发布回滚与任务副作用恢复需要分别设计。
对有副作用的动作，应记录是否已经执行、外部资源标识、幂等依据与可用补偿。工具超时但状态未知时，直接用旧版本重试，可能造成重复操作。可靠的恢复先查询事实，再决定重试、补偿或转交。
灰度也应覆盖多维信号：任务质量、关键约束、工具异常、重试次数、时延与成本。总体平均改善并不足以掩盖特定用户群或任务类型的严重退化。各项门槛由真实产品风险决定，不预设一个适用于所有技能的“涨一点就推全”。
为了让灰度结果可解释，每次请求至少要关联以下信息。表中的字段是本文建议，不是某个现成平台的接口规范。
| 记录 | 用途 |
|---|---|
| 发布快照、技能包与索引指纹 | 解释实际使用了什么 |
| 实验组与分配时间 | 解释用户接受了哪个处理 |
| 模型、工具和环境版本 | 识别非技能变化 |
| 实际披露与执行事件 | 定位链路上的失效环节 |
| 验收、成本与副作用状态 | 支持推广、回退与恢复 |
若服务无法提供完全稳定的模型版本，也应记录可取得的返回信息与时间窗口，并在报告中保留不确定性。无法冻结所有条件不意味着实验不能做，但会限制能够归因的范围。
6. 把治理做成可解释的决策
库治理最终可以围绕一类变更单组织：修改对象、问题证据、预期影响、验证任务、发布快照和回退方式。新增、合并、拆分、替代与退役都沿同一条可追溯流程处理，差异在于所需证据和回归范围。
例如合并两个表格导出技能，变更单应列出双方独有任务和权限差异，给出合并后触发条件，并证明原有功能仍能被正确采用。若合并仅仅减少一份文件，却增加路由歧义，就没有完成治理目标。
适配器也需要按能力产物管理。上游提供金额、下游要求带币种的金额时，新增字段映射不能凭空恢复币种语义。类型能对上只是开始，实际转换是否保留信息、缺失时如何拒绝，需要单独验证。
从零建设时，我会按这个顺序推进：先保证完整技能包和不可变快照；再记录请求实际采用的版本；接着做配对回归、灰度和回滚；之后才开放自动合并、退役与动态学习。每一步都应让一次失败更容易解释，而不是增加一个看起来先进但难以审计的后台任务。
自动化适合承担发现候选、整理证据、运行回归和生成变更报告。真正值得自动推广的，是那些已有清晰边界、可靠验收和恢复能力的操作。对语义不确定的合并，保持待审状态往往更合理。
一个健康的技能库，不一定最小，也不一定更新最快。它应该能说明每项能力为什么存在、每次变更凭什么接受，以及出现问题后怎样找到并恢复原来的状态。
参考资料
- SkillNet，arXiv:2603.04448v2：技能组织与关系；作者仓库。
- SkillOps，arXiv:2605.13716v1：Pu、Song、Zhao 的技能库维护研究。注意附录 D、G 的任务与故障注入协议。
- SkillOps 官方实现：研究底稿于 2026-09-27 静态核对
skill_graph.py、maintenance.py；公开示例不等于论文所有实验资产。 - Agent Skills Specification：技能包格式与元数据。
- SkillFlow，arXiv:2604.17308v1：跨任务技能发现与演化的评测协议。
2026-10-07 合并修订。本文的版本、实验与发布流程使用通用教学案例，没有公开内部业务日志，也没有将设计建议写成已上线系统的效果报告。
