Google Antigravity 现已推出 Agent Skills：让你的 AI 代理真正“会做事”
摘要
Google Antigravity 中的 Agent Skills 是一种开放标准，用于扩展 AI 代理能力。通过在特定文件夹放置包含 YAML 前置元数据和详细指令的 SKILL.md 文件，开发者可以创建可复用的知识包。技能支持工作区专用（.agent/skills/）和全局（~/.gemini/antigravity/skills/）两种作用域，代理会在对话开始时看到技能列表，根据任务相关性自动读取并执行对应指令，实现渐进式能力增强。
近年来 AI 代理（Agent）越来越强大，但很多人发现：光靠通用大模型的对话能力，在面对重复性强、领域专精或团队规范的任务时，仍然显得“聪明但不靠谱”。Google Antigravity 最近推出的 Agent Skills 功能，正好解决了这类痛点。
今天我们就来完整拆解这项功能：它到底是什么？怎么创建？代理如何使用？应该遵循哪些最佳实践？全文基于官方文档和公告内容，带你一步步搞清楚。
（图：Google Antigravity 官方发布风格图，彩色光点构成的螺旋象征能力不断扩展）
什么是 Agent Skills？一句话说清楚
Agent Skills 是 Google Antigravity 引入的一种开放标准，允许开发者把针对特定任务的知识、流程、最佳实践甚至辅助脚本“打包”成一个文件夹，让 AI 代理在需要时自动调用。
简单比喻：
以前你得每次都长篇累牍地提示代理“请按照我们团队的代码规范来审代码”；
现在你只要写好一个 code-review 技能，代理以后一看到类似任务，就会主动去读这个技能的完整说明，然后按你写好的 checklist 来执行。
这不是简单地把提示词存档，而是结构化、可发现、可复用的能力扩展方式。
Skills 到底包含什么？
每个 Skill 至少包含一个核心文件：SKILL.md
这个 Markdown 文件由两大部分组成：
-
YAML 前置元数据（Frontmatter） —— 代理靠这个决定要不要用你这个技能 -
正文指令 —— 真正指导代理该怎么做事
最简结构示例：
---
name: my-skill
description: Helps with a specific task. Use when you need to do X or Y.
---
# My Skill
在这里写详细的指导语……
## 什么时候使用这个技能
- 当……的时候
- 需要处理……场景时
## 如何使用
1. 第一步……
2. 第二步……
必填字段只有 description，name 如果不写就默认用文件夹名（建议显式写，便于管理）。
技能存放位置与作用域对比
Antigravity 设计了两种存放路径，满足不同场景需求：
| 存放路径 | 作用域 | 典型使用场景 | 优先级 |
|---|---|---|---|
<workspace-root>/.agent/skills/<skill-folder>/ |
当前工作区专用 | 团队专有部署流程、项目特定代码规范、内部工具链 | 高（优先读取） |
~/.gemini/antigravity/skills/<skill-folder>/ |
全局（所有工作区） | 个人常用工具、通用测试模板、语言风格偏好 | 低 |
经验建议：
先把技能写在工作区里，跑通了、觉得好用再考虑提炼到全局。这样可以避免全局污染，也方便团队协作。
（图：典型的技能文件夹结构示意）
推荐的技能目录结构（非强制，但强烈建议）：
.agent/skills/my-skill/
├── SKILL.md # 必须存在
├── scripts/ # 可选：辅助脚本
│ └── lint.sh
├── examples/ # 可选：参考样例
│ └── good-pr.md
└── resources/ # 可选：模板、配置文件
└── template.py
代理到底是怎么使用 Skills 的？（核心机制）
Antigravity 采用 渐进式披露（progressive disclosure） 策略，避免一次性塞给代理太多信息：
-
发现阶段（Discovery）
每次新对话开始时，代理会获得当前可用的所有技能列表，只包含：-
文件夹名 / name -
description
-
-
激活阶段（Activation）
当用户任务出现时，代理根据 description 判断“这个技能看起来很相关”，才会去读取完整的SKILL.md内容。 -
执行阶段（Execution）
读取后就把里面的指令当作高优先级上下文，严格遵循来完成任务。
关键点：
你不需要在提示词里写“请使用 code-review 技能”，代理自己会判断。
但如果你明确写“用 code-review 技能帮我看这段代码”，可以强制激活。
（图：渐进式披露机制的概念示意）
如何创建第一个有价值的 Skill？手把手示例
我们用文档里给出的 code-review 技能来实际走一遍。
步骤 1：在工作区根目录创建文件夹
mkdir -p .agent/skills/code-review
步骤 2：创建 SKILL.md 并写入内容
---
name: code-review
description: Reviews code changes for bugs, style issues, and best practices. Use when reviewing PRs, checking code quality, or auditing implementation.
---
# Code Review Skill
当你被要求审查代码时，必须严格按照以下流程执行，不要跳步。
## 审查检查清单（必须逐项覆盖）
1. **正确性**：这段代码是否真正实现了需求描述的功能？
2. **边界情况**：空输入、极大/极小值、并发访问、超时、网络中断等异常是否被正确处理？
3. **风格一致性**：是否遵循项目已有的编码规范？（缩进、命名、注释位置等）
4. **性能与资源**：是否存在明显的 O(n²) 嵌套循环？是否频繁创建大对象？锁粒度是否过大？
5. **可维护性**：魔法值是否被常量替代？复杂逻辑是否抽取成小函数？是否有足够的单元测试保护？
6. **安全性**：是否存在注入点？密钥是否硬编码？依赖库版本是否已知漏洞？
## 反馈原则
- **具体**：不要写“这里有问题”，要写“第23行变量未初始化，可能导致空指针”
- **讲原因**：每次指出问题都要说明为什么重要（崩溃、性能、安全、可读性……）
- **给建议**：尽可能给出修改后的代码片段或重构方向
- **语气专业且建设性**：避免“你怎么这么写”“这太烂了”等评价性语言
## 优先级排序建议
高危问题（崩溃、安全、数据丢失）→ 中危（性能、并发隐患）→ 低危（风格、可读性）
保存后，重新开始一个新对话，贴一段代码并说“帮我 review 这段代码”，代理大概率会主动调用这个技能。
最佳实践：让你的 Skill 被代理真正“爱用”
-
保持专注
一个 Skill 只解决一类问题。宁可拆成 5 个专注的小技能，也不要写一个“万能瑞士军刀”。 -
Description 是生死线
这是代理判断是否读取你的唯一依据。写得越精准越好。
好例子：
“Generates pytest unit tests following Google Python style guide and coverage >85% target.”
差例子：
“帮你写测试”（太泛） -
脚本当作黑盒
如果放了scripts/lint.sh，在 SKILL.md 里写：
“先运行./scripts/lint.sh --help了解用法，再根据需要执行，不要直接阅读全部源码。” -
加入决策树
复杂任务建议写明“If … then … else …” 逻辑，帮助代理在上下文里快速选择路径。 -
持续迭代
实际用几次后，把代理反馈里反复出错的地方补充到 SKILL.md，形成闭环。
常见问题 FAQ
Q1：我必须自己写所有技能吗？
不需要。官方和社区未来可能会共享一些通用技能，你也可以直接 fork 别人的仓库后放在自己全局目录。
Q2：技能之间会冲突吗？
有可能。如果两个技能的 description 都很匹配同一个任务，代理会根据相关性排序或综合使用。建议 description 写得足够特异。
Q3：可以放二进制文件或大模型权重吗？
文档未明确支持，建议只放文本、脚本、小模板。大文件会严重影响上下文加载效率。
Q4：全局技能和项目技能同时存在时，哪个优先？
项目技能（.agent/skills/）优先级更高，会覆盖同名全局技能。
Q5：代理真的会主动用技能，还是我得一直提醒？
设计目标就是让代理主动判断。只要 description 写得好，任务特征明显，代理会在绝大多数情况下自动激活。
小结：为什么 Agent Skills 很重要？
在 AI 代理从“能聊天”向“能落地”演进的当下，Skills 提供了一种轻量、标准、可组合的扩展方式。它让个人和团队把最宝贵的资产——流程知识、经验教训、最佳实践——变成可复用的“肌肉记忆”，从而大幅降低重复提示成本，提高交付一致性。
如果你已经在用 Google Antigravity，不妨现在就去 .agent/skills/ 目录下建第一个技能文件夹，写一个你每天都在重复教代理的事情。很可能用几次之后，你就会发现：原来 AI 也可以这么“懂事”。
