Claude Skills：AI Agent 的“应用层“标准，而非又一个插件格式

曦尧

119人浏览 · 2026-07-23 19:48:43

曦尧 · 2026-07-23 19:48:43 发布

现在我有足够的信息来撰写完整的中文学习笔记了。

Claude Skills：AI Agent 的"应用层"标准，而非又一个插件格式

核心观点

这件事本质上是一次范式层面的卡位动作，而不是单纯的技术功能发布。

Anthropic 在 2025 年 10 月正式推出 Claude Skills 标准，并于同年 12 月将其作为开源规范发布。Composio 随即构建了 awesome-claude-skills，收录了 1000+ 个生产可用的 Skills，成为目前最大的第三方 Skills 聚合社区。但如果只把这理解为"Claude 的插件市场"，就彻底低估了它的战略意图。

Skills 真正想解决的问题是：Agent 很聪明，但不稳定、不一致、无法沉淀经验。你今天教会 Claude 一套代码审查流程，明天重开对话它就忘了。Skills 是把这套"怎么做"封装成可复用文件的机制——不是工具，不是 MCP，而是专业知识的版本化载体。

关键机制：三层分离 + 渐进加载

三层架构，各司其职

Skills 的最核心设计是把 AI Agent 的能力拆成互不混淆的三层：

层	组件	职责
连接层	MCP Server	负责"能做什么"——接入外部 API、数据库、服务
行为层	Skill	负责"应该怎么做"——工作流程、顺序、护栏
执行层	Tool	负责"如何调用"——具体函数调用

用掘金作者的类比来说：MCP 是外设（键盘、摄像头），Tool 是驱动程序，Skill 才是应用软件。三者在生产环境中协同运行，缺一不可，但职责边界极其清晰。这个设计的高明之处在于：MCP 是 Anthropic 自己定义的连接协议，Skills 是 Anthropic 自己定义的行为协议——两个关键层都被锁死在 Anthropic 的标准上。

渐进加载——解决"百技能不撑满上下文"难题

Skills 的加载机制是其工程上最聪明的设计：

Session 启动时：Agent 只加载每个 Skill 的 name + description，约 100 tokens/个
判断相关后：再加载完整的 SKILL.md 正文（通常 < 5000 tokens）
执行时按需：scripts/ 和 references/ 目录下的辅助文件才被读入

这意味着一个 Agent 可以"持有"数百个 Skills，而不会因上下文窗口撑爆而崩溃。对比之前把所有 Prompt 塞进 System Prompt 的粗暴做法，这是一次真正意义上的架构升级。

SKILL.md 格式：极简但可扩展

---
name: test-driven-development
description: Use when implementing any feature or bugfix, before writing implementation code.
---

# Test-Driven Development

[具体的 TDD 工作流程指令...]

## 参考文档
- See references/tdd-patterns.md for pattern library

前置 YAML 元数据（name + description）决定 Agent 是否激活该 Skill；正文 Markdown 是实际执行指令；references/ 目录存放按需加载的参考资料。整个格式对开发者极度友好，门槛极低。

横向对比：比 System Prompt 好在哪，牺牲了什么

对比维度	传统 System Prompt	Skills
复用性	几乎没有，每个项目重写	文件夹即可 git clone、版本控制
上下文占用	全量注入，不管用不用	按需加载，未激活几乎不占 token
可维护性	字符串散落各处	文件结构化，可 PR、可 Review
跨平台	绑定单一系统	已支持 Claude Code、Cursor、Gemini CLI、Windsurf、Codex 等
风险	较低	Skills 投毒风险真实存在（见下文）

牺牲的东西也要直说：Skills 带来了新的供应链攻击面。恶意 Skill 可以在指令中植入数据窃取逻辑，或通过捆绑的脚本引入漏洞。掘金的独立分析明确提到"社区已经发现过 Skills 投毒事件"，这不是理论风险。

交叉验证

信源一：掘金专栏《一文了解 Anthropic 新推出的 Claude agent 的 Skills 标准》

作者独立于 Composio 对 Skills 做了完整的机制分析，结论与原文高度吻合，但补充了两个原文未强调的重要判断：

Skills 的本质是"经验封装"而非"工具扩展"——原文更偏向罗列 1000+ Skills 的数量，掘金作者从哲学层面做了更深的论证，指出 Agent 行为不稳定的根因就是缺乏专业知识沉淀机制。
安全风险的具体性——掘金文章明确指出 Skills 投毒事件已有实际案例，并建议"仅从可信来源安装、彻底审核第三方 Skills"。这是原文 Composio 仓库没有突出说明的风险警示。

信源二：Anthropic 官方 `anthropics/skills` 仓库（GitHub，163k stars）

官方仓库确认了以下关键事实：

Skills 格式规范与原文描述完全一致（SKILL.md + YAML frontmatter + Markdown）
官方支持平台：Claude Code（插件市场）、Claude.ai（付费计划内置 + 自定义上传）、Claude API
仓库 163k stars、743 个 PR，生态活跃度可信

需要注意的分歧：Composio 原文声称 Skills 已支持"OpenAI Codex、Cursor、Gemini CLI、Antigravity、Windsurf"，但 Anthropic 官方仓库文档只提及自家三端（Claude Code、Claude.ai、API）。第三方平台的兼容性由各平台自行声明，不等同于 Anthropic 官方认证——这一说法需要对照各平台最新文档独立核实。

个人启发：该如何实际应用

对独立开发者：最直接的价值是把你的"最佳实践"从脑子里搬出来。你有一套 code review checklist？写成 code-review/SKILL.md，扔进项目根目录，每个项目都能一致执行，新团队成员也能立刻复用你的经验。成本极低，收益是把经验变成资产。

对工程团队：Skills 天然适合做团队标准化。把公司的 security guidelines、deployment checklist、品牌规范写成 Skills，通过 git 统一分发，替代散落在 Wiki 里的文档——这些文档 AI 以前读不懂，现在可以直接驱动执行。

对决策者（技术负责人）：现在值得花 2-4 小时认真做的事是：从 awesome-claude-skills 里挑 5-10 个与你团队工作流最相关的 Skills，在沙箱环境里跑一遍，评估实际的 token 开销和质量提升比。不要因为"1000+ Skills"的噱头就全量引入——每引入一个第三方 Skill 都需要人工审核 SKILL.md 的完整内容（通常只需要 5 分钟），这是避免供应链攻击的最低成本防护。

安全底线：永远不要直接安装不知名作者的 Skills 到生产环境的 Agent 里。Skills 有读取文件系统、调用脚本的权限，这个风险等级接近 npm 包，而不是浏览器插件。

延伸思考

Skills 生态的商业化路径在哪里？ Composio 通过 awesome-claude-skills 收集了大量用户，其商业模式是让 Skills 对接 500+ App 时使用 Composio 的鉴权服务。这意味着 Skills 格式本身是开放的，但"会做事的 Skills"（调用外部服务那些）存在被 Composio/类似平台商业化的结构性依赖——类似 npm 包免费但 CI/CD 要钱。这个依赖值得警惕。
Skills 会不会最终变成 MCP 的竞争对手而非互补？ 目前的三层模型（MCP 连接 + Skills 行为 + Tools 执行）划分看起来清晰，但实践中有大量 MCP server 已经在用自己的 prompt 注入做"行为定义"。随着两者的社区壮大，边界模糊是大概率事件——Anthropic 如何维护这个标准的权威性，值得持续观察。
"Skills 才是资产，Agent 只是入口"这个判断有没有被过度夸大？ Skills 的价值依赖于背后模型的能力上限。如果未来模型本身通过 fine-tuning 或更长上下文完全内化了这些"专业知识"，Skills 这个显式封装层还有多少必要性？这是一个真实的技术风险，和"应用软件 vs. 操作系统集成"的历史博弈有相似的结构。

📚 参考来源