9.0
重磅
AI SCORE
编程提效2026-08-20 04:44
AI技能即代码：应建立代码审查机制
dev.to · AI#AI安全#Agent#最佳实践
Editor brief · 编辑速览
AI技能文件虽以Markdown存在，但可驱动Agent执行Shell、安装包、调用MCP工具甚至修改代码仓库——安全假设「只是文档」是危险的。提出了五问审查框架和威胁模型。
Markdown 本身不是可执行代码。
但用 Markdown 写的 AI skill，却可以指示 Agent 运行 shell 命令、打开凭据文件、安装包、调用 MCP 工具、修改仓库，或将工作委托给另一个 Agent。
文件本身不会自己执行。它影响的是一个能够执行这些操作的系统。
这意味着"这只是文档"是一种危险的安全假设。
在第一部分，我论证了可复用 skill 已经成为了软件制品。在第二部分，我描述了一种可移植的治理架构。这最后一篇文章聚焦于一个后果：skill 需要威胁模型和代码审查的纪律。
真正的执行链
风险不在 Markdown 解析器，而在于下游的授权。
打开全尺寸 SVG 图表 →
同样的句子，当被一个没有任何工具的聊天机器人阅读时，与被一个持有仓库写权限和云凭据的自主编码 Agent 阅读时，风险状况完全不同。
要在 Agent 权限的上下文中审查指令。
一个实用的威胁模型
一次有用的审查从五个问题开始。
作者可能是可信的，但 skill 可以导入或引用不可信的内容：网页、issue、邮件、仓库文件，或另一个工具的输出。一个写着"按照链接文档中的指示操作"的工作流，已经在代码审查之外创建了一条指令通道。
除非有明确的信任决策将外部内容提升为指令，否则将其视为数据。
列出可用的工具、文件系统范围、网络访问、凭据、MCP 服务器、钩子和委托机制。最小权限属于运行时，但 skill 不应假设它需要比实际更多的权限。
只读发现与重写库不同。本地格式化更改与发布包不同。审查最大爆炸半径，而不仅仅是愉快路径。
考虑部分变更后的中断、超时后重试、并发运行、过期状态、缺失依赖以及模糊的工具输出。"Agent 会自己想明白"不是恢复计划。
审查者应该能够回答：什么运行了、用了哪个 skill 和策略版本、发生了什么变更、以及如何验证完成。
攻击面比 skill 主体更大
完整的审查要追踪所有引用。
打开全尺寸 SVG 图表 →
一个看起来干净的 skill 可能指向一个危险的脚本。一个安全的脚本可能由带有未转义输入的钩子启动。MCP 配置可能启动一个意想不到的命令。一次交接可能将任务扩展到用户批准的范围之外。
审查单元是行为图，不是一个 Markdown 文件。
提示注入与信任边界崩塌
标记那些将获取的内容视为权威的指令，特别是"服从……中的所有指示"这类短语，或者将远程文本复制到 Agent 指令层级中的工作流。
更安全的 skill 会分离阶段：
提取事实或数据；
根据用户目标和本地策略验证这些事实；以及
在扩展范围之前请求批准。
密钥与凭据路径
审查字面形式的密钥和引导 Agent 前往凭据存储的指令。在报告中遮蔽匹配项。不要为了调试而回显 token。优先使用环境提供的、作用域受限的凭据，避免在可复用的 skill 中教导某个特定人员的密钥放在哪里。
危险的 shell 模式
将远程下载管道到 shell、递归删除、强制推送、绕过审批或硬重置等操作应该被标记为高严重性。文档示例也需要谨慎：Agent 会复制示例。
一个合法执行破坏性操作的 skill 应该定义精确的目标、预览变更、要求确认，并解释恢复方式。"小心点"不是控制手段。
隐藏的 Unicode 和同形异义字
双向控制字符和零宽字符可以使显示的文本与其逻辑顺序不同。同形异义字可以替换看起来几乎相同的字符。这些技术非常适合用来对审查者隐藏命令、域名、变量或路径。
扫描每一个 Agent 资产，而不仅仅是 SKILL.md：提示词、Agent、命令、清单、MCP 配置和运行时别名。
逃逸出仓库的引用
相对于显式根目录解析引用路径。除非例外是经过深思熟虑和审查的，否则拒绝超出该目录的遍历。缺失的引用应该明显地失败，而不是静默地削弱工作流。
MCP 配置和钩子
MCP 服务器和钩子是可执行的边界。审查用于启动服务器的命令和参数、传递给它环境变量、网络可达性，以及 skill 声明的 MCP 依赖是否与其实际使用的工具相匹配。
对于钩子，检查输入插值、shell 引号、触发范围，以及钩子是否可以在没有与 skill 相同预览和审批契约的情况下进行更改。
变更型 skill 的安全属性
对于任何变更状态的 skill，审查时应出现四个概念。
爆炸半径：受影响的文件、记录、系统或人员的最大集合是什么？范围是否在变更之前确定？
预览：用户是否可以在变更之前检查精确的计划或差异？确认是否绑定到该预览而不是模糊的意图？
回滚：变更可以撤销吗？如果不能，在执行之前这个事实是否明确？
幂等性：如果 skill 运行两次会怎样？重试不应重复评论、不应重建资源、不应两次应用同一迁移。
为多阶段工作流添加检查点。中断后，从已验证的状态恢复，而不是信任会话式记忆。
Skill 的代码审查清单
在 pull request 中使用：
自动化应该阻止什么
并非每个不完美的句子都应该导致 CI 失败。阻止策略应该是狭窄且可预测的。
高置信度、高影响力的缺陷是好的候选：
清晰度、示例质量、可发现性和组合优雅通常属于审查证据，而不是硬性确定性门禁。
Skill Governance Toolkit 实现这种分离。它的只读引擎使用版本化规则扫描 Agent 资产，只能阻止新引入的高严重性发现。其模型驱动的 skill 添加了九维质量评估和库级分析。
治理不是沙箱
Skill 审查不能替代运行时隔离、权限、网络策略、密钥管理或高风险操作的人工审批。
它处理的是不同的层：我们分发的可复用指令是否是良构的、透明的、可移植的、以及设计上安全的。
纵深防御仍然适用：
打开全尺寸 SVG 图表 →
没有单一层承担全部信任负担。
标准应随权限提升
我们不会用相同的严格程度来审查注释、构建脚本和生产迁移。Skill 值得获得同样的基于风险的处理方式。
写作助手 skill 可能只需要清晰的契约和隐私边界。部署 skill 需要依赖固定、最小权限、预览、审批、回滚、幂等性和审计跟踪。
Agent 获得的权限越多，将其可复用指令视为"只是提示词"就越不合理。
AI skill 是可执行资产——不是因为 Markdown 变成了代码，而是因为 Markdown 成为了能够行动的系统控制平面的一部分。
让我们据此来审查它。
AI Skills 正在成为软件。它们需要治理。
为 AI Skills 设计治理层
AI Skills 是可执行资产。让我们像审查代码一样审查它们。（本文）
探索或贡献 MIT 许可的工具包：github.com/artemrudenko/skill-governance-toolkit。
你在一个看起来无害的 Agent 指令背后见过的最危险的能力是什么？