转：Agent Skill也有了设计模式 - 简书

Rolei_zl

433人浏览 · 2026-03-31 07:07:55

Rolei_zl · 2026-03-31 07:07:55 发布

Agent Skill也有了设计模式 - 简书

openclaw有哪些好用的skill

5 Agent Skill Design Patterns every ADK Developer Should Know

5 Agent Skill Design Patterns @GoogleCloudTech

5 Agent Skill Design Patterns every ADK Developer Should Know

原文链接：https://x.com/GoogleCloudTech/status/2033953579824758855文章来源：Google Cloud Tech (@GoogleCloudTech)摘录时间：2026-03-20

5 种 Agent Skill 设计模式

原文（English）	译文（中文）
When it comes to SKILL.md, developers tend to fixate on the format—getting the YAML right, structuring directories, and following the spec. But with more than 30 agent tools standardizing on the same layout, the formatting problem is practically obsolete.	关于 SKILL.md，开发者往往执着于格式——写对 YAML、整理目录、遵循规范。但当 30 多个 agent 工具都采用相同布局时，格式问题已基本解决。
The challenge now is content design. The specification explains how to package a skill, but offers zero guidance on how to structure the logic inside it.	现在的挑战是内容设计。规范只解释了如何打包一个技能，但完全没有指导如何构建内部逻辑。
By studying how skills are built across the ecosystem, there are five recurring design patterns: Tool Wrapper, Generator, Reviewer, Inversion, Pipeline.	通过研究整个生态中技能构建方式，发现了五种常见设计模式：Tool Wrapper、Generator、Reviewer、Inversion、Pipeline。

Pattern 1: The Tool Wrapper（工具包装器）

原文（English）	译文（中文）
A Tool Wrapper gives your agent on-demand context for a specific library. Instead of hardcoding API conventions into your system prompt, you package them into a skill.	Tool Wrapper 为 agent 提供按需加载的特定库上下文。不必将 API 规范硬编码到系统提示中，而是将它们打包成技能。
The SKILL.md file listens for specific library keywords in the user's prompt, dynamically loads your internal documentation from the `references/` directory, and applies those rules as absolute truth.	SKILL.md 文件监听用户提示中的特定库关键词，从 `references/` 目录动态加载内部文档，并将这些规则作为绝对真理应用。
Example: A Tool Wrapper that teaches an agent how to write FastAPI code. Notice how it tells the agent to load `references/conventions.md` only when it starts reviewing or writing code.	示例：教 agent 如何编写 FastAPI 代码的 Tool Wrapper。注意它如何指示 agent 仅在开始审查或编写代码时才加载 `references/conventions.md`。

# skills/api-expert/SKILL.md name: api-expert description: FastAPI development best practices. Use when building, reviewing, or debugging FastAPI applications.

Pattern 2: The Generator（生成器）

原文（English）	译文（中文）
While the Tool Wrapper applies knowledge, the Generator enforces consistent output. If you struggle with an agent generating different document structures on every run, the Generator solves this by orchestrating a fill-in-the-blank process.	Tool Wrapper 应用知识，而 Generator 强制一致的输出。如果你苦恼于 agent 每次运行生成不同的文档结构，Generator 通过"填空"流程解决了这个问题。
It leverages two optional directories: `assets/` holds your output template, and `references/` holds your style guide.	它利用两个可选目录：`assets/` 存放输出模板，`references/` 存放样式指南。

Pattern 3: The Reviewer（审查器）

原文（English）	译文（中文）
The Reviewer pattern separates what to check from how to check it. You store a modular rubric inside `references/review-checklist.md`.	Reviewer 模式将检查什么和如何检查分离。你将模块化的评分规则存放在 `references/review-checklist.md` 中。
When a user submits code, the agent loads this checklist and methodically scores the submission, grouping its findings by severity.	当用户提交代码时，agent 加载此检查清单并系统地评分，按严重程度分组发现的问题。

Reviewer 输出格式：

Summary：代码概述，总体质量评估
Findings：按严重程度分组（error → warning → info）
Score：1-10 分及简短理由
Top 3 Recommendations：最影响重大的改进建议

Pattern 4: Inversion（反转）

原文（English）	译文（中文）
Agents inherently want to guess and generate immediately. The Inversion pattern flips this dynamic. Instead of the user driving the prompt and the agent executing, the agent acts as an interviewer.	Agent 天生想要立即猜测和生成。Inversion 模式反转了这种动力。不再是用户驱动提示、agent 执行，而是 agent 充当采访者。
Inversion relies on explicit, non-negotiable gating instructions (like "DO NOT start building until all phases are complete") to force the agent to gather context first.	Inversion 依赖明确的、不可协商的门控指令（如"所有阶段完成前不要开始构建"），迫使 agent 先收集上下文。

典型流程：

Phase 1：问题发现（一次问一个问题，等待回答）
Phase 2：技术约束（Phase 1 全部回答后才开始）
Phase 3：综合（所有问题回答后才开始合成最终输出）

Pattern 5: The Pipeline（流水线）

原文（English）	译文（中文）
For complex tasks, you cannot afford skipped steps or ignored instructions. The Pipeline pattern enforces a strict, sequential workflow with hard checkpoints.	对于复杂任务，不能容忍跳过步骤或忽略指令。Pipeline 模式通过硬关卡强制严格的顺序工作流程。
The instructions themselves serve as the workflow definition. By implementing explicit gate conditions (such as requiring user approval before moving to the next step), the Pipeline ensures an agent cannot bypass a step and present an unvalidated final result.	指令本身就是工作流程定义。通过实现明确的门控条件（如进入下一步前需要用户批准），Pipeline 确保 agent 无法绕过步骤并呈现未经验证的最终结果。

Pipeline 示例结构：

Step 1 — Parse & Inventory（解析并清点） Step 2 — Generate（生成）← 用户确认后才到下一步 Step 3 — Assemble（组装） Step 4 — Quality Check（质量检查）

选择正确的模式

模式	回答的问题	典型场景
Tool Wrapper	如何让 agent 按需获取特定库知识？	代码规范、特定框架最佳实践
Generator	如何让 agent 输出一致的文档结构？	标准化报告、API 文档、项目脚手架
Reviewer	如何系统化、结构化地审查代码？	PR 审查、漏洞检查、质量审计
Inversion	如何在 agent 行动前强制收集完整需求？	项目规划、系统设计、需求访谈
Pipeline	如何确保复杂任务不跳步、可审计？	多步骤文档流水线、完整构建流程

模式可以组合

原文（English）	译文（中文）
These patterns are not mutually exclusive. They compose.	这些模式并非互斥，可以组合。
A Pipeline skill can include a Reviewer step at the end to double-check its own work.	Pipeline 技能可以在末尾包含一个 Reviewer 步骤来复检自己的输出。
A Generator can rely on Inversion at the very beginning to gather the necessary variables before filling out its template.	Generator 可以在开头依赖 Inversion 来收集必要变量，然后再填充模板。

Thanks to ADK's SkillToolset and progressive disclosure, your agent only spends context tokens on the exact patterns it needs at runtime.

核心结论

Stop trying to cram complex and fragile instructions into a single system prompt. Break your workflows down, apply the right structural pattern, and build reliable agents.

不要再试图将复杂而脆弱的指令塞进单一系统提示中。将工作流程拆分，应用正确的结构模式，构建可靠的 agent。

整理自 Google Cloud Tech @GoogleCloudTech，2026年3月18日

Agent Skill也有了设计模式

本文基于 Google Cloud Tech 发布的《5 Agent Skill design patterns every ADK developer should know》，聊聊 Skill 开发中常见的问题和五种实用设计模式。

Skill 开发的那些坑

Claude Code、Gemini CLI、Cursor 这些工具都在用 SKILL.md 这个格式。Claude Code 团队提过，现在超过 30 种 Agent 工具都采用了这个标准——格式问题算是解决了。

但新问题冒出来了：内容该怎么设计？
实际开发中，开发者经常遇到这些情况：
Agent 太爱"猜"了。 你给一句模糊需求，它立马开始生成，而不是先问清楚你到底想要什么。结果经常跑偏。
复杂任务容易"跳步"。 明明要求先做 A 再做 B，它可能直接跳到 C，或者漏掉关键步骤，给你一个"差不多"的结果。
输出不稳定。 同样的需求跑两次，生成的文档结构可能完全不一样。没有模板约束，Agent 就像脱缰野马。
检查标准混乱。 想让 Agent 帮你审查代码，却不知道该检查什么、怎么评分。把规则写进系统提示里，又难以复用和替换。
所有逻辑都往系统提示里塞。 复杂的指令越写越长，越来越脆弱，改一处可能崩全局。
这些问题，说白了就是缺乏结构化的设计思路。Google Cloud Tech 的团队研究了大量实际案例后，总结出了五种常见的设计模式。

五种设计模式

模式一：Tool Wrapper（工具包装器）

解决什么问题：Agent 对特定库/框架不够熟悉，或者团队内部规范难以统一分发。
核心思路：不要把库的用法硬编码到系统提示里，而是打包成 Skill。SKILL.md 监听用户提示中的关键词，动态从 references/ 目录加载对应的规范文档。
举个例子：你们团队有一套 FastAPI 开发规范，可以做成 Tool Wrapper Skill。只有当 Agent 在审查或编写 FastAPI 代码时，才会加载 conventions.md，把这些规则当作"绝对真理"来执行。
效果：Agent 瞬间变成特定领域的专家，团队规范也能标准化分发。

模式二：Generator（生成器）

解决什么问题：Agent 每次生成的文档结构都不一样，输出不可预测。
核心思路：用 assets/ 存放输出模板，用 references/ 存放风格指南。Skill 的指令充当"项目经理"，协调这些资源，并主动询问用户缺失的变量，最后填充到模板里。
举个例子：技术报告生成器 Skill 可以分 5 步执行：加载风格指南 → 加载模板 → 询问缺失信息 → 填充模板 → 返回完整报告。
效果：输出格式高度一致，不再担心"这次生成的和上次不一样"。

模式三：Reviewer（审查器）

解决什么问题：代码审查标准不统一，难以自动化；或者想换一套审查标准（比如从 Python 风格换成安全审计），得重写整个 Skill。
核心思路：把"检查什么"和"如何检查"分离。将评分标准存储在 references/review-checklist.md 中，Agent 加载后系统性评分，并按严重程度分组输出发现的问题。
举个例子：Python 代码审查 Skill 的输出包含：摘要、发现（按严重程度分组）、1-10 分评分、前 3 项改进建议。
效果：把 review-checklist.md 换成 OWASP 安全检查清单，你就得到了一个完全不同的安全审计 Skill。模块化，可替换。

模式四：Inversion（反转）

解决什么问题：Agent 固有的"猜测并立即生成"倾向，导致输出偏离需求。
核心思路：翻转用户驱动提示和 Agent 执行的动态关系。让 Agent 充当"采访者"，按顺序提出结构化问题，等待用户回答后才进入下一阶段。使用明确的门控指令（如"在所有阶段完成前不要开始构建"）来约束行为。
举个例子：项目规划 Skill 分 3 个阶段：问题发现 → 技术约束 → 综合。每个阶段必须完全回答后，才能进入下一阶段。
效果：Agent 不再瞎猜，而是先充分收集信息，再综合输出。输出质量显著提升。

模式五：Pipeline（流水线）

解决什么问题：复杂任务中 Agent 跳过步骤、忽略指令，或呈现未经验证的结果。
核心思路：指令本身作为工作流定义，实现明确的"菱形门"条件（如需要用户批准才能进入下一阶段）。确保 Agent 无法绕过复杂任务，也利用可选目录在特定步骤才加载需要的参考文件。
举个例子：文档生成流水线 Skill 分 4 步：解析与清单 → 生成文档字符串 → 组装文档 → 质量检查。每步都有明确的门控条件。
效果：复杂任务被拆解为可管理的步骤，每步都可控、可验证。