Google Cloud Tech 发了一篇很值得认真看的文章，以下是文章内容：

现在做 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（高性能Python Web框架）。
当用户开始写 FastAPI 代码、审查 FastAPI 代码时，Skill 会去加载对应的规范文档，然后按这些规则来执行。

这个思路很重要。
因为很多人现在写 Agent，习惯把一大堆规则长期塞在 system prompt 里。
结果通常是：

• • prompt 很长
• • context 很脏
• • 换一个任务，旧规则还在干扰
• • 后期很难维护

Tool Wrapper 的好处，就是把这类专业知识独立出来，按需加载。

落地怎么用

如果把它放到日常场景里，这个模式其实特别实用。

学生党可以封这些 Skill：

• • 论文引用格式规范（APA / IEEE / GB/T 7714）
• • 实验报告撰写规则
• • 课程笔记整理标准
• • 简历和求职信写作规范

技术开发可以封这些 Skill：

• • Spring Boot / React / Go 等项目编码规范
• • 公司内部 API 调用约定和鉴权规则
• • Git commit message 和 PR 描述模板
• • 团队 Code Review 检查标准

对初学者的启发

正在学 Agent 的人，很容易一开始就想做“万能 Agent”。

但更现实的路线，通常是先做一个小专家。

先让 Agent 在某一个点上变得稳定、可控。
比如只负责：

• • 帮你按导师要求的格式整理参考文献
• • 按公司规范自动生成 Jira 工单描述
• • 按团队标准做 Code Review

这样更容易做出结果，也更容易积累自己的 Skill 资产。

模式 2：Generator

把“每次都该长得差不多”的输出，固定成一个生成器

这个模式解决的是一个非常常见的问题：

为什么同一个 Agent，今天输出这个结构，明天又换了一种写法？

如果一个任务本来就需要稳定格式，那最好的办法是提前把模板、风格规则、必要变量都准备好。

它的思路通常是：

1. 1. 先加载风格说明
2. 2. 再加载输出模板
3. 3. 发现信息不够，就先向用户补问题
4. 4. 把内容填进模板
5. 5. 输出完整成稿

落地怎么用

这个模式太适合那些"格式固定、反复要写"的任务了。

学生党可以直接拿来做：

• • 课程读书报告（固定结构：摘要→核心观点→批判分析→结论）
• • 实验报告生成器（按模板填充目的、方法、数据、结论）
• • 文献综述段落（每篇论文按统一格式提炼）
• • 求职简历针对不同岗位的定制版本

技术开发可以拿来做：

• • 每日站会汇报（昨天做了什么→今天计划→卡点）
• • 周报 / 月报生成器
• • 技术方案文档初稿
• • Bug 报告（复现步骤→预期结果→实际结果→环境信息）
• • 上线变更记录

只要你发现某类输出“每次都应该差不多”，就适合 Generator。

为什么它很关键

很多人觉得 Agent 好不好用，取决于模型强不强。
但在实际业务里，更影响体验的，往往是输出稳不稳定。

格式稳定，后面才能批量化。
风格统一，后面才适合持续复用。
模板明确，后面才容易接进工作流。

对学生和技术开发有什么参考意义

这类模式特别适合拿来练手。

因为它不要求一上来就做复杂系统。
先从一个最简单的模板型任务开始，就能感受到 Skill 的价值。

比如先做一个：

• • “课程笔记摘要生成器”——把老师的 PPT 自动整理成固定格式的复习笔记
• • “技术分享文档生成器”——把学到的新技术按统一模板输出成团队内部分享文档

把模板和风格约束住，很快就能看出前后差别。

模式 3：Reviewer

把“检查标准”单独拿出来，做成一个审核员

这个模式特别实用，它抓住了一个常被忽略的问题：

很多任务，难点是“生成完以后怎么审”。

比如写代码、写论文、写方案、写技术文档，常见的问题都是：

• • 漏信息
• • 逻辑跳步
• • 风格不统一
• • 重点不清楚
• • 存在事实错误
• • 缺少安全性 / 合规性检查

Reviewer 的思路很直接：

把“检查什么”从主逻辑里拆出来。

主 Skill 负责完成任务。
Reviewer Skill 负责按清单逐项检查。

文章里举的是代码审查。
它会加载 review checklist，然后按严重程度输出问题和建议。

这个模式的妙处在于，Skill 主体几乎不用变。
只要换一份 checklist，审核员就能切换身份。

落地怎么用

对学生来说，Reviewer 完全可以变成：

• • 论文格式检查员（引用格式、参考文献是否合规）
• • 代码作业审查员（变量命名、注释规范、边界情况）
• • 答辩 PPT 逻辑检查员（论点是否自洽、数据是否支撑结论）
• • 简历内容检查员（有没有量化成果、经历是否和岗位匹配）

对技术开发来说，它可以变成：

• • Code Review 审查员（代码风格、性能隐患、安全漏洞）
• • SQL 审查员（慢查询、索引缺失、注入风险）
• • 技术文档质量检查员（API 参数是否完整、示例代码能否跑通）
• • 上线前 Checklist 检查员（回滚方案、监控告警、灰度策略）

为什么这一步很重要

因为一个工作流真正开始可用，通常不是“第一次能生成”，而是“生成以后能稳定纠偏”。

很多 Agent 看起来很聪明，但真正落地时问题频出。
往往不是前面不会做，而是后面没人检查。

Reviewer 就是在补这一步。

模式 4：Inversion

不急着执行，先把需求采访清楚

这个理解成“把默认流程反过来”。Inversion。

平常的流程一般是：

用户提一句需求，Agent 马上开始干活。

Inversion 则要求 Agent 先停下来，先问问题，先收集信息。
等信息足够完整，再进入执行阶段。

这个模式特别适合那些需求本来就模糊的任务。

比如用户一上来就说：

• • "帮我做个毕业设计"
• • "帮我写个后端服务"
• • "帮我重构这个模块"
• • "帮我做个数据分析报告"

这类任务如果直接开始生成，方向很容易跑偏。
因为任务真正需要的关键信息，通常还没讲清楚。

Inversion 的价值就在这里：

它强制 Agent 先做需求访谈。

落地怎么用

学生场景可以做：

• • 毕业设计选题顾问——先问清研究方向、导师偏好、数据来源、时间线
• • 课程项目规划助手——先了解小组人数、技术栈、DDL、评分标准
• • 考研/求职规划助手——先收集目标院校/公司、个人背景、时间安排

技术开发场景可以做：

• • 技术选型顾问——先问清业务场景、团队技术栈、性能要求、维护成本
• • 系统架构设计助手——先了解 QPS、数据量、一致性要求、部署环境
• • 需求拆分助手——先把产品经理模糊的需求问清楚再拆 Story

先问清楚：

• • 目标是什么、验收标准是什么
• • 给谁用、用户量级多大
• • 技术约束是什么（语言、框架、部署环境）
• • 时间线和优先级怎么排
• • 有没有现成可复用的东西

这些信息清楚以后，后面的方案质量会明显更高。

模式 5：Pipeline

把复杂任务拆成严格顺序执行的流水线

这是 5 个模式里最适合做“长期可运行工作流”的一个。

它的核心思想是：

复杂任务不要一把梭。
要拆成明确步骤，而且每一步都要有检查点。

文章里的例子是文档生成流程。
先分析 API 清单，再补接口注释，接着组装文档，最后做质量检查。
中间甚至明确规定，没有用户确认，就不能进入下一步。

这类设计的意义非常大。
因为很多复杂任务，一旦不分步，Agent 很容易跳步骤、省步骤、自己脑补步骤。

落地怎么用

对学生来说，Pipeline 很适合这样的链路——比如写毕业论文：

1. 1. 先做文献检索和筛选
2. 2. 再提炼每篇文献的核心观点
3. 3. 再生成文献综述初稿
4. 4. 再检查引用格式和逻辑连贯性
5. 5. 再按导师的修改意见调整
6. 6. 再做最终查重和格式审查

对技术开发来说，Pipeline 可以套用到日常开发流程：

1. 1. 先从 Jira/Tapd 等平台 拉取需求，拆解成技术任务
2. 2. 再生成数据库设计和接口定义
3. 3. 再生成业务代码骨架
4. 4. 再跑单元测试和 lint 检查
5. 5. 再做 Code Review
6. 6. 再生成上线文档和变更记录

Pipeline 其实是在用结构换稳定性。
它让 Agent 更像系统，而不只是一个随机发挥的聊天窗口。

这 5 个模式最重要的一点：它们可以组合

Google 这篇文章最后一个很关键的提醒是：

这 5 个模式不是互斥的，它们可以组合。

比如：

• • 写完毕业论文初稿（Generator），最后接一个格式审查（Reviewer）
• • 做技术方案之前（Generator），先用 Inversion 把需求问清楚
• • 开发流水线里的某一步，加载特定框架的编码规范（Tool Wrapper）
• • 自动生成周报后（Generator），再交给 Reviewer 检查数据是否准确

这就意味着，Skill 的设计不是单点思维。
而是像搭积木一样，把不同能力模块拼起来。

这也是 Agent 和普通 prompt 最大的区别之一。

prompt 更像一次性对话。
Skill 设计更像在搭一个可复用的系统。

对学生和 技术开发来说，最值得抄的实操路线

如果你正在学 Agent，建议走这条路线：

第一步：先做一个 Tool Wrapper

先把自己最熟的一套规则封起来。

学生可以从这些开始：

• • 你导师偏好的论文写作规范
• • 你最常用的编程语言的代码风格指南
• • 课程作业的提交格式要求

技术开发可以从这些开始：

• • 团队的 Git 工作流规范
• • 项目使用的框架最佳实践（Spring Boot / Next.js / FastAPI）
• • 公司内部接口文档编写标准

这一步最容易做出成就感。

第二步：再做一个 Generator

把一个固定格式的输出做稳定。

比如：

• • 实验报告 / 读书笔记生成器（学生）
• • 周报 / 站会汇报 / Bug 报告生成器（技术开发）
• • 技术博客文章生成器（两者都适用）

这一步会开始感受到“可复用”的价值。

第三步：补一个 Reviewer

给输出加一层质量检查。

比如检查：

• • 论文引用是否遗漏、代码是否有明显 bug
• • 技术方案是否考虑了边界情况
• • 文档是否和代码实际行为一致
• • 数据报表里的数字是否对得上

这一步会让整个工作流从“能跑”走向“更可用”。

第四步：再考虑 Inversion 和 Pipeline

当任务变复杂以后，再加：

• • 先访谈再执行（毕设选题前先问清方向、技术选型前先问清约束）
• • 强制分步骤（把"开发一个功能"拆成需求→设计→编码→测试→文档）
• • 每步设 checkpoint（完成一步确认一步，避免返工）

这一步更接近真正的 Agent 系统设计。

放到真实场景里，这 5 个模式怎么串起来

用一个学生写毕业论文的例子，把 5 个模式串一遍：

1. 1. Tool Wrapper —— 加载学校的论文格式规范、引用标准、查重要求
2. 2. Inversion —— 先问清楚：研究方向是什么、用什么方法论、数据从哪来、导师有什么特别要求
3. 3. Generator —— 按论文模板生成各章节初稿（摘要、绪论、方法、实验、结论）
4. 4. Reviewer —— 检查引用格式、逻辑自洽性、数据是否支撑结论、有没有遗漏关键文献
5. 5. Pipeline —— 把整个过程按顺序串起来：选题→文献综述→方法设计→实验→写作→审查→定稿

再用一个 技术开发做需求开发的例子：

1. 1. Tool Wrapper —— 加载团队编码规范、API 设计标准、安全合规要求
2. 2. Inversion —— 先把产品需求问清楚：用户场景、数据量、性能要求、上线时间
3. 3. Generator —— 按模板生成技术方案文档、接口定义、数据库设计
4. 4. Reviewer —— 检查方案是否遗漏边界情况、接口是否向后兼容、有没有安全隐患
5. 5. Pipeline —— 串成：需求分析→方案设计→编码→Code Review→测试→上线→复盘

这样搭出来的 Agent 工作流，才更接近“能持续跑”的系统。

最后总结 Skill 资产

真正有壁垒的东西，可能会慢慢变成：

有没有把自己的经验、流程、标准、模板，整理成一套高质量、结构化、可持续调用的 Skill 资产。

对学生来说，这些资产可能是：

• • 你整理的论文写作 SOP
• • 你积累的实验报告模板
• • 你打磨的求职材料生成流程

对技术开发来说，这些资产可能是：

• • 你沉淀的 Code Review 检查清单
• • 你总结的技术方案写作模板
• • 你积累的排障和复盘流程

这些东西一旦结构化，就会变成你独有的竞争力——别人还在对着空白页发呆，你已经一键启动了整个工作流。

从现在开始，别只研究格式。要开始研究结构。

来源：小梁编程汇