正在编写 Agent Skills 的你，或许已经发现一个尴尬的现实：SKILL.md 的格式已高度标准化，三十多个主流工具（如 Claude Code、Gemini CLI、Cursor 等）都采用同一套写法。格式不再是瓶颈，但很多人写着写着就注意到——即便格式相同，不同 skill 的执行效果却天差地别。

问题的核心在于内容设计。同样是 skill，封装 FastAPI 规范与实现一个四步文档流水线，两者内部的逻辑结构截然不同，但外表看起来一模一样。Google Cloud 最新发布的这份指南（由 Saboo_Shubham_ 和 la vinigam 撰写）正是针对这一痛点而生，它总结了五种经过验证的设计模式，每种都配有完整的 ADK 代码示例。

Tool Wrapper：让 Agent 快速成为特定领域的行家

这是最容易上手的一种模式。简单来说，就是将某个库或框架的规范文档封装成一个 skill，Agent 只有在实际用到该技术时才会加载相关文档。例如，一个面向 FastAPI 的 skill，无需把所有 API 约定都塞进 system prompt。更优的做法是让 SKILL.md 监听特定的库关键词，当用户开始编写 FastAPI 代码时，动态加载 references/ 目录下的 conventions.md，并将这些规则作为绝对准则来执行。

这一模式特别适用于分发团队内部的编码标准或特定框架的最佳实践。

Generator：基于模板生成结构化输出

如果说 Tool Wrapper 是应用知识，那么 Generator 就是强制输出格式的一致性。许多 Agent 每次运行生成的文档结构都不尽相同，Generator 通过一种“填空”流程解决了这个问题。它利用两个可选目录：assets/ 存放输出模板，references/ 存放样式指南。SKILL.md 扮演项目经理的角色，指示 Agent 加载模板、读取样式指南、向用户询问缺失的变量，然后填充文档。

这对于生成统一的 API 文档、标准化的 commit 信息或脚手架项目结构来说，都非常实用。

Reviewer：将检查清单与检查逻辑分离

这是一种非常实用的模式。传统的代码审查常把所有规则都写入 system prompt，结果越写越长。Reviewer 模式则把“检查什么”和“怎么检查”完全分开。审查标准存放在 references/review-checklist.md 中，可以是 Python 风格检查，也可以替换为 OWASP 安全检查——同样的 skill 基础设施，更换清单就能变成完全不同的专项审计。

代码示例展示了一个 Python 代码审查 skill 的结构。指令保持静态，但 Agent 会动态加载特定的审查标准，并强制输出按严重程度分组的结构化结果。

Inversion：Agent 先提问再执行

这是最反直觉的一种模式。Agent 天生倾向于直接猜测和生成，而 Inversion 将这个流程完全反转——Agent 化身面试官，先向你提出一系列问题，等你回答完毕再采取行动。关键在于明确、不可协商的门控指令（例如“不到所有阶段完成就不开始构建”）。Agent 会逐个阶段提问，等待你的答案，然后才进入下一个阶段。

一个项目规划 skill 的示例展示了这一点：必须等用户回答完所有问题，Agent 才会加载 plan-template.md 并生成最终计划。

Pipeline：带有硬性检查点的严格工作流

对于复杂任务，你绝不想承受跳过步骤或忽略指令的风险。Pipeline 模式强制执行严格的顺序工作流，并在关键节点设置硬性检查点。指令本身定义了工作流。通过实现明确的门控条件（例如要求用户在进入下一步之前确认生成的文档字符串），Pipeline 确保 Agent 无法绕过复杂任务直接给出未经验证的最终结果。

一个文档流水线的例子展示了四个步骤：解析与清点、生成文档字符串、组装文档、质量检查。每一步都有明确的前置条件，用户必须在进入下一步之前确认。

如何选择合适的模式

每种模式都有其适用的场景，你可以参考下图来判断哪种更符合你的需求。

这些模式可以组合使用

这一点常被忽略。五种模式并非互斥，而是可以相互组合。例如，Pipeline 可以在最后包含一个 Reviewer 步骤来 double-check 自己的成果；Generator 可以在最开始时依赖 Inversion 来收集必要的变量。得益于 ADK 的 SkillToolset 和渐进式披露机制，Agent 只在运行时需要时才消耗上下文 token 来加载特定的模式。

别再把所有复杂又脆弱的指令都塞进一个 system prompt 了。将工作流拆分开，应用正确的结构模式，才能构建出真正可靠的 Agent。