技能就是代码，代码需要检查点

技能就是代码，代码需要检查点

NVIDIA 本周开源了一个叫 SkillSpector 的工具。它的职责很窄，而且早该有人做了：在智能体加载技能之前，扫描其中的安全问题。该项目内置了对 64 种漏洞模式的检测，这个数字值得停下来想想，因为它意味着有人认真坐下来，把技能可能出问题的方式逐一列了出来。

与此同时，Cloudflare 发布了一个安全审计技能，能对代码库执行多阶段审计并输出机器可读的发现结果；GitHub 则详解了一个具备上下文感知能力的密钥检测分类器，它把真实发现结果的加权采纳率提升了 11.5%，同时把扫描中位耗时降低了 86%。三个不同的团队，三个不同的角度，结论一致：智能体获取指令的这一层已经成为基础设施，而基础设施就要接受审计。

技能到底是什么

“技能”这个词让整件事听起来比实际温和。技能不是一个设置项。它是一组指令，而且往往还包含脚本、模板和工具定义，智能体会读取它们，并以自己被授予的权限照着执行。

最后半句话就是整个安全模型的一句话概括。技能不需要漏洞利用，因为它不是“闯进来”的。它是被请进来、拿到钥匙、被请求帮忙的。如果它的指令是恶意的，或者只是写得随意，智能体都会把它们当作你自己的意图去执行，因为在它看来，它们就是。

这正是一个个包管理器在几十年前遇到的问题，而解决方式也一样：假定供应链是敌对的，并在其中设置检查点。智能体生态在这条路上还处于早期，所以像 SkillSpector 这样的项目，其重要性远超它的 star 数所暗示的程度。

为什么 64 种模式是最有意思的数字

一张包含 64 种漏洞模式的清单就是一套分类法，而分类法正是一个领域走向成熟的标志。在没有它之前，每次事故都是意外；有了它之后，事故就变成已知类别中的一个实例，这意味着它们可以被测试、被追踪，最终被设计规避。

其中一些类别在普通软件里早已熟悉：不安全的 shell 命令、未经验证的输入、被写进本不该保存密钥的文件里的凭据。另一些则专属于这个新层。比如悄悄扩大智能体权限范围的指令；把不可信内容拉进来并当作命令对待的提示词；对工具功能描述不实，导致智能体因为错误的原因去调用它；以及把多个技能串成一条没人预料到的调用链。

最后一类正是难点所在。一个技能有多危险，恰恰与它的触达范围成正比，而现代智能体能触达的东西很多：文件系统、网络、其他智能体，以及其他技能注册的工具。一个坏技能的影响半径不是这个技能本身，而是智能体能碰到的一切，而这取决于先加载了哪些其他技能，是个不断变化的目标。

上下文被投毒的问题

智能体安全里最让人不安的一点是，数据与指令之间的边界不受任何机制强制约束。模型读的是文本，它天生无法分辨哪些句子是供它参考的事实，哪些是必须服从的命令。

所以，一个会抓取网页、读取 issue 跟踪器、或者总结邮件的技能，都在把智能体暴露给可能含有指令的文本。如果模型照做了，从任何传统意义上讲都不存在漏洞利用。有的只是一个系统，按某个它本不该信任的东西所说的去做了。

这就是为什么扫描必须在加载时进行，而不是在出事之后。一旦技能已经在拥有广泛权限的智能体里运行起来，那个关键问题早就被糟糕地回答了。检查点必须前置，而且必须自动，因为对注册表里每一个技能都做人工审查，规模上根本行不通，将来也不行。

审计正在变成一个产品

Cloudflare 的这次发布指向第二个趋势。它的审计技能输出的是机器可读的发现结果，而不是一份需要人去读的清单。这个措辞是有实质意义的。需要人读的发现结果，人只会扫一眼；而流水线能消费的发现结果，可以被自动转成工单、被阻断的合并，或被拒绝的部署，不需要任何人记得去看。

GitHub 的密钥检测工作符合同一个模式。密钥泄露的规模与代码产出量成正比，而代码产出量已大幅上升。应对方式不是“多招几个审查员”，而是一个具备上下文感知的分类器，用来削减噪音，让人真正看到的告警更可能是真的。在安全工具里，精确率决定了到第三个月还有没有人愿意看告警。

这两者都是在不同层面上做的同一件事：与其要求人更警惕，不如让自动检查足够好，使人的注意力只花在真正重要之处。这是唯一能扛住海量规模的策略。

底层的治理问题

这里还有一层政策层面的变化，其速度比大多数团队意识到的更快。版本控制系统开始携带来源溯源元数据。包注册表开始加入认证声明。标准组织正在研究如何给合成内容打标、如何识别一个智能体。趋势指向这样一个世界：制品的来源与完整性必须可证明，而不是靠假设。

技能在这个世界里处于尴尬位置，因为同一个技能可能因上下文不同而既有用又危险。一个能修改文件的技能对编码智能体必不可少，但对一个同时会读取不可信邮件的智能体却是灾难。信任决策不是技能本身的属性，而是技能加上环境、再加上它能触达的其他技能共同决定的属性。

这也意味着扫描器最终要做的将不止是模式匹配。这个工具真正困难的版本，会检查一组被提议组合使用的技能是否授予了没人要求过的能力，并在上线前而不是上线后发出警告。

团队现在该做什么，而不是反应过度

恐慌不是正确的反应，把它当作别人的问题同样不对。

实际做法并不光鲜。把第三方技能当作不可信依赖来对待，因为它们确实就是。固定版本，并在它们变化时审查差异。在影响半径受限的环境里运行智能体，这样一个坏技能不会仅仅因为图方便就够到网络或生产数据库。记录加载了哪些技能、它们做了什么，因为任何事故之后第一个难回答的问题就是：当时到底允许了什么在运行。

这个行业以前走过这条路。包生态曾经不安全，后来被弄得攻击起来很麻烦，而这种“麻烦”正是关键。智能体技能正在走向同样的平衡点，而本周发布的这些项目，是第一批认真尝试搭建检查点的努力。在事故之前做到，代价比事故之后更低，而要提早做到，唯一需要的就是甘于做枯燥之事的意愿。