刚刷到 Google 的一篇Skill设计模式硬核分享，讲得很透彻，内容干货满满，赶紧翻译成中文，慢慢研究！
以下是原文翻译：
5个Agent Skill设计模式
开发者在编写Agent技能（SKILL.md）时，最爱纠结 YAML 写得对不对、目录结构漂不漂亮、符不符合规范……但现在呢？Claude Code、Gemini CLI、Cursor 等 30 多个代理工具已经全部统一了SKILL.md规范，格式问题基本过时了。
现在的真正挑战是内容设计。
规范只告诉你如何打包一个“技能”（skill），却完全没有指导你如何构建它内部的逻辑结构。例如，一个封装 FastAPI 约定的技能，其运行方式与一个四步文档管道完全不同——尽管它们的外层 𝚂𝙺𝙸𝙻𝙻.𝚖𝚍 文件看起来一模一样。
通过研究整个生态系统中技能的构建方式——从 Anthropic 的仓库，到 Vercel，再到 Google 的内部指南——我们总结出 五个反复出现的经典设计模式，它们能帮助开发者构建出更可靠的代理。
作者：@SabooShubham和@lavinigam
本文逐一讲解这五个模式，并附上可直接运行的 ADK 代码示例：
- Tool Wrapper
：让你的代理瞬间成为任何库的专家 - Generator
：从可重用模板生成结构化文档 - Reviewer
：对照检查清单按严重程度对代码评分 - Inversion
：代理先采访你，再开始行动 - Pipeline
：强制执行严格的多步工作流，并设置检查点
模式 1：Tool Wrapper（工具封装器）
Tool Wrapper 能让你的代理按需获取特定库的上下文知识。不要把 API 约定硬编码进系统提示，而是打包成一个技能。只有当代理真正要使用该技术时，才会加载这个上下文。
这是最简单的实现模式。𝚂𝙺𝙸𝙻𝙻.𝚖𝚍 文件会监听用户提示中的特定库关键词，然后动态从 𝚛𝚎𝚏𝚎𝚛𝚎𝚗𝚌𝚎𝚜/ 目录加载内部文档，并将其作为绝对真理应用。这正是你把团队内部编码规范或特定框架最佳实践直接分发到开发者工作流中的机制。
下面是一个教代理如何编写 FastAPI 代码的 Tool Wrapper 示例。注意指令明确告诉代理：只有在开始审查或编写代码时，才加载 𝚌𝚘𝚗𝚟𝚎𝚗𝚝𝚒𝚘𝚗𝚜.𝚖𝚍 文件。
# skills/api-expert/SKILL.md
---
name:api-expert
description:FastAPIdevelopmentbestpracticesandconventions.Usewhenbuilding,reviewing,ordebuggingFastAPIapplications,RESTAPIs,orPydanticmodels.
metadata:
pattern:tool-wrapper
domain:fastapi
---
YouareanexpertinFastAPIdevelopment.Applytheseconventionstotheuser'scodeorquestion.
## Core Conventions
Load'references/conventions.md'forthecompletelistofFastAPIbestpractices.
## When Reviewing Code
1.Loadtheconventionsreference
2.Checktheuser'scodeagainsteachconvention
3.Foreachviolation,citethespecificruleandsuggestthefix
## When Writing Code
1.Loadtheconventionsreference
2.Followeveryconventionexactly
3.Addtypeannotationstoallfunctionsignatures
4.UseAnnotatedstylefordependencyinjection
模式 2：Generator（生成器）
Tool Wrapper 是应用知识，而 Generator 则是强制输出一致性。如果你经常遇到代理每次生成文档结构都不一样的问题，Generator 通过“填空”流程来彻底解决。
它利用两个可选目录：𝚊𝚜𝚜𝚎𝚝𝚜/ 存放输出模板，𝚛𝚎𝚏𝚎𝚛𝚎𝚗𝚌𝚎𝚜/ 存放风格指南。指令扮演项目经理角色，告诉代理加载模板、阅读风格指南、向用户询问缺失变量，然后填充文档。这非常适合生成可预测的 API 文档、标准化提交信息，或搭建项目架构。
在这个技术报告生成器示例中，技能文件本身并不包含实际布局或语法规则，它只是协调资产的检索，并强制代理一步步执行。
# skills/report-generator/SKILL.md
---
name:report-generator
description:GeneratesstructuredtechnicalreportsinMarkdown.Usewhentheuseraskstowrite,create,ordraftareport,summary,oranalysisdocument.
metadata:
pattern:generator
output-format:markdown
---
You are a technical report generator. Follow these steps exactly:
Step 1:Load'references/style-guide.md'fortoneandformattingrules.
Step 2:Load'assets/report-template.md'fortherequiredoutputstructure.
Step 3: Ask the user for any missing information needed to fill the template:
-Topicorsubject
-Keyfindingsordatapoints
-Targetaudience(technical,executive,general)
Step 4:Fillthetemplatefollowingthestyleguiderules.Everysectioninthetemplatemustbepresentintheoutput.
Step 5:ReturnthecompletedreportasasingleMarkdowndocument.
模式 3：Reviewer（审查器）
Reviewer 模式把“要检查什么”和“如何检查”彻底分开。你不再需要把每个代码坏味道都写进长长的系统提示，而是把模块化的评分表存放在 𝚛𝚎𝚏𝚎𝚛𝚎𝚗𝚌𝚎𝚜/𝚛𝚎𝚟𝚒𝚎𝚠-𝚌𝚑𝚎𝚌𝚔𝚕𝚒𝚜𝚝.𝚖𝚍 文件里。
当用户提交代码时，代理会加载这份清单，有条不紊地打分，并按严重程度分组输出结果。如果你把 Python 风格清单换成 OWASP 安全清单，就能用完全相同的技能架构得到一个完全不同的专业审计。这是一种自动化 PR 审查或在人类审阅前捕捉漏洞的极高效方式。
下面的代码审查器技能展示了这种分离：指令保持静态，但代理会动态加载具体审查标准，并强制输出结构化、按严重程度分类的结果。
# skills/code-reviewer/SKILL.md
---
name:code-reviewer
description:ReviewsPythoncodeforquality,style,andcommonbugs.Usewhentheusersubmitscodeforreview,asksforfeedbackontheircode,orwantsacodeaudit.
metadata:
pattern:reviewer
severity-levels:error,warning,info
---
You are a Python code reviewer. Follow this review protocol exactly:
Step 1:Load'references/review-checklist.md'forthecompletereviewcriteria.
Step 2:Readtheuser'scodecarefully.Understanditspurposebeforecritiquing.
Step 3: Apply each rule from the checklist to the code. For every violation found:
-Notethelinenumber(orapproximatelocation)
-Classify severity:error(mustfix),warning(shouldfix),info(consider)
-ExplainWHYit'saproblem,notjustWHATiswrong
-Suggestaspecificfixwithcorrectedcode
Step 4: Produce a structured review with these sections:
-**Summary**:Whatthecodedoes,overallqualityassessment
-**Findings**:Groupedbyseverity(errorsfirst,thenwarnings,theninfo)
-**Score**:Rate1-10withbriefjustification
-**Top 3 Recommendations**:Themostimpactfulimprovements
模式 4：Inversion（反转模式）
代理天生喜欢直接猜测并立即生成。Inversion 模式彻底翻转这种动态：不是用户驱动提示、代理执行，而是让代理变成面试官。
Inversion 依赖明确的、不可协商的门控指令（例如“在所有阶段完成前，绝不能开始构建”），强制代理先收集上下文。它会按顺序提出结构化问题，并在得到你的回答后才进入下一阶段。代理只有在完全掌握你的需求和部署约束后，才会合成最终输出。
看看这个项目规划器技能示例。关键在于严格的分阶段设计和明确的门控提示——它会阻止代理在收集完所有用户答案前就合成最终计划。
# skills/project-planner/SKILL.md
---
name: project-planner
description: Plans anew software project by gathering requirements through structured questions before producing a plan. Use when the user says "I want to build", "help me plan", "design a system", or"start a new project".
metadata:
pattern: inversion
interaction: multi-turn
---
You are conducting a structured requirements interview. DO NOT start building or designing until all phases are complete.
## Phase 1 — Problem Discovery (ask one question at a time, wait for each answer)
Ask these questions in order. Do not skip any.
- Q1: "What problem does this project solve for its users?"
- Q2: "Who are the primary users? What is their technical level?"
- Q3: "What is the expected scale? (users per day, data volume, request rate)"
## Phase 2 — Technical Constraints (only after Phase 1 is fully answered)
- Q4: "What deployment environment will you use?"
- Q5: "Do you have any technology stack requirements or preferences?"
- Q6: "What are the non-negotiable requirements? (latency, uptime, compliance, budget)"
## Phase 3 — Synthesis (only after all questions are answered)
1. Load 'assets/plan-template.md'forthe output format
2. Fill in every section ofthe template usingthe gathered requirements
3. Present the completed plan tothe user
4. Ask: "Does this plan accurately capture your requirements? What would you change?"
5. Iterate onfeedbackuntiltheuserconfirms
模式 5：Pipeline（流水线）
对于复杂任务，你绝不能允许跳步或忽略指令。Pipeline 模式强制执行严格的顺序工作流，并设置硬检查点。
指令本身就是工作流定义。通过实现明确的菱形门控条件（例如要求用户在从 docstring 生成进入最终组装前必须确认），Pipeline 确保代理无法绕过复杂步骤并给出未经验证的结果。
这个模式会使用所有可选目录，仅在具体步骤需要时才拉取相应的参考文件和模板，从而保持上下文窗口干净。
在这个文档流水线示例中，请注意明确的门控条件：代理被明确禁止在用户确认上一步生成的 docstring 之前进入组装阶段。
# skills/doc-pipeline/SKILL.md
---
name: doc-pipeline
description: Generates API documentation from Python source code through a multi-step pipeline. Use when the user asks to document a module, generate API docs, or create documentation from code.
metadata:
pattern: pipeline
steps: "4"
---
You are running a documentation generation pipeline. Execute eachstepinorder. DoNOTskip steps or proceed if a step fails.
## Step1 — Parse & Inventory
Analyze the user's Python code to extract all public classes, functions, and constants. Present the inventory as a checklist. Ask: "Is this the complete public API you want documented?"
## Step2 — Generate Docstrings
Foreachfunction lacking a docstring:
- Load 'references/docstring-style.md' for the required format
- Generate a docstring following the style guide exactly
- Present each generated docstring for user approval
DoNOT proceed toStep3until the user confirms.
## Step3 — Assemble Documentation
Load 'assets/api-doc-template.md' for the output structure. Compile all classes, functions, and docstrings into a single API reference document.
## Step4 — Quality Check
Review against 'references/quality-checklist.md':
- Every public symbol documented
- Every parameter has a type and description
- At least one usage example per function
Report results. Fix issues before presenting the final document.
如何选择合适的Agent Skill模式
每个模式解决不同的问题。使用下面这张决策树，就能快速找到适合你用例的模式：
最后：模式可以组合使用
这些模式并非互斥，而是可以相互组合。
一个 Pipeline 技能可以在最后嵌入 Reviewer 步骤来双重检查自己的工作；一个 Generator 可以在开头使用 Inversion 来先收集必要变量，再填充模板。得益于 ADK 的 𝚂𝚔𝚒𝚕𝚕𝚝𝚘𝚘𝚕𝚜𝚎𝚝 和渐进式披露机制，你的代理在运行时只会把上下文 token 用在当前真正需要的模式上。
别再试图把复杂而脆弱的指令全部塞进一个系统提示里了。把工作流拆解开，应用正确的结构模式，就能构建出真正可靠的代理。
总结一句：
技能（skill）格式已经不是问题，内容设计才是高手过招的关键！掌握这 5 个模式，你的 AI Agent 会稳很多、聪明很多～
（原帖来自 @GoogleCloudTech，作者 @SabooShubham 和 @lavinigam）