整理文件路径：Technical→AI/
This commit is contained in:
@@ -1,106 +0,0 @@
|
||||
---
|
||||
title: 继Anthropic后，Google放出5个常用的Agent Skill设计模式
|
||||
source:
|
||||
author: shenwei
|
||||
published:
|
||||
created:
|
||||
description:
|
||||
tags: []
|
||||
---
|
||||
|
||||
# 继Anthropic后，Google放出5个常用的Agent Skill设计模式
|
||||
|
||||
**作者:** winkrun
|
||||
**来源:** https://mp.weixin.qq.com/s/yu120tW0l4DJAJfWmbJYxg
|
||||
**公众号:** AI工程化
|
||||
**日期:** 2026年3月19日 06:12
|
||||
**标签:** Agent、Skill、设计模式、Google、Anthropic
|
||||
|
||||
---
|
||||
|
||||
如果你也在写Agent Skills，应该会发现一个尴尬的事实：SKILL.md的格式已经标准化了，三十多个主流工具（Claude Code、Gemini CLI、Cursor……）都支持同一种写法。格式不再是问题，但很多人写着写着就发现——同样格式的skill，执行效果天差地别。
|
||||
|
||||
问题出在内容设计上。同样是一个skill，包装FastAPI规范和实现一个四步文档流水线，内部的逻辑结构完全不同，但外在看起来一模一样。Google Cloud最新发布的这份指南，由Saboo_Shubham_和lavinigam撰写，就是专门解决这个问题的。
|
||||
|
||||
这份指南总结了**五种经过验证的设计模式**，每种都有完整的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。
|
||||
|
||||
---
|
||||
|
||||
## 相关链接
|
||||
|
||||
- 原文：https://x.com/i/article/2033941492633362432
|
||||
- awesome-agent-skills：https://github.com/skillmatic-ai/awesome-agent-skills
|
||||
|
||||
---
|
||||
|
||||
## 附录：Anthropic 的 Skill 实践
|
||||
|
||||
> Anthropic 把内部几百个 Skills 用了个遍，发现最好的 Skill 不是写得好的提示词，而是一个「工具箱」。他们把 Skills 分成九类，从参考手册到故障排查，每类都有明确的场景。写好 Skill 的三条铁律：只写 Agent 不知道的东西、重点写踩坑清单、给工具不给指令。
|
||||
|
||||
- Anthropic工程师分享的Claude Code技能设计指南：9种类型与实战技巧 https://wink.run/pings/content/111668?from=wx
|
||||
Reference in New Issue
Block a user