软件供应链安全不是一个新话题。从 npm 的 package-lock.json 到 Docker 的镜像摘要锁定，开发者早已习惯在依赖链中建立信任锚点。但当 Agent Skill 成为一种新的“依赖”时，供应链验证的路径需要重新设计。
传统依赖 vs Agent Skill
传统软件依赖（npm 包、Docker 镜像、Python wheel）和 Agent Skill 有几个关键区别：
| 维度 | 传统依赖 | Agent Skill |
|---|---|---|
| 内容类型 | 代码和配置 | 说明、脚本和运行环境的组合 |
| 执行方式 | 被宿主程序调用 | 被 Agent 直接执行 |
| 权限范围 | 受宿主程序限制 | 可能涉及文件系统、网络、系统命令 |
| 版本管理 | 语义化版本号 | 通常没有版本号，靠 Git tag 或 commit hash |
| 审计方式 | 代码审查 | 需要理解意图、环境和执行边界 |
这些区别意味着传统的依赖管理工具（npm audit、Dependabot、Snyk）不能直接套用到 Agent Skill 上。需要专门的验证层。
供应链的四个阶段
Agent Skill 从仓库到执行的完整路径可以分为四个阶段：
1. 来源（Provenance）
Skill 从哪里来？是谁创建的？是否被修改过？
SkillSync 的 verify 命令检查：
- 文件的创建时间和修改时间。
- Git 历史（如果有的话）。
- 文件的哈希值，用于后续版本比对。
这些信息帮助回答“这个 Skill 的来源是否可追溯”。但来源可追溯不等于来源可信——可信度判断是人的职责。
2. 兼容性（Compatibility）
Skill 面向什么环境？当前环境是否满足要求？
SkillSync 的 compat 命令对照 Capability Profile 检查：
- Skill 声明支持的 Agent 是否与当前环境匹配。
- Skill 需要的文件系统权限是否被当前环境允许。
- Skill 声明的运行时能力是否在当前环境中可用。
这一步确保 Skill 在当前环境下有可能正常运行，而不是等到执行时才发现环境问题。
3. 变更（Diff）
与上一个版本相比，改了什么？这些变化是否安全？
SkillSync 的 diff 命令：
- 逐行比较两个版本的差异。
- 过滤掉无关的格式变化，聚焦于实质内容的变化。
- 高亮显示新增、删除和修改的部分。
这一步帮助审阅者快速理解“这个版本改了什么”，而不是逐行阅读整个 Skill。
4. 执行（Replay & Verify）
在隔离环境中验证 Skill 的执行行为。
SkillTape 的 verify 命令：
- 在沙箱中重放 Skill。
- 记录每一步的执行结果。
- 生成 Receipt 作为审计证据。
这一步不信任 Skill 的“声明”，而是通过实际执行来验证“行为”。
锁定机制
传统依赖管理使用 lockfile 锁定版本。Agent Skill 的供应链也需要类似的锁定机制：
哈希锁定
SkillSync 使用确定性的 Skill 摘要（digest）来锁定版本。相同的 Skill 内容总是产生相同的摘要值，任何修改都会改变摘要。
安装脚本锁定
SkillTape 的安装脚本从特定的 commit hash 获取，不使用“最新版本”的模糊引用：
SKILLTAPE_VERSION="0.1.0"
SKILLTAPE_RELEASE_BASE_URL="https://github.com/Chumaniac/skilltape/releases/download"依赖项（Rust 和 npm）被锁定在特定版本。
Docker 镜像锁定
SkillSync 的 Docker 沙箱后端使用摘要锁定的镜像执行，确保每次执行都在相同的环境中进行。
策略评估
供应链验证不仅是技术问题，也是策略问题。SkillSync 的 verify --policy 支持加载自定义安全策略：
- 不允许网络访问的 Skill 不能在需要网络的环境中执行。
- 不允许文件系统写入的 Skill 不能修改宿主系统的配置。
- 不允许执行外部命令的 Skill 不能调用系统工具。
策略评估的结果会作为 verify 报告的一部分呈现，帮助审阅者判断 Skill 是否满足组织的安全要求。
CI/CD 集成
供应链验证需要融入开发流程，而不是事后补救。SkillSync 支持 SARIF 格式输出，可以集成到 CI/CD 流程中：
- 在 PR 检查中自动运行 SkillSync verify。
- 将发现状态（pass/warn/fail/unknown）作为合并条件。
- 在 CI 模板中定义标准的验证流程。
这意味着 Agent Skill 的供应链验证可以像代码审查一样成为开发流程的一部分。
当前实践的局限
供应链验证是一个持续演进的领域，当前实践有几个明显的局限：
- 本地优先：两个工具都只支持本地 Skill，不支持远程仓库的自动验证。
- 手动审阅：所有发现都需要人工审阅，自动化程度有限。
- 平台限制：Windows 上的沙箱支持尚未实现，隔离重放在该平台上不可用。
- 生态碎片化：不同 Agent 的 Skill 格式不统一，验证工具需要为每个 Agent 定义 Profile。
这些局限不是技术债务，而是当前阶段的合理边界。随着 Agent Skill 生态的发展，验证工具也会相应演进。
接下来
供应链验证的核心思想是：信任需要证据，证据需要可审计。SkillSync 提供执行前的检查证据，SkillTape 提供执行后的重放证据。两者的衔接形成了一条从仓库到执行的完整验证路径。
这条路径不是完美的，但它把“信任一个 Agent Skill”从一个模糊的感觉变成了一个可以逐项检查的过程。在 Agent Skill 被越来越广泛使用的今天，这种可审计的验证路径比以往任何时候都更重要。
评论