作者：Lei阅读 --

当提示词成为依赖：读 Warp 的 skills-lock.json

Warp 仓库根目录躺着一个 skills-lock.json：25 个'依赖'全是 Markdown 提示词，每条锁一个内容哈希。它不是标准的一部分，却标志着一个转折——当提示词成为跨团队共享的工件，它就继承了软件依赖的完整生命周期：manifest、锁文件、可复现安装，以及供应链攻击。结合五篇 arXiv 论文，拆解 Agent Skill 依赖管理的现状、原则与锁不住的部分。

AgentSkills工程实践

锁文件（lockfile）是包管理器的招牌发明：把依赖树冻结成哈希，保证今天装的和上个月装的完全一致。Warp 仓库根目录也有一个锁文件，但它锁的不是代码——是 25 段 Markdown 提示词。当提示词需要锁文件的那一刻，它就不再是”写给 AI 的备忘录”，而是正式加入了软件依赖的行列：享受依赖的全部工具链，也继承依赖的全部攻击面。

上一篇拆了 Warp 客户端源码的四层结构化赌注。这一篇看它仓库里一个容易被略过的文件：skills-lock.json。这个文件本身只有一百多行 JSON，但它背后是一整套把”提示词当依赖管理”的工程体系——而这套体系正好踩在 2026 年 Agent 领域一个高速成型的研究方向上。

先把三个问题的答案压成三句话：

  1. 它是什么：Vercel skills CLI 生成的锁文件，把 25 个来自 warpdotdev/common-skills 仓库的 Agent Skill 钉死在内容哈希上。
  2. 它是标准吗：一半是。SKILL.md 的格式是开放标准（Anthropic 主导的 Agent Skills 规范）；skills-lock.json 的锁定只是某个 CLI 的事实约定——相当于 npm 生态里 package-lock.json 的地位，格式随工具走，理念是通用的。
  3. 为什么需要它：因为论文已经给出了完整的证据链——skills 确实有效（会被大规模共享），共享的 skills 里 26.1% 带漏洞（共享必有供应链风险），锁文件是这条风险链上最便宜的第一道闸。

下面按这个顺序展开。

一、文件本体：一个不锁代码的锁文件

从 Warp 仓库 master 分支抓下来的 skills-lock.json，结构是这样的（截取一条）：

{
  "version": 1,
  "skills": {
    "create-pr": {
      "source": "warpdotdev/common-skills",
      "sourceType": "github",
      "skillPath": ".agents/skills/create-pr/SKILL.md",
      "computedHash": "d9f06f0219b3d402cf1ff3b0e..."
    }
  }
}

全文件 25 个条目，清一色来自同一个内部共享仓库 warpdotdev/common-skills，名字能看出 Warp 团队的日常：create-pr、review-pr、fix-errors、diagnose-ci-failures、write-tech-spec、resolve-merge-conflicts……每个条目四个字段：来源仓库、来源类型、SKILL.md 路径、内容哈希。

注意两件事。第一，被锁的对象是 SKILL.md 文件——按 Agent Skills 规范，一个 Skill 就是一个以 SKILL.md 为入口的目录，YAML frontmatter 声明元数据，正文是给 Agent 的过程性知识（procedural knowledge），可以附带脚本和参考资料。换句话说，这个锁文件锁的是提示词工件。

第二，条目里没有版本号，也没有 commit。对比 package-lock.json 的条目（version + resolved + integrity 三件套），skills-lock v1 只有 integrity（内容哈希），没有 version 也没有 resolved 的精确坐标。这个缺口后面会回来说——它是当前这套机制最实在的软肋。

二、它是标准吗：格式是，锁定不是

这里有个容易混淆的分层，值得掰开：

层是什么谁定的地位
工件格式层SKILL.md：目录 + frontmatter + 渐进披露Anthropic，2025 年 12 月发布于 agentskills.io，交由 Agentic AI Foundation 托管开放标准。Claude Code、Codex、Copilot、Gemini CLI 等三十余个工具读同一格式
分发与锁定层skills-lock.json + npx skills 安装/校验/更新Vercel，2026 年 1 月发布的开源 CLI（vercel-labs/skills），配套 skills.sh 目录站事实约定。不属于 Agent Skills 规范，格式随 CLI 演进

类比到大家熟的 npm 生态，映射几乎是一一对应的：

  • SKILL.md ≈ 包的入口文件
  • GitHub 仓库 ≈ registry
  • npx skills add owner/repo ≈ npm install
  • skills-lock.json ≈ package-lock.json
  • npx skills experimental_install（从锁精确还原）≈ npm ci

所以对”skills-lock 是不是标准概念”的准确回答是：锁文件这个理念是包管理三十年的标准答案，skills-lock.json 这个具体格式不是标准、只是最先跑出来的那个约定。就像 package-lock.json 从来不是 Node.js 规范的一部分，但没人会因此说”锁依赖”不是标准实践。历史上 npm/yarn/pnpm 三家锁文件格式互不兼容也各自活得很好——格式收敛是后话，理念先行。

三、Warp 怎么用它：把提示词纳入工程纪律

真正有信息量的不是锁文件本身，而是 Warp 仓库里那份配套规格：specs/common-skills-installation/，产品规格 44 条行为条款 + 技术规格。这是我见过的第一份把”提示词分发”写到依赖管理严谨度的生产级设计文档。把 44 条压缩成五条原则，每条都能直接搬去自己的团队：

1. 锁入库，工件不入库。 skills-lock.json 是被 git 追踪、进 code review 的源文件；安装出来的 skill 副本是本地开发者状态，被 gitignore。规格原文说得很直白：“checked-in common-skills lock is the source of truth for code review”——审阅者看锁的 diff，而不是指望本地流程悄悄同步。

2. 在门口校验，不匹配就拒绝启动。 script/bootstrap 和 script/run 每次都对照锁验证已装 skills：缺失就恢复，哈希不匹配就修复，修不了就在启动 Warp 之前失败。提示词漂移（drift）被当成和依赖损坏同级的构建失败，而不是”反正是提示词，差一点没关系”。

3. 更新是显式动作，永不浮动。 正常流程只从锁还原，绝不自动采纳上游新推的 skill 内容。想升级：跑 npx skills update，生成锁的 diff，人审，提交。规格里专门有一条：非交互环境（CI、云端）永远不提示更新锁——宁可失败，不可漂移。这正是 npm 世界里 “floating dependency” 教训的平移。

4. 单一安装目标，冲突即报错。 skill 可以装在项目本地或用户全局，但不能两处都有；全局副本被多个仓库共享时，若两个仓库锁的版本不同，直接报 version-mismatch 错误，要求人来显式调和——不静默覆盖。这是在防”我机器上明明好的”这类多副本幽灵。

5. 只管自己锁的，不碰别人的。 安装、校验、删除的作用域严格限定在锁列出的 25 个 skill，开发者自己的私人 skill 一概不动。最小作用域，防止工具本身变成破坏源。

flowchart LR
  A["skills-lock.json<br/>（git 追踪，code review）"] -->|"script/run 启动前校验"| B{"哈希匹配?"}
  B -->|是| C["静默通过，启动 Warp"]
  B -->|否| D["npx skills experimental_install<br/>从锁还原"]
  D --> C
  E["上游 common-skills 更新"] -.->|"显式 npx skills update"| F["锁 diff → 人审 → 提交"]
  F --> A

注意这套纪律的形状：它和你管理 Rust crate、npm 包的纪律完全同构。这就是本文标题的含义——提示词一旦跨人共享、影响生产行为，它就是依赖；是依赖，就得进依赖的生命周期。

四、为什么必须锁：论文给出的三段论

如果说 Warp 给了工程侧的”怎么做”，2026 年上半年密集出现的一批论文给了”为什么”。证据链是个严整的三段论。

大前提：skills 真的有效，所以必然被大规模共享。 SkillsBench（arXiv:2602.12670）第一次给了配对测量：87 个任务、8 个领域、18 个模型-harness 组合，同一任务在”无 skill”和”有精选 skill”两种条件下对比。结果：平均通过率从 33.9% 提到 50.5%（+16.6 个百分点），且带 skill 的小模型能追平不带 skill 的大模型。顺带一个反直觉发现：不超过 3 个模块的聚焦 skill 打败大而全的捆绑包——skill 也有”机会成本”，塞太多反而稀释。有效，就会共享；Skills Are Not Islands（arXiv:2607.01136）的爬取规模印证了这一点：公开可见的 skill 已超过 143 万个。

小前提：共享的 skills 里，安全状况相当糟糕。 Agent Skills in the Wild（arXiv:2601.10338）对两大市场的 31,132 个 skill 做了首次大规模安全分析：26.1% 至少含一个漏洞，数据外泄类占 13.3%、提权类占 11.8%，5.2% 呈现强恶意意图特征；捆绑可执行脚本的 skill 出漏洞的几率是纯指令 skill 的 2.12 倍。这不是理论风险——SkillFortify（arXiv:2603.00195）记录了 2026 年 1-2 月的 ClawHavoc 投毒事件：1,200+ 个恶意 skill 被灌进 OpenClaw 的市场。攻击面还在花样翻新：投毒（arXiv:2604.03081）、对注册表的语义供应链攻击（arXiv:2605.11418）——后者的要害是，skill 是自然语言，恶意语义可以写得对人畜无害、对 Agent 是指令。

结论：锁文件是这条链上最便宜的一道闸。 skill 的本质是被注入特权 Agent 的提示词——它拿到的是你 Agent 的全部权限。代码依赖被换包，你还有编译器、类型检查、测试兜底；提示词被换掉，Agent 会安静地照做。所以”上游内容悄悄变了”对 skill 而言不是可复现性的小麻烦，而是标准的供应链攻击路径。内容哈希锁死之后，攻击者至少无法在你审阅之后、运行之前偷换内容——你审的那份，就是跑的那份。

学术侧也在给这套实践补理论地基：SkillFortify 把锁文件语义正式纳入形式化框架（Agent Dependency Graph + SAT 求解），配上 Dolev-Yao 风格的攻击者模型，在 540 个 skill 的基准上做到 100% 精确率；Skills Are Not Islands 则借 SBOM（软件物料清单）的思路提出 Agent Skill Supply Chain（ASSC），把 skill 建模成”携带依赖的工件”——它对现状的判词很精准：skill 元数据”activation-ready but governance-poor”（激活即用，治理阙如）。工程约定先跑、论文随后形式化，这个节奏和当年 npm → 软件供应链研究的展开如出一辙。

五、灰度：锁文件锁不住什么

按惯例，讲清楚边界，这套机制目前至少有四个明确的”锁不住”：

1. 没有 commit pin，来源是浮动的。 前面提过，skills-lock v1 条目只有内容哈希，没有精确的 commit 坐标。这意味着”从锁还原”要去上游仓库的当前状态里找匹配内容——哈希能验证”拿到的对不对”，但不能独立指出”该去哪个历史坐标拿”。社区已有第三方方案主张 manifest + pinned commit + 内容哈希三件套，理由一针见血：a skill is a prompt injected into a privileged agent — silent drift is a supply-chain problem。package-lock.json 的 version+resolved+integrity 三件套是踩了多年坑才收敛的，skills-lock 大概率会走完同样的路。

2. 哈希语义是工具私有的。 computedHash 怎么算（只算 SKILL.md？算整个目录？规范化方式？）由 CLI 实现定义，上游 issue 里已有”computedHash 无法对照已安装文件独立校验”的讨论。在它变成可移植的规范之前，跨工具验证做不到——这正是”事实约定”和”标准”的差距所在。

3. 首次信任问题（TOFU）。 锁保证”审过的 = 运行的”，不保证”审过的 = 安全的”。第一次 skills add 时你信了什么，锁就固化什么。26.1% 的漏洞率意味着固化下来的很可能本来就带毒——锁文件之上还需要审计层（静态分析 + 语义检测，即 SkillScan、SkillFortify 们在做的事）。

4. 语义攻击对哈希免疫。 哈希只关心字节。一段从第一天起就精心构造的恶意提示词，哈希完全一致地通过所有校验。对代码依赖，这对应的是”恶意包本身就恶意”；对提示词依赖，检测难度更高——因为判定”这段自然语言是否恶意”本身就需要语义理解，这是 arXiv:2605.11418 那类攻击的生存空间。

所以准确的定位是：锁文件解决分发环节的完整性，不解决内容环节的可信性。它是必要条件，远非充分条件。

六、收尾：从 Voyager 的技能库到公共基础设施

把时间轴拉长看，“skill 库”这个概念走过了一条清晰的三年轨迹。2023 年的 Voyager（arXiv:2305.16291）在 Minecraft 里第一次展示了 ever-growing skill library：Agent 把学会的行为存成可执行代码，供未来检索复用——但那是单个 Agent 的私有记忆。2025 年底 SKILL.md 标准化，skill 变成人写给 Agent 的可移植知识包。2026 年 skills-lock 出现，skill 变成跨团队、跨仓库分发的公共工件——于是需要锁、需要审计、需要 SBOM。私有记忆 → 可移植文档 → 公共基础设施，每前进一步，能力共享的杠杆放大一级，供应链的攻击面也放大一级。

回到 Warp。上一篇的结论是：Warp 的全部架构是”把结构强加给字节流”这一个赌注的四次下注。现在可以补上第五次——它把同样的结构化纪律加给了自己的工程流程：提示词不是散落在 wiki 和聊天记录里的口口相传，而是有格式（SKILL.md）、有坐标（source + path）、有指纹（hash）、有生命周期（lock → verify → update → review）的正式工件。

带走一个判断标准：你的团队提示词，today 更像 wiki 还是更像依赖？如果一段提示词的变更不需要 review、不同成员机器上的副本可以不一致、上游改了会静默生效——那它就还处在 npm 出现之前的”复制 js 文件进仓库”时代。skills-lock.json 未必是终局格式，但它指出的方向几乎不可逆：提示词的工程化管理，会把软件依赖管理三十年的路，用三年再走一遍。

参考来源

工程实践

arXiv 论文