SkillDepAnalyzer:北大分析143万Agent技能,揭示隐藏供应链风险
Skills Are Not Islands: Measuring Dependency and Risk in Agent Skill Supply Chains

当前,大语言模型(LLM)Agent 的开发正从“手写 Prompt”走向“组装技能库”的新阶段。开发者们为了让 Agent 能够执行特定的专业任务,往往不再从零开始编写代码,而是直接复用社区中已有的Agent技能(Skills)。这种复用极大加速了Agent应用的繁荣,但同时也带来了一个致命的盲区:这些技能包的规模在急速膨胀,却没有任何一套系统来记录它们的身份、版本和来源。当一个Agent加载了数十个外部技能时,开发者根本不知道这些技能又在暗中调用了哪些第三方代码包、其他子技能或是外部API服务。
ArXiv URL:https://arxiv.org/abs/2607.01136
北京大学与中关村实验室的研究团队敏锐地捕捉到了这一痛点。他们指出,Agent 技能已经不再是孤立的文本文件,而是承载着复杂依赖关系的软件制品。由于当前的依赖管理极其不透明,社区中已经出现了大量重复安装、环境冲突以及难以察觉的隐蔽恶意代码。为了解决这一问题,研究团队创新性地提出了Agent技能供应链(Agent Skill Supply Chains,简称 ASSCs)的概念,并开发了一款名为 SkillDepAnalyzer 的自动化工具。通过对超过143万个公开Agent技能的深度扫描,这项研究以前所未有的视角揭示了Agent生态下隐藏的依赖网络与级联安全风险。
为什么传统软件物料清单(SBOM)管不了 Agent 技能?
在传统软件工程中,软件物料清单(SBOM)是解决供应链透明度的标准答案。现有的 SBOM 生成器(如 Syft、Cdxgen 或微软的 sbom-tool)可以轻松读取 package.json 或 requirements.txt 等标准文件,从而理清依赖树。然而,当这些成熟工具面对 Agent 技能时,却显得水土不服。
这是因为,一个典型的 Agent 技能通常围绕一个 SKILL.md 文件构建,这是一个包含了三部分内容的混合体:前端元数据(YAML格式)、供大模型阅读的自然语言指令,以及负责执行具体操作的代码脚本。
Agent 技能的依赖并不是整齐地写在配置文件里的。它可能是一段写在自然语言指令中的提示(例如“当执行此任务时,请调用外部搜索服务”),可能是脚本中隐含的包安装命令,也可能是对另一个复杂技能的直接调用。传统的 SBOM 工具预设了“包为中心”的输入模式,无法理解自然语言和代码混合环境下的“技能级重用”,更无法识别技能向外延伸的服务调用。这种技术代差,使得现有的Agent开发者实际上是在“蒙眼狂奔”。
SkillDepAnalyzer:深入混合文本的依赖捕获者
为了穿透技能内部的复杂性,研究团队设计了专门面向技能生态的分析工具 SkillDepAnalyzer(简称 SDA)。该工具借鉴了软件物料清单的理念,并首创了技能维度的物料清单格式——SkillBOM。SDA 的核心工作流包含四个精密的阶段,专门用于应对非结构化线索与多重调用逻辑。

从工具的架构图中可以看到,SDA 并没有简单地使用正则表达式或纯粹的大模型去瞎猜,而是采取了严谨的多步校准机制:
第一步是结构感知的技能解析。工具会优先剥离技能文件的前端元数据(如 YAML 块),从中提取名称、版本和描述作为最高优先级的身份证据。如果元数据缺失或不完整,SDA 会无缝回退到技能正文,通过元数据关键字匹配和指令模式匹配,从自然语言和执行命令中挖掘潜在的依赖线索。
第二步是基于证据校准的依赖分析。在 Agent 技能中,提到一个名词并不等于真正依赖它(例如某些包仅仅出现在示例说明中)。SDA 会将收集到的线索与上下文进行综合评估,为每一个候选依赖打上置信度标签,并将高置信度的依赖严格分类为三种渠道:代码包(packages)、子技能(skills)和外部服务(services)。
第三步是增量式的 BOM 构建。一旦梳理清了当前节点的直接依赖,SDA 就会顺藤摸瓜。对于代码包通道,它会去补全包级别的传递依赖;对于技能通道,它会递归地引入所依赖子技能的 SkillBOM;而对于外部服务,它则精准记录其服务端点,不再进行不必要的下探。
最后一步,SDA 将这份复杂的混合依赖图谱序列化,输出为结构化且经过模式校验的 SkillBOM。由于其底层架构基于标准的 SBOM IR,这种新格式不仅保留了独特的技能维度依赖关系(如对外部服务的调用),还能完美兼容 SPDX 和 CycloneDX 等国际通用 SBOM 标准,便于直接接入现有的企业级安全审计流水线。
精准与全面的平衡:SKILL-DEP 基准测试
为了验证 SDA 是否真的具备成为 Agent 生态基础设施的能力,研究团队手工构建了专属的评估基准测试集 SKILL-DEP,包含单层和多层依赖图谱的精准测试。实验设计引入了业内顶尖的五款传统 SBOM 生成工具作为基线对比。
结果具有压倒性:在单层基准测试中,SDA 取得了 0.95 的依赖提取 F1 分数,不仅在元数据提取(如代码仓库路径追踪)上达到了完美的 1.00 准确率,更在技能级和服务级的依赖捕捉上彻底击败了所有传统 SBOM 工具。因为传统工具在面对非包类依赖时几乎全军覆没。
在更严苛的多层基准测试(即模拟深层技能嵌套调用的真实场景)中,SDA 依然保持了 0.95 的 F1 分数和 0.98 的精准度,证明了其增量式构建策略在面对复杂依赖爆炸时依然稳健。相比之下,传统的基于纯语言模型的提取基线在这个环节往往因为上下文过长或幻觉问题而出现大量的错误链接。
透视143万技能生态:隐秘的四重供应链特征
拥有了强大的分析武器后,研究团队对大规模开源注册表 SkillsMP 中成功下载的超过 143 万个 GitHub 托管技能进行了全面扫描,勾勒出了 Agent 技能生态真实而残酷的供应链现状。
基于庞大的 ASSCs 图谱,研究总结出了四个值得高度关注的宏观结构特征:
-
可用性极强,但治理环境极差。数据表明,99.55% 的技能带有能够让 Agent 识别和激活的基础元数据(如名称和描述),但这其中只有寥寥 1.40% 的技能包含规范的依赖声明。更令人担忧的是,有高达 58.73% 的技能在名称上存在冲突。这就好比一个巨大的黑市,大家都急着把产品卖出去,却没有人愿意写清楚成分表。
-
多渠道且高度集中的依赖网。Agent 技能的依赖并不单一,它跨越了技能本体、传统代码包和云端服务三大通道。有趣的是,这些依赖并没有均匀分布,而是高度集中在极少数核心技能和底层包上。这种“头重脚轻”的倒金字塔结构意味着,一旦头部某个高频复用的底层技能出现故障,整个生态系统都会受到震荡。
-
递归复用导致的包库存隐蔽膨胀。由于技能可以嵌套技能,依赖图谱在纵深方向上出现了剧烈膨胀。数据显示,超过 22% 的技能完全是通过引用其他技能,而在不知不觉中被动加载了大量的外部代码包。在这个传递链条下,根技能实际上继承了大量毫无察觉的 Python(PyPI)或 Node.js(npm)包。如果不从全局图谱层面进行审查,开发者永远不知道自己到底引入了多少“定时炸弹”。
-
围绕特定工作流形成的环状集群。庞大的依赖网络中,有超过 30% 的有依赖技能节点处于循环依赖或闭环集群中。这通常是因为开发者将一个复杂的业务(如自动化数据处理流程)强行拆分成多个互相关联的小技能导致的。这种高耦合的集群,实际上应当被视为一个不可分割的治理单元,而不是零散的单点文件。
级联的安全梦魇:当风险沿图谱蔓延
如果说结构上的混乱只是维护者的烦恼,那么安全信号在 ASSCs 中的蔓延则直接威胁到了所有 Agent 用户的底层系统安全。研究团队在图谱分析中追踪了多种安全威胁的传播路径。
分析发现,安全风险的暴露绝大部分来自于“暗处”。对于恶意技能而言,约有 13.40% 的下游技能纯粹是因为传递依赖,而不小心引狼入室。例如,研究团队在手动审查中确认,早期被曝光的恶意窃取技能 clawhub1,依然阴魂不散地藏匿在某些提供“一键式多技能包”的项目深处。只要开发者不知情地调用了这个上游集合,恶意代码就会堂而皇之地在本地 Agent 环境中获得执行权限。
而在传统代码包层面,这一问题被成倍放大。由于多数技能在编写依赖安装指令时,没有采取版本锁定(Version Pinning)策略,导致每次部署都会默认拉取最新版本的包。这种粗放的做法使得类似 axios 等知名包的潜在漏洞暴露率极高。统计指出,受到 axios 漏洞波及的根技能中,高达 98.01% 完全是因为复杂的传递依赖被动中招。这种“一人感冒,全家吃药”的供应链级联效应,让传统的单文件代码审查形同虚设。
对未来的审视与行动指南
Agent 技能从孤立的提示词片段演变成复杂的依赖制品,这是技术走向规模化部署的必然结果。但正如这篇研究所展示的,现有的开发习惯和基础设施,还远远没有做好迎接这种复杂性的准备。
要消除 ASSCs 带来的阴影,仅仅依靠事后的扫描是不够的。研究团队给生态提出了明确的整改建议:对于 Agent 基础设施的维护者(如各大应用商店和注册表),必须尽快建立类似代码包注册表那样的强制依赖声明规范,并在工具链中引入针对依赖集群的自动预警机制;而对于一线的 Agent 开发者而言,在开发技能时维持一份类似于 package-lock.json 的技能锁定记录(Lockfile)已经刻不容缓。只有将依赖的具体版本、源头路径以及哈希值牢牢锁定,才能保证这套基于人工智能构建的脆弱供应链,不会因为某个遥远节点的崩溃而轰然倒塌。