ADK 开发者必懂的 5 种 Agent Skill 设计模式
出处
来源：原网页
一句话结论
重点已经不是 SKILL.md 怎么写格式，而是 Skill 内部逻辑该怎么设计。这条内容给出的核心价值，是把 Agent Skill 的常见实现方式抽成 5 类可复用模式。
一张图看懂
核心观点
1. 格式问题基本已经不是问题
原帖先指出一个现实：
- 现在已经有 30+ agent tools 在采用相同或类似的 Skill 布局
- 比如 Claude Code、Gemini CLI、Cursor 等
- 所以开发者如果还把精力放在 YAML、目录结构、规范格式上，收益已经很低
核心转向： 现在真正难的是 内容设计，也就是 Skill 里面到底该怎么组织规则、流程、模板和决策逻辑。
2. Skill 规范只解决“包装”，不解决“方法论”
原帖点得很准：
- spec 只告诉你怎么打包 Skill
- 但不会告诉你 Skill 的内部逻辑该怎么组织
- 外表一样的
SKILL.md，内部可能是完全不同的工作机制
举的例子也很典型：
- 一个包 FastAPI 约定的 Skill
- 和一个严格四步文档流水线的 Skill
- 外观看起来格式类似，本质上却是两种完全不同的设计模式
五种 Agent Skill 设计模式
Pattern 1. Tool Wrapper
定义： 给 agent 挂一个“按需加载的领域知识包”。
核心作用：
- 不把某个框架/API 的大量规则硬塞进 system prompt
- 而是在真正遇到对应技术时，再加载这份 Skill
适合场景：
- FastAPI 规范
- Cocos/Unity/React/SQL 等框架约定
- 团队内部代码规范、目录规范、接口规范
本质： 让 agent 在特定技术领域里瞬间变成“带组织经验的专家”。
Pattern 2. Generator
定义： 用固定模板生成结构稳定的输出。
核心作用：
- 避免 agent 每次生成的文档结构都不一样
- 强制它按预设模板填空式输出
适合场景：
- PRD
- 设计文档
- 复盘文档
- 周报/日报
- 标准化知识卡片
本质： 解决“输出不稳定”的问题，让结果可复用、可审阅、可对比。
Pattern 3. Reviewer
定义： 按清单审查，并按严重级别打分或归类。
核心作用：
- 让 agent 不只是给主观建议
- 而是基于 checklist 做结构化审查
- 输出问题等级、依据、修复建议
适合场景：
- 代码 review
- 安全审查
- 设计审查
- 发布前检查
本质： 把“经验判断”变成“规则化评审”。
Pattern 4. Inversion
定义： agent 先反过来采访用户，再开始执行。
核心作用：
- 不急着产出
- 先补齐上下文、目标、限制条件
- 通过提问减少误判和返工
适合场景：
- 需求不清的任务
- 多方案选择
- 高风险执行前的信息确认
- 策略制定类任务
本质： 不是“先做”，而是“先问对问题”。
Pattern 5. Pipeline
定义： 强制多步骤流程，且每一步有检查点。
核心作用：
- 把复杂任务拆成固定阶段
- 每阶段都有明确输入/输出
- 避免 agent 跳步、漏步、乱序执行
适合场景：
- 调研 → 分析 → 方案 → 输出
- 抓取 → 清洗 → 总结 → 发布
- 需求分析 → 实现 → Review → 交付
本质： 把不稳定的大任务，变成可控的流程系统。
我对这 5 种模式的理解
可以把它们分成三层
A. 知识注入型
- Tool Wrapper
解决的是：agent 知不知道该领域该怎么做。
B. 输出约束型
- Generator
- Reviewer
解决的是：agent 输出得稳不稳、是否可检查。
C. 流程控制型
- Inversion
- Pipeline
解决的是：agent 做事顺序是否正确、是否缺上下文、是否容易跑偏。
最重要的启发
1. Skill 不是“提示词文件”，而是“行为模式容器”
很多人把 Skill 当成提示词片段集合，这理解太浅。更准确的看法是：
- Skill 是一种行为设计单元
- 它决定 agent 在某类任务里如何获取知识、如何提问、如何审查、如何生成、如何分步骤执行
2. 真正有价值的是“模式复用”
如果一个团队能把常见任务沉淀成这 5 类模式组合，agent 的稳定性会明显提升。
3. 复杂任务通常不是单一模式
实际落地往往是组合：
- Tool Wrapper + Reviewer
- Inversion + Pipeline
- Generator + Reviewer
也就是说，重点不是死记 5 个名词，而是知道 什么时候该组合什么模式。
对你这种开发工作流最有价值的用法
结合你的实际工作，我认为最值得落地的是这几个方向：
1. Cocos / 游戏项目规范封装成 Tool Wrapper
让 agent 在处理：
- 目录结构
- UI 命名
- 热更资源规范
- 网络协议层约定
- Lua/TS/原生桥接规则 时，自动带上你的团队规则。
2. 版本合并/需求实现做成 Pipeline
比如：
- 先读需求
- 再读差异版本
- 再做冲突点清单
- 再给合并方案
- 最后输出执行建议
3. Code Review 用 Reviewer
把你关心的问题做成清单：
- 可读性
- 空值风险
- 性能风险
- 资源释放
- 平台兼容
- 线上事故风险
4. 需求模糊时强制 Inversion
先问清楚：
- 目标是什么
- 改线上还是新功能
- 有无兼容包袱
- 能不能改协议/配置
- 是否允许动资源结构
这个能大幅减少 agent 一本正经做错方向。