10 月 8 日提交到 arXiv 的一篇论文（编号 2610.11169，Skill Constellations: Tracing the Supply Chain of Agent Skills on GitHub），把 Agent Skill 当成一条真正的供应链来量化，这是近半年头一份。
前提不复杂。Claude Code、Codex 这类编码智能体加载的 agent skill，本质是以 SKILL.md 承载的一包指令与脚本，且以用户的权限执行。开发者之间分享技能的方式，主要是把文件在仓库之间复制粘贴——没有注册中心，没有版本号，没有来源记录。
三个数字，指向同一个麻烦
论文从 GitSkills 语料里每一个 SKILL.md 的 git 历史重建了一张带时间戳的拷贝网络，覆盖 2,193,119 次技能采纳事件，并提供了可交互查看器。由此得到三条结论。
其一，少数几个仓库是几乎全部拷贝的源头，而 GitHub 星标并不能识别出它们。也就是说，最被拷贝的技能不是星标最高的那个，靠流行度找源头在方法上就不成立。
其二，技能副本几乎从不随源头变化。一个技能被复制进新仓库之后就冻结了，于是源头修的安全问题，很少能传播到下游——生态看起来像一张活的网络，行为上却像一片化石。这条判断很关键：安全补丁的可达性问题被彻底放大。
其三，来源不可见。没有注册表、没有版本、没有回指来源的链接，一条有问题的指令可以扩散并滞留在数千个仓库里，没有任何办法召回。
审计价值：同样 100 个人力，差 30 倍
论文没有停在描述上。作者拟合了一个「哪些仓库被别人拷贝」的模型，用它给仓库做审计排名，然后和「按星标排名」做了对照：审查模型排名最高的 100 个仓库，可拦下后续高危技能采纳的 14.9%；审查星标最高的 100 个仓库，只拦下 0.5%。同样的人力投入，收益相差约 30 倍。
由此可以给出一个相当可操作的结论：在技能扩散的早期，审计资源应该投给少数源头仓库，而不是投给最热门的那些。星标衡量的是人气，拷贝关系衡量的是传播力，两者在这件事上几乎无关。
论文给出的结构性建议
建议很直接：平台应当分发带版本的引用，而不是让开发者互相拷贝文件。有了引用关系，来源可追，修复才有可能流下去。这句话听起来平淡，但它指向的是生态基础设施层面的缺失——npm 与 PyPI 之所以能形成成熟的依赖治理，靠的是锁定版本、依赖哈希与发布溯源，而技能生态目前这三样都没有。
读这篇论文要留的几个口子
结论的适用范围需要说清楚。首先，数据的边界是 GitSkills 语料，语料覆盖不等于全网，14.9% 是相对该语料后续采纳的比例，不是绝对风险下降幅度。其次，拷贝网络的重建依赖 git 历史记录，而现实中也有相当比例的技能是通过非 git 途径传播的，这部分无从观测。再次，这是一篇预印本，方法与结论还需要更多独立复核。
但即便如此，这篇论文的方法论价值也可能比它的数字更重要。它本质上是在说一件事：审计对象应该从 popularity 换成 lineage。看哪些仓库最红，和看谁在被拷贝，这是两个不同的问题，而后者才对应真实的攻击面。
对多数团队来说，可立刻上手的动作有两条：一是把引入的外部技能来源查一遍，记录原始出处，别让它以「我从某仓库复制来的」这种形态进入自己的代码库；二是如果团队内部有共享技能池，务必从一开始就带版本与引用，而不是靠拷贝同步。