一项针对 2,465 个公开列出的 AI 智能体“技能”的最新审计发现，超过一半的技能违反了已发布的规范，更有 7.8% 的技能甚至无法被智能体选中，因为它们缺少必要的元数据。这些缺陷威胁到任何自动发现并加载这些技能的系统的可靠性。
为什么审计很重要
智能体技能注册表允许开发者发布可重用的能力——即自主智能体可以按需调用的代码包。智能体会扫描注册表，读取每个技能的 YAML frontmatter（一段必须包含至少名称和描述的结构化文本块），并决定该技能是否符合其目标。如果 frontmatter 缺失或格式错误，该技能就会从智能体的菜单中消失。在自主智能体可以安排会议、排除服务器故障等任务的世界里，一个损坏的技能就会破坏整个工作流。
数据揭示了什么
- 57.8% 的技能至少存在一项规范违规。
- 29.2% 列出的名称与注册表 slug（URL 标识符）不匹配。
- 18.1% 包含损坏的包路径或失效链接。
- 7.8%（192 个技能）完全没有 YAML frontmatter，导致它们既无名称也无描述。
- 3.8% 嵌入了仅存在于作者本地机器上的绝对文件路径。
- 2.4% 误用了
allowed-tools字段，导致智能体无法读取。 - 2.1% 通过环境变量暴露 API 密钥，这是一个安全警示。
- 1.3% 在未声明的情况下调用外部命令行工具，违反了可移植性规则。
可移植性问题出现频率最高。像 /home/USER/.local/bin/tool 这样的绝对路径对编写该技能的开发者有效，但对其他所有用户都会失效，从而导致静态检查无法捕获的运行时错误。
深入探究：openclaw 案例
审计还检查了 openclaw 仓库中捆绑的 46 个技能。在优化了测试脚本以减少误报后，审查人员发现了 59 个真实的缺陷——这提醒人们，过于激进的 linter 可能会适得其反。当一个工具标记了太多无害的问题时，开发者就会停止使用它，从而导致真实问题被漏掉。
两个 openclaw 的缺陷指向了仓库中已不存在的文件。维护者合并了一个修复程序来恢复缺失的引用，这展示了一个 pull request 如何清理损坏的依赖链。
开发者的反应
审计人员在原始技能仓库中提交了 issue。其中一份报告被拒绝了；维护者辩称，“损坏”应该根据实际的运行时行为来判断，而不是通过静态文件检查。审计人员也同意，对“损坏”的严格定义必须与技能在实践中的执行方式保持一致。另一个 issue 被接受了，相应的修复程序现已上线。
谁将获益——或受损
- 智能体和最终用户：当注册表仅包含符合规范且具有可移植性的技能时，他们可以享受到更顺畅、更可预测的行为。
- 技能作者：可以获得更清晰的验证规则，在发布前捕获错误，减少 issue 分拣时的反复沟通。
- 注册表运营方：必须构建或集成更严格的验证流水线；否则，整个生态系统将面临信任流失的风险。
宽松的验证会鼓励“快而糙”的提交，这些提交可能会在生产环境中破坏智能体，从而可能导致昂贵的停机时间或安全风险。
反方观点：所有的违规都是致命的吗？
有人认为某些“错误”是无害的。对于通过 slug 而非显示名称来选择技能的智能体来说，名称不匹配可能不会产生影响。从环境中读取 API 密钥可能是本地开发的一种刻意设计选择。然而，审计的百分比将任何偏离规范的行为都视为违规，这可能会夸大某些问题的实际影响。
下一步值得关注的方向
- 增强型 linter：能够将真正的可移植性 bug 与良性特性区分开来。
- 注册表端的验证钩子 (validation hooks)：拒绝缺少必要 frontmatter 或包含绝对路径的提交。
- 社区驱动的审计：在缺陷到达生产环境智能体之前将其暴露出来。
- 潜在的规范修订：澄清诸如
allowed-tools之类的模糊字段，并定义环境变量的可接受用法。
下一波工具可能会将这些检查嵌入到持续集成 (CI) 流水线中，使合规性从手动的事后考虑转变为自动化的准入关卡。
核心启示
大多数公开列出的 AI 智能体技能无法通过基本的合规性检查，且有相当一部分根本无法被选中。这些研究结果强调，迫切需要更严格的验证、更好的 linting 工具，以及一种将遵循规范视为发布前提条件的社区文化。在这些保障措施到位之前，智能体将继续在脆弱且不具备可移植性的技能上碰壁。