谷歌提出的 5 种 Skill 设计模式，第 4 种 90% 的人都没用过
深入解析谷歌提出的 5 种 Agent Skill 设计模式，从 Tool Wrapper 到 Pipeline，帮你从'会用格式'进阶到'设计得好'。
格式只是皮囊，内容设计才是灵魂
同一个模型、同样的 SKILL.md 格式规范，为什么有些 Agent 干活干净利落，有些却像没睡醒？
这个问题很多人琢磨了很久。直到看到 Google Cloud Tech 这篇文章，才恍然大悟——格式只告诉你"怎么包装"，没告诉你"里面该怎么设计"。
现在超过 30 个 Agent 工具（Claude Code、Gemini CLI、Cursor 等）都统一了 SKILL.md 布局，格式问题基本解决了。但一个包装 FastAPI 规范的 Skill，和一个四步文档流水线，外表看着一模一样，内部逻辑却天差地别。
这篇文章提炼出了 5 种经过实战验证的设计模式，帮你从"会用格式"进阶到"设计得好"。
一、五种设计模式速览
先给个全局视角，这五种模式各解决什么问题：
┌─────────────────────────────────────────────────────────┐
│ Skill 设计模式地图 │
├─────────────────────────────────────────────────────────┤
│ │
│ Tool Wrapper → 让 Agent 懂某个库/规范 │
│ ↓ │
│ Generator → 输出结构固定的内容 │
│ ↓ │
│ Reviewer → 检查/评审代码或文档 │
│ ↓ │
│ Inversion → 需求复杂，先问再做 │
│ ↓ │
│ Pipeline → 多步骤任务，一步不能跳 │
│ │
└─────────────────────────────────────────────────────────┘
接下来逐一拆解。
二、Tool Wrapper——让 Agent 秒变专家
核心理念：与其把某个库的最佳实践硬编码到系统提示词里，不如包装成一个 Skill，让 Agent 在需要时才加载。
┌──────────────────┐ ┌──────────────────┐
│ 系统提示词 │ │ Skill 按需加载 │
├──────────────────┤ ├──────────────────┤
│ 臃肿 │ vs │ 精简 │
│ 浪费 token │ │ 上下文按需加载 │
│ 团队规范难同步 │ │ 即插即用 │
└──────────────────┘ └──────────────────┘
实现要点：
references/目录存放详细的规范文档- SKILL.md 里告诉 Agent"什么时候加载"以及"加载后怎么用"
笔者的判断：这是最简单也最实用的模式。如果你团队有内部编码规范，用 Tool Wrapper 分发给每个开发者，比写一万个 Notion 文档都有用——因为 Agent 真的会去读、去执行。
三、Generator——模板驱动生成
解决的问题：每次输出结构都不一样，Agent 写文档总是东一块西一块。
核心思路：
assets/目录放输出模板references/目录放风格指南- SKILL.md 充当"项目经理"，指挥 Agent 按步骤填空
技术报告生成器示例：
| |
为什么这么设计？把"内容"和"结构"分离。模板管结构，Agent 管内容填充。换个模板就能产出完全不同类型的文档，复用性极强。
四、Reviewer——模块化检查清单
精髓：把"查什么"和"怎么查"分开。
与其在系统提示词里写一长串"检查变量命名、检查是否有 SQL 注入风险、检查是否……"，不如把这些规则放到 references/review-checklist.md 里，让 Agent 动态加载。
妙处在哪里？把 Python 风格检查清单换成 OWASP 安全清单，同一个 Skill 瞬间变成安全审计工具——基础设施完全不变，只是换了个参考文档。
五、Inversion——先问再做（90% 的人没用过）
这是最关键的模式。
Agent 天生爱"猜"。用户说一句，它就想给出一个答案。但在复杂场景下，猜错了比不回答更可怕。
Inversion 的核心：把"用户驱动 Agent"变成"Agent 面试用户"。
关键设计：
- 明确的"门禁"指令，比如"DO NOT start building until all phases are complete"
- 分阶段提问，每个阶段必须等用户回答完才能进入下一阶段
- 最后才输出结果
笔者的思考：这个模式有点像心理咨询——先倾听，后诊断。很多失败的 Agent 项目，问题就出在"答得太快"。Inversion 强制 Agent 慢下来，把需求搞清楚再动手。
六、Pipeline——严格流水线
有些任务，一步都不能少。比如生成 API 文档，必须先解析代码、再生成文档字符串、再组装、再检查。跳过任何一步，结果都可能出问题。
Pipeline 用"硬检查点"确保流程完整。
设计亮点：注意 Step 2 那句"Do NOT proceed to Step 3 until user confirms"——这就是钻石门禁。Agent 不能自己跳过，必须等人工确认。这对保证质量至关重要。
七、如何选择合适的模式？
用一个决策树来帮你选：
你的任务是什么？
│
┌────────────────┼────────────────┐
↓ ↓ ↓
让 Agent 懂某 需要输出固定 需要检查/评审
个库/规范 格式的内容
↓ ↓ ↓
Tool Wrapper Generator Reviewer
↓ ↓
需求复杂、易 多步骤任务、
理解错 不能跳步
↓ ↓
Inversion Pipeline
简单说：
| 场景 | 模式 |
|---|---|
| 只需要让 Agent 懂某个库 | Tool Wrapper |
| 需要输出固定格式 | Generator |
| 需要检查、评审 | Reviewer |
| 需求复杂、容易理解错 | Inversion |
| 任务多步骤、不能跳步 | Pipeline |
八、模式可以组合
这五种模式不是互斥的，而是可以组合使用。
举个例子：
- 一个 Pipeline 可以在最后加一个 Reviewer 步骤，自己检查自己的工作
- 一个 Generator 可以先用 Inversion 模式收集必要信息，再填充模板
ADK 的 SkillToolset 和渐进式上下文加载机制，让 Agent 只在需要的时候才加载对应的 Skill。这意味着组合使用不会炸 token——该用哪个就用哪个。
九、结语
看完这五种模式，有三点感悟：
第一，格式已死，设计永生。SKILL.md 的 YAML、目录结构，这些已经标准化了，再卷也卷不出花。真正的竞争力在于：你能不能把业务逻辑抽象成合适的设计模式。
第二，每种模式都在对抗 Agent 的"本能"。Agent 天生爱猜、爱跳步、爱一次性输出。这五种模式，本质上都是"约束"——约束 Agent 按规矩办事。好的设计，就是好的约束。
第三，组合才是王道。单一模式能解决的问题有限。真正复杂的生产场景，往往是 Pipeline + Reviewer + Tool Wrapper 的组合拳。把 Atomic Skill 设计好，让它们能灵活编排，这才是架构师的价值。
写 Skill 就像写代码，抽象对了，事半功倍。
参考资料
- 5 Agent Skill design patterns every ADK developer should know - Google Cloud Tech
- Agent Development Kit (ADK) - Google
相关阅读：