无论是AI 工具（如 Claude Code、Gemini CLI 和 Cursor），还是最近爆火的OpenClaw，它们能力的大幅提升，都离不开Skill。
那什么是Skill呢？Skill 本质上就是：把一段“可复用的提示词 + 明确的任务说明 + 输入输出规范”封装起来，让 AI 能像调用工具一样稳定地完成某个功能或任务。
Skill一般包含什么内容呢？
通用Skill结构一般如下：
- SKILL.md：Skill的“灵魂”，告诉Agent在什么情况下可以调用这个Skill，以及如何调用
- references/：Agent 调用Skill时需要的参考信息或知识来源
- assets/：用于存放资源文件
- scripts/：可执行脚本
谷歌的Shubham Saboo、Lavini Nigam通过研究整个生态中的 Skill 设计（包括 Anthropic、Vercel 以及 Google 的实践），总结出了 5 种 Agent Skill 设计模式，掌握这5种 Skill 的设计模式，可以让你构建出更强大的 Agent。
下面我用大白话的方式，并结合使用示例，给大家讲一下这5种 Skill 设计模式。
模式1： Tool Wrapper（工具封装）
核心思想：按需加载知识，而不是全部写死在 Prompt 里。
比如我们想做一个FastAPI专家的Agent ，Tool Wrapper 可以让 Agent 在需要时，才去获取特定技术（如 FastAPI）的上下文知识。
与其把要求全部硬编码到 system prompt 中，不如把它封装成一个 Skill。
Agent 只会在真正使用到该技术时，才去加载这些知识。
这样既提升了效率，又节省了token。
工作机制
- 监听用户 Prompt 中的关键词（如 FastAPI）
- 动态加载
references/目录中的文档 - 将这些规则作为“绝对标准”应用
示例：FastAPI 专家 Skill
# skills/api-expert/SKILL.md
---
name: api-expert
description: FastAPI 开发最佳实践与规范。在构建、评审或调试 FastAPI 应用、REST API 或 Pydantic 模型时使用。
metadata:
pattern: tool-wrapper
domain: fastapi
---
你是一名 FastAPI 开发专家。请将这些规范应用到用户的代码或问题中。
## 核心规范
加载 'references/conventions.md' 以获取完整的 FastAPI 最佳实践列表。
## 代码评审时
1. 加载规范参考
2. 根据每一条规范检查用户的代码
3. 对于每一个违反规范的地方，指出具体规则并给出修复建议
## 编写代码时
1. 加载规范参考
2. 严格遵循每一条规范
3. 为所有函数签名添加类型注解
4. 使用 Annotated 风格进行依赖注入
模式2： Generator（生成器）
核心思想：让输出结构“固定”，而不是每次生成都不一样。
如果你遇到过：
同一个任务，Agent 每次输出结构都不一样
那 Generator 就是解决方案。
实现方式
利用两个目录：
assets/：模板（结构）references/：风格指南（语气 + 规范）
Agent 的角色类似“项目经理”：
- 加载模板
- 加载风格规范
- 向用户补全缺失信息
- 填充模板
适用场景
- API 文档生成
- 规范化 commit message
- 项目脚手架生成
示例：技术报告生成器
# skills/report-generator/SKILL.md
---
name: report-generator
description: 生成结构化技术报告的 Markdown 文档。当用户要求撰写、创建或起草报告、摘要或分析文档时使用。
metadata:
pattern: generator
output-format: markdown
---
你是一个技术报告生成器。请严格按照以下步骤执行：
步骤 1：加载 'references/style-guide.md' 以获取语气和格式规则。
步骤 2：加载 'assets/report-template.md' 以获取所需的输出结构。
步骤 3：向用户询问填充模板所需的任何缺失信息：
- 主题或议题
- 关键发现或数据点
- 目标受众（技术人员、管理层、普通大众）
步骤 4：按照样式指南规则填充模板。输出内容必须包含模板中的每一个部分。
步骤 5：将完成的报告作为一个 Markdown 文档返回。
👉 注意：这个Skill 只是一个流程骨架，只负责“调度”。需要结合样式指南：references/style-guide.md、模板文件assets/report-template.md一起使用。其他的模式也类似，不再赘述。
模式3： Reviewer（评审器）
核心思想：把“检查什么”和“如何检查”解耦。
不要在 Prompt 里写一大堆规则，而是：
👉 把规则写到 references/review-checklist.md
这样做的好处是，当你需要别的类型的"审核员"，Skill 的主体几乎不用变。 只需要换一份 checklist（检查标准）就行
工作流程
- 加载 checklist
- 逐条检查代码
- 按严重程度分类输出
严重等级
- error（必须修复）
- warning（建议修复）
- info（可优化）
示例：代码审查 Skill
# skills/code-reviewer/SKILL.md
---
name: code-reviewer
description: 审查 Python 代码的质量、风格和常见错误。当用户提交代码进行审查、请求对其代码提供反馈或希望进行代码审计时使用。
metadata:
pattern: reviewer
severity-levels: error,warning,info
---
你是一个 Python 代码审查员。请严格按照以下审查流程执行：
步骤 1：加载 'references/review-checklist.md' 以获取完整的审查标准。
步骤 2：仔细阅读用户的代码。在进行评判之前，先理解其用途。
步骤 3：将清单中的每一条规则应用于代码。对于发现的每一个违规：
- 注明行号（或大致位置）
- 分类严重级别：error（必须修复），warning（应该修复），info（可考虑修复）
- 解释为什么这是个问题，而不仅仅指出什么错了
- 通过修改后的代码来建议具体的修复方法
步骤 4：生成结构化的审查意见，包含以下部分：
- **摘要**：代码的功能及总体质量评估
- **发现项**：按严重级别分组（先 errors，再 warnings，最后 info）
- **评分**：以 1-10 分进行评级并附上简要理由
- **三大建议**：最具影响力的改进点
模式4：Inversion（倒置）
核心思想：先问清楚、逐步确认、完整理解后再生成结果。
默认情况下，Agent 会：
❌ 直接猜测 → 立刻生成结果
Inversion 模式则反过来：
✅ 先提问 → 收集信息 → 再生成
关键机制
- 按步骤收集信息：把整个任务拆成多个阶段，按顺序提问，每一步都必须先得到答案才能进入下一步
- 条件限制：在每个阶段设置“必须完成”的条件，智能体不能提前生成最终结果。
- 全面理解需求再行动：只有在完整收集了用户的需求和限制条件后，才会生成最终方案或输出。
示例：项目规划 Skill
# skills/project-planner/SKILL.md
---
name: project-planner
description: 通过结构化提问收集需求来规划一个新的软件项目。当用户说"我想构建"、"帮我规划"、"设计一个系统"或"开始一个新项目"时使用。
metadata:
pattern: inversion
interaction: multi-turn
---
你正在进行一次结构化的需求访谈。在所有阶段完成之前，不要开始构建或设计。
## 第一阶段 — 问题发现（一次问一个问题，等待每个回答）
按顺序询问这些问题。不要跳过任何问题。
- Q1："这个项目为其用户解决什么问题？"
- Q2："主要用户是谁？他们的技术水平如何？"
- Q3："预期的规模是多大？（每日用户数、数据量、请求频率）"
## 第二阶段 — 技术约束（只有在第一阶段完全回答后才进行）
- Q4："你将使用什么部署环境？"
- Q5："你有什么技术栈要求或偏好吗？"
- Q6："有哪些不可协商的要求？（延迟、正常运行时间、合规性、预算）"
## 第三阶段 — 综合（只有在所有问题都回答后才进行）
1. 加载 'assets/plan-template.md' 以获取输出格式
2. 使用收集到的需求填写模板的每一部分
3. 向用户展示完成的计划
4. 询问："这个计划准确捕捉了你的需求吗？你想修改什么？"
5. 根据反馈进行迭代，直到用户确认
模式5： Pipeline（流水线）
核心思想：复杂任务必须强制分步骤执行。
当任务复杂时：
❌ Agent 很容易跳步骤 / 忽略约束 ✅ Pipeline 强制执行顺序 + 校验点
特点
- 严格顺序执行
- 每一步都有“检查点”
- 没有得到用户的确认或批准，不能进入下一步
示例：文档生成流水线
# skills/doc-pipeline/SKILL.md
---
name: doc-pipeline
description: 通过多步骤流水线从 Python 源代码生成 API 文档。当用户要求为模块编写文档、生成 API 文档或根据代码创建文档时使用。
metadata:
pattern: pipeline
steps: "4"
---
你正在运行一个文档生成流水线。按顺序执行每一步。如果某一步失败，不要跳过步骤或继续执行。
## 步骤 1 — 解析与清单
分析用户的 Python 代码，提取所有公共类、函数和常量。将清单以检查表的形式呈现。询问："这是你想要记录完整公共 API 的全部内容吗？"
## 步骤 2 — 生成文档字符串
对于每个缺少文档字符串的函数：
- 加载 'references/docstring-style.md' 以获取所需格式
- 严格按照样式指南生成文档字符串
- 呈现每个生成的文档字符串供用户批准
在用户确认之前，不要进入步骤 3。
## 步骤 3 — 组装文档
加载 'assets/api-doc-template.md' 以获取输出结构。将所有类、函数和文档字符串编译成单个 API 参考文档。
## 步骤 4 — 质量检查
根据 'references/quality-checklist.md' 进行审查：
- 每个公共符号都有文档记录
- 每个参数都有类型和描述
- 每个函数至少有一个使用示例
报告检查结果。在呈现最终文档之前修复问题。
如何选择合适的模式？
每种模式解决不同问题：
| 问题 | 模式 |
|---|---|
| 需要专业知识注入 | Tool Wrapper |
| 输出结构不稳定 | Generator |
| 需要自动评审 | Reviewer |
| 需求不清晰 | Inversion |
| 任务复杂易出错 | Pipeline |
最重要的一点：模式是可以组合的
这些模式不是互斥的，而是可以组合：
- Pipeline 的最后接一个 Reviewer 做自动质量校验
- Generator 前面加一层 Inversion 先收集信息再生成
- Tool Wrapper 嵌入 Pipeline 每一步都加载专业知识
- Generator 输出后交给 Reviewer 做风格校验
关键点：Skill 设计是可复用的系统化模块，而不是一次性对话。 Prompt 是临时指令，Skill 是工程化组件，可以按需组合成一套完整的工作流。
实操路线
大家可以按照下面的顺序上手实践一下：
- 先做 Tool Wrapper
- 把自己熟悉的规则封装成 Skill
- 示例：写作风格、报告模板、框架开发规范
- ✅ 收获：最快体验到“技能能用”的成就感
- 再做 Generator
- 固定输出格式，保证每次生成一致
- 示例：日报生成器、周报生成器、会议纪要生成器
- ✅ 收获：感受到“可复用”的价值
- 加 Reviewer
- 对输出增加质量检查
- 检查点：信息是否完整、风格统一、逻辑合理、事实正确
- ✅ 收获：从“能跑”到“更可用”的工作流
- 最后考虑 Inversion + Pipeline
- 复杂任务加：先收集信息再执行 + 强制分步骤 + 每步设检查点
- ✅ 收获：接近真正的工程化 Agent 系统
👉 关注公众号"北灵聊AI"，一个专注于技术的博主
