一个共享 skill 库最大的成本不是存储，是每多一个重叠 skill，agent 选错的概率就上升一点。
当 agent 从「一个人玩」走到「全组织用」，每个团队都在往一个共享 library 里塞 skill（可复用的能力模块：一段封装好的 prompt + 工具 + 流程）。半年后你会得到一个典型的失败态：300 个 skill，没人知道哪个能用、哪个是僵尸；3 个功能重叠的「发邮件」让 agent 不知道选哪个；某个没人审过的 skill 偷偷能读生产库。这不是「文档太多」，是一个平台治理问题叠加一个AI 特有问题——Day 4 讲过「工具太多 → agent 选择退化」，组织级 skill 库把这个退化放大成系统性成本。Skill 库本质是一个内部的能力包注册中心（像 npm + 服务目录），但它比代码库多两个麻烦：里面的东西可执行、能触达数据（是攻击面），而且消费者是 agent 不是人（选择由 description 驱动，不是由人读文档）。本期四件工程：准入契约、去重、质量与安全门、度量驱动淘汰。核心心法：治理的北极星不是「库里有多少 skill」，是「agent 在任一任务上面对的候选集有多小而准」。
把 skill 当一个有契约的内部产品，而不是一段随手分享的脚本。进库要过 intake review，核心是一份标准化 manifest：清晰的 description——注意它是写给 agent 看、用来做选择的，不是给人读的文档（回到 Day 4：参数描述 > 名字，描述质量直接决定 agent 选不选对它）；明确的 owner（无主即孤儿）；输入 / 输出 schema；安全分级；以及一个关联的 eval。整个库有单一事实源(SOT)的目录：每个 skill 一条记录，带状态（experimental / active / deprecated）。这是 Day 35 prompt registry、Day 33 provenance 的思想上移到「能力」这一层。
# skill manifest：进库的契约（进 git，可 review / diff / 回滚）
id: send-invoice-email
description: "给客户发带 PDF 发票附件的邮件。用于财务催收场景。" # 写给 agent 选择
owner: finance-platform
inputs: { to: email, invoice_id: str }
outputs: { message_id: str }
risk: high # 触达外发 + 客户数据
permissions: [email.send, invoice.read] # 最小权限，见 Day 31
eval_set: invoice-email-golden-30
status: active # experimental / active / deprecated这是 skill 库最反直觉、也最 AI 特有的成本。Day 4 讲过「工具过多 → 选择退化」：3 个都叫「发邮件」的 skill，agent 不知道用哪个，可能选了不带附件的那个把任务搞砸。所以治理的核心动作不是「鼓励多贡献」，是主动控制重叠：新 skill 进库时用 embedding 算它和现有 skill 的语义相似度，超阈值就告警「疑似重复，请合并或说明差异」；定期扫描全库的能力重叠，合并冗余。更关键的是暴露给 agent 的不是全库——而是按当前任务上下文检索出的一个小候选集（skill 的 RAG / 分层 / 命名空间）。衡量库健康的指标是「平均候选集大小」，不是「skill 数量」。
共享 skill 库的风险被严重低估：它是个能力供应链，一个 skill 被攻陷 / 写错 / 权限过宽，所有引用它的 agent 都被波及（呼应 Day 24 注入、Day 31 lethal trifecta）。三道门。其一，质量门：进库 / 升级必须过 eval（在金标任务上证明它真能干活）+ 版本化（改动不能悄悄影响所有调用者，见 Day 35）。其二，安全门：manifest 声明所需权限并强制最小权限（Day 31），扫描它触达哪些敏感数据、外发面、注入面；高危 skill（能转账 / 删数据 / 外发客户信息）打 risk: high。其三，权限与可见性：高危 skill 默认不对全员可见，被 agent 调用前需额外审批（接 Day 34 HITL）。再加 provenance：谁发布、哪版，出事能定位 + 召回（Day 33）。
def promotion_gate(skill): # experimental → active 的晋级门
assert run_eval(skill) >= skill.baseline # 质量：金标任务不退步
assert declared(skill.permissions) # 安全：权限必须显式声明
assert minimal(skill.permissions) # 最小权限，拒绝「万能 skill」
if skill.risk == "high":
skill.visibility = "restricted" # 高危默认限可见 + 调用需审批
record_provenance(skill.author, skill.version) # 出事可召回没有淘汰，库只增不减，僵尸越堆越多，sprawl 反噬选择质量。度量驱动淘汰：每个 skill 记调用量、成功率、最近使用时间；长期零调用 / 成功率持续低 → 自动标 deprecated → 归档。但废弃要优雅：给 deprecation 周期 + 迁移指引，别硬删（可能还有 agent 在用，硬删=线上故障）。另一面是可发现性——好 skill 没被发现，团队就重复造轮子，又喂回 §2 的 sprawl。所以要有命名规范、标签、语义检索、以及「这个任务该用哪个 skill」的推荐。最后建一个健康度仪表盘：活跃 / 僵尸比、重复率、平均候选集大小、高危 skill 数——让库的健康可被一眼看见、可被治理。
def lifecycle_sweep(skill): # 定期跑，度量驱动淘汰
if skill.calls_90d == 0 or skill.success_rate < 0.6:
skill.status = "deprecated" # 标记，不硬删
notify(skill.owner, "migrate_within: 30d") # 给迁移周期
# 可发现性：别让团队因找不到而重复造
suggest = search_skills(task_ctx) # 语义检索 + 「该用哪个」推荐
dashboard = { "active/zombie": "180/120", "dup_rate": 0.18, "avg_candidates": 6 }把四点串成一个落地清单：哪怕你只是个带几个 agent 的小团队，这套也能防止半年后变成「300 个没人敢动的 skill」。
做完这套，你评估任何「我们建了个 agent skill 平台」时会本能地先问：新 skill 怎么准入、重叠怎么防、高危 skill 谁能调、僵尸怎么淘汰——而不是被「我们有 300 个 skill」这种伪指标唬住。skill 库的价值不在大，在于 agent 每次都能从一个小而准的候选集里选对那一个。
send_email(format=...)），而不是三个并列项，这样 agent 选「发邮件」这一个、再填参数，候选集不膨胀。如果差异只是实现细节、agent 根本分不清（两个都叫「发邮件」描述雷同）——那是冗余，留一个。原则：用户可感知的能力差异 → 参数；实现差异 → 合并。永远别让 agent 在「语义重叠的并列项」之间抽卡。experimental 区：贡献门槛极低（有 manifest 就能进），但默认不进 agent 的候选集、不对全员可见、不保证维护——让创新自由发生。只有当一个 experimental skill 攒够使用量 / 过了质量+安全门，才晋级 active 进入主候选集。这样底层创新不被卡，而「能被 agent 默认调用」这个特权是挣来的。甜点不是某个严格度数值，是把「贡献」和「晋升为默认能力」解耦：前者宽，后者严。Backstage 这类目录、npm 的 experimental tag 都是这个思路。critical: true 豁免自动淘汰（年度合规 skill 显式保留）；（2）淘汰是提议而非自动执行——lifecycle_sweep 只标记 + 通知 owner，由人确认（同 Day 34：让回归提议、人决策）；（3）区分「零调用」和「低调用」——真正零调用 90 天大概率是僵尸，一年一次的 skill 至少有调用记录、不会触发。核心是：度量驱动的是「引起注意」，不是「自动删除」。删除这种不可逆动作永远留人确认（Day 31 可逆性）。