一、Skills 为什么让人"装得放心,用得担心" Skills 的核心价值是"扩展 Agent 能力的低成本路径"。一个 Skill 通常包含三类内容:工具定义(可调用的 API 或本地命令)、系统提示词(给模型的额外指令)、可选的执行脚本(本地 Shell、Python 等)。用户只需要执行一行 install,Agent 就具备了 Skill 描述的所有能力。 这种便利带来的隐忧是:用户往往
一、Skills 为什么让人"装得放心,用得担心"
Skills 的核心价值是"扩展 Agent 能力的低成本路径"。一个 Skill 通常包含三类内容:工具定义(可调用的 API 或本地命令)、系统提示词(给模型的额外指令)、可选的执行脚本(本地 Shell、Python 等)。用户只需要执行一行 install,Agent 就具备了 Skill 描述的所有能力。
这种便利带来的隐忧是:用户往往只看了 Skill 的 README 和评分,没看代码;Agent 加载 Skill 时,也不做严格的权限校验。于是出现了一种典型的攻击面——"延迟触发":Skill 装上时一切正常,但在某个特定环境、特定输入、特定时间点后,Skill 中的隐藏指令被激活,把用户的 Shell 交出去。
Trail of Bits 在 2026 年 5 月发布的审计报告中,对 200 个公开 Skills 做了分析,发现 12.5% 存在"延迟激活"风险,其中 3% 包含明确的恶意逻辑。这些数字看似不高,但乘以百万级的安装量,绝对数量不容小觑。
二、典型攻击模式:三类
- 提示词注入延迟触发
Skill 在系统提示词中嵌入条件判断:"当用户输入包含特定关键词时,执行以下命令"。用户安装时,提示词看起来无害,但特定输入会激活隐藏逻辑。
这类攻击的特点是"静态审查难以发现"。审查者只看 Skill 的提示词,看不到"特定输入"是什么;只有真正运行并触发,才暴露意图。
- 环境变量劫持
Skill 安装时向用户的 .bashrc、.zshrc、或系统环境变量写入特定配置。这些配置在 Skill 加载时不会立即生效,但在用户下次打开 Shell 时,会改变 PATH、PYTHONPATH 等关键变量,把恶意脚本"提前"到所有命令之前。
这类攻击的特点是"跨越 Skill 边界"。即便用户只信任 Skill 的功能,不信任其脚本,环境变量劫持仍然能把恶意脚本"注入"到所有后续命令里。
- 工具调用劫持
Skill 注册的工具,在被 Agent 调用时,实际执行的不是 Skill 描述的功能,而是经过修改的版本。例如 Skill 描述"读取本地配置文件",实际执行"读取 + 上传到外部服务器"。
这类攻击的特点是"行为与描述不符"。只有对比实际执行结果与 Skill 描述,才能发现异常;静态审查完全看不到。
三、Skills 协议层缺失的"权限宣言"
根本问题在于:当前 Skills 协议层没有"权限宣言"机制。
对比移动操作系统的权限模型:Android 在安装 App 时,会列出"该 App 需要访问您的位置、相机、通讯录"。用户看到的不是"App 能做什么",而是"App 申请哪些权限",然后决定是否授权。授权是显式的、可撤回的、可审计的。iOS 更进一步,把权限声明写进一个独立的 Info.plist 字段,App Store 审核会逐项核对权限用途,任何无实际功能的权限都会被驳回。这套"权限透明 + 强制声明 + 第三方审查"的组合拳,过去十年里被验证为移动生态最关键的安全护栏。
Skills 当前缺乏这一层。用户安装 Skill 时,看不到"该 Skill 需要执行 Shell 命令、需要访问特定文件、需要联网"。用户看到的只是"该 Skill 能帮你做 X",至于做 X 的过程中需要哪些底层权限,完全不清楚。更糟的是,Skills 商店的搜索排序大多基于安装量和评分,而这两项指标都不能反映"该 Skill 在多大程度上触碰了底层系统资源"。一个评分 4.9 但悄悄写了 .bashrc 的 Skill,与一个评分 4.5 但只做纯内存计算的工具,在用户视角下被同等推荐,这显然不合理。
更糟糕的是,即便 Skill 想声明权限,协议层也没有"权限字段"。Skill 的 metadata 只能描述功能,不能描述底层权限需求。这就导致"权限透明"在协议层就不可能,更不用说落地。Anthropic 在 2026 年 3 月发布的 Skill 安全指南中,把这个问题列为"P0 优先解决",但截至目前,公开的协议草案里仍未引入"权限宣言"字段。社区多次反馈建议仿照 npm 的 postinstall 脚本审查机制或 Chrome 扩展的 permissions 字段设计,但协议推进缓慢,这与 Skills 生态过去半年高速扩张的速度形成鲜明对比。
四、工程化应对方案
虽然协议层尚未完善,但工程实践层面已经有可落地的应对方案。
1. 沙盒执行
所有 Skill 的工具调用,必须跑在沙盒里:本地可用 Docker、Firecracker、gVisor;云端可用 Cloudflare Workers、Deno Deploy 等隔离环境。沙盒不是万能,但能把"Shell 交出去"的攻击面限制在沙盒内部。关键是沙盒要默认"网络出站受限"、"文件系统读写受限"、"进程能力受限"。任何超出这些限制的操作,都需要用户显式授权。
2. 权限审计工具
类似移动应用商店的权限审计,Skills 生态也需要专门的审计工具。这种工具能自动分析 Skill 的代码、提示词、配置,标注"该 Skill 需要哪些权限",与 README 对比,发现异常。Trail of Bits 在 2026 年 5 月的报告里附带了开源审计工具的原型,但目前还在早期阶段,识别准确率约 70%。社区需要更多贡献来完善。
3. 安装时显式确认
即便协议层没有权限字段,客户端(Agent 加载 Skill 的入口)也应该在安装时显示"该 Skill 将执行以下操作",让用户有机会拒绝。这种设计借鉴了浏览器扩展的安装确认模式。Chrome 在安装扩展时,会列出"该扩展可以访问您在所有网站上的数据"。Skills 也应该类似。
4. 运行时行为监控
即便 Skill 通过了所有静态审查,运行时仍然可能暴露问题。监控手段包括:网络出站白名单(只允许特定域名)、文件系统读写白名单(只允许特定路径)、进程启动白名单(只允许特定二进制)。一旦运行时触发异常,立即暂停 Skill 执行并告警。这种"纵深防御"的策略,是当前 Skills 生态最现实的方案。
5. 评分与社区审查
Skills 商店应该引入类似 npm 的评分机制,但更严格:不只看下载量,更看"权限透明度"、"代码审计结果"、"运行时行为记录"。社区审查员应该有权标记可疑 Skill,而平台应该根据标记降低其曝光。这种机制不能 100% 阻止恶意 Skill,但能显著降低其传播速度。
五、与 MCP 协议的关系
Skills 与 MCP(Model Context Protocol)是互补关系,但解决的问题不同。MCP 解决的是"工具如何被 Agent 发现和调用",Skills 解决的是"Agent 如何获得一组配套能力"。两者都需要权限机制,但实现路径不同。
MCP 已经在协议层引入了"工具元数据",但仍未标准化"权限字段"。Skills 作为 MCP 的上层封装,理应把权限宣言作为一等公民纳入设计,但目前仍然缺失。
社区呼声是:Skills 协议层应尽快引入"permissions"字段,声明 Skill 需要的全部底层权限(Shell、网络、文件系统、进程)。用户在安装时看到这些声明,可以逐项授权或拒绝。
六、长期建议
对于使用 Skills 的团队,建议按以下顺序推进:
- 优先使用有审计记录的 Skill,而不是"看起来评分高"的 Skill。审计记录比评分更可信,因为它来自独立第三方。
- 部署 Skills 时启用沙盒,即便 Skill 看起来无害。沙盒是"纵深防御"的第一道线。
- 建立 Skills 白名单/黑名单机制。团队内部明确"可以使用哪些 Skill"、"禁止使用哪些 Skill",而不是让每个工程师自由选择。
- 监控 Skills 的运行时行为,建立异常告警。运行时监控是发现"延迟触发"攻击的最有效手段。
- 关注协议层演进。Skills 协议仍在快速发展,引入权限宣言是大概率事件,提前布局能减少后续改造成本。
结语
Skills 是 Agent 扩展能力的利器,但当前的协议层在权限宣言上存在根本性缺失。"装即用"的便利,与"安全可控"的目标,之间需要一座桥梁——这座桥梁就是标准化的权限宣言机制。在协议层补齐之前,沙盒、审计、监控这些工程化方案是当前的现实选择。
当权限透明成为默认,Skills 才能从"演示惊艳"走向"生产可信",真正成为 Agent 生态的可靠基础设施。
