你在使用智能体（Agent）时，是否遇到过这样的困境：

        · 想让Agent处理PDF文件，每次都要在提示词里详细描述"先用工具PyPDF2提取文本，如果乱码就换成工具pdfplumber，再不行就转图片用工具 OCR"——既繁琐又难以复用。

        · 想给Agent注入专业领域知识，却发现除了往系统提示词里堆砌大段文本、大量消耗上下文空间之外，没有更好的办法。

        · 想让Agent按公司规范生成合同，却发现ReAct模式下Agent调用工具的顺序飘忽不定，同一需求经常走入不同的工具执行路径；

        · 想让Agent稳定执行固定的业务流程，Workflow 确实能做到，但执行路径被平台固化，稍微有个性化需求就得找开发人员改代码，终端用户只能"用"，不能"改"

        这些困境的本质，指向了同一个问题：现有的Agent能力扩展方式（提示词工程、工具调用、ReAct、Workflow）各有侧重，但都未能同时满足"专业化、标准化、可复用"这三个需求。

        这正是 Agent Skill 试图解决的问题。

一、什么是Agent Skill？

        Agent Skill是Anthropic 提出的一种轻量级、可灵活装配、按需加载的能力模块，用于为智能体（Agent）编排特定工作流程并注入专业领域知识。它以文件夹为物理载体，遵循约定的目录结构，使得Agent能够按需加载并执行特定任务。

        Agent Skill在物理结构上是一个文件夹，文件夹名称即为该Skill的名称。文件夹内包含以下组件，其中SKILL.md是唯一必选文件，其余均为可选。

        · SKILL.md文件（必选）：这是Skill的核心文件，也是唯一的必选组件。它采用 Markdown格式编写，充当该Skill的"说明书"，内容分为两个部分：

        1. 元数据（Metadata）：以YAML格式位于SKILL.md文件的顶部（Frontmatter），至少包含Skill的名称和描述。智能体通过读取元数据来判断是否应该调用该 Skill。

        2. 执行指令（Instructions）：指导智能体"如何正确执行"任务，包括输入/输出格式规范、执行步骤、使用示例等。智能体通过解析这些指令，了解如何正确使用该 Skill。

        · scripts/（可选）：存放可执行的脚本文件（如 Python、Shell 等），用于执行 Skill中的自动化操作，如数据清洗、文件格式转换、PDF导出等。

        · references/（可选）：存放支撑Skill运行的参考资料，如法律条款库、术语表、API接口文档等。这些资料可在 SKILL.md的指令中被引用或按需加载。

        · assets/（可选）：存放静态资源和输出模板文件，如图片、模板文档等。这些资源通常作为Skill的输出模板或渲染素材。

        图1展示了名为 contract_generator 的"合同生成"Skill的完整目录结构，包含 SKILL.md 核心文件及 scripts/、references/、assets/ 三类可选资源的具体组织方式。代码1展示了该Skill的SKILL.md文件内容的样例。

图1：“合同生成”Skill

---
name: contract-generator
description: 专业合同生成器。当用户需要生成销售合同或服务协议时使用此技能。
---

# 合同生成器
## 概述
自动化生成销售合同或服务协议文档，支持模板填充和 PDF 格式文档导出。

## 可用模板
- `sales_contract_template.docx` - 销售合同模板
- `service_agreement_template.docx` - 服务协议模板

## 工作流程
### 1. 选择模板
根据用户需求选择合适的模板：
- 涉及产品销售 → `sales_contract_template.docx`
- 涉及服务提供 → `service_agreement_template.docx`

### 2. 收集信息
参考 `references/field_mapping.csv` 获取必填字段，向用户收集：
- 合同双方信息
- 合同金额
- 服务/产品详情
- 签署日期

### 3. 生成合同
运行生成脚本：
```bash
python scripts/generate_contract.py --template <模板> --data <用户数据> --output <输出路径>
```
脚本会自动应用：
公司 Logo（assets/company_logo.png）
电子印章（assets/official_seal.png）

### 4. 导出 PDF
如需导出 PDF 格式文档，运行：
```bash
bash scripts/export_to_pdf.sh <输入文件> <输出文件>
```

## 参考文件
| 文件 | 用途 |
| :--- | :--- |
| references/clause_library.md | 标准条款库 |
| references/field_mapping.csv | 字段映射表 |
| references/legal_terms_glossary.yaml | 法律术语表 |

## 文件结构
contract-generator/
├── SKILL.md
├── scripts/
│   ├── generate_contract.py
│   └── export_to_pdf.sh
├── references/
│   ├── clause_library.md
│   ├── field_mapping.csv
│   └── legal_terms_glossary.yaml
└── assets/
    └── templates/
    │    ├── sales_contract_template.docx
    │    └── service_agreement_template.docx
    ├── company_logo.png
    └── official_seal.png

## 注意事项
生成的合同或协议建议由法务审核后再正式使用
电子印章仅供预览，正式签署需遵循法律流程

代码1：“合同生成”Skill的SKILL.md文件内容样例

二、Agent Skill 是如何工作的？

        智能体通过渐进式披露（Progressive Disclosure）的方式加载Skill，整个过程分为三个阶段：

        · 发现（Discovery）：在智能体初始化时，只加载每个可用Skill的元数据，即SKILL.md中的名称和描述。这使得智能体在启动时仅占用极小的上下文空间，却能够"知道"自己拥有哪些技能。当用户输入问题后，智能体会将用户输入与所有 Skill的元数据一同输入LLM，LLM根据用户输入与各Skill描述之间的相关性，推理出最匹配的一个或多个 Skill。

        · 激活（Activation）：当智能体确定要使用某个Skill后，才进一步读取该Skill文件夹中 SKILL.md的剩余内容，即指导智能体如何执行任务的完整指令（包括输入/输出规范、执行步骤、使用示例等）。这些指令随后被加载到LLM的上下文中。未被选中的 Skill，其指令内容不会被加载，从而保持上下文的高效利用。

        · 执行（Execution）：LLM根据加载的指令进行推理。如果指令中要求运行 scripts/目录下的脚本或读取 references/目录下的参考资料，LLM会以结构化格式（如 JSON或函数调用） 输出相应的操作请求。智能体解析该输出并执行对应操作（如运行Python脚本、调用外部API、读取文件等），再将执行结果返回给LLM，驱动下一轮推理，直至任务完成。

        上述三个阶段也被一些文献归纳为 L1、L2、L3 三个加载层级，如图2所示：

        1. L1（元数据）：对应SKILL.md中的元数据（名称+描述），始终存在于LLM上下文中，用于"发现"阶段。

        2. L2（执行指令）：对应 SKILL.md 中除元数据以外的完整指令，仅在Skill被激活后加载，用于"激活"和“执行”阶段。

        3. L3（动态内容）：对应执行过程中脚本运行、工具调用后返回的结果，以及 references/和 assets/中按需引用的文件内容，仅在需要时加载，用于"执行"阶段。

图2：渐进式披露，三个加载层级

        这种渐进式披露机制的核心优势在于：LLM 始终"携带"所有Skill的元数据（L1），但实际占用的上下文空间极小；完整的指令（L2）和动态内容（L3）仅在需要时才加载，从而在保证功能完备的同时，实现了上下文资源的高效利用。

三、提示词工程、ReAct/工具调用、Workflow和Agent Skill的异同

        提示词工程：当模型具备足够的通用能力，但缺乏特定任务所需的表达范式或推理框架时，提示词是最轻量的干预手段。它解决的是"激发"问题，即通过精心设计的指令、角色设定和示例，引导模型将内化的知识以符合预期的方式输出。其优势是成本低、响应快，劣势是临时性、非模块化，且难以版本控制或共享。

        ReAct/工具调用：当模型需要突破自身知识的时效性和封闭性，与外部世界交互（如查询数据库、调用 API、发送邮件）时，工具调用成为必要。ReAct范式解决的是"连接"问题——模型在"推理（Reasoning）"中生成调用工具的指令，智能体据此"行动（Acting）"，将工具执行结果作为"观察（Observation）"反馈给模型，驱动下一轮推理，如此循环。工具在此过程中是模型连接外部世界的媒介。ReAct的核心突破并非取代提示词，而是在提示词框架内嵌入了"推理-行动-观察"的闭环。其优势是灵活、适应性强，但劣势也源于此：执行路径由LLM自主决策，同一问题可能每次走不同的路径，结果不稳定且难以调试。

        Workflow：许多实际任务流程相对固定、步骤明确且重复性高，此时可将执行路径预先定义为结构化的DAG（有向无环图），在任务执行路径上固定LLM模块和工具模块的位置与顺序。Workflow解决的是"编排"问题——通过固化执行路径，确保任务以稳定、可预期的方式运行。与ReAct的开放性和探索性不同，Workflow强调的是确定性和可控性，本质上是对ReAct不确定性的刻意约束。它适合规则清晰、变更频率低的业务场景，其实现在平台编排层，通常由平台方或管理员定义，终端用户无法直接修改执行逻辑。

        Agent Skill：Skill不是对提示词工程、工具调用和Workflow的简单叠加，而是将三者有机融合并封装为可复用、可插拔的标准化模块。具体而言：

        · SKILL.md 中的指令利用提示词工程规范LLM的输入/输出格式、明确使用条件、展示示例，引导模型"做什么"、"怎么做"、"做成什么样"。

        · SKILL.md 中的工具调用指令与 Scripts/目录下的可执行脚本，赋予LLM通过工具与外部世界交互的能力；相比ReAct模式下LLM需自行推理决策调用哪些工具，SKILL.md中的工具调用链路已被预先定义，大幅提升了执行的可控性与稳定性。

        · SKILL.md中定义的执行步骤，确保复杂任务能够按照固定的Workflow 有序推进。与平台内置的Workflow不同，Skill中的Workflow由终端用户自行编排，可根据具体任务定制并随时插拔，实现了"平台提供执行引擎，用户提供执行剧本"的协作模式。

        综上，Agent Skill 的本质可以概括为：

        Agent Skill = 标准化封装（提示词工程 + 工具调用 + Workflow编排），并支持按需动态加载。

        它既保留了Workflow的确定性，又继承了ReAct/工具调用的扩展性，同时以提示词工程规范交互边界，最终为终端用户提供了"用自己的方式定义Agent行为"的能力。

三、小结

        Agent的能力扩展从提示词工程、ReAct/工具调用、Workflow到Agent Skill不断演进。我们看到，这种演进并非简单的"新范式取代旧范式"，而是一个分层进化、各安其位的过程：提示词工程解决"激发"，ReAct 解决"连接"，Workflow 解决"编排"，而 Skill则将三者有机融合，通过标准化封装和按需加载，为终端用户提供了"用自己的方式定义Agent行为"的能力。

        Agent Skill 的核心理念可以归结为一句话：平台提供执行引擎，用户提供执行剧本。它并不试图取代提示词工程或ReAct或Workflow，而是在它们之上构建了一个更贴近业务场景的抽象层，让专业知识和工作流程能够像"技能包"一样被随时装配、按需加载。

四、参考文献

1. Agent Skills Overview. https://agentskills.io/home.

2. Yao, S., Zhao, J., Yu, D., et al. ReAct: Synergizing Reasoning and Acting in Language Models, 2023.

作者：徐宏勤
版权声明：本文为原创内容。如需转载，请务必在文章开头标注作者和来源，并保持文章完整，否则视为侵权。