Google 下场做 Agent Skills：一个正在赢得事实标准之争的格式

TL;DR

2025 年下半年，GitHub Trending 上反复出现一类仓库：anthropics/skills、mattpocock/skills、addyosmani/agent-skills，以及最新下场的 google/skills。它们都在围绕同一个格式——Agent Skills——构建生态。Google 的官方入场尤其值得关注：一个 17,000+ star 的仓库，把 GKE、BigQuery、AlloyDB、Gemini API 等 80+ Google 产品知识打包成了可以被任意编码智能体加载的 skill。

这不是又一个 prompt 模板库。这是知识封装格式的事实标准化——一个 Anthropic 提出、Google 背书、30+ 主流客户端已支持的跨厂商格式。这篇文章从七个方向深度拆解这件事。

一、Agent Skills 格式的起源：Anthropic 怎么提出的

从"系统提示词"到"可加载的技能包"

Agent Skills 的核心问题意识很简单：LLM 的能力是通用的，但真实任务需要领域知识。

早期解决这个问题的方法是堆系统提示词（system prompt）——把所有指令塞进一个巨大的 context window。但这条路有三个致命缺陷：

上下文窗口是有限的，堆满后挤占了推理空间；
所有指令同时在场，模型需要自己判断哪段指令当前相关，容易跑偏；
不可复用，换个项目就得重写一遍。

Anthropic 的解法是渐进式披露（Progressive Disclosure）：把领域知识封装成独立的"技能"单元，平时只暴露一个极简的索引（name + description，约 100 token），等智能体判断出当前任务匹配某个技能时，才加载完整指令。

规范定义

官方规范现在托管在 agentskills.io/specification，仓库为 anthropics/skills（167k star，47 commits）。一个 skill 的最小定义是：

skill-name/
├── SKILL.md          # 必需：元数据 + 指令
├── scripts/          # 可选：可执行代码
├── references/       # 可选：详细参考文档
├── assets/           # 可选：模板、图片、数据文件
└── ...               # 任何额外的文件或目录

SKILL.md 由 YAML frontmatter 和 Markdown 正文组成。Frontmatter 的字段规范如下：

字段	是否必需	约束
`name`	✅ 是	最长 64 字符；仅小写字母、数字、连字符；不能以连字符开头/结尾；不能有连续连字符；必须与父目录名一致
`description`	✅ 是	最长 1024 字符；描述技能做什么以及何时使用；应包含帮助智能体识别任务的特定关键词
`license`	❌ 否	许可证名称或指向打包许可证文件的引用
`compatibility`	❌ 否	最长 500 字符；环境要求（目标产品、系统依赖、网络访问等）
`metadata`	❌ 否	字符串到字符串的任意键值映射，用于扩展属性
`allowed-tools`	❌ 否（实验性）	空格分隔的工具列表，预批准技能可使用的工具

一个最小示例：

---
name: pdf-processing
description: >-
  Extracts text and tables from PDF files, fills PDF forms, and merges
  multiple PDFs. Use when working with PDF documents or when the user
  mentions PDFs, forms, or document extraction.
---

加载机制：三级渐进式披露

这是整个格式设计的精髓。智能体不是一次性加载所有技能，而是分三级：

索引层（约 100 tokens / 技能）：启动时加载所有技能的 name 和 description 字段——这是智能体做"路由决策"的唯一依据；
正文层（建议 < 5000 tokens）：当智能体决定激活某技能时，加载 SKILL.md 的完整正文；
引用层（按需）：正文里引用的 scripts/、references/、assets/ 文件，只在具体需要时才读入。

关键洞察：description 字段是整个系统的"搜索引擎"。写得不好，技能永远不会被激活；写得好，智能体能在 100 token 的成本内做出准确的路由判断。这就是为什么规范专门有一篇《Optimizing descriptions》指南。

官方建议 SKILL.md 保持在 500 行以内，详细参考材料拆分到独立文件，且引用深度不超过一层——避免智能体陷入深层引用链。

验证工具

官方提供 skills-ref 参考库来验证技能格式，检查 frontmatter 是否合法、命名是否遵守约定。这让 skills 从"文档约定"升级为"有工具链支撑的工程规范"。

二、Google 官方版的定位

仓库概览

google/skills：17.2k star，1.4k fork，221 commits，Apache-2.0 协议。描述非常直白："Agent Skills for Google products and technologies"。

仓库标注"under active development"（积极开发中），结构清晰：

google/skills/
├── skills/              # 核心：80+ 个 skill
│   ├── ads/             # 广告：Google Ads API、Mobile Ads SDK、IMA SDK
│   ├── analytics/       # 分析：Google Analytics Admin/Data API
│   └── cloud/           # 云：占了绝大多数，下文详述
├── plugins/             # 插件（Skills + MCP servers 的打包）
│   └── cloud/data-agent-kit/
├── .agents/plugins/     # 智能体框架适配
├── .claude-plugin/      # Claude Code 插件清单
└── .gitmodules          # 子模块：Flutter/Dart/Firestore 等独立仓库

覆盖范围：一份 Google 产品知识图谱

Google 的 skills 目录本质上是Google Cloud 产品矩阵的结构化教学文档。按领域分类：

云入门与解决方案架构

Google Cloud 认证、Foundation Builder、Onboarding
多产品方案：跨云 Agentic 分析、开放数据湖仓、GKE 上的 AI Agent 部署、RAG 企业搜索、Serverless n-tier 安全架构……

AI/ML（Agent Platform 为核心）

这是最大的一块：Alert 配置、Endpoint 管理、Eval Flywheel、GenAI 推理、Model Garden 部署、Model Registry、Model Tuning、Prompt Management、RAG Engine、Troubleshooting、Tuning Management……
BigQuery AI & ML、Gemini API、Gemini Interactions API、LiveAPI Service、Skill Registry

基础设施（GKE 占了 20+ 个 skill）

GKE 创建、Autoscaler、ComputeClasses、Golden Path、Multi-Tenancy、Networking、Storage、Reliability、Productionize、TPU 动态切片监控、Workload Scaling/Troubleshooting……
负载均衡器配置、网络可观测性、Cloud Storage 基础

数据库与分析

AlloyDB、BigFrames、BigQuery（基础 + 资产影响分析）、Bigtable、Cloud SQL、Data Lineage、Spanner、Airflow 迁移

管理工具

Cloud Monitoring 图表生成、Cloud Logging 配置（含跨项目）、日志查询语言生成、GKE 成本分析/优化/可观测性、SLO 告警、TPU 指标、Workload Manager

Well-Architected Framework（六大支柱）

成本优化、运营卓越、性能优化、可靠性、安全、可持续性——每个支柱一个 skill

安全与身份

GKE 平台安全、GKE 工作负载安全、SecOps 检测覆盖

Web 与应用托管

Cloud Run 基础、Firebase 基础

广告（这是一个惊喜）

Google Ads API（账户诊断、MCP Server 安装、Quickstart）、Mobile Ads SDK（Banner/插屏/激励/安装）、Data Manager API、IMA SDK

开发者工具

Developer Device Platform、gcloud CLI、Google Agents CLI Onboarding

此外，通过 .gitmodules 链接了独立维护的附加技能：Flutter、Dart、Advanced Cloud Storage、Agent Development Kit (ADK)、Firestore、Genkit。

一个真实 skill 长什么样

以 skills/cloud/bigquery-basics/SKILL.md 为例：

---
name: bigquery-basics
metadata:
  category: BigDataAndAnalytics
description: >-
  Manages datasets, tables, and jobs in BigQuery. Use when you need to
  interact with BigQuery, run SQL queries, manage BigQuery resources
  (datasets, tables, views), or perform basic data ingestion and analysis.
---

正文包含：BigQuery 架构说明、gcloud/bq CLI 的具体命令（启用 API、建数据集、建表、跑 SQL）、以及一个 references/ 目录，里面有 Core Concepts、Change History、Continuous Queries 等按需加载的深度文档。

可以看到 Google 的做法：严格遵守 Anthropic 格式规范，额外用 metadata.category 做内部分类。指令正文不是抽象的方法论，而是可复制粘贴的命令和配置——这跟社区版"工程方法论"风格形成鲜明对比。

插件机制：Skills + MCP 的组合拳

Google/skills 还打包了 plugins——把 Skills（知识）和 MCP servers（工具）组合在一起。目前支持三个智能体框架：

智能体框架	安装方式
Claude Code	`claude plugin marketplace add google/skills` → `claude plugin install <plugin>@google-plugins`
Codex	`codex plugin marketplace add google/skills` → 从 `/plugins` 浏览器安装
Antigravity CLI	`agy plugin install https://github.com/google/skills/<plugin-path>`

通用安装入口是 npx skills add google/skills，可以交互式选择具体技能。

Google 版 vs Anthropic 版：异同

维度	anthropics/skills	google/skills
定位	格式定义 + 示例库	产品知识库
技能数量	约 10+ 示例	80+ 生产级技能
技能类型	创意、技术、企业工作流、文档处理	Google 产品操作指南
知识风格	展示"可能性"的模式	可执行的运维手册
协议	Apache-2.0（部分 source-available）	Apache-2.0
格式创新	定义规范本身	遵循规范，无扩展
插件	Claude Code 插件市场	多框架插件（Claude/Codex/Antigravity）

关键差异：Anthropic 是"规范制定者 + 灵感库"，Google 是"规范消费者 + 最大企业内容贡献者"。Google 没有发明新格式，而是选择拥抱现有标准——这个姿态本身就是对格式标准化的最强背书。

三、生态全景：四大仓库横向对比

Agent Skills 生态目前已形成清晰的分层。下面是四个最重要的仓库对比。

数据一览（截至 2026-08-10）

仓库	Star	Fork	Commits	定位
mattpocock/skills	211k	18.3k	420	个人工程方法论
anthropics/skills	167k	19.9k	47	官方规范 + 示例
addyosmani/agent-skills	85.1k	9.2k	419	生产级工程技能包
google/skills	17.2k	1.4k	221	Google 产品知识

注：star 数会持续变化，以上为调研时快照。

逐个拆解

1. anthropics/skills —— 规范之源

角色：格式的发明者和权威定义者；spec 已独立到 agentskills.io
内容：少量高质量示例（docx/pdf/pptx/xlsx 文档技能是 Claude 生产环境在用的，source-available），创意/技术/企业工作流演示
社区：47 commits 说明这不是一个频繁迭代的"产品"，而是一个标准参考实现
价值：想理解格式、学习最佳实践、看复杂 skill 怎么写——这里是第一站

2. google/skills —— 大厂官方内容

角色：Google Cloud/Ads/Analytics 的官方技能库
内容：80+ 个产品操作技能，GKE 覆盖最深（20+ 个），Agent Platform AI/ML 次之
特色：指令可执行（具体命令而非抽象方法论）；支持多框架插件安装；用 metadata.category 做内部分类
价值：用 Google Cloud 的团队可以直接装；其他人可以学习企业级技能怎么写

3. addyosmani/agent-skills —— 工程方法论大全

Addy Osmani（Google Chrome 团队工程 leader）的个人项目，可能是目前最完整的通用工程技能包。

角色：把资深工程师的工作流编码成可复用的技能
内容：24 个技能，按软件生命周期组织：
- DEFINE：interview-me（逐题访谈直到 95% 置信度）、idea-refine、spec-driven-development
- PLAN：planning-and-task-breakdown
- BUILD：incremental-implementation、test-driven-development（红绿重构）、context-engineering、source-driven-development、doubt-driven-development（CLAIM→EXTRACT→DOUBT→RECONCILE）、frontend-ui-engineering、api-and-interface-design
- VERIFY：browser-testing-with-devtools、debugging-and-error-recovery（五步分诊）
- REVIEW：code-review-and-quality（五轴评审）、code-simplification、security-and-hardening（OWASP Top 10）、performance-optimization
- SHIP：git-workflow-and-versioning、ci-cd-and-automation、deprecation-and-migration、documentation-and-adrs、observability-and-instrumentation、shipping-and-launch
特色：
- 8 个 slash 命令（/spec→/plan→/build→/test→/review→/ship）映射开发生命周期
- 内置 using-agent-skills 元技能——帮你判断该用哪个技能
- 4 个专家 persona（code-reviewer / test-engineer / security-auditor / web-performance-auditor）
- 框架中立：同时适配 Claude Code、Cursor、Codex、Copilot、Cline、Windsurf、OpenCode、Gemini CLI、Antigravity 等 70+ 智能体（通过 .claude-plugin/.codex-plugin/.gemini/commands/.opencode 多目录适配）
- 有 evals/ 目录和 CI 校验（references 链接检查）
价值：想要一套"开箱即用的工程纪律"的团队，这是首选

4. mattpocock/skills —— 个人实战方法论

Matt Pocock（TypeScript 教育者，Total TypeScript 作者）的个人技能集，star 数最高。

角色：从个人 .agents/ 目录提炼的实战技能
理念：明确反对 GSD/BMAD/Spec-Kit 等"接管流程"的框架——主张技能应该小、易改、可组合、模型无关
内容：约 20 个技能，分两类：
- User-invoked（用户触发）：/grill-me（ relentless 访谈直到设计树的每个分支都被解决）、/grill-with-docs（访谈 + 构建领域模型 + ADR）、/triage、/to-spec、/to-tickets、/implement、/wayfinder、/improve-codebase-architecture、/setup-matt-pocock-skills
- Model-invoked（模型自动触发）：prototype、diagnosing-bugs、research、tdd、domain-modeling、codebase-design、code-review、resolving-merge-conflicts、wizard
特色：
- User-invoked vs Model-invoked 的二分法：用户触发的技能负责编排，模型触发的技能持有可复用的纪律——前者可调用后者，但不可互相调用。这是一个比 addyosmani 更清晰的架构原则。
- 围绕四个"AI 编码常见失败模式"组织：①Agent 没做对（→grilling）②Agent 太啰嗦（→shared language/领域模型）③代码不工作（→反馈循环/TDD）④代码变泥球（→架构深化）
- 大量引用经典工程文献：《程序员修炼之道》《领域驱动设计》《Extreme Programming》《软件设计哲学》
- 有 changeset 版本管理、CHANGELOG、正式 release（v1.2.3）
价值：如果你认同"技能应该是小而锋利的工具而非臃肿的框架"，这是最好的参考

四者关系图

           规范层                    内容层
     ┌─────────────────┐    ┌──────────────────────────┐
     │                 │    │ 企业产品知识              │
     │ anthropics/     │    │  google/skills (80+)     │
     │ skills (规范)   │    │                          │
     │                 │    │ 通用工程方法论            │
     │ agentskills.io  │    │  addyosmani (24)         │
     │ (spec 独立站)   │    │  mattpocock (~20)        │
     └────────┬────────┘    └─────────────┬────────────┘
              │                           │
              └───────────┬───────────────┘
                          ▼
                   客户端支持层
            (30+ 智能体，见下文第五节)

总结：这四个仓库不是竞争关系，而是生态分层。Anthropic 定规则，Google 填充企业产品知识，两位社区领袖填充通用工程方法论。一个成熟的团队可能同时安装 google/skills（云运维）+ addyosmani（工程纪律）+ mattpocock（需求澄清），它们互不冲突，因为都遵循同一个格式。

四、技术规范深度分析

文件结构

一个 skill 的完整结构：

my-skill/
├── SKILL.md              # 必需：唯一硬性要求
├── scripts/
│   ├── build.sh          # 可执行代码（自包含或文档化依赖）
│   └── analyze.py
├── references/
│   ├── api-details.md    # 详细技术参考
│   ├── form-templates/   # 表单模板、结构化数据
│   └── domain-glossary.md
└── assets/
    ├── template.docx     # 文档模板
    ├── diagram.png       # 示意图
    └── lookup.json       # 查找表、schema

约定（非强制）：

scripts/ 应自包含或明确文档化依赖；包含有用的错误信息；优雅处理边缘情况。支持语言取决于智能体实现（常见：Python、Bash、JavaScript）
references/ 的单个文件应聚焦——智能体按需加载，文件越小，消耗的上下文越少
assets/ 放静态资源

Frontmatter 的设计哲学

规范的每个字段都有明确的设计意图：

name（必需）——身份标识 + 文件系统约定：

必须与父目录名一致（bigquery-basics/SKILL.md 的 name 必须是 bigquery-basics）
命名约束严格（小写/数字/连字符，无连续连字符）——保证跨平台路径安全

description（必需）——整个系统的路由引擎：

规范明确要求"描述技能做什么以及何时使用"
应包含"帮助智能体识别相关任务的特定关键词"
官方给了好/坏对比：
- ✅ Extracts text and tables from PDF files, fills PDF forms, and merges multiple PDFs. Use when working with PDF documents or when the user mentions PDFs, forms, or document extraction.
- ❌ Helps with PDFs.

compatibility（可选）——环境声明：

大多数技能不需要；只有特定环境依赖时才写
例：Requires git, docker, jq, and access to the internet

metadata（可选）——扩展槽：

Google 用它放 category；其他实现可自由扩展
建议键名足够独特以避免冲突

allowed-tools（实验性）——预批准工具：

例：Bash(git:*) Bash(jq:*) Read
实验性质，各实现支持程度不同

触发机制：智能体怎么决定加载哪个技能

这是理解整个格式的关键。触发不是基于正则匹配或显式调用，而是基于语义路由：

用户输入 + 当前上下文
        │
        ▼
┌───────────────────────────┐
│ 智能体看到所有技能的       │  ← 索引层（每技能约100 token）
│ name + description 索引   │
└─────────────┬─────────────┘
              │ 语义匹配判断
              ▼
     ┌─────────────────┐
     │ 决定激活某技能   │
     └────────┬────────┘
              │
              ▼
┌───────────────────────────┐
│ 加载 SKILL.md 完整正文     │  ← 正文层（建议<5000 token）
│ （正文可能引用其他文件）   │
└─────────────┬─────────────┘
              │ 按需读取
              ▼
┌───────────────────────────┐
│ 读取 references/scripts/  │  ← 引用层（按需）
│ assets 中的具体文件        │
└───────────────────────────┘

两个推论：

description 决定生死——写得模糊，技能永远不会被触发；写得精准，智能体能在极低成本下做对路由。这就是为什么"优化 description"是一门值得专门研究的技艺。
文件拆分有经济意义——把详细内容放在 references/ 而不是塞进 SKILL.md，意味着这些内容只在真正需要时才消耗 token。

加载方式的实现差异

虽然规范统一，但各客户端的加载实现有差异：

Claude Code：原生支持，插件市场机制（claude plugin marketplace add）
Claude.ai：付费计划内置官方示例技能；可上传自定义技能
Claude API：通过 Skills API 上传和使用
skills.sh CLI（跨客户端）：npx skills add <repo> 安装到 70+ 智能体，支持 --list 浏览和 --skill 单独安装
Codex / Cursor / Gemini CLI / GitHub Copilot / Windsurf 等：各有适配路径

npx skills add 正在成为事实上的通用安装入口——无论你用哪个客户端，安装语法都一样。这进一步降低了格式采纳门槛。

五、为什么这个格式正在赢得事实标准之争

客户端支持的广度

agentskills.io 的 Client Showcase 列出了 30+ 个已支持 Agent Skills 格式的智能体产品，包括：

类别	代表产品
IDE/编辑器	VS Code、Cursor、Roo Code、TRAE、Kiro、Junie、VT Code
终端智能体	Claude Code、Gemini CLI、Codex/ChatGPT、Codex CLI、Amp、Mistral Vibe、OpenCode、Hermes Agent
平台/云	Snowflake Cortex Code、Databricks Genie Code、Pulumi Neo、Google AI Edge Gallery
开源框架	OpenHands、Goose、nanobot、Mux、Letta、Spring AI、OpenClaw、ZeroClaw
企业	Factory、Agentman、Superconductor、Ona、Workshop、Piebald、Emdash
行业特定	Firebender（Android）、Laravel Boost（PHP）、Command Code

注意这个名单的构成：它不只有 Anthropic 自家产品。Google、OpenAI（Codex/ChatGPT）、Microsoft（GitHub Copilot/VS Code）、Snowflake、Databricks、Mistral——几乎所有主要厂商的编码智能体都在列。

为什么是它赢了

Agent Skills 之前，类似的"知识封装"尝试不少：各种 prompt 库、.cursorrules、AGENTS.md、CLAUDE.md、自定义 MCP servers……为什么是 Agent Skills 脱颖而出？

1. 极简的格式定义 最小 skill 只需要一个文件夹 + 一个 SKILL.md + 两个 frontmatter 字段。没有 schema 文件、没有编译步骤、没有运行时依赖。门槛低到任何人都能在 5 分钟内写出第一个技能。

2. 渐进式披露的上下文经济学 这是最核心的竞争优势。与"把所有指令塞进系统提示词"相比，Skills 让你拥有 100 个技能但只消耗 100×100=10,000 token 的索引成本——而不是 100×5000=500,000 token 的全量加载。规模决定了这个格式能扩展到多大的知识库。

3. 跨厂商中立性 Anthropic 提出格式，但没有把它绑死在 Claude 上。agentskills.io 是独立站点，spec 是开放文档，任何人都可以实现客户端。Google/OpenAI/Microsoft 的产品支持它，不是因为被迫，而是因为这个格式确实好用。

4. 恰到好处的规范约束 规范定义了"必需的"和"约定的"，但不越界。name 和 description 是硬约束；scripts//references//assets/ 是软约定；正文内容完全自由。这种"严格元数据 + 自由内容"的平衡，让格式既能被机器可靠解析，又能容纳任意复杂的人类知识。

5. 生态正反馈已经启动 更多的客户端支持 → 更多的用户 → 更多的技能创作者 → 更多的技能 → 更多的客户端有动力支持。四个头部仓库的 star 数（211k + 167k + 85k + 17k = 48 万）说明这个飞轮已经在转。

6. skills.sh CLI 统一了安装体验 无论你用什么客户端，npx skills add <repo> 都能工作。这消除了"格式虽好但每个工具安装方式不同"的最后一道摩擦。

与其他方案的对比

方案	定位	与 Skills 的关系
`.cursorrules`	单文件项目规则	功能子集；Skills 是结构化的超集
`AGENTS.md`/`CLAUDE.md`	项目级持久指令	互补——项目级规则用 md 文件，可复用的工作流用 Skills
MCP servers	工具/能力扩展	互补——MCP 给智能体"手"（工具调用），Skills 给智能体"脑"（领域知识）。Google/skills 的 plugins 正是把两者打包
Custom system prompts	一次性指令	被 Skills 的可复用性取代

Skills 不是要取代这些方案，而是填补了"可复用的领域知识封装"这个此前空缺的生态位。

六、对开发者的实际价值：怎么给自己的项目写 Skills

什么时候该写 Skill

适合做成 skill 的场景：

团队有反复执行的工作流（部署流程、代码审查清单、事故响应）
项目有特定的领域知识/术语表/架构约定
使用特定框架/库/云服务，且官方文档太长需要浓缩
新人 onboarding 需要的知识

不适合的场景：

一次性的任务（直接在对话里说就行）
依赖大量动态上下文且无法预先文档化的操作
简单到一句话能说清的指令（直接写进 AGENTS.md/CLAUDE.md）

写一个 Skill 的实操步骤

第 1 步：定义触发条件

先问自己：智能体在什么情况下应该激活这个技能？把答案写成 description：

---
name: deploy-to-staging
description: >-
  Deploys the current branch to the staging Kubernetes cluster using
  our internal helm charts. Use when the user asks to deploy, push to
  staging, or release a new version for QA testing.
---

关键词要覆盖用户可能的说法（"deploy"、"push to staging"、"release for QA"）。

第 2 步：写指令正文

正文是给智能体看的操作手册。推荐结构：

# Deploy to Staging

## Prerequisites
- Ensure you're on the correct branch (git branch --show-current)
- Run `pnpm test` and confirm all tests pass
- Check that .env.staging exists

## Steps
1. Build the Docker image:
   `docker build -t registry.internal/app:$(git rev-parse --short HEAD) .`
2. Push to registry:
   ...
3. Update helm values:
   ...

## Common Issues
- If you see "ImagePullBackOff": check registry credentials
- If migrations fail: ...

## Verification
- After deploy, hit https://staging.example.com/healthz
- Check Grafana dashboard for error spikes

第 3 步：拆分参考资料

如果某些细节很长（完整的环境变量表、架构决策记录、API schema），放到 references/：

deploy-to-staging/
├── SKILL.md
├── references/
│   ├── env-variables.md      # 完整环境变量清单
│   ├── rollback-procedure.md # 回滚步骤
│   └── helm-values.yaml      # values 模板
└── scripts/
    └── pre-deploy-check.sh   # 预检查脚本

第 4 步：验证

用 skills-ref 库校验 frontmatter 合法性。手动测试：在智能体里用不同措辞描述任务，看技能是否被正确触发。

团队级 Skills 的组织建议

1. 建一个组织内部 skills 仓库

yourorg/skills/
├── skills/
│   ├── deploy-pipeline/
│   ├── code-review-standards/
│   ├── onboarding/
│   └── incident-response/
├── .claude-plugin/
└── README.md

遵循 google/skills 的目录结构，按领域分目录。

2. 用 git 管理，code review 把关

Skills 是知识资产，应该和代码一样有 review 流程。addyosmani/agent-skills 甚至有 CI 检查 references 链接的有效性。

3. 先用社区的，再写自己的

在写自己的之前，先看看有没有现成的：

云运维：npx skills add google/skills
工程方法论：npx skills add addyosmani/agent-skills
需求澄清/TDD：npx skills add mattpocock/skills

在社区技能的基础上叠加你团队的定制——这比从零开始高效得多。

4. 写 description 时考虑"反面例"

好的 description 不只说"何时使用"，还隐含"何时不使用"。如果你的技能和另一个容易混淆，在 description 里做区分。

5. 控制 SKILL.md 长度

500 行是官方建议上限。超过就拆到 references。这不是洁癖——长正文意味着每次激活都消耗更多上下文，挤占推理空间。

七、作者立场与预测

我的判断

Agent Skills 正在成为 AI 编码智能体领域第一个真正"跨厂商落地"的知识封装标准。 理由是前面第五节论述的网络效应：格式足够简单、上下文经济学足够合理、客户端支持足够广泛、社区内容足够丰富。

Google 的下场是一个标志性事件。当一家拥有 GKE、BigQuery、Gemini 这样庞大产品线的公司，选择用竞争对手（Anthropic）定义的格式来分发自己产品的操作知识——这只能说明一件事：格式之争已经结束了。争的不再是"用不用 Agent Skills"，而是"谁的 skills 写得更好"。

三个预测

预测一：会出现 skills 的"应用商店"和策展层

现在找 skills 要去各个 GitHub 仓库翻 README。随着技能数量爆炸（Google 已 80+，社区还在增长），必然出现中心化的目录/搜索/评分平台——agentskills.io 已经在朝这个方向走。策展（"最佳安全技能 Top 10"、"React 开发必备技能包"）会成为新的内容生态位。

预测二：skills + MCP 的融合会加深

Google/skills 的 plugins 已经在把 Skills（知识）和 MCP servers（工具）打包在一起。未来的趋势是一个"能力包" = 领域知识 + 可调用工具 + 使用场景，三者缺一不可。Skills 提供"什么时候用、怎么用"，MCP 提供"能用什么"，组合起来才是完整的智能体能力扩展。

预测三：企业内部 skills 管理会成为新的基础设施需求

当团队积累了 50+ 个内部 skills，就需要版本管理、权限控制、分发机制、使用分析、效果评估。这会催生一类新的内部工具——类似"企业的 skills registry"。Google/skills 里已经有一个 agent-platform-skill-registry 技能，暗示了方向。

给读者的建议

如果你是 AI 产品工程师，我的建议是：

现在就开始用——安装 1-2 个社区技能包，体验渐进式披露的效果
给当前项目写 2-3 个技能——部署流程、代码审查标准、新人 onboarding 是最好的起点
跟踪格式演进——agentskills.io 的 spec 和博客是权威来源
不要过度投资——格式还在演进（allowed-tools 还是实验性的），保持技能小而可迭代

这不是又一个会过气的技术趋势。知识封装格式的标准化，是 AI 智能体从"通用聊天机器人"走向"可靠的专业工具"的必经之路。 谁先把自己的领域知识沉淀成高质量的 skills，谁就能在 AI 辅助工作中获得结构性的效率优势。

参考链接

Agent Skills 官方规范：https://agentskills.io/specification
Client Showcase（30+ 支持客户端）：https://agentskills.io/clients
anthropics/skills（167k star）：https://github.com/anthropics/skills
google/skills（17.2k star）：https://github.com/google/skills
addyosmani/agent-skills（85.1k star）：https://github.com/addyosmani/agent-skills
mattpocock/skills（211k star）：https://github.com/mattpocock/skills
通用安装 CLI：https://skills.sh（npx skills add <repo>）

本文数据截至 2026 年 8 月 10 日，star/commit 数为调研时快照，会持续变化。