话不多说,先上干货。本文梳理自 Google ADK 智能体工程专家 La vi Nigam 关于 Agent Skill 设计的一些核心心得,重点总结了 5 种可落地、能直接用的 SKILL.md 设计模式。核心目标就一个:帮开发者把 Token 浪费降下来,把 Skill 编写质量提上去。
背景:为什么需要 Skill 设计模式?
如果仔细复盘过 AI Native 产品的开发过程,你会发现一个很扎心的现实:大量 Token 都浪费在了无关紧要的“猜测”上。大模型需要反复揣摩一个本来很明确的用户意图,或者被迫用一套臃肿的指令去理解一个本可以简单表达的逻辑。
使用结构化的 SKILL.md 设计模式,能直接解决这个痛点:
- 减少模型的“瞎猜”成本,让它在正确的时机精准触发正确的行为
- 让 Skill 的编写方式标准化,团队协作时少些“我以为,你以为”的摩擦
- 巧妙利用渐进式知识加载,把 Token 消耗降下来
- 核心目的:让 Agent 在正确的时间,激活正确的技能
5 种模式总览
Pattern 1:Tool Wrapper(工具包装器)
这个模式的思路很直接:SKILL.md 通过 load_skill_resource 加载 references/ 目录下的规范文件,Agent 应用这些规则后,瞬间就能变成某个领域的专家。没有脚本,没有模板——本质上就是一个知识封装的过程。
工作原理
(图片位置:此处应插入 Tool Wrapper 工作原理示意图)
文件结构
my-skill/
├── SKILL.md # 触发关键词 + 加载指令(无脚本、无模板)
└── references/
└── conventions.md # 规范、约定、最佳实践
适用场景
- FastAPI 路由约定、响应模型规范
- Terraform 资源命名与模块化模式
- PostgreSQL 查询优化最佳实践
- 公司内部 API 设计规范
SKILL.md 示例
---
name: fastapi-expert
description: 帮助编写符合 FastAPI 最佳实践的代码。当用户需要编写 FastAPI 相关代码、路由、依赖注入时触发。
---
# FastAPI 专家模式
## 激活规则
- 加载参考文档:`references/fastapi-conventions.md`
- 按照文档中的约定,确保所有生成的 FastAPI 代码符合规范。
Pattern 2:Generator(生成器)
核心思想是:assets/ 里的模板决定了“输出什么结构”,而 references/ 里的风格指南则控制“怎么输出”。模板负责强制结构,风格指南负责保证质量。
工作原理
(图片位置:此处应插入 Generator 工作原理示意图)
文件结构
my-skill/
├── SKILL.md
├── assets/
│ └── report-template.md # 输出结构模板(必须包含哪些章节)
└── references/
└── style-guide.md # 语气、格式风格指南
适用场景
- 技术分析报告
- API 参考文档
- 规范化 Git Commit Message
- Agent 脚手架代码
- 周报/月报模板
Pattern 3:Reviewer(审查员)
这个模式的核心在于“分离”:把“检查什么”(checklist)与“如何检查”(审查协议)拆开。你只需要替换 references/ 中的检查清单文件,就能用同一个技能结构,完成完全不同类型的审查任务。
工作原理
(图片位置:此处应插入 Reviewer 工作原理示意图)
文件结构
my-skill/
├── SKILL.md # 审查协议(如何检查:加载、应用、报告)
└── references/
└── review-checklist.md # 检查清单(检查什么:按严重程度列举规则)
输出格式规范
审查结果按严重程度分组,一目了然:
| 级别 | 含义 | 示例 |
|---|---|---|
| ❌ Error(错误) | 必须修复,影响功能或安全 | SQL 注入漏洞、未处理异常 |
| ⚠️ Warning(警告) | 建议修复,影响质量 | 缺少类型注解、命名不规范 |
| ℹ️ Info(信息) | 可选优化 | 注释不完整、可提取复用逻辑 |
适用场景
代码审查
- Python 类型提示检查
- 异常处理完整性
- 函数复杂度评估
安全审计
- OWASP Top 10 检查
- 密钥硬编码检测
- SQL 注入风险
内容审查
- 技术文档排版规范
- 语气一致性检查
- 术语使用规范
API 文档审查
- 参数说明完整性
- 示例代码正确性
- 错误码文档覆盖
Pattern 4:Inversion(反转/提问模式)
这个模式的思路很有意思:把 Agent 和用户的交互主导权翻转过来。不再是用户提问、Agent 回答,而是 Agent 先提问、用户回答——让技能本身来驱动对话。这能有效防止 Agent 凭空胡乱假设,减少大量无效输出。
三阶段流程
(图片位置:此处应插入 Inversion 三阶段流程示意图)
关键控制指令
必须在 SKILL.md 中明确写出:
在完成所有阶段前,绝对不要开始构建!
DO NOT start building until all phases are complete.
适用场景
- 项目需求文档收集
- 系统故障诊断引导
- 基础设施配置向导
- 定制化报告生成前的信息采集
Pattern 5:Pipeline(流水线)
这套模式定义了一个严格有序的多步骤工作流,步骤之间设置了明确的“门槛”(Gate Conditions)。门槛条件的作用就是防止跳过任何验证步骤。
工作原理
(图片位置:此处应插入 Pipeline 工作原理示意图)
文件结构
my-skill/
├── SKILL.md # 步骤定义 + 门槛控制逻辑
├── references/ # 各步骤参考规范
├── assets/ # 输出模板
└── scripts/ # 自动化脚本(可选)
关键控制指令模板
## Step N: [步骤名称]
[步骤操作描述]
*控制门槛:在[条件]之前,绝对不要进入 Step N+1!*
*如果跳过任何步骤或某一步失败,请勿继续。*
适用场景
- 代码文档化(解析 → 用户确认 → 生成 → 质量检查)
- 数据清洗与处理流水线
- 代码部署工作流(审查 → 测试 → 发布 → 验证)
- 多步骤审批流程
如何选择合适的模式?
话说回来,面对这 5 种模式,到底该怎么选?这里整理了一份快速决策指南:
快速决策指南
| 核心需求描述 | 推荐模式 | 复杂度 | 判断标准 |
|---|---|---|---|
| 让 Agent 掌握特定库/工具的专家知识 | ? Tool Wrapper | 低 | 只需封装约定和最佳实践,无需生成固定格式 |
| 确保输出内容结构始终保持一致 | ? Generator | 中 | 有固定的章节/格式模板,结构一致性 > 创造性 |
| 对照特定标准评估/打分现有内容 | ✅ Reviewer | 中 | 任务类似“根据 Rubric 评分”,需按严重程度分类输出 |
| 防止 Agent 盲目假设,必须先收集上下文 | ❓ Inversion | 中 | Agent 必须了解用户具体情况才能开始工作 |
| 执行含验证门槛的严格多步骤有序流程 | ? Pipeline | 高 | 步骤有依赖关系,顺序绝对不能乱,需用户中途确认 |
决策树
(图片位置:此处应插入模式选择决策树示意图)
实战案例:电商选品 Pipeline
场景描述
设计一个结合了 Inversion + Reviewer + Generator 三种模式的电商选品 Pipeline,实现从需求收集到最终选品报告的完整闭环。
目录结构
ecommerce-product-selector/
├── SKILL.md # 主指令文件(Pipeline 控制)
├── references/
│ └── product-evaluation-checklist.md # 商品评估标准(Reviewer 模式)
└── assets/
└── selection-report-template.md # 最终报告模板(Generator 模式)
SKILL.md 完整示例
---
name: ecommerce-product-selector
description: 帮助进行电商选品(Product Selection)、市场分析、利润测算并生成标准选品报告。当用户需要寻找或评估电商商品时触发。
metadata:
pattern: Pipeline
domain: E-commerce
---
# 电商选品工作流
你是一个专业的电商选品专家。请严格按照以下顺序执行选品工作流。
**核心规则:在完成所有阶段前,绝对不要开始生成选品方案!**
如果跳过任何步骤或某一步失败,请勿继续。
## Step 1: 收集需求(Inversion Pattern)
主动向用户提问以收集选品上下文:
1. 目标受众是谁?
2. 预算和预期利润率是多少?
3. 是否有特定的类目偏好或供应链优势?
*控制门槛:必须等待用户回答完所有问题后,才能进入 Step 2。*
## Step 2: 评估商品(Reviewer Pattern)
加载并应用评估标准:
- 加载检查清单:`references/product-evaluation-checklist.md`
- 按清单标准对商品进行打分(❌ 致命缺陷 / ⚠️ 潜在风险 / ✅ 优势)
## Step 3: 用户确认(Pipeline Gate)
向用户展示 Step 2 的初步审查结果。
*控制门槛:在用户明确确认之前,绝对不要进入第四步!*
## Step 4: 生成最终报告(Generator Pattern)
在用户确认后,综合输出正式报告:
- 加载报告模板:`assets/selection-report-template.md`
- 将收集到的需求和评估结果填入模板,严格遵守模板定义的章节结构
关键设计解析
精准的 Description 触发
description 字段是 Agent 的“搜索索引”。它必须包含具体业务关键词(如“电商选品”、“利润测算”),才能确保 Agent 在正确时机激活该技能,避免误触发或漏触发。
渐进式知识加载
Agent 初始只消耗约 100 Token 加载技能描述。references/ 里的评估清单和 assets/ 里的报告模板,只有当流程流转到对应步骤时才会被加载。这一点对节省上下文窗口至关重要。
进阶建议
从简单开始
如果不确定该从哪个模式下手,最简单的 Tool Wrapper 绝对是不错的选择。先把团队规范封装进去,后续如果需要结构化输出,再升级为 Generator;需要评估能力,再升级为 Reviewer。一步步来。
模式组合最佳实践
生产系统中往往不是单一模式打天下,组合 2~3 个模式是常态。以下是一些常见搭配:
| 组合方式 | 典型场景 |
|---|---|
| Pipeline + Reviewer | 流程末尾的质量控制步骤 |
| Generator + Inversion | 先收集用户信息,再生成定制化报告 |
| Pipeline + Inversion + Generator | 完整端到端业务流(如本文选品案例) |
| Tool Wrapper + Generator | 按专家规范生成代码或文档 |
渐进式知识加载机制
| 加载时机 | 加载内容 | Token 消耗 |
|---|---|---|
| 技能激活时 | SKILL.md 描述 + 基础指令 | 约 100 Token(极低) |
| 到达对应步骤时 | references/ 检查清单或规范文档 | 按需加载,避免预先消耗 |
| 生成阶段时 | assets/ 输出模板 | 仅在需要时加载 |
