Skill开发黄金法则！谷歌放出5种智能体Skill设计模式

谷歌放出5种智能体 Skill 设计模式。

这是谷歌工程师研究整个 Skill 开发生态，从中浓缩出来的 5 条黄金法则。

该文章完全忠于原文翻译整理，养虾人学习起来：

提到 𝚂𝙺𝙸𝙻𝙻.𝚖𝚍，开发者往往会专注于格式：确保 YAML 格式正确无误、构建目录结构以及遵循规范。

但是，随着超过 30 种 Agent 工具（如 Claude Code、Gemini CLI 和 Cursor）在同一套布局上实现标准化，格式问题实际上已经不存在了。

现在的挑战在于内容设计。

规范虽然解释了如何打包一个 Skill，但对于如何构建其内部的逻辑却未提供任何指导。

例如，一个封装 FastAPI 约定的 Skill 与一个包含四个步骤的文档处理流水线（pipeline）运作方式截然不同，尽管它们的 𝚂𝙺𝙸𝙻𝙻.𝚖𝚍 文件在外观上看起来一模一样。

通过研究整个生态系统中（从 Anthropic 的代码库到 Vercel 和 Google 的内部指南）是如何构建这些 Skill 的，我们发现了 5 种反复出现的设计模式，它们可以帮助开发者更好地构建 Agent。

每一种模式，附带可运行的 ADK（Agent Development Kit，智能体开发套件）代码：

• 工具封装器（Tool Wrapper）：让你的 Agent 瞬间成为任何代码库的专家

• 生成器（Generator）：从可复用的模板生成结构化文档

• 审查器（Reviewer）：根据严重程度对照清单对代码进行评分

• 反转（Inversion）：Agent 在执行操作前先对你进行访谈

• 流水线（Pipeline）：强制执行带有检查点的严格多步骤工作流

模式 1：工具封装器（The Tool Wrapper）

工具封装器为你的 Agent 提供关于特定代码库的按需上下文。

你无需将 API 约定硬编码到系统提示词（system prompt）中，而是将它们打包成一个 Skill 。你的 Agent 只有在实际使用该技术时才会加载这个上下文。

这是最容易实现的模式。𝚂𝙺𝙸𝙻𝙻.𝚖𝚍 文件会监听用户提示词中特定代码库的关键字，从 𝚛𝚎𝚏𝚎𝚛𝚎𝚗𝚌𝚎𝚜/ 目录动态加载你们的内部文档，并将这些规则作为绝对真理来应用。

这正是你将团队的内部编码指南或特定框架最佳实践直接分发到开发者工作流中所使用的机制。

以下是一个工具封装器的示例，它教 Agent 如何编写 FastAPI 代码。请注意，指令中明确告诉 Agent 只有在开始审查或编写代码时，才去加载 𝚌𝚘𝚗𝚟𝚎𝚗𝚝𝚒𝚘𝚗𝚜.𝚖𝚍 文件：

模式 2：生成器（The Generator）

工具封装器侧重于应用知识，而生成器则用于强制执行一致的输出。

如果你正苦恼于 Agent 每次运行都会生成不同的文档结构，生成器可以通过精心编排的“填空”过程来解决这个问题。

它利用了两个可选的目录：𝚊𝚜𝚜𝚎𝚝𝚜/ 用于存放你的输出模板，而 𝚛𝚎𝚏𝚎𝚛𝚎𝚗𝚌𝚎𝚜/ 用于存放风格指南。

指令在这里充当项目经理的角色。它们告诉 Agent 加载模板、阅读风格指南、向用户询问缺失的变量，并填充文档。

这对于生成可预测的 API 文档、标准化提交信息（commit messages）或搭建项目架构非常实用。

在这个技术报告生成器的示例中， Skill 文件本身并不包含实际的排版或语法规则。它仅仅负责协调这些资产的检索，并强制 Agent 逐步去执行它们：

模式 3：审查器（The Reviewer）

审查器模式将“检查什么”与“如何检查”分离开来。

你无需编写冗长的系统提示词来详细说明每一个代码异味（code smell），而是将模块化的评分标准存储在 𝚛𝚎𝚟𝚒𝚎𝚠-𝚌𝚑𝚎𝚌𝚔𝚕𝚒𝚜𝚝.𝚖𝚍 文件中。

当用户提交代码时，Agent 会加载此清单并有条理地对提交内容进行评分，按严重程度将其发现进行分组。

如果你将 Python 代码风格检查清单替换为 OWASP 安全检查清单，你就可以使用完全相同的 Skill 基础设施，获得一个截然不同且高度专业化的审计过程。

这是一种非常有效的方法，可以自动化 PR 代码审查，或者在人工查看代码之前捕捉到漏洞。

下面的代码审查器 Skill 演示了这种分离机制。指令保持静态不变，但 Agent 会从外部清单动态加载特定的审查标准，并强制输出基于严重程度的结构化结果：

模式 4：反转（Inversion）

Agent 往往本能地想要立刻进行猜测并生成结果。

反转模式颠覆了这种动态逻辑。不再是用户驱动提示词而 Agent 去执行，而是由 Agent 扮演面试官（访谈者）的角色。

反转模式依赖于明确的、不容妥协的门控指令（例如“在所有阶段完成之前，切勿开始构建”），以强制 Agent 首先收集上下文。

它会按顺序提出结构化问题，并等待你的回答，然后再进入下一个阶段。

在全面掌握你的需求和部署约束条件之前，Agent 会拒绝合成最终的输出结果。

想要了解实际效果，可以看看下面这个项目规划器 Skill 。此处的关键要素是严格的阶段划分和明确的把关提示词，它能够阻止 Agent 在收集完所有用户回答之前合成最终计划：

模式 5：流水线（The Pipeline）

对于复杂的任务，你无法承受遗漏步骤或无视指令所带来的后果。

流水线模式强制执行一个带有硬性检查点（hard checkpoints）、严格按顺序执行的工作流。

指令本身即作为工作流定义。通过实现明确的菱形门控条件（diamond gate conditions）（例如，要求在从生成文档字符串进入最终组装阶段之前必须得到用户批准），流水线确保了 Agent 无法绕过复杂任务并直接给出一个未经充分验证的最终结果。

此模式利用了所有可选目录，仅在需要的特定步骤才提取相应的参考文件和模板，从而保持上下文窗口的干净整洁。

在这个文档处理流水线示例中，请注意那些明确的门控条件。我们明确禁止 Agent 进入组装阶段，除非用户先确认了上一步生成的文档字符串：

每种模式都解决了不同的问题。使用下图这个决策树来为你的用例寻找正确的模式：

这些模式并不是相互排斥的。它们可以进行组合。

一个流水线（Pipeline） Skill 可以在最后包含一个审查器（Reviewer）步骤，以复查其自身的工作。

一个生成器（Generator）可以在最开始依赖反转（Inversion）模式收集必要的变量，然后再填充它的模板。

得益于 ADK 的 𝚂𝚔𝚒𝚕𝚕𝚃𝚘𝚘𝚕𝚜𝚎𝚝 和渐进式披露（progressive disclosure）机制，你的 Agent 只会在运行时为它实际需要的特定模式去消耗上下文 token。

停止尝试将复杂且脆弱的指令全部塞进单一的系统提示词中吧。

拆分你的工作流，应用正确结构的设计模式，并构建可靠的 Agent。

Agent Skills 规范是开源的，并已在整个 ADK 生态中得到原生支持。

你已经了解了如何进行格式打包。现在你也掌握了如何设计其内容。现在，去使用 Google Agent Development Kit 构建更智能的 Agent 吧。