每个ADK开发者都应该了解的5种 Agent Skill 设计模式

每个ADK开发者都应该了解的5种 Agent Skill 设计模式

每个ADK开发者都应该了解的5种 Agent Skill 设计模式 每个ADK开发者都应该了解的5种 Agent Skill 设计模式 Modified March 18 在这个技术报告生成器示例中,技能文件并不包含实际的布局或语法规则。它只是协调这些资源的检索,并强制Agent按步骤执行它们: Code block Plain Text Copy skills/report generator/SKILL.md name: report generator description: Generates structured technical reports in Markdown. Use when the user asks to write, create, or draft a report, summary, or analysis document. metadata: pattern: generator output format: markdown You are a technical report generator. Follow these steps exactly: Step 1: Load 'references/style guide.md' for tone and formatting rules. Step 2: Load 'assets/report template.md' for the required output structure. Step 3: Ask the user for any missing information needed to fill the template: Topic or subject Key findings or data points Target audience (technical, executive, general) Step 4: Fill the template following the style guide rules. Every section in the template must be present in the output. Step 5: Return the completed report as a single Markdown document. 模式3:评审者 审查者模式将检查内容与检查方式分离开来。与其编写一个冗长的系统提示来详细说明每一种代码异味,不如将模块化的评分标准存储在 𝚛𝚎𝚏𝚎𝚛𝚎𝚗𝚌𝚎𝚜/𝚛𝚎𝚟𝚒𝚎𝚠 𝚌𝚑𝚎𝚌𝚔𝚕𝚒𝚜𝚝.𝚖𝚍 文件中。 当用户提交代码时,Agent会加载此检查清单,并对提交内容进行评分,按严重程度对检查结果进行分组。如果将Python风格的检查清单替换为OWASP安全检查清单,你将使用完全相同的技能基础设施进行完全不同的、专门的审计。这是一种非常有效的方法,可以自动进行PR审查,或在人工查看代码之前发现漏洞。 以下代码审查员技能展示了这种分离。指令保持静态,但Agent会从外部检查表中动态加载特定的审查标准,并强制生成基于严重程度的结构化输出: Code block Plain Text Copy skills/code reviewer/SKILL.md name: code reviewer description: Reviews Python code for quality, style, and common bugs. Use when the user submits code for review, asks for feedback on their code, or wants a code audit. 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' for the complete review criteria. Step 2: Read the user's code carefully. Understand its purpose before critiquing. Step 3: Apply each rule from the checklist to the code. For every violation found: Note the line number (or approximate location) Classify severity: error (must fix), warning (should fix), info (consider) Explain WHY it's a problem, not just WHAT is wrong Suggest a specific fix with corrected code Step 4: Produce a structured review with these sections: Summary : What the code does, overall quality assessment Findings : Grouped by severity (errors first, then warnings, then info) Score : Rate 1 10 with brief justification Top 3 Recommendations : The most impactful improvements 模式4:倒置 智能体本质上倾向于立即猜测和生成内容。反转模式改变了这种动态。与用户发起提示、智能体执行不同,智能体扮演面试官的角色。 倒置依赖明确、不可协商的门控指令(比如“在所有阶段完成之前不要开始构建”),从而迫使智能体首先收集上下文信息。它会按顺序提出结构化问题,并在进入下一阶段之前等待你的回答。在全面了解你的需求和部署限制之前,智能体不会生成最终输出。 要了解实际运作情况,可以查看这个项目规划师技能。这里的关键要素是严格的分阶段执行和明确的把关提示,后者会阻止智能体在收集到所有用户答案之前就合成最终计划: Code block Plain Text Copy skills/project planner/SKILL.md name: project planner description: Plans a new 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' for the output format 2. Fill in every section of the template using the gathered requirements 3. Present the completed plan to the user 4. Ask: "Does this plan accurately capture your requirements? What would you change?" 5. Iterate on feedback until the user confirms 模式5:管道 对于复杂任务,你不能容忍跳过步骤或忽略指令。管道模式通过严格的检查点强制执行严格的顺序工作流程。 指令本身就作为工作流定义。通过实施明确的菱形判定条件(例如在从文档字符串生成进入最终组装之前需要用户批准),管道确保Agent无法绕过复杂任务并提交未经验证的最终结果。 这种模式利用了所有可选目录,仅在需要的特定步骤引入不同的参考文件和模板,从而保持上下文窗口的简洁。 在这个文档处理流程示例中,请注意明确的关卡条件。在用户确认上一步生成的文档字符串之前,Agent被明确禁止进入组装阶段: Code block Plain Text Copy 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 each step in order. Do NOT skip steps or proceed if a step fails. Step 1 — 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?" Step 2 — Generate Docstrings For each function 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 Do NOT proceed to Step 3 until the user confirms. Step 3 — Assemble Documentation Load 'assets/api doc template.md' for the output structure. Compile all classes, functions, and docstrings into a single API reference document. Step 4 — 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模式 每个模式都回答一个不同的问题。使用此决策树为你的用例找到合适的模式: 在这个技术报告生成器示例中,技能文件并不包含实际的布局或语法规则。它只是协调这些资源的检索,并强制Agent按步骤执行它们: 模式3:评审者 审查者模式将检查内容与检查方式分离开来。与其编写一个冗长的系统提示来详细说明每一种代码异味,不如将模块化的评分标准存储在 𝚛𝚎𝚏𝚎𝚛𝚎𝚗𝚌𝚎𝚜/𝚛𝚎𝚟𝚒𝚎𝚠 𝚌𝚑𝚎𝚌𝚔𝚕𝚒𝚜𝚝.𝚖𝚍 文件中。 当用户提交代码时,Agent会加载此检查清单,并对提交内容进行评分,按严重程度对检查结果进行分组。如果将Python风格的检查清单替换为OWASP安全检查清单,你将使用完全相同的技能基础设施进行完全不同的、专门的审计。这是一种非常有效的方法,可以自动进行PR审查,或在人工查看代码之前发现漏洞。 以下代码审查员技能展示了这种分离。指令保持静态,但Agent会从外部检查表中动态加载特定的审查标准,并强制生成基于严重程度的结构化输出: 模式4:倒置 智能体本质上倾向于立即猜测和生成内容。反转模式改变了这种动态。与用户发起提示、智能体执行不同,智能体扮演面试官的角色。 倒置依赖明确、不可协商的门控指令(比如“在所有阶段完成之前不要开始构建”),从而迫使智能体首先收集上下文信息。它会按顺序提出结构化问题,并在进入下一阶段之前等待你的回答。在全面了解你的需求和部署限制之前,智能体不会生成最终输出。 要了解实际运作情况,可以查看这个项目规划师技能。这里的关键要素是严格的分阶段执行和明确的把关提示,后者会阻止智能体在收集到所有用户答案之前就合成最终计划: 模式5:管道 对于复杂任务,你不能容忍跳过步骤或忽略指令。管道模式通过严格的检查点强制执行严格的顺序工作流程。 指令本身就作为工作流定义。通过实施明确的菱形判定条件(例如在从文档字符串生成进入最终组装之前需要用户批准),管道确保Agent无法绕过复杂任务并提交未经验证的最终结果。 这种模式利用了所有可选目录,仅在需要的特定步骤引入不同的参考文件和模板,从而保持上下文窗口的简洁。 在这个文档处理流程示例中,请注意明确的关卡条件。在用户确认上一步生成的文档字符串之前,Agent被明确禁止进入组装阶段: 选择合适的Agent Skill模式 每个模式都回答一个不同的问题。使用此决策树为你的用例找到合适的模式: 最后,模式相互组合 这些模式并非相互排斥,而是相互组合的。 流水线技能可以在末尾包含一个审核步骤,以对自身工作进行二次检查。生成器可以在最开始依赖反转来收集必要的变量,然后再填充其模板。得益于ADK的技能工具集和渐进式披露,你的Agent在运行时仅在其所需的精确模式上消耗上下文token。 别再试图把复杂且脆弱的指令塞进单一的系统提示里了。拆解你的工作流程,运用正确的结构模式,打造可靠的智能体。 立即开始 《Agent Skil规范》是开源的,并且在ADK中可以得到原生支持。你已经知道如何打包格式,现在你也知道如何设计内容了。那就去构建更智能的Agent吧。 👉Google Agent Development Kit Google Agent Development Kit 🔗 原文链接: https://x.com/GoogleCloudTech/statu... https://x.com/GoogleCloudTech/statu... 说到 𝚂𝙺𝙸𝙻𝙻.𝚖𝚍,开发者往往会执着于格式——确保 YAML 无误、构建目录结构并遵循规范。但随着 30 多种Agent工具(如 Claude Code、Gemini CLI 和 Cursor)都采用相同的布局进行标准化,格式问题实际上已经过时了。 当前的挑战在于内容设计。规范解释了如何打包技能,但对于如何构建技能内部的逻辑却毫无指导。例如,一个封装了FastAPI约定的技能与一个四步文档流程的操作方式完全不同,尽管它们的SKILL.md文件从外观上看是一样的。 通过研究技能在整个生态系统中是如何构建的——从Anthropic的代码库到Vercel和谷歌的内部指南——有五种反复出现的设计模式可以帮助开发者构建智能体。 By @Saboo Shubham and @lavinigam @Saboo Shubham @lavinigam 本文将结合有效的ADK代码对每一项进行介绍: • 工具包装器:让你的智能体瞬间成为任何库的专家 • 生成器:从可复用的模板生成结构化文档 • 审核人:根据严重程度对照检查表对代码进行评分 • 反转:Agent在行动前会先询问你 • Pipeline:通过检查点实施严格的多步骤工作流程 模式1:工具包装器 工具包装器为你的智能体提供特定库的上下文。你可以将 API 打包成一项技能,而不是将其硬编码到系统提示中。智能体只有在实际使用该技术时才会加载这个上下文。 这是最简单的实现模式。𝚂𝙺𝙸𝙻𝙻.𝚖𝚍文件会监听用户提示中的特定关键字,从𝚛𝚎𝚏𝚎𝚛𝚎𝚗𝚌𝚎𝚜/目录动态加载内部文档,并将这些规则作为绝对真理来应用。这正是你用来将团队的内部编码指南或特定框架最佳实践直接融入到开发人员工作流程的机制。 以下是一个工具包装器的示例,它教会Agent如何编写FastAPI代码。请注意,这些说明是如何明确告知Agent仅在开始审查或编写代码时才加载𝚌𝚘𝚗𝚟𝚎𝚗𝚝𝚒𝚘𝚗𝚜.𝚖𝚍文件的: 模式2:生成器 工具包装器负责应用知识,而生成器则确保输出的一致性。如果您在使用Agent时遇到每次运行都会生成不同文档结构的问题,生成器可以通过编排填空过程来解决这个问题。 它利用两个可选目录:𝚊𝚜𝚜𝚎𝚝𝚜/ 用于存放输出模板,而 𝚛𝚎𝚏𝚎𝚛𝚎𝚗𝚌𝚎𝚜/ 用于存放样式指南。指令起到项目管理的作用。它们指示Agent加载模板、读取样式指南、向用户询问缺失的变量,并填充文档。这对于生成可预测的 API 文档、标准化提交消息或搭建项目架构非常实用。

在 小宇宙note 阅读完整内容