Anthropic在25年12月18日宣布把Agent Skills 发布为开放标准，到现在刚一个多月时间里，Cursor、OpenCode、Antigrativy 等主流 AI 编程工具就已经完成了集成，GitHub 上星标也超过了 52k。
项目地址：https://github.com/anthropics/skills
刚发布那会儿我在忙着录制视频课程，一月初才来得及具体测试。起初先是跑了一遍 Reddit 和 X 上热议的几个开源项目，然后又在手头的知识库和数据治理项目里实际用了一段时间。目前用了两三周下来，整体感受是 Skills 解决的问题不新鲜（Prompt 管理、脚本复用），但它提供的抽象方式确实够简洁，一个文件夹、一份 Markdown、一套目录约定，就把让大模型记住怎么做某件事这个需求给标准化了。
市面上介绍Agent Skills 的文章不少，但大多停留在个人效率工具层面。这些玩法当然有用，但我更感兴趣的是另一个问题，就是 Skills 这套机制，在 2B 企业大模型应用里能怎么用？能不能把已有的业务脚本和工作流封装成 Skill，让非技术人员也能调用？
这篇试图说清楚：
Skill 的核心设计理念（渐进式披露）与文件规范、它与 MCP 及多 Agent 的本质区别、如何将现有项目（以数据治理工具包为例）进行 Skill 化改造，以及从投标书生成等长文档场景出发，探讨 Skill 在企业级交付中的产品化潜力。
以下，enjoy:
1
什么是 Agent Skills？
一句话定义：Agent Skills 是一套基于文件系统的 Prompt 工程化规范。说人话就是，它把让大模型记住怎么做某件事这个需求，抽象成了一个标准化的文件结构。核心我总结下来就三件事：
1、用一个文件夹来封装一个"能力"；2、用 Markdown 来描述这个能力的调用方式；3、用 YAML 头部来做索引，让大模型知道什么时候该调用
规范本身很简单，没有复杂协议，不需要 SDK，任何支持文件读取的 Agent 都能实现。
1.1
为什么需要渐进式加载
渐进式加载是 Skill 设计里最核心的理念，也是它区别于传统 Prompt 管理方式的关键。
传统做法是把所有指令都塞进 System Prompt。问题在于上下文窗口是稀缺资源。假设你有 50 个 Skill，每个 2000 tokens，全塞进去就是 10 万 tokens，大模型还没干活，上下文就爆了。
但很多人聊上下文优化，第一反应是怎么压缩、怎么摘要、怎么用 RAG 只召回相关片段。这些当然有用，但从第一性原理出发，最有效的优化其实是"非必要不传入"，也就是在源头上就把当前处理阶段模型不需要看到的内容排除掉。Skill 的渐进式加载，本质上就是这个思路的工程化落地。
Skill 的解决方案是三层按需加载：
第一层相当于一份目录索引，模型看完就知道"有哪些能力可用"。只有当用户的请求和某个 Skill 的 description 匹配的时候，大模型才会去读取完整的指令。这样 50 个 Skill 的索引加起来也就 2500-5000 tokens，完全可接受。
1.2
文件结构与 SKILL.md格式
一个Skill就是一个文件夹，核心是 SKILL.md 文件：
my-skill/├── SKILL.md # 核心：指令文件├── scripts/ # 可选：可执行脚本├── references/ # 可选：详细文档└── assets/ # 可选：配置文件、Schema 等
SKILL.md 的格式也很直接，开头是 YAML 头部，后面是 Markdown 正文：
---name: data-analysisdescription: 分析数据集并生成可视化报告，支持 CSV/Excel/JSON 格式。---# 数据分析 Skill## 使用场景...## 执行流程...
这里有个关键点：description 的质量直接决定模型能否正确匹配到这个Skill。写 description 要像写函数签名一样，说清楚输入输出和适用场景。
1.3
不只是Prompt 管理：scripts/references/assets 的价值
如果只看 SKILL.md，可能会有盆友觉得这不就是把 Prompt 放到文件里管理，意义也不是很大。确实，纯文本指令的场景下，Skill 和传统的 Prompt 模板没有本质区别。
但 Skill 的真正价值在于它可以封装完整的工作流，不只是一段提示词，而是提示词 + 可执行代码 + 参考文档 + 配置文件的组合。这让它能覆盖从简单到复杂的各种场景：
以上篇文章介绍的数据治理工具包为例，进行Skill化之后，scripts/ 里放了文档解析、格式识别、质量评估等脚本；references/ 里放了质量标签的详细说明文档；assets/ 里放了输出报告的 JSON Schema。用户只需要说"帮我扫描这个文件夹的文档质量"，模型读取 SKILL.md后知道该怎么调用脚本、怎么解读结果，整个流程一气呵成。
这就是 Skill 区别于普通 Prompt 模板的地方，它不是把复杂逻辑都塞进提示词让大模型理解，而是把执行逻辑外置到脚本、把领域知识外置到 references、把配置参数外置到 assets，SKILL.md只负责告诉模型这些东西在哪、怎么用。
1.4
发现与激活机制
Skill 的发现机制说白了就是目录扫描。Agent 启动时遍历指定目录（全局目录和项目目录），找到所有包含 SKILL.md 的文件夹，解析 YAML 头部，构建索引。（不同平台的目录约定略有差异）
全局目录放跨项目通用的 Skill，比如代码审查、文档生成；项目目录放特定项目的 Skill，比如某客户的数据治理规则。
激活流程也很简单直接：用户发消息 → 模型根据 description 判断匹配哪个 Skill → 读取完整 SKILL.md→ 按指令执行。
但有一点需要强调，就是原则上脚本代码不进入上下文，只有执行结果进入。这是上下文优化的关键。比如我在上篇文章中介绍的 RAG 入库前的文档扫描工具包，其中有 27 个 Python 脚本，全塞进 Prompt 大家要 5 万 tokens；但通过 Skill 机制，上下文只需要 SKILL.md（2000 tokens 左右）加上脚本的执行结果。
1.5
两种集成方式
Skill 有两种集成方式，选哪种取决于 Agent 的运行环境：
方式一：文件系统直读
适用于 Cursor、Claude Code 这类本地 IDE 环境。模型直接用 Shell 命令读取文件：
cat ~/.claude/skills/data-analysis/SKILL.md
这是最灵活的方式，大模型可以自主决定读取哪些内容。
方式二：通过 Tool 调用
适用于 Web 应用（例如网页端的Claude）、API 服务等没有文件系统访问权限的场景。需要封装成 Tool 供模型调用，比如通过 MCP Server 提供 list_skills、get_skill_content 等接口。
两种方式的核心逻辑一样，只是访问路径不同。对于企业级应用，工具方式更常见，因为可以做权限控制、审计日志、远程 Skill 库等。
1.6
底层实现原理
虽然大家应该主要是在 IDE 里使用 Skill，但它的底层实现并不复杂，本质就是目录扫描 + 提示词注入 + 按需加载。核心代码逻辑大约 50 行：
# 1. 启动时：扫描目录，只读取 YAML 头部（name + description）def discover_skills(skills_dir):for folder in Path(skills_dir).iterdir():skill_md = folder / "SKILL.md"if skill_md.exists():metadata = parse_frontmatter(skill_md) # 只读头部skills.append(metadata)return skills# 2. 生成索引，注入到 System Promptavailable_skills_xml = generate_xml(skills) # <available_skills>...</available_skills># 3. 运行时：模型判断需要某 Skill 时，调用工具读取完整内容if tool_name == "view_text_file":content = Path(file_path).read_text() # 此时才加载完整 SKILL.md
特别解释一下这个底层的原理，是想说明 Skill 机制不依赖任何特定 IDE，可以嵌入到任何后端服务里。大家完全可以在自己的大模型应用中实现同样的逻辑：目录扫描、元数据索引、按需加载，把 Skill 作为模块化知识与能力的封装形态。
2
官方 Skill 案例拆解：以 docx 为例
聊完核心概念，来看一个真实的 Skill 长什么样。Anthropic 在发布规范的同时，官方仓库里提供了 16 个参考实现。除此之外，GitHub 上也涌现出不少开源 Skill 库项目，热度很高。这篇我就针对官方的这 16 个 skill 做些盘点，它们按用途大致可以分成四类：
从企业应用场景出发，文档处理类的 Skill 最有参考价值。我拿 docx（Word 文档处理）来做个拆解。
2.1
docx Skill 的文件结构
docx/├── SKILL.md # 主指令文件（约 200 行）├── docx-js.md # 参考文档：docx-js 库用法├── ooxml.md # 参考文档：OOXML 格式详解├── scripts/ # Python 脚本│ ├── document.py # 文档操作库（5 万字符）│ └── utilities.py # 工具函数└── ooxml/ ├── scripts/ # unpack.py、pack.py 等 └── schemas/ # XML Schema 定义
这是一个相对重度的 Skill 结构。主指令文件 SKILL.md负责告诉大模型什么场景用什么工具，具体的技术细节则外置到 references（这个skill官方包里实际没有这个文件夹） 和 scripts 里。
2.2
SKILL.md的设计思路
打开 SKILL.md，开头是 YAML 头部：
name: docxdescription: "Comprehensive document creation, editing, and analysis with support for tracked changes, comments, formatting preservation, and text extraction. When Claude needs to work with .docx files..."
description 写得很具体，不是泛泛的处理 Word 文档，而是明确列出了能力边界：创建、编辑、分析、修订追踪、批注、格式保留、文本提取。这样大模型在匹配的时候就更精准。正文部分采用了决策树结构：
## Workflow Decision Tree### Reading/Analyzing ContentUse "Text extraction" or "Raw XML access" sections below### Creating New DocumentUse "Creating a new Word document" workflow### Editing Existing Document- Your own document + simple changes → Basic OOXML editing- Someone else's document → Redlining workflow (recommended)- Legal, academic, business docs → Redlining workflow (required)
这种设计不得不说很聪明，大模型不需要一次性理解所有内容，而是根据用户的具体需求，跳转到对应的章节。这也是渐进式披露思想在 SKILL.md 内部的应用。
2.3
脚本与参考文档的分工
SKILL.md里引用了两份核心文档：
docx-js.md：用于创建新文档，详细说明了 docx-js 这个 JS 库的用法ooxml.md：用于编辑现有文档，详细说明了 OOXML 格式和 Document 库的 API
SKILL.md里写明了加载时机：
MANDATORY - READ ENTIRE FILE: Read `ooxml.md` (~600 lines) completely from start to finish. Pay special attention to "Document Library" and "Tracked Change Patterns" sections.
注意这里说的是"completely from start to finish"，对于复杂任务，大模型需要完整阅读参考文档，而不是只看片段。这其实是在教大模型怎么使用第三层内容。
scripts目录下的 Python 代码提供了文档对象操作能力（如 document.py 提供 DOM 操作接口），而 ooxml/scripts/ 目录下则包含 unpack.py 和 pack.py 这样用于解压和重打包 docx 文件的底层工具。SKILL.md 告诉模型怎么调用这些脚本，但脚本代码本身不进入上下文。
2.4
一个典型的调用流程
假设用户说："帮我把这份合同里的'甲方'全部改成'委托方'，要有修订痕迹"
1、模型读取 SKILL.md，根据决策树判断这是"Editing Existing Document"场景2、进一步判断是"Someone else's document"，应该用 Redlining workflow3、模型读取 ooxml.md，了解如何使用 Document 库和修订追踪的 XML 格式4、执行脚本：先 unpack、再用 Python 脚本修改 XML、最后 pack5、返回修改后的文档
整个过程中，模型只需理解 SKILL.md的决策逻辑和 ooxml.md 的 API 说明，不需要看大约5万字符的 document.py源码。这就是 Skill 机制在复杂任务上的价值。
从这个官方示例可以看出，一个好的 Skill 设计核心就是把复杂度分层：description 写清楚能力边界让匹配更精准，正文用决策树结构让大模型按需跳转，执行逻辑和领域知识外置到 scripts 和 references 里。如果你在做企业大模型应用，财务报表处理、合同审核、技术文档生成这类场景，都可以参考这个结构来封装。
3
Skill vs MCP vs 多 Agent
聊完 Skill 本身，再来说说它和 MCP、多 Agent 是什么关系。这三个概念经常被混在一起讨论，但实际上解决的问题不太一样。我梳理了一个表格，尝试从下面五个维度给大家做个直观的对比：
说人话就是：
Skill 是给 Agent 写的操作手册，告诉它遇到某类任务该怎么做；MCP 是外部系统的数据接口，让 Agent 能访问数据库、API、文件系统等；多 Agent 是分工协作机制，把复杂任务拆成多个子任务交给不同 Agent 处理
https://claude.com/blog/skills-explained
从企业大模型应用落地的角度来说，这三种技术可以组合使用：Skill 解决标准化流程复用问题，比如文档质量检测、代码审查、报告生成这类可以沉淀成 SOP 的任务；MCP 解决外部数据接入问题，让 Agent 能查数据库、调 API、读文件系统，这是企业应用的刚需；多 Agent 解决复杂流程编排问题，当任务涉及多个步骤、需要状态管理时，单个 Agent 搞不定
换句话说，在一个多 Agent 工作流里，某个子 Agent 可以调用 MCP 获取数据，然后用 Skill 里定义的标准流程来处理。这篇文章主要先介绍 Skill，MCP 和多 Agent 的搭配使用后续结合具体案例再展开。
4
把数据治理工具包 Skill 化
前面都是概念，这一部分来点实际的。我拿上篇文章介绍的一个 RAG 数据治理工具包来演示完整的 Skill 化过程。
做了十几个知识库项目后，我把入库前的文档摸底流程产品化了
方便大家看到效果，这里的演示还是搭配 IDE（Antigravity）来操作，但在真实的生产环境里，Skill 机制并不依赖 IDE，本质是一个标准化入口，可以接到后端服务或编排系统里，前提是运行环境具备必要的权限和依赖。
4.1
项目背景
这个工具包是给知识库项目做的，具体项目背景在上一篇文章当中有详细说明了。这里就不再赘述。核心功能是在入库之前先做一次扫描和画像盘点，主要覆盖文档格式分布、扫描型 PDF 的识别与 OCR 标记、复杂度评估（纯文字/含表格/含图片）、敏感信息的初筛、相似/重复候选的识别，并生成一份 HTML 报告来指导后续的分块和清洗策略。
知识库文档入库扫描的HTML报告样图
4.2
Skill 化的核心改动
原来这个工具包是通过 Web UI 使用的：启动 FastAPI 服务，打开浏览器，点按钮扫描，再查看结果。但在 IDE + 大模型的场景下，我希望一句话调用，就是用户说“帮我扫描这个文件夹”，模型就能直接执行并返回结果。
所以 Skill 化的改动主要集中在三个动作上：增加 CLI 入口、补齐 SKILL.md 、按平台规则注册到 Skill 目录。其中最关键的是新增 cli_scan.py，接受文件夹路径作为参数，调用原有 ScanPipeline，直接输出 HTML 报告。
下面是简化后的核心逻辑示意（省略参数校验与部分工具函数定义）：
from pathlib import Pathimport sysfrom scanner.pipeline import ScanPipelinefrom utils.export_utils import generate_export_htmldef print_progress(msg):print(msg)def main():input_dir = sys.argv[1]output_file = sys.argv[2] if len(sys.argv) > 2 else "report.html"template_dir = Path(file).parent / "backend" / "templates"# 调用原有的扫描流水线pipeline = ScanPipeline()result = pipeline.start_scan(input_dir, progress_callback=print_progress)# 生成 HTML 报告html = generate_export_html(result, template_dir)Path(output_file).write_text(html, encoding="utf-8")# 输出摘要print(f"✅ 报告已生成: {output_file}")
这个 CLI 脚本复用了原有的主流程和核心模块，只是换了一个更适合自动化调用的入口。与此同时，SKILL.md 用来告诉模型“这个工具包能做什么、怎么调用”：
---name: rag-data-governancedescription: | RAG入库前的文档质量扫描与分析工具。扫描指定文件夹中的文档， 自动识别格式、检测扫描型PDF、分析复杂度、检测敏感信息、 发现重复文档，生成 HTML 格式的扫描报告。---
正文里把使用场景、调用方式（如 python cli_scan.py <路径> [输出文件]）、输出说明（终端摘要 + HTML 报告）、支持的文档格式、质量标签含义以及配置调整方式都写清楚。最后把整个工具包注册到平台会扫描的 Skill 全局目录，让大模型能稳定发现并调用：
cp -r 数据治理工具包 ~/.gemini/antigravity/global_skills/rag-data-governance
或者在项目目录下使用，只要运行环境会扫描该路径，模型也能发现。Skill 化之后，使用流程就变成了“用户一句话提出扫描需求，模型识别对应 Skill，读取 SKILL.md 获取命令，执行扫描脚本并返回摘要和报告路径”，全程不需要手动操作 Web UI。
通过这个案例也想说明，尽量提供 CLI 入口以便自动化调用，优先产出 HTML/JSON/Markdown 等可复用文件而不是只在终端打印，复用原有主流程而不是重写项目，并在 SKILL.md 里把命令、参数、输出位置和注意事项写清楚，这样模型才能稳定、可控地使用。
5
从投标书生成看 Skill 的行业价值
写到这里，我想跳出技术细节，聊聊 Skill 对行业应用（尤其是 ToB 交付）的真正价值。我之前做过不少类似的长文档生成项目，像银行的信贷尽调报告、法律行业的合同生成，还有环保行业的环评报告。这些场景听起来行业跨度很大，但技术底座其实都差不多。无非就是先把长文档拆成若干个小章节，写好每一章的模板，然后用"RAG（找素材）+ 规则引擎（算数据）+ 大模型"一段段生成，最后再拼起来。这个路子跑通了很多遍，能生成，质量也还行。
最近在做一个投标书生成项目的时候，我一直在思考产品化的问题：当面对有类似需求但场景不同（如投软件、投硬件、投服务）的客户时，原有的那套把逻辑写在 Workflow 里的方法暴露出了一些局限性，换句说每接一个新客户，就得把核心代码改一遍，功能边界很难定义，交付也变得比较重。而在思考技术架构怎么设计才能更好复用时，Skill 这种能力包的形态提供了一些新的思考方向。
5.1
解决的不是生成问题，而是复用问题
按之前的做法，逻辑是写在代码里的。比如做"软件开发类"标书，在代码里硬编码了很多软件工程的规范、引用了特定的检索库。这时候如果来了个"硬件集采类"的标书项目，虽然大流程一模一样（都是分章生成），但因为领域知识变了，就得去改代码、换 Prompt、重新部署一套环境。这意味着每做一个新行业，边际成本并没有明显降低。
我在尝试用 Skill 改造这个环节，思路是把领域知识从代码里剥离出来，封装成一个个独立的 Skill 包。比如做一个 bid-software-spec 的 Skill，里面放软件开发的规范；再做一个 bid-hardware-spec 的 Skill，放硬件参数校验规则。这样核心的 Workflow 代码就可以保持稳定，遇到同类但不同领域的项目时，只需要挂载不同的 Skill 包。
当然，这本质上还是软件工程里"配置化/插件化"的新瓶装旧酒。但 Skill 的独特之处在于，它是一种自然语言驱动的配置，大模型能读懂、能按需加载的技能包，这比传统的 JSON 配置要灵活得多。
它虽然不能直接变身标准化产品，但确实提供了一种"领域知识与流程代码解耦"的可行路径，让"同一套代码 + 不同的技能包"成为可能。这在面对同一场景下（如长文档生成）跨客户、跨行业的复用难题，也确实多了一种更轻量的解法。
5.2
在长文档生成中的三个具体落点
既然在尝试 Skill 化，具体应该怎么切分？在投标书生成这个场景里，目前初步探索下来有三个环节比较适合用 Skill 来进行结构化封装。
章节规范包
在固定格式的长文档生成场景里，业界早也有了"分章节、分 Prompt"的生成做法。而 Skill 的主要价值并不在于分治，而是提供了一种物理内聚的打包方式。说人话就是，以前这些规则往往分散在代码配置、数据库字段或者 Prompt 模板库里，迁移一个章节很麻烦。现在 Skill 把单一章节所需的 Prompt、校验规则、素材文件全部放在一个文件夹里。这种所见即所得的物理结构，让跨项目的规则变成了可复用模块。
审稿能力包
审稿环节往往依赖业务专家的经验（比如"报价单金额必须与正文一致"）。这部分可能会有盆友想，这不就是把规则塞进知识库让 RAG 召回吗？个人认为，这里的区别在于 RAG 本身不执行校验，必须依赖后续校验逻辑；而 Skill 可以封装具体的检查脚本或工具（硬约束）。比如写一个 Python 脚本去自动比对正文和报价单的数字。Skill 的价值在于把老师傅觉得这里容易出错的经验，变成了一段能自动跑起来的代码，比纯靠大模型自觉要靠谱得多。
企业资质包
写投标书的时候，营业执照、专利证书、客户案例等都属于必须绝对准确的刚性素材。在没有 Skill 之前，我倾向于用“资产库 + 元数据治理 + 版本控制 + 模板绑定”的组合：资质文件有唯一 ID、有效期、项目归属等字段，正文通过占位符或字段绑定引用，检索更多是辅助入口，并配合强过滤与人工校验。这样可以把误用/错用的风险控制在流程层面，而不是寄希望于语义召回的准确率。
而 Skill 可以把这套做法进一步产品化，就是把特定项目所需的资质与规则打包成可复用的资产包，模型生成到对应章节时按清单读取并校验，减少歧义入口、提升可追溯性和审计性。它不是替代所有治理手段，而是提供一个更工程化、可复用的载体。
5.3
Workflow vs Skill：编排与能力的关注点分离
最后关于架构设计，还有个问题需要厘清，就是 Skill 和 Workflow 到底以谁为主？
在目前的实践中，我更倾向于把核心控制权放在 Workflow（编排系统）这一侧，但不同团队也可能会采用 Agent 驱动的架构(让 Agent 自主决定调用哪些 Skill 以及执行顺序)。Workflow 通常负责全流程的任务拆解、状态流转和并发控制（或者至少负责流程描述），而 Skill 更像是被剥离出来的领域能力层，里面既有知识，也有工具和校验逻辑。人工编排好的 Workflow 决定什么时候做，Skill 提供做什么所需的上下文和工具。比如主流程决定现在要生成"系统架构章节"，就去调用架构师 Skill，加载架构图规范和绘图工具。
这种"流程编排与领域能力分离"的架构，带来的最大好处之一是让 Workflow 变轻量了些。Workflow 回归纯粹的流程控制，而繁杂多变的业务细节被下沉到了一个个独立的 Skill 包里。当然，前提是 Skill 有清晰的接口和版本治理，这种架构清晰度才能成为工程维护性的关键保障。
6
写在最后
抛开技术细节换个角度看 Skill，让我想起当年的 Docker。Docker出来之前，国内大厂其实早就基于 Linux 的 cgroups/namespaces 做过资源隔离与部署体系，只是一直缺一套被行业广泛接受的交付格式与工作流标准。但为什么最后是 Docker 成了行业标准？因为它定义了一套所有人都认的镜像格式和交付流程，把复杂的运行环境封装成了一个标准包，谁拿到都能跑。
今天的 Skill 和 MCP，非常像当年的 Docker。大模型、RAG、Prompt 这些技术大家都会，但怎么把这些能力封装好、分发出去、让别人的系统能直接用，一直缺乏标准。Anthropic 现在做的，就是在定义大模型时代的 Dockerfile。在这个视角下，Skill 给做企业应用的从业者带来的启发也很明显了：交付的终局不是交付代码，而是把行业 Know-how 封装成能被下一个项目直接调用的 Skill 包。
这种标准化的价值在于，它提供了一个通用的业务载体。现在的 AI Coding 已经非常成熟，理论上80% 以上的项目代码实现都可以交给大模型 24 小时去跑。当 Skill 解决了怎么封装的问题，而 AI Coding 搞定了怎么写代码的问题，作为从业者应该腾出手来更多去关注业务逻辑本身，也就是那些必须由人来做的设计选型、复杂的数据预处理，以及在预算、工期等现实约束下的一期二期规划。
换句话说，真正的壁垒不再是代码写得有多快，而是能不能在这些约束条件下，把那 3-5 个核心场景里的行规、经验、窍门，提炼并封装进这一套能被大模型完美执行的 Skill 里。对业务场景的深刻理解与抽象，才是从能做项目到能做产品的真正跨越。
