星辉: 保存微信公众号文章-Google-5个Agent-Skill设计模式-2026-03-19
This commit is contained in:
@@ -0,0 +1,96 @@
|
||||
# 继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