Google Cloud 总结：每位 ADK 开发者都该知道的 5 种 Agent Skill 设计模式

Google Cloud 总结：每位 ADK 开发者都该知道的 5 种 Agent Skill 设计模式

原始链接：https://x.com/GoogleCloudTech/status/2033953579824758855[1] 原作者：Google Cloud Tech，@Saboo_Shubham_，@lavinigam 说明：以下内容为中文整理与翻译版，配图来自原帖。

当越来越多的 Agent 工具开始采用统一的 SKILL.md 结构之后，真正拉开差距的已经不再是“文件格式写得对不对”，而是“技能内容该怎么设计”。

原文的核心观点很清晰：规范只告诉你如何打包一个 Skill，却没有告诉你怎样设计 Skill 内部的逻辑。而在真实开发里，一个封装 FastAPI 规范的 Skill，和一个分 4 步执行的文档流水线 Skill，虽然外表都叫 SKILL.md，但内部结构完全不是一回事。

Google Cloud 将这些常见做法总结成 5 种高频设计模式：

• Tool Wrapper：把某个库或框架的知识即时注入给 Agent
• Generator：按固定模板生成结构化输出
• Reviewer：按清单逐项审查并给出分级结论
• Inversion：先反过来提问，再开始行动
• Pipeline：强制 Agent 按顺序执行复杂流程

模式总览图

一、Tool Wrapper：让 Agent 立刻成为某个技术栈的“领域专家”

Tool Wrapper 的目标，是让 Agent 在处理某个特定技术栈时，按需加载该栈的内部规范，而不是把大量约定硬塞进系统提示词。

这种模式最适合：

• 团队内部编码规范分发
• 特定框架最佳实践注入
• 库级 API 使用约束
• 让 Agent 只在“需要时”加载上下文

它的重点不在于“写很多规则”，而在于：

• 监听用户提问中的特定关键词
• 在命中相关技术栈时，再去加载 references/ 中的资料
• 将这些资料视为该场景下的最高优先级规则

这样一来，Agent 平时不会被无关知识污染，只有在真正处理 FastAPI、React、Pydantic 等问题时，才临时变成该领域的专家。

Tool Wrapper 示意图

二、Generator：把“每次都不一样”变成“稳定输出”

如果你经常遇到 Agent 每次生成的文档结构都不同，那么 Generator 模式就是最直接的解决方案。

它的思路是：

• 把输出结构放到 assets/ 里
• 把语气、格式、风格要求放到 references/ 里
• Skill 本身只负责协调执行顺序

这种模式特别适合：

• 技术报告生成
• API 文档模板化输出
• 周报、总结、方案文档统一格式
• 项目脚手架类文本产物生成

它本质上是在让 Agent 扮演“模板执行器”而不是“自由发挥的写手”。 你不再要求它每次都重新思考文档结构，而是要求它先读模板、再补变量、最后按风格指南填完整份文档。

Generator 示意图

三、Reviewer：把“怎么检查”与“检查什么”拆开

Reviewer 模式的核心，是把审查规则模块化。

传统做法往往把所有代码异味、风格要求、安全要求都写进一大段提示词里，结果既难维护，也很难复用。 而 Reviewer 模式会把检查标准独立放进一个清单，比如：

• references/review-checklist.md

然后让 Agent：

1. 先理解代码在做什么
2. 再按清单一项项审查
3. 对每个问题标记严重级别
4. 给出原因与修复建议

这种模式特别适合：

• PR 自动审查
• 安全清单扫描
• 风格检查
• 质量审计

最大的好处是： 你只需要替换“检查清单”，就能把同一套 Reviewer 结构，切换成 Python 代码审查器、OWASP 安全审查器，或者 API 设计审查器。

Reviewer 示意图

四、Inversion：让 Agent 先采访你，而不是先猜

Agent 天生倾向于“尽快给答案”，但很多场景下，这反而会让它在信息不完整时过早行动。 Inversion 模式就是反过来设计：先提问，后输出。

它通常会加入强约束，例如：

• 在所有阶段完成前，不允许直接开始设计
• 一次只问一个问题
• 必须把需求、约束、用户类型、部署环境都问清楚

这种模式最适合：

• 新项目规划
• 系统设计访谈
• 需求不明确的复杂任务
• 高风险方案生成

它的价值在于： 让 Agent 从“立刻给结论的执行者”，变成“先建立问题模型的采访者”。

Inversion 示意图

五、Pipeline：复杂任务必须按步骤走完，不能跳

当一个任务步骤很多、并且中间结果必须人工确认时，就需要 Pipeline 模式。

这种模式强调：

• 步骤必须串行
• 每一步都有明确输入与输出
• 失败不能跳过
• 关键节点需要人工确认后才能继续

常见适用场景：

• 文档流水线
• 多阶段发布流程
• 审核制生成流程
• 需要阶段性验收的复杂任务

它本质上是把 Skill 写成一个“带关卡的工作流”，而不是一段自由提示词。 Agent 不能直接跳到最后一步给你一个看起来完整、实际上未经验证的结果。

Pipeline 示意图

六、如何选型：先问自己“你真正缺的是什么”

原文给出的判断思路可以归纳成一句话：

• 如果你缺的是“特定知识注入”，选 Tool Wrapper
• 如果你缺的是“固定输出结构”，选 Generator
• 如果你缺的是“标准化审查”，选 Reviewer
• 如果你缺的是“需求澄清”，选 Inversion
• 如果你缺的是“严格流程控制”，选 Pipeline

很多团队一开始就把所有要求塞进一个超长系统提示词，结果提示词越来越脆、越来越难维护。 更好的方式，是把任务拆开，然后针对不同问题选择最合适的结构模式。

模式决策图

七、这些模式不是互斥的，真正强大的是“组合”

这 5 种模式不是“只能选一个”，而是可以组合使用：

• Pipeline 的最后一步可以接一个 Reviewer，自动做质量复核
• Generator 的第一步可以接 Inversion，先把变量问清楚
• Tool Wrapper 可以被嵌入进更复杂的流程节点里

换句话说，模式本身不是目的，可维护、可验证、可复用的 Agent 结构才是目的。

模式可组合示意图

八、结语

这篇内容最值得记住的一点，不是 5 个模式的名字，而是它背后的设计观：

不要再试图把复杂、脆弱、彼此冲突的指令都塞进一条系统提示词。 更稳妥的做法，是把任务拆成结构清晰的模式，再让 Agent 在运行时按需加载对应的上下文与步骤。

格式规范解决的是“怎么打包”。 而这 5 种模式解决的是“怎么设计 Skill 的灵魂”。

原文来源

• Google Cloud Tech on X: https://x.com/GoogleCloudTech/status/2033953579824758855[2]

引用链接

[1]https://x.com/GoogleCloudTech/status/2033953579824758855

[2]https://x.com/GoogleCloudTech/status/2033953579824758855