目录一、Skills 起源和发展1.1 疯狂的Skill从极客玩笑到全网刷屏1.2 Skill 的起源二、Skills 的核心原理与架构机制2.1 什么是 Skills2.2 Skills 的核心结构2.3 三层渐进式披露架构三、Skills 如何参与运行3.1 上下文窗口动态变化过程3.2 Skills 的代码执行能力混合 LLM 推理与代码执行四、过往架构对比4.1 与 Prompt 对比4.2 与 MCP 对比4.3 与传统 Agent 架构对比五、Skill 市场与资源平台六、参考资料一、Skills 起源和发展1.1 疯狂的Skill从极客玩笑到全网刷屏在2026年4月的这段时间科技圈的目。光被 GitHub 上的一个开源项目所吸引。有人在 GitHub 上发布了一个名为「同事.skill」的项目所吸引该项目生成只要提供某位同事的飞书聊天记录、钉钉文档、微信聊天记录和工作邮箱作为原材料系统就能通过AI技术生成一个可替代该同事工作的数字分身。其slogan充满赛博朋克的慈悲「将冰冷的离别化为温暖的 Skill欢迎加入赛博永生。」这个看似荒诞的项目却在短短5天内狂揽了6.6k颗星截至本文章写作时间为止已经收获了18.9k颗星。随后这股风潮迅速破圈蔓延至各大社交平台。紧接着迎来了一场「蒸馏」狂欢各种脑洞大开的变种项目层出不穷。从「前任.skill」、「导师.skill」、「暗恋对象.skill」一路发展到「老板.skill」甚至「自己.skill」。随后skill 便彻底爆火出圈被全网刷屏。1.2 Skill 的起源开年爆火的Skill其实早在去年就已出现这项技术也是经历了典型的技术扩散轨迹2025年10月Anthropic 发布 Agent Skill彼时仅限于开发者小范围关注2025年11~12月技能规范开放生态迅速扩展2025年12月18日Anthropic 将 Skills 规范开源为开放标准交由 Linux 基金会管理标志 Skills 从单一产品功能演变为行业通用标准2026年1月产品更新叠加非编程场景落地触发病毒式传播2026年4月「同事.skill」项目在 GitHub 爆火5 天 6.6k StarsSkills 从技术圈破圈至大众2025年10月16日Anthropic 在一篇名为Equipping agents for the real world with Agent Skills为现实世界的特工装备特工技能的文章中正式提出 Agenyt Skills 概念。2025年10月16日Anthropic 在一篇名为 Equipping agents for the real world with Agent Skills 的文章中正式提出 Agenyt Skills 概念。文章开头便引出Claude 模型很强大但真正的落地还需要特定的组织框架、业务流程以及实际生产知识。为此我们推出 Agent Skills 这样一个可以直接利用公司内部文件的新生产方式”Claude is powerful, but real work requires procedural knowledge and organizational context. Introducing Agent Skills, a new way to build specialized agents using files and folders.可见Agent Skills 旨在解决通用AI只懂原理却不会干活的核心痛点。传统 AI Agent 存在三大痛点痛点表现Skills 的解法Prompt 重复编写每次都要从头教 AI 怎么做事写一次永久复用结果不稳定依赖每次 prompt 质量输出不一致固定 SOP 模板保证一致性工具对接繁琐MCP/Tools 只提供能力不告诉 AI 何时用、怎么组合把「何时用、怎么组合」写进 SKILL.md传统大模型虽然可以生成代码或文本但缺乏对特定组织架构、业务流程和品牌规范的深层理解。例如DeepSeek 虽能编写代码却不知道开发团队的具体技术栈Kimi 能生成分析报告但无法理解企业独特的财务审批链条。通俗一点来说原本的通用 Agent 是公司新招来的某个行业专家即使能力再强也需要一段 landing 期来熟悉公司内部的业务推进方式、审批流程甚至是部门间微妙的人际关系。而一个 skill 就是为这个新入职员工建立的入职手册和原有业务文档。Skills 原理图2025年12月18日Anthropic 将 Skills 规范开源为开放标准并交由 Linux 基金会管理。这标志着 Skills 从单一产品功能演变为行为通用标准与 MCP 形成互补生态。二、Skills 的核心原理与架构机制2.1 什么是 Skills简单来说Skills 就是“完成特定任务的标准化、可复用流程”它不是一种单一的能力而是一套“能直接用、能重复用、还能不断优化的具体方法”。Skills 并不是新能力而是“新边界”。它并没有让AI 变得更聪明它只是让 AI 变得可控。Skills 跟我们之前惯用的 Prompt 是共存关系Prompt 描述的是「意图想做什么」Skills 决定「执行流程怎么做」。简单来说Prompt 就是来描述我要 大模型 做的事情比如写一个贪吃蛇的小游戏大模型 Get 到我们的意图后尝试用自己的认知去实操而 Skills 则可以理解为说明书大模型可以参考贪吃蛇游戏开发说明书进行开发效果比大模型自己实操效果更好。Skills 本质上就是教 AI 按照固定流程做事的操作说明书一旦写好就能像函数一样反复调用。Skills 可以看成「把某件事应该怎么专业做」这件事封装成一个可复用、可自动触发的能力模块。2.2 Skills 的核心结构Skills 的核心结构就是一个文件夹一个 SKILL.md 文件。SKILL.md 文件包含元数据至少要有名称和描述告诉 AI 如何完成某一特定任务的指令一个 Skill 本质上就是一个 Markdown 文件文件名固定为 SKILL.mdmy-skill/ └── SKILL.md 唯一必需YAML Frontmatter必填元数据--- name: pdf-processing # 必填最长 64 字符小写字母数字连字符 description: - # 必填最长 1024 字符最关键的一行 从 PDF 中提取文本和表格填写表单并合并文档。 触发场景处理 PDF、提取文字、填写表单 license: Apache-2.0 # 可选 compatibility: 需要 Python 3.8 # 可选最长 500 字符 metadata: # 可选自定义键值对 author: your-name version: 1.0 allowed-tools: bash read # 可选允许使用的工具列表 trigger_keywords: # 可选提升自动触发率 - PDF - 填表单 - 提取文字 ---Markdown 正文指令部分# PDF 处理 ## 使用场景 当需要对 PDF 文件进行操作时使用例如 - 提取 PDF 文本或表格数据 - 填写 PDF 表单 - 合并多个 PDF 文件 ## 提取文本 - 使用 pdfplumber 提取文本型 PDF 内容 - 扫描版 PDF 需配合 OCR 工具 ## 填写表单 1. 调用 Bash 工具执行 python {baseDir}/scripts/extract_form_fields.py --input $PDF_PATH --output form_fields.json 2. 读取 form_fields.json解析字段信息 3. 根据用户需求填写并生成新文件 ## 参考资料 - 表单填写规则见 forms.md - 品牌视觉规范见 brand-guide.pdf完整目录结构示例~/.claude/skills/react-component-review/ ├── SKILL.md # 核心指令 元数据建议控制在 400 行内 ├── templates/ # 常用模板AI 按需读取 │ ├── functional.tsx.md │ └── class-component.md ├── examples/ # 优秀/反例给 AI 看标准 │ ├── good.md │ └── anti-pattern.md ├── references/ # 规范、规则、禁用词表 │ ├── hooks-rules.md │ └── naming-convention.md └── scripts/ # 可执行脚本 ├── validate-props.py └── check-cycle-deps.sh在 SKILL.md 中引用方式需要给出标准函数组件时参考templates/functional.tsx.md的结构如果违反 Hooks 规则对照references/hooks-rules.md第 3-5 条说明如需校验 propTypes可执行scripts/validate-props.py {代码片段}AI 看到路径引用后会按需加载对应文件而不是一次性全部塞入上下文。字段必需说明name是Skill 名称最长 64 字符只能使用小写字母、数字和-且不能以-开头或结尾description是功能与使用场景说明最长 1024 字符不能为空license否许可证名称或指向随 Skill 附带的许可证文件compatibility否环境与依赖说明产品、系统包、网络权限等最长 500 字符metadata否自定义键值对用于扩展元数据如作者、版本号allowed-tools否允许使用的工具列表空格分隔实验性功能如果你需要一些参考资料参考实例执行脚本可以使用更复杂 Skill 的目录结构my-skill/ ├── SKILL.md # 必需指令 元数据 ├── scripts/ # 可选可执行代码 ├── references/ # 可选文档资料 └── assets/ # 可选模板、资源2.3三层渐进式披露架构为真正了解 Skills 的核心原理和架构机制可以参考 Anthropic 最初发布的Equipping agents for the real world with Agent Skills里面The anatomy of a skill 部分清晰明了地介绍了 Skills 的原理架构。利用开头提到的新员工landing方式来更通俗的讲解核心概念给 AI 一本工作手册想象你招了一个超级聪明的实习生但 TA 刚入职时懂通用知识但不知道公司的具体流程会写代码但不懂组里的技术规范能分析数据但不知道具体的业务逻辑Skills 就可以理解为给这位实习生准备的 Landing 文档。这个过程不是重新训练 AI 而是把特定领域的操作指南、工具脚本、参考资料打包成文件夹让 TA 在需要时查找学习然后立刻执行。在架构上Skills 采用三层渐进式披露架构Progressive Disclosure渐进式加载Progressive Disclosure是 Skills 区别于传统 Prompt 的最关键设计也是 Skills 最精妙的架构。-- 第一层目录索引元数据metadata每次对话开始时AI只看目录包括技能名称最多64字符和一句话描述最多1024字符。就像这位新入职的实习生刚接到一个新需求时先翻一下组内知识库的目录判断和手头上的项目有没有关系以此来看需不需要打开查看详细步骤。这一层只占用约100个tokenAI可以同时知道几百个技能的存在并且不增加任何负担。-- 第二层详细步骤SKILL.md当 AI 通过 metadata 判断这个任务需要某个 Skill 时它会调用 Bash 工具读取选中的 SKILL.md将其中的完整指令加载到上下文中到这一步AI才真正学会如何具体操作。在写SKILL.md时需要注意一些技术细节文件采用YAML前导格式类似简历开头的个人信息区包含 name、description 等元数据也就是上面提到的第一层主体是 Markdown 格式的详细指令Skills 以 Markdown 文件形式存在不执行功能而是通过按需、渐进式加载实现高效且可复用的经验传递。-- 第三层参考资料链接文件在真实工作场景下主手册往往会放不下太复杂的情况类似于我们平时在公司都没时间看的文档比如各种表单填写规则forms.md品牌视觉规范brand-guide.pdf代码示例库examples.py而AI只会在特定子任务时才去读取这些文件。比如填表时才看 forms.md做数据分析时忽略它。一个简单的 SKILL.md 文件示例层级内容触发时机Token 消耗第一层目录索引每个 Skill 的 name description元数据始终可见启动时预加载~100第二层详细步骤完整的 SKILL.md 正文指令技能相关时加载~1,500第三层参考资料附件文件scripts/references/assets必要时按需加载按需三、Skills 如何参与运行3.1 上下文窗口动态变化过程这里的上下文窗口可以理解为 AI 调用每一层 Skills 的触发时机这里我们沿用 Anthropic 举的让 Claude 填写 PDF 表单的例子。技能会在上下文窗口中通过系统提示符触发。阶段 1初始状态对应第一层 Skills[系统提示] [所有技能目录] [用户消息] ↑ 用 PDF 技能填写这份合同AI 看到「PDF 技能」的描述判断出需要详细操作手册。阶段 2加载主手册对应第二层[系统提示] [技能目录] [用户消息] [SKILL.md 完整内容] ↑ 明白了先读取 PDF再识别表单字段然后填写阶段 3按需加载子手册对应第三层[系统提示] [技能目录] [用户消息] [SKILL.md] [forms.md] ↑ 这个表单看起来像 W-9 税务表按照 forms.md 的特殊规则处理阶段 4执行任务[系统提示] [技能目录] [用户消息] [SKILL.md] [forms.md] [执行结果] ↑ 已填写完毕请检查整个过程中AI 不会一次性加载所有 PDF 技能相关的 10,000 tokens 资料而是像人类一样边做边学token 消耗量降低 70-90%。3.2 Skills 的代码执行能力混合 LLM 推理与代码执行Skills 不仅是 YAML 和 Markdown 格式的文档还可以包含提前写好的可执行代码。这极大地保证了 Skills 的稳定运行。Skills 本身不是可执行代码。一个 Skill 的核心是 SKILL.md一份大提示词 说明书它不会自己跑 Python 或 JavaScript。真正跑代码的主体仍然是 AI 的工具系统Bash、code executionSkills 只是告诉 AI「在某一步请用 Bash 去执行某个脚本然后再根据结果继续推理。」一份涉及到代码的标准 Skill 目录大致是这样my-skill/ ├── SKILL.md # 说明书主提示词 ├── scripts/ # 这里放可执行脚本Python / Bash 等 │ └── helper.py ├── references/ # 需要读进上下文的文档 └── assets/ # 模板、二进制文件等只按路径引用其中 scripts/ 里放的是要执行的代码典型用途数据解析、转换如分析代码库、清洗日志跑各种命令行工具git、npm、pdftotext做复杂、多步骤、对结果要求100%确定的操作Skill 里诸如 python {baseDir}/scripts/analyzer.py.... 这样的命令来引用脚本。{baseDir}是一个自动替换的变量表示当前这个 Skill 在本地的安装路径这样技能可以在不同机器、不同项目路径下通用不用写死绝对路径。AI 如何决定要跑哪个脚本呢这一步需要 LLM 自己读描述做匹配。对话一开始时AI 只看到了所有的 Skills 的 name description 列表存在 Skill 工具的描述中当用户提出任务例如提取PDF表单AI 会自动根据描述选择匹配的对应的 Skill一旦选中了某个 Skill系统会把 SKILL.md 整个读出来作为一段新的指令注入对话隐藏在元消息中在这份指令里用户会提前写好类似如下内容当需要抽取 PDF 表单字段时 - 调用 Bash 工具执行 python {baseDir}/scripts/extract_form_fields.py --input $PDF_PATH --output form_fields.json - 执行完后读取 form_fields.json解析其中的字段信息再根据用户需求进行后续处理当 AI 读到这段 Markdwon再结合当前任务就会在下一步工具调用中发起一个 Bash 调用例如{ tool: bash_code_execution, input: { command: python /home/user/.claude/skills/pdf/scripts/extract_form_fields.py --input \contract.pdf\ --output form_fields.json } }Bash 工具真的在沙箱里跑这条命令执行脚本回传命令执行结果output form_fields.json。AI 再读取 form_fields.json用自己的自然语言能力理解这些结果继续完成后续推理与回答。Skills 能够保证一致性和稳定性的核心原因是混合执行模式Hybrid Execution—— 将 LLM 的语言理解能力与代码的可靠执行相结合。Skills 的关键优势在于 Efficient script execution高效脚本执行和 Reliability可靠性而非单纯的 “确定性”。这种设计确保了- Efficient高效脚本代码不进入上下文只有输出消耗 tokens- Reliable可靠相同输入产生一致的结果减少 LLM 生成的随机性- Consistent一致通过代码执行而非 LLM 生成来保证格式和计算的准确性代码执行的运作流程用户提出任务 ↓ AI 读取 SKILL.md发现需要执行脚本 ↓ AI 通过 Bash 工具执行命令如 python {baseDir}/scripts/analyzer.py ... ↓ 脚本在沙箱中运行处理文件、调用 API 等 ↓ 脚本输出结构化结果如 JSON ↓ AI 读取结果继续推理和生成回答用「确定性代码」补足「随机性模型」LLM 有两个天然相反的特性理解、推理、生成都很强但计算、排序、格式严谨场景容易出错同样的提示多次生成会有差异。而代码执行正好互补。官方原文里有一句话很重要PDF skill 里有个 Python 脚本用于读取 PDF 并提取所有表单字段Claude 可以运行这个脚本而不需要把脚本本身或者 PDF 内容加载进上下文。In the PDF skill shown below, theSKILL.mdrefers to two additional files (reference.mdandforms.md) that the skill author chooses to bundle alongside the coreSKILL.md. By moving the form-filling instructions to a separate file (forms.md), the skill author is able to keep the core of the skill lean, trusting that Claude will readforms.mdonly when filling out a form.这句话背后透露了代码执行的优势脚本文件本身不进上下文上下文只出现一句命令脚本源代码不塞进 prompt节省大量 token大文件PDF也不必全文进上下文脚本在沙箱中直接操作文件只把结构化结果返回给 AI确定性保证同样的输入永远产生同样的输出工作流一致且可重复效率提升重 IO、重计算的部分交给脚本省 token、提速、更稳定适合写成脚本的典型任务排序/过滤/统计用生成文本排序数百条记录既慢又可能错脚本一次 sort/filter/groupby 搞定复杂文件/目录操作扫描代码库统计语言比例、合并 Markdown、CSV 转 JSON多步流水线任务npm install npm run lint npm test这种 CI/CD 流程调用第三方命令行工具pdftotext、ffmpeg、git、exiftool 等技术核心关键文件系统加载 - Skill 文件被复制到代码执行容器的/skills/{directory}/目录 - 文件已就绪但完整内容不会自动读取到上下文 - Claude 可通过 bash 或 Python 代码随时访问这些文件自动触发机制 - Claude 基于任务描述与 Skill 的description字段进行语义匹配 - 无需用户显式调用如/use-skill xxx - 匹配成功后自动加载 Level 2 和 Level 3 内容多技能组合 - 一个请求可同时使用多个 Skills最多 8 个 - Skills 之间可以自然组合无需预定义交互逻辑 - 例如xlsxSkill → 自定义分析 Skill →pptxSkill 的工作流四、过往架构对比4.1 与 Prompt 对比为什么这种架构可以解决上下文爆炸问题传统方法的问题# 传统方式将所有指令都加载到上下文 system_prompt 你是一个助手。 # 品牌指南5000 tokens ...完整的品牌指南内容... # 数据分析流程3000 tokens ...完整的分析流程... # 代码审查标准4000 tokens ...完整的审查标准... # 其他 10 个技能30000 tokens ... # 总计42000 tokens 始终占用上下文 # 即使当前任务只需要其中一个技能Skills 的解决方案# Skills 方式渐进式加载 初始上下文Level 1 - Metadata - 品牌指南 Skillname description~100 tokens - 数据分析 Skillname description~100 tokens - 代码审查 Skillname description~100 tokens - 其他 10 个 Skills各 ~100 tokens # 总计仅 ~1,300 tokens13 个 Skills 的元数据 当用户请求 生成品牌文档 时 → Claude 识别需要品牌指南 Skill → 系统动态加载该 Skill 的 Level 2指令层~5000 tokens → 其他 12 个 Skills 依然只占用元数据空间Level 1 # 实际上下文1,300 5,000 6,300 tokens # 相比传统方式42,000 tokens节省了 85% 的上下文这种架构的优势理论上无限的技能数量未激活的 Skill 几乎不占空间减少噪音干扰无关技能的详细内容不会干扰 Claude 的推理提高推理质量更多的上下文空间用于任务本身节省成本更少的 token 消耗对比项普通 PromptSkills 机制每次都要重新描述是否只描述一次上下文长度占用每次全量塞入渐进式加载只在触发时才读完整内容一致性依赖每次 prompt 质量高固定 SOP 模板复用性手动复制粘贴自动匹配 / slash 命令 / 项目共享维护方式改一次 prompt 就要重新发修改 SKILL.md 文件全局/项目生效Skills 和传统的 Prompt 最大的区别是按需加载渐进式披露只有在需要时才加载进上下文极大节约Token。4.2 与 MCP 对比Skills 与 MCP 是互补关系不是替代关系。Skills 解决「怎么做」方法论/工作流MCP 解决「连到哪儿」连接外部系统。对比维度SkillsMCP设计目标封装人类工作流和领域知识为可复用指令为 LLM 调用外部工具提供统一接口触发机制自动检测无需显式调用代理通过协议显式调用函数配置复杂度创建文件夹和 Markdown 文件无运行时服务需部署 MCP 服务器编写 JSON 配置Token 效率渐进披露初始开销极小通常需预加载 API 文档消耗数千 tokens执行环境完全在 Claude 沙箱内运行外部服务器执行返回结果给 Claude安全模型运行用户安装的受信任代码通过权限控制外部资源访问适用场景嵌入专业知识和内部流程连接实时数据源和遗留系统Skills 方法论层 / 能力层把一套业务流程、写作规范、分析步骤封装成一个可复用的“数字 SOP 小脚本工具箱”完全在 Claude 环境里跑。MCP 协议层 / 基础设施层提供一个标准接口让任何 LLM 可以通过统一协议访问外部系统数据库、GitHub、ERP、SaaS、IoT…。如果把 AI 体系想象成一栋楼MCP 一楼机房负责「水电气网」接进来各种外部系统和工具Skills 楼上的办公室负责「大家具体怎么用这些资源干活」流程、规范、组合动作Skills 可以是本地文件夹里的“能力包”形态上非常朴素一个文件夹 一堆文本/脚本。my-reporting-skill/ ├── SKILL.md # 说明书 大提示词 流程 ├── scripts/ # Python / Bash 等脚本 ├── references/ # 参考文档SOP、模板、规范 └── assets/ # 其他资源图标、示例文件等核心文件SKILL.md前面是 YAML名字、描述、允许用哪些工具后面是详细的自然语言流程说明。scripts/ 里的代码由 AI 通过 Bash 或 code-execution 工具在沙箱里执行用来做确定性的事情解析 PDF、排序、跑测试等。没有任何“服务端进程”就是纯文件结构放在~/.claude/skills/、Claude Code 项目目录或通过 API 上传即可生效。MCP 则完全是另一种设计思路它是一个开放协议JSON-RPC 2.0Host宿主LLM 应用比如 Claude Code、某个 Agent 框架Client客户端宿主里的 MCP 客户端Server服务器对接具体系统的 MCP 服务如 GitHub、数据库、CRM。在触发和调用机制上Skills 偏向自动感知而 MCP 则是显式调用。Skills 靠 “描述匹配” 自动激活。会话一开始AI 拿到的是所有技能的名字 一句话描述清单大概只几十几百 token几乎不占上下文。当用户提出一个任务时AI 会“读懂”需求然后自己判断“这个更像 PDF 处理技能”、“这个更像 财报撰写技能”。于是触发对应 Skill加载它的SKILL.md再根据里面写好的流程决定是否调用脚本、读参考文件等。而对 MCP 来说每个外部能力基本就是一个工具函数像github.listPullRequests(repoxxx)、erp.createInvoice(...)之类。LLM / Agent 在推理过程中如果判断需要某个工具就会构造一个call_tool请求客户端用 JSON‑RPC 发给对应的 MCP Server再拿回结果。所以 MCP 侧更像传统 “函数调用系统 RPC 协议”谁调用哪个工具是一步一步显式决策出来的。4.3 与传统 Agent 架构对比先给一个直观类比传统 Agent 很多“不同员工”协作Skills 一个“核心员工”根据场景换不同身份。维度传统多 Agent 架构Skills 架构架构一个总控 Agent 下挂一堆子 Agent写代码的、查资料的、出报告的……只有一个 Agent按需加载不同的 Skill通信子 Agent 之间要传消息、切上下文、协调工具使用技能本身是文件按需加载无需进程间通信复杂度高多进程、消息传递、状态同步低单 Agent 文件系统灵活性每个 Agent 专精一个领域一个 Agent 通过换 Skill 扮演不同角色LangChain 的架构文章甚至把 Skills 叫作一种“轻量级、单 Agent 版的 quasi-multi-agent 架构”只用一个 Agent就拿到了多 Agent 的好处多角色、多专长、分工清晰但没有那么多进程和消息传递负担。LangChain 讲解 Skills 原文插图先回顾一下传统 Agent 架构一般怎么做单体大 Agent一个超长 system prompt一堆工具。最早一代的做法是一个 Agent系统提示词里一次性写进角色定义你是一个资深 XXX 专家工作流程先问需求、再列计划、再执行所有工具/接口怎么用还有若干“风格要求”“公司背景”...但问题是prompt 越写越长一点点规范都往里塞最终变成“提示垃圾场”prompt sludge维护起来也很困难想改一个流程就要动整段大提示同时不同项目、不同团队之间难以复用token消耗还会因巨长的上下文而无意义增大。后来大家开始搞 Multi-Agent 架构一个总控 多个专职 Agent。Orchestrator Agent负责理解用户目标决定把任务拆成哪些步骤。决定每一步交给哪个子 Agent 做。多个子 Agent“规划 Agent”只负责写计划“执行 Agent”根据计划做具体动作“评审 Agent”只负责检查和打分甚至加入更多的UI 文案 Agent、法务 Agent、财务 Agent 等等。这个架构很强但问题也很明显路由与编排逻辑复杂要写一大堆“如果是XX任务就交给XX Agent” 的规则要设计消息格式、上下文裁剪、错误恢复。上下文切换成本高每个 Agent 有自己的 system prompt 和 context信息在多个 Agent 间来回传递时要不断摘要、压缩、转译容易丢信息和变形。很难沉淀经验每个 Agent 虽然能访问外部记忆向量库、数据库但工作方法本身往往还是写在各自 prompt 里。结果就是新加一个 Agent 就要重新写一套怎么干活的 prompt导致多个团队重复造轮子。Anthropic 的研究员曾经就在采访里吐槽过“今天很多 Agent 聪明但失忆每次任务都像从头来一遍不会真正变成越干越熟的老员工。”而 Skills 的出现很好地解决了传统 Agent 的问题用户不再需要为“每个业务线”单独造一个 Agent而是只有一个 Agent但它可以需要写合同时 → 加载“合同起草 Skill”需要审代码时 → 加载“代码评审 Skill”需要写财报时 → 加载“财报生成 Skill”每个 Skill 就是一个“小专长”而不是一个独立 Agent 进程。技术上Skills 像动态 persona 工作流的组合。LangChain / builder.io 在这一点上总结得很形象传统多 Agent 相当于是换 Agent 换一个完全独立的“人格 工具配置 环境”而Skills 模式相当于不换 Agent只给当前这个 Agent 换“角色手册”。所以你可以把 Skill 理解成一个可插拔的“角色配置 操作手册 工具调用套路”在需要时临时加载进当前 Agent 的上下文让它戴上一顶特定的专业帽子。但也并不是说 Skills 就会完全颠覆和替代 Agent业界还是存在几个共识的必须多Agent的场景需要“物理隔离”的场景某些任务需要严格不同的权限配置只读 vs 可写生产环境某个安全敏感模块必须跑在隔离环境不能跟别的逻辑混在一起此时用独立 Agent 独立工具配置更安全。需要完全不同模型或推理策略规划 Agent 用大模型、温度低、思考步长长执行 Agent 用便宜模型、温度高追求速度评审 Agent 用最贵模型只做关键环节质量把关。任务之间需要非常干净的上下文隔离比如安全审计、红队演练、法务审查等不希望被之前聊天内容污染这类用独立 Agent 比在同一个 Agent 里换 Skill 更干净。在这方面builder.io 的总结很实用默认先用 Skills 扩展你现有的 Agent只有当你遇到需要换模型、需要强权限隔离、上下文实在被污染等问题时再考虑上新的Agent或子Agent。五、Skill 市场与资源平台平台链接特点skills.shThe Agent Skills DirectoryVercel 推出实时热度排名SkillsmpAgent Skills 市场 - Claude、Codex 和 ChatGPT Skills | SkillsMP资源总量超 53 万中文界面Skill Hub 腾讯云SkillHub-专为中国用户优化的Skills社区基于 OpenClaw 生态本土化Agent Skills 官方标准Agent Skills Overview - Agent Skills跨平台开放标准Anthropic 官方 GitHubhttps://github.com/anthropics/skills官方示例仓库Awesome Claude Skillshttps://github.com/ComposioHQ/awesome-claude-skills16.5k Stars300 高质量 SkillVS Code Copilot SkillsUse Agent Skills in VS Code微软官方文档ModelScope魔搭社区ModelScope - Skills 技能中心中国最大的开源模型社区六、参考资料1. Anthropic 官方博客Equipping agents for the real world with Agent Skills2. 知乎专栏 2026开年新概念 - 万字讲清 Skills3. 机器之心 / AITNT疯狂的Skill4. 腾讯云开发者Skill到底是什么从「同事.skill」爆火说起5. 个人博客Anthropic Agent Skills 完整指南6. 菜鸟教程Skills 教程 — AI Agent Skills 入门与实战7. agentskills.ioAgent Skills 开放标准8. LangchainChoosing the Right Multi-Agent Architecture9. ClaudeClaude can now create and edit files10. LangchainClaude Agent Skills: A First Principles Deep Dive11. Anthropic GitHubSkills 官方仓库12. 知乎专栏Skill 入门全面介绍13. SkillsmpSkills 市场14. ModelScope魔搭社区Skills 中心
SKILL 介绍
目录一、Skills 起源和发展1.1 疯狂的Skill从极客玩笑到全网刷屏1.2 Skill 的起源二、Skills 的核心原理与架构机制2.1 什么是 Skills2.2 Skills 的核心结构2.3 三层渐进式披露架构三、Skills 如何参与运行3.1 上下文窗口动态变化过程3.2 Skills 的代码执行能力混合 LLM 推理与代码执行四、过往架构对比4.1 与 Prompt 对比4.2 与 MCP 对比4.3 与传统 Agent 架构对比五、Skill 市场与资源平台六、参考资料一、Skills 起源和发展1.1 疯狂的Skill从极客玩笑到全网刷屏在2026年4月的这段时间科技圈的目。光被 GitHub 上的一个开源项目所吸引。有人在 GitHub 上发布了一个名为「同事.skill」的项目所吸引该项目生成只要提供某位同事的飞书聊天记录、钉钉文档、微信聊天记录和工作邮箱作为原材料系统就能通过AI技术生成一个可替代该同事工作的数字分身。其slogan充满赛博朋克的慈悲「将冰冷的离别化为温暖的 Skill欢迎加入赛博永生。」这个看似荒诞的项目却在短短5天内狂揽了6.6k颗星截至本文章写作时间为止已经收获了18.9k颗星。随后这股风潮迅速破圈蔓延至各大社交平台。紧接着迎来了一场「蒸馏」狂欢各种脑洞大开的变种项目层出不穷。从「前任.skill」、「导师.skill」、「暗恋对象.skill」一路发展到「老板.skill」甚至「自己.skill」。随后skill 便彻底爆火出圈被全网刷屏。1.2 Skill 的起源开年爆火的Skill其实早在去年就已出现这项技术也是经历了典型的技术扩散轨迹2025年10月Anthropic 发布 Agent Skill彼时仅限于开发者小范围关注2025年11~12月技能规范开放生态迅速扩展2025年12月18日Anthropic 将 Skills 规范开源为开放标准交由 Linux 基金会管理标志 Skills 从单一产品功能演变为行业通用标准2026年1月产品更新叠加非编程场景落地触发病毒式传播2026年4月「同事.skill」项目在 GitHub 爆火5 天 6.6k StarsSkills 从技术圈破圈至大众2025年10月16日Anthropic 在一篇名为Equipping agents for the real world with Agent Skills为现实世界的特工装备特工技能的文章中正式提出 Agenyt Skills 概念。2025年10月16日Anthropic 在一篇名为 Equipping agents for the real world with Agent Skills 的文章中正式提出 Agenyt Skills 概念。文章开头便引出Claude 模型很强大但真正的落地还需要特定的组织框架、业务流程以及实际生产知识。为此我们推出 Agent Skills 这样一个可以直接利用公司内部文件的新生产方式”Claude is powerful, but real work requires procedural knowledge and organizational context. Introducing Agent Skills, a new way to build specialized agents using files and folders.可见Agent Skills 旨在解决通用AI只懂原理却不会干活的核心痛点。传统 AI Agent 存在三大痛点痛点表现Skills 的解法Prompt 重复编写每次都要从头教 AI 怎么做事写一次永久复用结果不稳定依赖每次 prompt 质量输出不一致固定 SOP 模板保证一致性工具对接繁琐MCP/Tools 只提供能力不告诉 AI 何时用、怎么组合把「何时用、怎么组合」写进 SKILL.md传统大模型虽然可以生成代码或文本但缺乏对特定组织架构、业务流程和品牌规范的深层理解。例如DeepSeek 虽能编写代码却不知道开发团队的具体技术栈Kimi 能生成分析报告但无法理解企业独特的财务审批链条。通俗一点来说原本的通用 Agent 是公司新招来的某个行业专家即使能力再强也需要一段 landing 期来熟悉公司内部的业务推进方式、审批流程甚至是部门间微妙的人际关系。而一个 skill 就是为这个新入职员工建立的入职手册和原有业务文档。Skills 原理图2025年12月18日Anthropic 将 Skills 规范开源为开放标准并交由 Linux 基金会管理。这标志着 Skills 从单一产品功能演变为行为通用标准与 MCP 形成互补生态。二、Skills 的核心原理与架构机制2.1 什么是 Skills简单来说Skills 就是“完成特定任务的标准化、可复用流程”它不是一种单一的能力而是一套“能直接用、能重复用、还能不断优化的具体方法”。Skills 并不是新能力而是“新边界”。它并没有让AI 变得更聪明它只是让 AI 变得可控。Skills 跟我们之前惯用的 Prompt 是共存关系Prompt 描述的是「意图想做什么」Skills 决定「执行流程怎么做」。简单来说Prompt 就是来描述我要 大模型 做的事情比如写一个贪吃蛇的小游戏大模型 Get 到我们的意图后尝试用自己的认知去实操而 Skills 则可以理解为说明书大模型可以参考贪吃蛇游戏开发说明书进行开发效果比大模型自己实操效果更好。Skills 本质上就是教 AI 按照固定流程做事的操作说明书一旦写好就能像函数一样反复调用。Skills 可以看成「把某件事应该怎么专业做」这件事封装成一个可复用、可自动触发的能力模块。2.2 Skills 的核心结构Skills 的核心结构就是一个文件夹一个 SKILL.md 文件。SKILL.md 文件包含元数据至少要有名称和描述告诉 AI 如何完成某一特定任务的指令一个 Skill 本质上就是一个 Markdown 文件文件名固定为 SKILL.mdmy-skill/ └── SKILL.md 唯一必需YAML Frontmatter必填元数据--- name: pdf-processing # 必填最长 64 字符小写字母数字连字符 description: - # 必填最长 1024 字符最关键的一行 从 PDF 中提取文本和表格填写表单并合并文档。 触发场景处理 PDF、提取文字、填写表单 license: Apache-2.0 # 可选 compatibility: 需要 Python 3.8 # 可选最长 500 字符 metadata: # 可选自定义键值对 author: your-name version: 1.0 allowed-tools: bash read # 可选允许使用的工具列表 trigger_keywords: # 可选提升自动触发率 - PDF - 填表单 - 提取文字 ---Markdown 正文指令部分# PDF 处理 ## 使用场景 当需要对 PDF 文件进行操作时使用例如 - 提取 PDF 文本或表格数据 - 填写 PDF 表单 - 合并多个 PDF 文件 ## 提取文本 - 使用 pdfplumber 提取文本型 PDF 内容 - 扫描版 PDF 需配合 OCR 工具 ## 填写表单 1. 调用 Bash 工具执行 python {baseDir}/scripts/extract_form_fields.py --input $PDF_PATH --output form_fields.json 2. 读取 form_fields.json解析字段信息 3. 根据用户需求填写并生成新文件 ## 参考资料 - 表单填写规则见 forms.md - 品牌视觉规范见 brand-guide.pdf完整目录结构示例~/.claude/skills/react-component-review/ ├── SKILL.md # 核心指令 元数据建议控制在 400 行内 ├── templates/ # 常用模板AI 按需读取 │ ├── functional.tsx.md │ └── class-component.md ├── examples/ # 优秀/反例给 AI 看标准 │ ├── good.md │ └── anti-pattern.md ├── references/ # 规范、规则、禁用词表 │ ├── hooks-rules.md │ └── naming-convention.md └── scripts/ # 可执行脚本 ├── validate-props.py └── check-cycle-deps.sh在 SKILL.md 中引用方式需要给出标准函数组件时参考templates/functional.tsx.md的结构如果违反 Hooks 规则对照references/hooks-rules.md第 3-5 条说明如需校验 propTypes可执行scripts/validate-props.py {代码片段}AI 看到路径引用后会按需加载对应文件而不是一次性全部塞入上下文。字段必需说明name是Skill 名称最长 64 字符只能使用小写字母、数字和-且不能以-开头或结尾description是功能与使用场景说明最长 1024 字符不能为空license否许可证名称或指向随 Skill 附带的许可证文件compatibility否环境与依赖说明产品、系统包、网络权限等最长 500 字符metadata否自定义键值对用于扩展元数据如作者、版本号allowed-tools否允许使用的工具列表空格分隔实验性功能如果你需要一些参考资料参考实例执行脚本可以使用更复杂 Skill 的目录结构my-skill/ ├── SKILL.md # 必需指令 元数据 ├── scripts/ # 可选可执行代码 ├── references/ # 可选文档资料 └── assets/ # 可选模板、资源2.3三层渐进式披露架构为真正了解 Skills 的核心原理和架构机制可以参考 Anthropic 最初发布的Equipping agents for the real world with Agent Skills里面The anatomy of a skill 部分清晰明了地介绍了 Skills 的原理架构。利用开头提到的新员工landing方式来更通俗的讲解核心概念给 AI 一本工作手册想象你招了一个超级聪明的实习生但 TA 刚入职时懂通用知识但不知道公司的具体流程会写代码但不懂组里的技术规范能分析数据但不知道具体的业务逻辑Skills 就可以理解为给这位实习生准备的 Landing 文档。这个过程不是重新训练 AI 而是把特定领域的操作指南、工具脚本、参考资料打包成文件夹让 TA 在需要时查找学习然后立刻执行。在架构上Skills 采用三层渐进式披露架构Progressive Disclosure渐进式加载Progressive Disclosure是 Skills 区别于传统 Prompt 的最关键设计也是 Skills 最精妙的架构。-- 第一层目录索引元数据metadata每次对话开始时AI只看目录包括技能名称最多64字符和一句话描述最多1024字符。就像这位新入职的实习生刚接到一个新需求时先翻一下组内知识库的目录判断和手头上的项目有没有关系以此来看需不需要打开查看详细步骤。这一层只占用约100个tokenAI可以同时知道几百个技能的存在并且不增加任何负担。-- 第二层详细步骤SKILL.md当 AI 通过 metadata 判断这个任务需要某个 Skill 时它会调用 Bash 工具读取选中的 SKILL.md将其中的完整指令加载到上下文中到这一步AI才真正学会如何具体操作。在写SKILL.md时需要注意一些技术细节文件采用YAML前导格式类似简历开头的个人信息区包含 name、description 等元数据也就是上面提到的第一层主体是 Markdown 格式的详细指令Skills 以 Markdown 文件形式存在不执行功能而是通过按需、渐进式加载实现高效且可复用的经验传递。-- 第三层参考资料链接文件在真实工作场景下主手册往往会放不下太复杂的情况类似于我们平时在公司都没时间看的文档比如各种表单填写规则forms.md品牌视觉规范brand-guide.pdf代码示例库examples.py而AI只会在特定子任务时才去读取这些文件。比如填表时才看 forms.md做数据分析时忽略它。一个简单的 SKILL.md 文件示例层级内容触发时机Token 消耗第一层目录索引每个 Skill 的 name description元数据始终可见启动时预加载~100第二层详细步骤完整的 SKILL.md 正文指令技能相关时加载~1,500第三层参考资料附件文件scripts/references/assets必要时按需加载按需三、Skills 如何参与运行3.1 上下文窗口动态变化过程这里的上下文窗口可以理解为 AI 调用每一层 Skills 的触发时机这里我们沿用 Anthropic 举的让 Claude 填写 PDF 表单的例子。技能会在上下文窗口中通过系统提示符触发。阶段 1初始状态对应第一层 Skills[系统提示] [所有技能目录] [用户消息] ↑ 用 PDF 技能填写这份合同AI 看到「PDF 技能」的描述判断出需要详细操作手册。阶段 2加载主手册对应第二层[系统提示] [技能目录] [用户消息] [SKILL.md 完整内容] ↑ 明白了先读取 PDF再识别表单字段然后填写阶段 3按需加载子手册对应第三层[系统提示] [技能目录] [用户消息] [SKILL.md] [forms.md] ↑ 这个表单看起来像 W-9 税务表按照 forms.md 的特殊规则处理阶段 4执行任务[系统提示] [技能目录] [用户消息] [SKILL.md] [forms.md] [执行结果] ↑ 已填写完毕请检查整个过程中AI 不会一次性加载所有 PDF 技能相关的 10,000 tokens 资料而是像人类一样边做边学token 消耗量降低 70-90%。3.2 Skills 的代码执行能力混合 LLM 推理与代码执行Skills 不仅是 YAML 和 Markdown 格式的文档还可以包含提前写好的可执行代码。这极大地保证了 Skills 的稳定运行。Skills 本身不是可执行代码。一个 Skill 的核心是 SKILL.md一份大提示词 说明书它不会自己跑 Python 或 JavaScript。真正跑代码的主体仍然是 AI 的工具系统Bash、code executionSkills 只是告诉 AI「在某一步请用 Bash 去执行某个脚本然后再根据结果继续推理。」一份涉及到代码的标准 Skill 目录大致是这样my-skill/ ├── SKILL.md # 说明书主提示词 ├── scripts/ # 这里放可执行脚本Python / Bash 等 │ └── helper.py ├── references/ # 需要读进上下文的文档 └── assets/ # 模板、二进制文件等只按路径引用其中 scripts/ 里放的是要执行的代码典型用途数据解析、转换如分析代码库、清洗日志跑各种命令行工具git、npm、pdftotext做复杂、多步骤、对结果要求100%确定的操作Skill 里诸如 python {baseDir}/scripts/analyzer.py.... 这样的命令来引用脚本。{baseDir}是一个自动替换的变量表示当前这个 Skill 在本地的安装路径这样技能可以在不同机器、不同项目路径下通用不用写死绝对路径。AI 如何决定要跑哪个脚本呢这一步需要 LLM 自己读描述做匹配。对话一开始时AI 只看到了所有的 Skills 的 name description 列表存在 Skill 工具的描述中当用户提出任务例如提取PDF表单AI 会自动根据描述选择匹配的对应的 Skill一旦选中了某个 Skill系统会把 SKILL.md 整个读出来作为一段新的指令注入对话隐藏在元消息中在这份指令里用户会提前写好类似如下内容当需要抽取 PDF 表单字段时 - 调用 Bash 工具执行 python {baseDir}/scripts/extract_form_fields.py --input $PDF_PATH --output form_fields.json - 执行完后读取 form_fields.json解析其中的字段信息再根据用户需求进行后续处理当 AI 读到这段 Markdwon再结合当前任务就会在下一步工具调用中发起一个 Bash 调用例如{ tool: bash_code_execution, input: { command: python /home/user/.claude/skills/pdf/scripts/extract_form_fields.py --input \contract.pdf\ --output form_fields.json } }Bash 工具真的在沙箱里跑这条命令执行脚本回传命令执行结果output form_fields.json。AI 再读取 form_fields.json用自己的自然语言能力理解这些结果继续完成后续推理与回答。Skills 能够保证一致性和稳定性的核心原因是混合执行模式Hybrid Execution—— 将 LLM 的语言理解能力与代码的可靠执行相结合。Skills 的关键优势在于 Efficient script execution高效脚本执行和 Reliability可靠性而非单纯的 “确定性”。这种设计确保了- Efficient高效脚本代码不进入上下文只有输出消耗 tokens- Reliable可靠相同输入产生一致的结果减少 LLM 生成的随机性- Consistent一致通过代码执行而非 LLM 生成来保证格式和计算的准确性代码执行的运作流程用户提出任务 ↓ AI 读取 SKILL.md发现需要执行脚本 ↓ AI 通过 Bash 工具执行命令如 python {baseDir}/scripts/analyzer.py ... ↓ 脚本在沙箱中运行处理文件、调用 API 等 ↓ 脚本输出结构化结果如 JSON ↓ AI 读取结果继续推理和生成回答用「确定性代码」补足「随机性模型」LLM 有两个天然相反的特性理解、推理、生成都很强但计算、排序、格式严谨场景容易出错同样的提示多次生成会有差异。而代码执行正好互补。官方原文里有一句话很重要PDF skill 里有个 Python 脚本用于读取 PDF 并提取所有表单字段Claude 可以运行这个脚本而不需要把脚本本身或者 PDF 内容加载进上下文。In the PDF skill shown below, theSKILL.mdrefers to two additional files (reference.mdandforms.md) that the skill author chooses to bundle alongside the coreSKILL.md. By moving the form-filling instructions to a separate file (forms.md), the skill author is able to keep the core of the skill lean, trusting that Claude will readforms.mdonly when filling out a form.这句话背后透露了代码执行的优势脚本文件本身不进上下文上下文只出现一句命令脚本源代码不塞进 prompt节省大量 token大文件PDF也不必全文进上下文脚本在沙箱中直接操作文件只把结构化结果返回给 AI确定性保证同样的输入永远产生同样的输出工作流一致且可重复效率提升重 IO、重计算的部分交给脚本省 token、提速、更稳定适合写成脚本的典型任务排序/过滤/统计用生成文本排序数百条记录既慢又可能错脚本一次 sort/filter/groupby 搞定复杂文件/目录操作扫描代码库统计语言比例、合并 Markdown、CSV 转 JSON多步流水线任务npm install npm run lint npm test这种 CI/CD 流程调用第三方命令行工具pdftotext、ffmpeg、git、exiftool 等技术核心关键文件系统加载 - Skill 文件被复制到代码执行容器的/skills/{directory}/目录 - 文件已就绪但完整内容不会自动读取到上下文 - Claude 可通过 bash 或 Python 代码随时访问这些文件自动触发机制 - Claude 基于任务描述与 Skill 的description字段进行语义匹配 - 无需用户显式调用如/use-skill xxx - 匹配成功后自动加载 Level 2 和 Level 3 内容多技能组合 - 一个请求可同时使用多个 Skills最多 8 个 - Skills 之间可以自然组合无需预定义交互逻辑 - 例如xlsxSkill → 自定义分析 Skill →pptxSkill 的工作流四、过往架构对比4.1 与 Prompt 对比为什么这种架构可以解决上下文爆炸问题传统方法的问题# 传统方式将所有指令都加载到上下文 system_prompt 你是一个助手。 # 品牌指南5000 tokens ...完整的品牌指南内容... # 数据分析流程3000 tokens ...完整的分析流程... # 代码审查标准4000 tokens ...完整的审查标准... # 其他 10 个技能30000 tokens ... # 总计42000 tokens 始终占用上下文 # 即使当前任务只需要其中一个技能Skills 的解决方案# Skills 方式渐进式加载 初始上下文Level 1 - Metadata - 品牌指南 Skillname description~100 tokens - 数据分析 Skillname description~100 tokens - 代码审查 Skillname description~100 tokens - 其他 10 个 Skills各 ~100 tokens # 总计仅 ~1,300 tokens13 个 Skills 的元数据 当用户请求 生成品牌文档 时 → Claude 识别需要品牌指南 Skill → 系统动态加载该 Skill 的 Level 2指令层~5000 tokens → 其他 12 个 Skills 依然只占用元数据空间Level 1 # 实际上下文1,300 5,000 6,300 tokens # 相比传统方式42,000 tokens节省了 85% 的上下文这种架构的优势理论上无限的技能数量未激活的 Skill 几乎不占空间减少噪音干扰无关技能的详细内容不会干扰 Claude 的推理提高推理质量更多的上下文空间用于任务本身节省成本更少的 token 消耗对比项普通 PromptSkills 机制每次都要重新描述是否只描述一次上下文长度占用每次全量塞入渐进式加载只在触发时才读完整内容一致性依赖每次 prompt 质量高固定 SOP 模板复用性手动复制粘贴自动匹配 / slash 命令 / 项目共享维护方式改一次 prompt 就要重新发修改 SKILL.md 文件全局/项目生效Skills 和传统的 Prompt 最大的区别是按需加载渐进式披露只有在需要时才加载进上下文极大节约Token。4.2 与 MCP 对比Skills 与 MCP 是互补关系不是替代关系。Skills 解决「怎么做」方法论/工作流MCP 解决「连到哪儿」连接外部系统。对比维度SkillsMCP设计目标封装人类工作流和领域知识为可复用指令为 LLM 调用外部工具提供统一接口触发机制自动检测无需显式调用代理通过协议显式调用函数配置复杂度创建文件夹和 Markdown 文件无运行时服务需部署 MCP 服务器编写 JSON 配置Token 效率渐进披露初始开销极小通常需预加载 API 文档消耗数千 tokens执行环境完全在 Claude 沙箱内运行外部服务器执行返回结果给 Claude安全模型运行用户安装的受信任代码通过权限控制外部资源访问适用场景嵌入专业知识和内部流程连接实时数据源和遗留系统Skills 方法论层 / 能力层把一套业务流程、写作规范、分析步骤封装成一个可复用的“数字 SOP 小脚本工具箱”完全在 Claude 环境里跑。MCP 协议层 / 基础设施层提供一个标准接口让任何 LLM 可以通过统一协议访问外部系统数据库、GitHub、ERP、SaaS、IoT…。如果把 AI 体系想象成一栋楼MCP 一楼机房负责「水电气网」接进来各种外部系统和工具Skills 楼上的办公室负责「大家具体怎么用这些资源干活」流程、规范、组合动作Skills 可以是本地文件夹里的“能力包”形态上非常朴素一个文件夹 一堆文本/脚本。my-reporting-skill/ ├── SKILL.md # 说明书 大提示词 流程 ├── scripts/ # Python / Bash 等脚本 ├── references/ # 参考文档SOP、模板、规范 └── assets/ # 其他资源图标、示例文件等核心文件SKILL.md前面是 YAML名字、描述、允许用哪些工具后面是详细的自然语言流程说明。scripts/ 里的代码由 AI 通过 Bash 或 code-execution 工具在沙箱里执行用来做确定性的事情解析 PDF、排序、跑测试等。没有任何“服务端进程”就是纯文件结构放在~/.claude/skills/、Claude Code 项目目录或通过 API 上传即可生效。MCP 则完全是另一种设计思路它是一个开放协议JSON-RPC 2.0Host宿主LLM 应用比如 Claude Code、某个 Agent 框架Client客户端宿主里的 MCP 客户端Server服务器对接具体系统的 MCP 服务如 GitHub、数据库、CRM。在触发和调用机制上Skills 偏向自动感知而 MCP 则是显式调用。Skills 靠 “描述匹配” 自动激活。会话一开始AI 拿到的是所有技能的名字 一句话描述清单大概只几十几百 token几乎不占上下文。当用户提出一个任务时AI 会“读懂”需求然后自己判断“这个更像 PDF 处理技能”、“这个更像 财报撰写技能”。于是触发对应 Skill加载它的SKILL.md再根据里面写好的流程决定是否调用脚本、读参考文件等。而对 MCP 来说每个外部能力基本就是一个工具函数像github.listPullRequests(repoxxx)、erp.createInvoice(...)之类。LLM / Agent 在推理过程中如果判断需要某个工具就会构造一个call_tool请求客户端用 JSON‑RPC 发给对应的 MCP Server再拿回结果。所以 MCP 侧更像传统 “函数调用系统 RPC 协议”谁调用哪个工具是一步一步显式决策出来的。4.3 与传统 Agent 架构对比先给一个直观类比传统 Agent 很多“不同员工”协作Skills 一个“核心员工”根据场景换不同身份。维度传统多 Agent 架构Skills 架构架构一个总控 Agent 下挂一堆子 Agent写代码的、查资料的、出报告的……只有一个 Agent按需加载不同的 Skill通信子 Agent 之间要传消息、切上下文、协调工具使用技能本身是文件按需加载无需进程间通信复杂度高多进程、消息传递、状态同步低单 Agent 文件系统灵活性每个 Agent 专精一个领域一个 Agent 通过换 Skill 扮演不同角色LangChain 的架构文章甚至把 Skills 叫作一种“轻量级、单 Agent 版的 quasi-multi-agent 架构”只用一个 Agent就拿到了多 Agent 的好处多角色、多专长、分工清晰但没有那么多进程和消息传递负担。LangChain 讲解 Skills 原文插图先回顾一下传统 Agent 架构一般怎么做单体大 Agent一个超长 system prompt一堆工具。最早一代的做法是一个 Agent系统提示词里一次性写进角色定义你是一个资深 XXX 专家工作流程先问需求、再列计划、再执行所有工具/接口怎么用还有若干“风格要求”“公司背景”...但问题是prompt 越写越长一点点规范都往里塞最终变成“提示垃圾场”prompt sludge维护起来也很困难想改一个流程就要动整段大提示同时不同项目、不同团队之间难以复用token消耗还会因巨长的上下文而无意义增大。后来大家开始搞 Multi-Agent 架构一个总控 多个专职 Agent。Orchestrator Agent负责理解用户目标决定把任务拆成哪些步骤。决定每一步交给哪个子 Agent 做。多个子 Agent“规划 Agent”只负责写计划“执行 Agent”根据计划做具体动作“评审 Agent”只负责检查和打分甚至加入更多的UI 文案 Agent、法务 Agent、财务 Agent 等等。这个架构很强但问题也很明显路由与编排逻辑复杂要写一大堆“如果是XX任务就交给XX Agent” 的规则要设计消息格式、上下文裁剪、错误恢复。上下文切换成本高每个 Agent 有自己的 system prompt 和 context信息在多个 Agent 间来回传递时要不断摘要、压缩、转译容易丢信息和变形。很难沉淀经验每个 Agent 虽然能访问外部记忆向量库、数据库但工作方法本身往往还是写在各自 prompt 里。结果就是新加一个 Agent 就要重新写一套怎么干活的 prompt导致多个团队重复造轮子。Anthropic 的研究员曾经就在采访里吐槽过“今天很多 Agent 聪明但失忆每次任务都像从头来一遍不会真正变成越干越熟的老员工。”而 Skills 的出现很好地解决了传统 Agent 的问题用户不再需要为“每个业务线”单独造一个 Agent而是只有一个 Agent但它可以需要写合同时 → 加载“合同起草 Skill”需要审代码时 → 加载“代码评审 Skill”需要写财报时 → 加载“财报生成 Skill”每个 Skill 就是一个“小专长”而不是一个独立 Agent 进程。技术上Skills 像动态 persona 工作流的组合。LangChain / builder.io 在这一点上总结得很形象传统多 Agent 相当于是换 Agent 换一个完全独立的“人格 工具配置 环境”而Skills 模式相当于不换 Agent只给当前这个 Agent 换“角色手册”。所以你可以把 Skill 理解成一个可插拔的“角色配置 操作手册 工具调用套路”在需要时临时加载进当前 Agent 的上下文让它戴上一顶特定的专业帽子。但也并不是说 Skills 就会完全颠覆和替代 Agent业界还是存在几个共识的必须多Agent的场景需要“物理隔离”的场景某些任务需要严格不同的权限配置只读 vs 可写生产环境某个安全敏感模块必须跑在隔离环境不能跟别的逻辑混在一起此时用独立 Agent 独立工具配置更安全。需要完全不同模型或推理策略规划 Agent 用大模型、温度低、思考步长长执行 Agent 用便宜模型、温度高追求速度评审 Agent 用最贵模型只做关键环节质量把关。任务之间需要非常干净的上下文隔离比如安全审计、红队演练、法务审查等不希望被之前聊天内容污染这类用独立 Agent 比在同一个 Agent 里换 Skill 更干净。在这方面builder.io 的总结很实用默认先用 Skills 扩展你现有的 Agent只有当你遇到需要换模型、需要强权限隔离、上下文实在被污染等问题时再考虑上新的Agent或子Agent。五、Skill 市场与资源平台平台链接特点skills.shThe Agent Skills DirectoryVercel 推出实时热度排名SkillsmpAgent Skills 市场 - Claude、Codex 和 ChatGPT Skills | SkillsMP资源总量超 53 万中文界面Skill Hub 腾讯云SkillHub-专为中国用户优化的Skills社区基于 OpenClaw 生态本土化Agent Skills 官方标准Agent Skills Overview - Agent Skills跨平台开放标准Anthropic 官方 GitHubhttps://github.com/anthropics/skills官方示例仓库Awesome Claude Skillshttps://github.com/ComposioHQ/awesome-claude-skills16.5k Stars300 高质量 SkillVS Code Copilot SkillsUse Agent Skills in VS Code微软官方文档ModelScope魔搭社区ModelScope - Skills 技能中心中国最大的开源模型社区六、参考资料1. Anthropic 官方博客Equipping agents for the real world with Agent Skills2. 知乎专栏 2026开年新概念 - 万字讲清 Skills3. 机器之心 / AITNT疯狂的Skill4. 腾讯云开发者Skill到底是什么从「同事.skill」爆火说起5. 个人博客Anthropic Agent Skills 完整指南6. 菜鸟教程Skills 教程 — AI Agent Skills 入门与实战7. agentskills.ioAgent Skills 开放标准8. LangchainChoosing the Right Multi-Agent Architecture9. ClaudeClaude can now create and edit files10. LangchainClaude Agent Skills: A First Principles Deep Dive11. Anthropic GitHubSkills 官方仓库12. 知乎专栏Skill 入门全面介绍13. SkillsmpSkills 市场14. ModelScope魔搭社区Skills 中心
![3分钟掌握VideoDownloadHelper：简单高效的网页视频下载插件终极指南 [特殊字符]](images/news3.jpg)
