用来源图追踪Agent技能复制与更新

Agent 的 skill 被复制到另一个仓库后，上游修了问题，副本怎么知道？作者提出给 SKILL.md 加两个可选字段，记录它从哪里来、复制时的内容是什么，再用一张派生关系图追踪修复影响。

这套方案解决的是 skill 的来源追踪和过期判断。它值得关注，因为复制提示词、操作规范和工具说明已经成为常见用法，但作者目前只有规范、参考实现和测试，没有证明实际收益的基准数据。

复制走了操作规则，却没带走更新关系

作者讲了一个团队案例：某业务部门的报表 skill 被另一团队复制并扩展，后来原版涉及的部分指标被废弃，原版随之更新，副本却继续调用旧指标。Agent 反复重试、尝试绕路，最终报错。团队深入排查后，才找到那份过期副本。

这里的问题是，副本丢失了来源关系。假如文件里保留「来自哪个 skill、哪个 ref」，排查就有了直接入口。

作者引用的研究「Skill Constellations」发表于 2026 年 10 月 8 日，编号为 arXiv:2610.11169。它重建了 GitHub 上涉及 2,193,119 次 skill 采用行为的复制网络：一半 SKILL.md 是其他文件的逐字副本；来源发生变更后，只有 11.1% 的克隆组变更能传播到所有副本。这些是原文引用的研究数据，并非作者对方案的实测结果。

原文还提到，Anthropic 于 2026 年 10 月 22 日将 Agent Skills 捐赠给 Linux Foundation 旗下的 Agentic AI Foundation（AAIF）。起步路线包括版本化发布、正式提案流程和安全指导。但版本号回答的是「这是哪次发布」，派生记录回答的是「它从哪里复制而来，还有哪些后代可能受影响」。

知道版本，不等于知道复制关系。

两个字段怎样区分原样副本和修改分支

作者提交的 Skill Derivation Graph v0.1，把入口压缩为现有 metadata 下的两个可选字符串字段。

下面的配置记录父 skill 的位置，以及复制时父文件的内容哈希：

metadata:
  derived-from: "https://github.com/acme/skills/tree/3f2c9e1/doc-summarizer"
  derived-from-hash: "sha256:9b1d…"

要看清第二行：derived-from-hash 存的是父文件的哈希，示例里的值是缩写，不能直接作为真实摘要使用。

derived-from 指向复制或改编的来源，并固定到某个 ref，可以是 commit SHA、tag，规范不强制版本格式。derived-from-hash 则取该 ref 下父 SKILL.md 的 SHA-256：先将换行统一为 LF、去除行尾空白，再排除这两个来源字段。

工具对当前副本做同样的规范化和哈希计算。如果结果与父哈希一致，就判为原样副本；不一致，就判为修改分支。无需维护者另填一个容易忘记更新的「是否修改」标记。

把字段放进 SKILL.md，也有实际考虑：人们经常整目录复制 skill，仓库根部的清单未必跟着走，文件内的记录更容易保留。不认识这些字段的 Agent 可以忽略它们。

不过，这只能在规定的规范化范围内判断内容是否一致。正文措辞调整也会产生不同哈希，修改分支是否仍受旧问题影响，还得继续检查。

上游修复后，工具应该给出什么结论

完整模型把 skill 及其版本作为节点，用三类边连接：DERIVED_FROM 表示复制或改编，SUPERSEDES 表示替代旧版本，PATCHES 表示修复某个存在漏洞的版本。

修复发布后，工具从被修复的版本出发，沿后代关系做广度优先遍历，并记录路径中是否经过修改分支。

对于存在漏洞版本的原样副本，工具可以标记为过期，再按使用方策略默认阻止，或给出强警告。对于修改分支，则提示审核，因为修复可能适用，也可能已被本地改动覆盖，不能静默升级。

来源断裂、缺失，或者无法访问派生索引时，结果应当是「过期状态未知」。主动固定旧版本则按提案给出警告：存在更新，但使用者明确选择了旧版。

查不到过期证据，不能据此报告为最新。

这里仍有一个落地缺口：两个字段提供父节点线索，但要向前找到后代，还需要工具收集各处的来源记录。原文没有给出跨仓库索引覆盖率的实测结果。因此，「不依赖特定注册表」不代表无需建设索引。

我的判断

我赞成把来源记录随 skill 一起保存。对已经把第三方 skill 放进仓库维护的团队，这个约定成本较低，也能让故障排查多一个入口。相比只写来源网址，固定 ref 和内容哈希提供了更明确的比对依据。

但标题里的「没有 lockfile」更像问题类比。两个字段尚不等于完整锁文件，它们也不保证来源可信。作者明确承认，来源声明由维护者自行填写，恶意作者可以冒称来自知名项目；哈希用于识别内容，不能证明作者身份或代码安全。

另一个局限是哈希目前只覆盖 SKILL.md。若目录里的脚本、模板或参考文件改变，正文哈希可能仍然相同。是否覆盖整个目录，正是提案留给维护者讨论的问题。

证据方面也要分开看。仓库已有仅依赖 Python 标准库的参考实现、单元测试，以及「源 skill → 原样副本 → 修改分支」的 3 节点示例，说明基本机制可以实现。它还定义了 fix reach %、time-to-fix、stale-descendant count、fork-detection accuracy、unresolved share 五项指标，但没有测量结果。

作者计划与「移除派生图、只做哈希匹配」的方案对照，这个设计合理。不过，在数据出来前，图能提高多少修复覆盖率、减少多少排查时间，都只能算待验证的判断。

能拿来做什么

• 团队复制外部 skill 时，可以试用这两个字段，记录固定 ref 和真实父文件哈希，并检查后续复制流程是否保留它们。
• 维护供前端或 Node 项目使用的公共 skill 时，可以先在内部集合中追踪一次上游修复，把原样副本和修改分支分别列出，交给维护者处理。
• 检查 AI 编程环境中的 skill 时，把「确认过期」「需要审核」「来源未知」分开呈现，避免把扫描失败显示成检查通过。
• 评估是否建设派生图时，按作者的基准定义加入仅哈希匹配的对照组，先验证父子关系是否带来额外收益，再决定投入规模。