概要
10 月 22 日，Agentic AI Foundation 在 AGNTCon 上宣布接收四个新项目，Anthropic 把 Agent Skills 捐了出来，它现在是 Linux Foundation 下的中立标准。同一天公布的还有一组数字：70 多个 Agent 平台支持、约 100 万个 skill 已发布、接近 2.8 亿次安装。
但这套生态缺两样东西：版本化发布和安装安全指引，两者都还停在提案阶段。2.8 亿次安装发生在一个没有版本号的格式上。
这篇讲三件事：一个 skill 到底能对你的机器做什么、装之前该查哪几项、skill 和 MCP 和沙箱这三层的信任边界怎么划。文末给一份可以直接用的审计清单。
一、四件事同时发生，但只有一件跟你的日常有关
10 月 22 日，圣何塞的 AGNTCon 加 MCPCon 现场，Agentic AI Foundation 宣布接收四个项目。这个基金会去年 12 月成立时只有 3 个项目，现在到了 10 个。后文简称 AAIF。
四个新项目分别是：
| 项目 | 贡献方 | 解决的问题 |
|---|---|---|
| Agent Skills | Anthropic | Agent 怎么获得新能力 |
| Open Responses | OpenAI | 应用怎么跨厂商调模型 |
| OpenEnv | Hugging Face | Agent 怎么训练和评测 |
| OpenSandbox | Alibaba | Agent 在哪安全地跑 |
AAIF 的 CTO 兼联合创始人 Manik Surtani 的说法是，四个公司把项目交给中立治理，是为了让这个领域有个共同的地方建标准，不被某一家公司定义。
四个项目里，另外三个离日常开发还有距离。只有 Agent Skills 是今天就在用的东西。
按基金会公布的数据：超过 70 个 Agent 平台已经支持这个格式，约 100 万个 skill 发布在 skills.sh 这个 registry 上，累计安装接近 2.8 亿次。registry 从零到 100 万，用了七个月。
配套的 GitHub 星数也能说明关注度的分布：Agent Skills 26,424，OpenSandbox 16,063，OpenEnv 2,745，Open Responses 1,135。
二、2.8 亿次安装，装在一个没有版本号的格式上
这是整件事里最值得警惕的一句，原文是这么说的：一个还没有版本化发布的格式，已经有 2.8 亿次安装，这是个很大的暴露面。
翻译成工程语言：你现在装一个 skill，装到的是那个仓库主分支当下的某个快照。 没有 semver，没有 release，没有 checksum。
对比一下你熟悉的场景。装 npm 包，有 package.json 锁版本，有 lockfile 锁哈希，有 npm audit。装 Docker 镜像，有 digest，可以按 sha256 固定。装 skill，什么都没有。
基金会自己在路线图里列出了三项待办：版本化发布、正式提案流程、给 skill 编写者和安装者的安全指引。三项都还在提案阶段。
也就是说，标准刚刚中立化，但配套的工程规范还没跟上。
三、一个 skill 到底能对你的机器做什么
很多人以为 skill 就是一段高级提示词，这是最大的误解。
按现在的实现，一个 skill 是一个目录，最小形态只有 SKILL.md，但可以带其他东西：
bash
my-skill/
├── SKILL.md # 必须，frontmatter 加正文工作流
├── scripts/ # 可选，可以带可执行脚本
├── references/ # 可选，参考资料
└── assets/ # 可选，模板、图片等资源关键在于中间那个 scripts 目录。skill 可以附带脚本，而脚本是被 Agent 调用的。
这句话的含义是：装一个 skill，等于在你这台机器上装了一份可能被执行的代码，外加一份能影响 Agent 行为的指令。前者是传统供应链问题，后者是新的、提示词层面的问题。
SKILL.md 的 frontmatter 里，常见的字段有 name、description、version 这些描述性的，部分客户端还支持 allowed-tools 这类声明式权限字段。也就是说，一个 skill 可以声明它需要用什么工具。
再叠加一层：description 那一行决定了 Agent 什么时候会调用这个 skill。写得越宽泛，被触发的场景越多。
于是风险结构就很清楚了，一共四类：
第一，脚本执行。 skill 带的脚本在 Agent 调用时运行，权限跟 Agent 本身一样。你的 Agent 能读文件、能跑命令，它带的脚本也能。
第二，指令注入。 SKILL.md 正文里可以写任何指令，包括让 Agent 去处理某些文件、往某个地址发请求。这类东西不会被杀毒软件拦，因为它是自然语言。
第三，触发范围失控。 description 写成「帮助处理所有文件相关任务」，这个 skill 会在你每次碰文件时被唤醒，等于常驻。
第四，版本漂移。 你上周装的和我这周装的可能不是同一份代码，而且双方都不知道。
四、装之前该查什么
这份清单可以直接拿去用，六项，按优先级排：
bash
一、仓库本身
[ ] 是不是官方或知名维护者的仓库，还是某个个人小号
[ ] 最近一次提交多久之前，长期不更新的要谨慎
[ ] issue 和 PR 有没有在回复，还是堆着没人管
[ ] 历史提交里有没有可疑的突然大批量改动
二、目录结构
[ ] 有没有 scripts 目录，有的话逐个看内容
[ ] 有没有引用外部地址，比如远程下载、远程配置
[ ] 有没有 assets 里夹带可执行文件
三、SKILL.md
[ ] frontmatter 的 description 写得窄不窄，太宽的要警惕
[ ] 有没有声明 allowed-tools，声明了哪些
[ ] 正文里有没有让它主动访问网络或读特定路径的指令
四、安装方式
[ ] 优先用固定 commit 的方式装，不要拉最新
[ ] 记录安装时的 commit hash 和日期
[ ] 装在项目目录而不是全局目录，缩小影响范围
五、运行环境
[ ] 能不能在容器或沙箱里跑
[ ] Agent 的文件访问范围有没有限制
[ ] 有没有出网白名单
六、定期复查
[ ] 一个月回看一次已装的 skill 有没有新提交
[ ] 有重大更新的，重新走一遍前面的检查第三项里的 description 最容易被忽略，但它决定了风险会不会被触发。一个 description 写得极宽的 skill，即使代码本身干净，也会持续干扰你的每一次对话。
五、三层信任模型：skill、MCP、沙箱
这次四个项目其实正好对应 Agent 栈的四层，其中三层跟安全直接相关。搞清楚它们各自的位置，才知道该在哪一层设防。
| 层 | 代表项目 | 它在哪 | 能做什么 | 风险点 | 怎么控 |
|---|---|---|---|---|---|
| 能力层 | Agent Skills | Agent 内部 | 注入指令和脚本，扩展行为 | 指令注入、脚本执行、触发失控 | 审内容、锁版本、窄 description |
| 连接层 | MCP | Agent 与外部系统之间 | 调用工具、读写数据 | 权限过大、令牌泄漏 | 最小权限、凭证托管、传输加密 |
| 执行层 | OpenSandbox | Agent 外部 | 隔离运行代码 | 沙箱逃逸、资源耗尽 | 网络隔离、资源限额、生命周期管理 |
三层的防法完全不同。
能力层是内容问题，只能靠看和审。连接层是权限问题，靠最小权限和凭证管理。执行层是隔离问题，靠容器和网络策略。
实际部署里最容易出错的是只防了一层。 把 skill 审得很严，但 Agent 有全盘文件权限，一个指令注入就能把工作目录全读走。或者沙箱配得很好，但装的 skill 本身就带着往外发数据的脚本，沙箱之外的部分早就泄漏了。
六、企业的做法
如果这套东西要进团队，四件事得先定下来。
第一，私有 registry。 不要直接从公网拉 skill。内部维护一份经过审计的清单，新 skill 进来要走审核。这跟内部 npm 源是一个道理。
第二，版本固定。 既然官方还没有版本化发布，就自己锁 commit。装的时候记下 hash，升级的时候显式改。不要用「装最新」这种写法。
第三，装的位置。 装在项目目录，不装全局。全局安装的 skill 对这台机器上所有项目生效，影响面差一个数量级。
第四，沙箱化。 需要跑脚本的 skill，放到沙箱里跑。OpenSandbox 这次进了基金会是好事，它提供 Docker 和 Kubernetes 两种运行时，有一套统一的生命周期接口，创建、检查、暂停、恢复、续期、快照、删除都有。这类东西以前是各家自己做，现在有中立实现了。
顺便说一句，我们在做网关类基础设施时踩过类似的坑：把凭证集中到一个地方的好处是统一管理，坏处是那个地方一旦出问题，半径特别大。skill 的安装目录其实是同一个性质，集中管理方便，但要有配套的审计。
七、我的判断
标准中立化是好事，但它不解决安全问题。
把 Agent Skills 交给 Linux Foundation，解决的是「谁来定规则」和「会不会被某一家公司控制」，不解决「装的东西安不安全」。后者要靠版本化、checksum、审计流程这些工程手段，而这些恰好都还在提案阶段。
现在的 skill 生态，大致相当于 2010 年前后的 npm。 好用、增长快、缺规范。这不是坏事，所有生态都这么过来的。但对用它的人来说，意味着不能默认它是安全的。
具体三条建议。
一，把装 skill 当成装依赖对待。看来源、锁版本、记 hash，这三件事现在就要做，别等官方规范出来。
二，优先选带代码的仓库而不是只放 md 的仓库。听起来反直觉，但有代码的仓库会有 issue、有 PR、有人 review，可疑改动容易被发现。只放 md 的仓库没人看，改一行指令也没人知道。
三，description 写得窄的 skill，风险本身就低。这一条可以当筛选标准用，一个 description 写得又长又泛的 skill，作者大概率没想清楚它该在什么时候被调用。
昨天 LiteLLM 的事刚过去，今天 Agent Skills 进了基金会。这两件事放在一起看，指向同一个结论：Agent 生态的供应链，正在成为比模型本身更值得关注的地方。
模型你只能选，供应链你可以管。