Skill 不只是插件包，它会注入提示词、执行脚本并继承权限，安全治理必须前置。
原文链接：AI 小老六
导语
很多团队在搭 AI Agent 平台时，会把 Skill 理解成插件的轻量版：装上一个 Skill，模型就多一项能力。
这个理解很顺手，但也很容易把风险看轻。Skill从来不只是一个功能包，它往往同时带着说明文本、可执行脚本、依赖声明，以及对当前运行环境权限的继承关系。它既像一个 npm 包，也像一次curl | bash，还会把陌生文本塞进模型上下文里。
问题就出在这里：Skill Registry不是普通的素材市场，而是一个新的供应链入口。你一旦把它设计成“拿来就装、装完就能继承现有权限”的分发系统，安全账就不可能等到后面再补。
为什么它比传统包管理更难管
传统包管理已经够难了。你要防 typosquatting、防安装脚本、防依赖混淆、防仓库接管、防维护者账号失守。
到了 Skill 生态，麻烦会再多两层：
- 第一层是 Prompt Injection。Skill 被激活后，不只是代码开始跑，Skill 自带的自然语言描述也会进入模型上下文，进而影响后续判断。
- 第二层是 权限继承。当前会话已经拿到文件、网络或命令执行权限时，新装的 Skill 往往会顺手继承这套能力，用户却未必再经历一次细粒度审批。
- 第三层是 多供应链扇出。一个 Skill 既可能调用自己的脚本，也可能再去拉
npm、pip、cargo或其他远端资源，一次安装就打开多条链路。
所以，一个 Skill 的危险性不只取决于“它装了什么”，还取决于“它让模型相信了什么”以及“它借用了多少现成权力”。
一张表看主要攻击面
| 层级 | 典型风险 | 真正麻烦的地方 |
|---|---|---|
| Loader | 加载时执行脚本、默认信任描述文本 | 用户以为只是安装，实际上执行已经开始 |
| Registry | 名称抢注、版本漂移、删除后复活 | 锁住名字不等于锁住内容 |
| Runtime | 描述字段误导模型选择恶意 Skill | 决策者不再是人，而是语言模型 |
| 依赖链 | Skill 再去调用其他包管理器 | 一次安装同时打开多条供应链 |
最容易被低估的，往往是Loader这一层。很多平台会把所有已安装 Skill 的描述，在每轮对话前都注入模型上下文，方便自动选择。体验上看很丝滑，安全上看却等于把发行者写的自然语言，长期放在系统指令附近。
只要清洗不严，Skill 即使没有被明确调用，也可能先一步影响模型行为。这个风险不需要脚本执行成功才会发生，它在“被看见”的那一刻就已经开始。
图：攻击面不只在执行脚本，很多风险在加载与选择阶段就已经发生。
“锁版本”为什么经常只是心理安慰
不少 Skill 生态目前仍是 Git 驱动。所谓版本，经常只是“当时默认分支指向哪里”。如果客户端只记下name@version，却没有记录实际 commit 和文件哈希，那么锁住的只是名字，不是字节内容。
这会带来几个直接后果：
- 发布者可以重写同一版本背后的内容。
- 仓库被转移或接管后，旧安装记录仍可能继续指向新主人。
- 自动更新时，新增权限或新增 secrets 需求可能被静默带入。
包管理器花了十几年，才逐步补齐 lockfile、校验和、不可变发布和透明日志这些能力。Skill 生态如果跳过这一课，迟早会重演同样的事故，只是这次事故里还额外带着 Prompt Injection。
决策入口才是 Skill 市场最不一样的地方
传统软件仓库面对的是人类搜索和安装，Skill 市场面对的却往往是 Agent 自己检索、自己筛选、自己决定装哪个。
这意味着新的攻击方式出现了：不是先骗过工程师，而是先骗过检索模型和 选择模型。如果平台把 README、描述字段和辅助文档一起向量化，发布者只要往这些文本里灌入足够多“相关但不诚实”的内容，就可能把无关 Skill 抬进候选列表；再进一步，用“官方”“已验证”“更适合当前任务”之类措辞去提高模型选中它的概率。
整个过程里，真正被操纵的不是安装命令，而是前面的 决策入口。
图：从检索、选择到执行，风险会沿着 Agent 决策链一路放大。
如果你只审查最后的执行脚本，却不审查前面的检索和选择链路，相当于只盯着炸弹落地，却不看它是怎么被送进来的。
真正难的是很多问题都不长得像漏洞
这类系统最棘手的地方在于，出了事之后，你未必能指出“哪一行代码写错了”。更多时候，问题来自默认设计本身：
- slug 会在 90 天后释放，因为产品默认就是这么设计的。
- 更新路径不会重新确认权限，因为团队觉得那样太打扰用户。
- 描述字段直接进提示词，因为这样实现成本最低。
- install fan-out 默认允许多种包管理器，因为生态接入更方便。
每一项单看都像合理权衡，合在一起就形成了非常大的攻击面。
所以 Skill 安全从来不只是扫描恶意脚本。它本质上是 设计治理问题，而不是上线之后再补的一轮安全加固。
平台团队优先补哪几块
对于正在做 Skill 平台或内部技能仓库的团队，下面几件事优先级很高：
- 锁定内容而不是只锁名称，客户端必须记录实际 commit 和哈希。
- 自动更新默认不能静默扩权，新增工具权限或新增 secrets 需求必须重新确认。
- Skill 描述文本要做长度限制、字符清洗，并尽量作为数据展示而不是指令拼接。
- 任意 Git URL 不能等价于可信注册表来源，至少要做显式风险分层。
- 检索排序和模型选择链路要纳入安全审计，不能只审 manifest。
把这五件事往前放，本质上是在承认一件事：Skill不是内容分发，而是复合型执行制品的供应链管理。
图：越早把内容锁定、权限确认与选择审计做进去，后续补洞成本越低。
结语
今天看 Skill 市场，很像在重演十多年前包管理器的早期阶段，只不过节奏更快，风险也更集中。以前一个恶意包最多是在你的机器上执行代码；现在一个恶意 Skill 既能执行代码，又能改写模型后续行为路径，还可能借用已经批准的工具能力继续扩散。
如果平台设计者还把它当作普通插件系统，后面会付出很高的补课成本。更成熟的做法，是从第一天就承认：Skill Registry管理的不是“内容”，而是带提示词、脚本、依赖和权限继承关系的复合制品。
这笔安全账，越早算越便宜。
推荐阅读
LLM 编程提速之后，为什么你反而更难想清楚问题
AI 编程争论变味了：为什么反 AI 情绪开始走向怀旧化
AI 没有 ROI？企业真正暴露的，是 Token 成本失控
Claude Opus 4.8 深度解读：让 AI 模型学会承认不确定性，才是真正的生产力升级
AI 已经进流程了，但人不能从责任链上消失：招聘、授信与公共服务里的治理底线
