30 多个 Agent 工具——Claude Code、Gemini CLI、Cursor、GitHub Copilot——已经统一到同一套 SKILL.md 规范。格式不再是问题，大家都会写。

但写什么，还没有答案。

Google 今天发布了 5 个 Agent Skill 设计模式，填上了这个空白。

为什么需要设计模式

一个包装 FastAPI 规范的 Skill，和一个四步文档生成流程的 Skill，底层逻辑完全不同——但格式长得一样。

Skills 可以做的事情太多，每个人都在摸索，大量重复踩坑。模式（pattern）的价值在于：把已经被验证的解法命名，让后来者不用从头想。

5 个模式

1. Tool Wrapper

把某个库或 API 的专家知识打包进 Skill，按需注入，不占 context。

适合：你有一个特定工具的使用约定（比如你们公司的内部 SDK），想让 Agent 每次用这个工具时自动遵守这些约定，而不是每次都在 prompt 里重复说明。

2. Pipeline Orchestrator

把多步骤的工作流编排成一个可重复执行的 Skill。

适合：你有一个固定流程（比如代码审查 → 格式检查 → 测试 → 文档更新），每次手动触发很累，想让 Agent 一次完整跑完，中间不需要人工确认。

3. Context Injector

在对话开始时向 Agent 注入背景知识，而不是靠 Agent 自己去找。

适合：项目有大量背景信息（架构决策、业务规则、团队约定），放在文件里 Agent 不一定会读，放在每次 prompt 里太占空间。Context Injector Skill 让这些信息在需要时自动出现。

4. Quality Gate

在关键节点上给 Agent 的输出打分、验证，不达标就触发重写。

适合：你有明确的质量标准（比如代码必须通过 lint，文章必须包含某些要素），但不想每次人工检查。Quality Gate 把验收标准编码进 Skill，让 Agent 自我校验。

5. Skill Composer

把多个小 Skills 组合成一个更大的工作流，像搭积木一样。

适合：你已经有一些可用的 Skills，想把它们串联成一个更复杂的自动化流程，而不是从头写一个大 Skill。

怎么用这 5 个模式

不是每个 Skill 都要套模式。但当你发现自己写的 Skill "不稳定"或者"只能用一次"时，大概率是因为没想清楚这个 Skill 要解决哪种问题。

对着这 5 个模式问一下：我的 Skill 是在给 Agent 装工具知识（Tool Wrapper），还是在规定它的工作流程（Pipeline），还是给它补背景（Context Injector），还是帮它检查结果（Quality Gate），还是把已有的 Skill 组合起来（Composer）？

想清楚了，写起来就不会绕远。

今天 Anthropic 工程师 @trq212 也同步发布了 Claude Code Skills 内部实践总结，加上 Google 这 5 个模式，Skills 的使用方法正在从"感觉"走向"工程化"。