Google 总结了 5 种 Agent Skill 结构：真正决定 Agent 靠不靠谱的，是里面的逻辑
Google Cloud Tech 发了一篇很值得认真看的文章：
x.com/GoogleCloudTech/status/2033953579824758855
现在做 Agent，很多人还在纠结 SKILL.md 该怎么排版、YAML 怎么写、目录怎么放。这些东西，正在快速变成“公共格式”。
真正开始拉开差距的，**一个 Skill 里面，装了什么逻辑。**也就是：
- 哪些经验适合封成 Skill
- 哪些流程适合拆成步骤
- 哪些标准适合做成检查清单
- 哪些任务需要先提问，再执行
- 哪些输出需要模板固定住
Google 这篇文章总结了 5 种常见的 Agent Skill 设计模式：
- Tool Wrapper
- Generator
- Reviewer
- Inversion
- Pipeline
如果正在学 Agent，这 5 个模式很值得优先学习。
因为它们对应的，基本就是以后搭 Agent 时最常见的 5 类任务。
先讲结论：Skill 是一个能力模块
很多人刚接触 Agent，会把 Skill 理解成“更长一点的 prompt”。
更准确一点说，Skill 更像一个可复用的能力模块。
里面装的可以是：
- 某个领域的专家知识
- 某种固定输出模板
- 一套审查规则
- 一套提问访谈流程
- 一条严格执行的多步工作流
当这些东西被整理好以后，Agent 才不只是“会聊天”或者“会生成内容”。
它开始更像一个能稳定调用、可持续复用、能拆能组合的工作单元。
这也是为什么这篇文章值得看。
它讨论的已经不是“怎么让模型回答得更聪明”，而是“怎么让 Agent 变得更可靠”。
模式 1：Tool Wrapper
把某个领域的经验，装进一个随时可调用的专家模块
这个专家平时不一直坐在上下文里。
只有当任务真的涉及某个库、某个框架、某套规则时，才把相关知识加载进来。
文章里举的例子是 FastAPI。
当用户开始写 FastAPI 代码、审查 FastAPI 代码时，Skill 会去加载对应的规范文档，然后按这些规则来执行。
这个思路很重要。
因为很多人现在写 Agent，习惯把一大堆规则长期塞在 system prompt 里。
结果通常是：
- prompt 很长
- context 很脏
- 换一个任务，旧规则还在干扰
- 后期很难维护
Tool Wrapper 的好处，就是把这类专业知识独立出来，按需加载。
落地怎么用
如果把它放到日常工作里，这个模式其实特别实用。
比如做内容工厂时，可以封这些 Skill：
- X 长线程写作规范
- Newsletter 改写规则
- GitHub 项目种草文案结构
- AI 日报筛选标准
- 某个平台的发文格式要求
如果是做开发，也可以封成：
- React 项目规范
- 某个 SDK 的最佳实践
- 内部 API 调用约定
- 团队 code style
对初学者的启发
正在学 Agent 的人，很容易一开始就想做“万能 Agent”。
但更现实的路线，通常是先做一个小专家。
先让 Agent 在某一个点上变得稳定、可控。
比如只负责：
- 按你的风格写 X 内容
- 按固定规范写日报
- 按团队标准检查代码
这样更容易做出结果，也更容易积累自己的 Skill 资产。
模式 2：Generator
把“每次都该长得差不多”的输出，固定成一个生成器
这个模式解决的是一个非常常见的问题：
为什么同一个 Agent，今天输出这个结构，明天又换了一种写法？
如果一个任务本来就需要稳定格式，那最好的办法是提前把模板、风格规则、必要变量都准备好。
它的思路通常是：
- 先加载风格说明
- 再加载输出模板
- 发现信息不够，就先向用户补问题
- 把内容填进模板
- 输出完整成稿
落地怎么用
这个模式太适合内容生产了。
比如可以直接拿来做：
- AI 科技日报
- X 短推 / 长推 / 线程
- 项目分析报告
- 竞品拆解
- 周报 / 月报
- 产品 PRD 初稿
- 调研摘要
- 会议纪要整理
只要你发现某类输出“每次都应该差不多”，就适合 Generator。
为什么它很关键
很多人觉得 Agent 好不好用，取决于模型强不强。
但在实际业务里，更影响体验的，往往是输出稳不稳定。
格式稳定，后面才能批量化。
风格统一，后面才适合持续复用。
模板明确，后面才容易接进工作流。
对我这种学习者有什么参考意义
这类模式特别适合拿来练手。
因为它不要求一上来就做复杂系统。
先从一个最简单的模板型任务开始，就能感受到 Skill 的价值。
比如先做一个：
- “X 文章转短线程生成器”
- “YouTube 转录转 X 长文生成器”
- “GitHub 项目种草生成器”
把模板和风格约束住，很快就能看出前后差别。
模式 3：Reviewer
把“检查标准”单独拿出来，做成一个审核员
这个模式特别实用，它抓住了一个常被忽略的问题：
很多任务，难点是“生成完以后怎么审”。
比如写代码、写文案、写方案、写报告，常见的问题都是：
- 漏信息
- 逻辑跳步
- 风格不统一
- 重点不清楚
- 存在事实错误
- 缺少安全性 / 合规性检查
Reviewer 的思路很直接：
把“检查什么”从主逻辑里拆出来。
主 Skill 负责完成任务。
Reviewer Skill 负责按清单逐项检查。
文章里举的是代码审查。
它会加载 review checklist，然后按严重程度输出问题和建议。
这个模式的妙处在于，Skill 主体几乎不用变。
只要换一份 checklist，审核员就能切换身份。
落地怎么用
对于内容工作流，Reviewer 完全可以变成：
- 文案审核员
- 风格一致性检查员
- 事实核查员
- 结构完整性检查员
- 品牌语气检查员
对于开发流程，它可以变成：
- Python 代码审核员
- 安全审查员
- PR 检查员
- API 文档质量检查员
为什么这一步很重要
因为一个工作流真正开始可用，通常不是“第一次能生成”，而是“生成以后能稳定纠偏”。
很多 Agent 看起来很聪明，但真正落地时问题频出。
往往不是前面不会做，而是后面没人检查。
Reviewer 就是在补这一步。
模式 4：Inversion
不急着执行，先把需求采访清楚
这个理解成“把默认流程反过来”。Inversion。
平常的流程一般是：
用户提一句需求，Agent 马上开始干活。
Inversion 则要求 Agent 先停下来，先问问题，先收集信息。
等信息足够完整，再进入执行阶段。
这个模式特别适合那些需求本来就模糊的任务。
比如用户一上来就说：
- 帮我做个网站
- 帮我做个产品方案
- 帮我搭个工作流
- 帮我做一套内容系统
这类任务如果直接开始生成，方向很容易跑偏。
因为任务真正需要的关键信息，通常还没讲清楚。
Inversion 的价值就在这里：
它强制 Agent 先做需求访谈。
落地怎么用
这个模式很适合做：
- 项目规划助手
- 建站需求收集助手
- 内容工厂搭建顾问
- 产品需求访谈助手
- 业务自动化方案规划器
先问清楚：
- 目标是什么
- 给谁用
- 规模多大
- 限制条件是什么
- 预算和技术偏好是什么
- 哪些要求必须满足
这些信息清楚以后，后面的方案质量会明显更高。
模式 5：Pipeline
把复杂任务拆成严格顺序执行的流水线
这是 5 个模式里最适合做“长期可运行工作流”的一个。
它的核心思想是：
复杂任务不要一把梭。 要拆成明确步骤，而且每一步都要有检查点。
文章里的例子是文档生成流程。
先分析 API 清单，再补 docstring，再组装文档，再做质量检查。
中间甚至明确规定，没有用户确认，就不能进入下一步。
这类设计的意义非常大。
因为很多复杂任务，一旦不分步，Agent 很容易跳步骤、省步骤、自己脑补步骤。
落地怎么用
如果放到内容工厂里，Pipeline 很适合这样的链路：
- 先搜集资料
- 再筛选重点
- 再提炼观点
- 再生成草稿
- 再按风格改写
- 再做审查
- 再输出定稿
如果放到开发流程里，也可以是：
- 先分析需求
- 再设计结构
- 再生成代码
- 再跑检查
- 再做 review
- 再整理文档
Pipeline 其实是在用结构换稳定性。
它让 Agent 更像系统，而不只是一个随机发挥的聊天窗口。
这 5 个模式最重要的一点：它们可以组合
Google 这篇文章最后一个很关键的提醒是：
这 5 个模式不是互斥的，它们可以组合。
比如：
- 一个 Pipeline 的最后，可以接一个 Reviewer
- 一个 Generator 的前面，可以先加一层 Inversion
- 一个 Tool Wrapper，可以被嵌进某个 Pipeline 的某一步
- 一个 Generator 输出内容后，还可以交给 Reviewer 做风格检查
这就意味着，Skill 的设计不是单点思维。
而是像搭积木一样，把不同能力模块拼起来。
这也是 Agent 和普通 prompt 最大的区别之一。
prompt 更像一次性对话。
Skill 设计更像在搭一个可复用的系统。
对普通学习者来说，最值得抄的实操路线
如果正在学 Agent，建议走这条路线：
第一步：先做一个 Tool Wrapper
先把自己最熟的一套规则封起来。
比如：
- X 写作风格
- GitHub 项目种草结构
- 某类报告写作规范
- 某个框架的开发规范
这一步最容易做出成就感。
第二步：再做一个 Generator
把一个固定格式的输出做稳定。
比如：
- AI 日报生成器
- 线程生成器
- 周报生成器
- 会议纪要生成器
这一步会开始感受到“可复用”的价值。
第三步：补一个 Reviewer
给输出加一层质量检查。
比如检查：
- 有没有漏信息
- 风格是否统一
- 逻辑是否完整
- 事实是否有误
这一步会让整个工作流从“能跑”走向“更可用”。
第四步：再考虑 Inversion 和 Pipeline
当任务变复杂以后，再加：
- 先访谈再执行
- 强制分步骤
- 每步设 checkpoint
这一步更接近真正的 Agent 系统设计。
放到内容工厂里，这 5 个模式怎么接
如果站在内容工厂 / Agent 的视角，这 5 个模式几乎可以直接对应成一条完整链路。
- Tool Wrapper
装入写作规则、平台规则、选题标准、资料库使用规范。
- Inversion
先问清楚这次内容的目标、平台、长度、对象、语气、是否要引用。
- Generator
按固定模板生成长推、短推、线程、文章、日报、选题卡片。
- Reviewer
检查事实、结构、风格、可读性、平台适配度。
- Pipeline
把整个过程按顺序串起来，保证不漏步骤。
这样做出来的内容工厂，才更接近“能持续跑”的系统。
最后总结 Skill 资产
真正有壁垒的东西，可能会慢慢变成：
有没有把自己的经验、流程、标准、模板，整理成一套高质量、结构化、可持续调用的 Skill 资产。
这类资产一旦积累起来，就会变成：
- 个人工作流的底座
- 团队知识的封装层
- Agent 的能力仓库
- 可复用的生产模块
从现在开始，别只研究格式。要开始研究结构。
