Agent Skills：基于数据驱动的 Claude Skills 扩展大语言模型功能的分析 Agent Skills: A Data-Driven Analysis of Claude Skills for Extending Large Language Model Functionality

本文的方法分为五个具体步骤。第一步，数据采集（Section 2.1）：通过爬虫从 skills.sh 平台提取每个 Skill 的元数据，包括 name、repository（托管链接）、first_seen（首次上架日期）和 installed_on（各平台安装量列表），最终获得 40,285 条记录。同时通过 GitHub GraphQL API 查询 OpenClaw 项目的每日新增 Star 数作为社区注意力的辅助信号。第二步，长度与冗余分析（Section 3）：用 tiktoken 的 o200k_base 编码器对每个 SKILL.md 文件进行 tokenize 并统计 token 数；冗余分析先用标准化名称（小写化、去特殊字符）进行精确匹配分组，再用 BAAI/bge-m3 对 Name+Description 进行语义编码计算最近邻相似度，但发现语义匹配不够可靠，主结果采用精确匹配。第三步，功能分类（Section 4.1）：构建 6 大类 20 子类的分类体系（软件工程、信息检索、生产力工具、数据与分析、内容创作、其他工具），因市场标签缺失，使用 Qwen2.5-32B-Instruct 对每个 Skill 的 name+description 进行分类，要求模型输出严格 JSON 并附理由。第四步，供需对比（Section 4.3）：先对 Skill 进行去重处理（Section 3.2 的去重结果），然后计算每个子类的去重后 Skill 数量（供给）和平均安装量（需求），对比两者的一致性和偏差。第五步，安全审计（Section 5）：使用 Qwen2.5-32B-Instruct 对每个 Skill 进行风险评估，输入包括 Skill 名称、描述和完整 SKILL.md 内容，模型按最坏情况解读输出 L0-L3 风险级别和推理理由。

本文的技术新颖性体现在三个层面。第一，在研究对象上，这是首个对公开 Agent Skills 生态进行万级规模量化分析的工作。此前的相关研究要么聚焦于特定 Agent 系统的设计（如 Voyager、Reflexion），要么讨论 Skills 的概念框架（如 Anthropic 的 Agent Skills Overview），但没有人系统统计过一个公开市场上到底有什么类型的 Skill、用户如何采纳、以及它们的风险分布。第二，在分析方法上，本文创新性地将供需分析框架引入 Skill 生态研究，用「发布量」衡量供给、用「平均安装量」衡量需求，首次揭示了软件工程类供给过剩、信息检索类需求旺盛但供给稀少的系统性错配。第三，在安全评估上，本文将 LLM-based auditing 从单个 Skill 的漏洞分析扩展到全量自动化扫描，建立了 L0-L3 四级风险分类体系，首次给出了 Agent Skills 风险分布的全局统计：54% L0、5% L1、30% L2、9% L3，这意味着近 40% 的公开 Skill 具备状态变更能力。这种从个案到统计的转变对平台治理和安全标准制定有直接的实践价值。

本文的弱点主要体现在以下几个方面。首先，数据的时间窗口极为狭窄——仅覆盖 20 天（2026 年 1 月 16 日至 2 月 5 日），这使得「增长趋势」的结论具有很强的时效性。20 天内的 bursty 增长很可能只是社区对新平台的新鲜感驱动，而非持续需求的反映。改进方向是进行纵向追踪研究，在更长时间跨度（如 3-6 个月）内多次采集快照，观察增长是否持续、bursty 模式是否反复出现。其次，供需分析中的「需求」仅用平均安装量作为代理指标，这个指标有两个严重缺陷：一是安装≠使用（用户可能装了但从未调用），二是安装量受平台排名算法影响很大（排名靠前的 Skill 会获得更多曝光和安装，形成马太效应）。改进方向是引入更精细的采纳信号，如实际调用次数、用户评分、留存率等。第三，安全审计的 LLM 标注缺乏人工验证。虽然论文给出了详细的 rubric 和 prompt（Appendix E），但没有报告 LLM 标注与人类专家标注的一致率。在安全领域，误报和漏报的代价不对称——将 L3 标为 L0 的漏报比将 L0 标为 L3 的误报更危险。改进方向是对 LLM 标注进行分层抽样人工验证，并报告 precision/recall。第四，冗余分析仅依赖标准化名称的精确匹配，这种方法无法捕获语义相同但名称不同的 Skill（如「code-review」和「review-code」），论文虽然尝试了语义匹配但效果不佳后就放弃了，没有进一步探索改进方案（如用更强的 embedding 模型或 fine-tuned 分类器）。

论文在 Section 6 和 Section 7 中提出了多个未来方向。第一，去重与质量信号：鉴于 46.3% 的意图级冗余，未来应将语义去重与质量指标（文档完整性、执行可靠性、维护活跃度、使用量）结合，推动每个意图收敛到少量「canonical skills」，让开发者在高质量基础上扩展能力而非重复包装相同工作流。第二，选择性加载与模块化：由于 token 长度的重尾分布，少数超长 Skill 可能占据大量 prompt 预算。未来系统应支持按需检索——只加载当前子目标所需的步骤、参数和工具 schema，结合摘要化、剪枝和指令压缩来降低开销。第三，需求驱动的 Skill 合成：平台可以利用需求信号指导创作工具和审核重点，支持将现有 Skill 适配到新连接器、新领域和新用户约束的需求驱动合成。第四，安全协议标准化：当前框架缺乏对状态变更操作的细粒度控制，未来应实现标准化的沙箱环境，强制执行最小权限原则，允许 Agent 执行复杂任务的同时保护主机系统。从我的视角看，还可以延伸以下方向：（1）建立 Skill 质量基准（benchmark），用标准化的测试用例评估 Skill 的正确性、鲁棒性和安全性；（2）研究 Skill 组合（composition）的安全性——单个 Skill 是安全的，但组合后可能产生意外的级联效应；（3）探索 Skill 的可移植性——目前的 Skill 生态主要围绕 Claude 框架，能否跨 Agent 平台复用？

从复现角度来看，本文的数据采集和分析流程相对透明。数据来源是公开市场 skills.sh，任何人都可以访问并爬取相同的 Skill 元数据（尽管随着时间推移，数据快照会有所不同）。论文详细描述了 tiktoken 的 o200k_base 编码器用于 token 计数、BAAI/bge-m3 用于语义嵌入、Qwen2.5-32B-Instruct 用于分类和安全审计，这些工具和模型都是公开可用的。分类的 prompt 模板在 Appendix D（Figure 14）中完整给出，安全审计的 prompt 在 Appendix E（Figure 15）中完整给出，这大大降低了复现门槛。然而，复现存在以下障碍：（1）skills.sh 的数据在持续变化，论文的 2026 年 2 月 5 日快照无法被精确复现，除非平台提供了历史数据存档；（2）分类和安全审计使用了 Qwen2.5-32B-Instruct，该模型的输出具有非确定性（即使设置 temperature=0），不同版本的模型可能给出不同结果；（3）论文没有开源分析代码（如数据清洗、统计、可视化脚本），复现者需要自行实现。总体而言，复现难度中等偏高——数据获取不难，但精确复现需要等待数据存档或进行近似复现。