这两天我把 Google Antigravity 的新版本更新一下，最直接的感受是：Agent Skills 的标准化速度比我预期快。

Antigravity 宣布原生支持之后，主流 Agent 平台CLI Claude Code/Codex/Gemini已全部支持Skills。

对我这种把工作流程沉淀到工具里的产品经理来说，这意味着“提示词 + 规范 + 轻脚本”的组合，开始成为一种更稳定的沉淀方式。

核心观点很简单：Agent Skills 正在走向通用标准，迁移成本可控，但需要配套的命名规范、范围边界和安全治理，才能在团队中长期可用。

关键更新

• Antigravity 原生支持 Agent Skills：可以在工作区与全局两层目录下管理和调用。
• 跨平台迁移更顺：基于结构化的 SKILL.md 和目录约定，和 Claude Code Skills、MCP 子代理/命令存在较高重合度，迁移时多为路径与脚本兼容性的小改动。
• 零起步门槛：不写代码也能先把流程写成 SKILL.md；有需要再补 scripts、examples、resources 等资源。
• “渐进式披露”机制：Agent 先看到技能列表（名称、描述），再按需加载完整指令，降低无关内容占用上下文的概率。

Agent Skills 是什么？

Skills 的本质是可复用的知识包，用来扩展 Agent 的能力。

一个 Skill 就是一个包含 SKILL.md 的文件夹，核心内容是明确的任务指令与使用时机，必要时可配合资源脚本。

目录结构

.agent/skills/
└── my-skill/
    ├── SKILL.md       # 主要指令（必需）
    ├── scripts/       # 辅助脚本（可选）
    ├── examples/      # 参考示例（可选）
    └── resources/     # 模板与资源（可选）

SKILL.md 结构（YAML frontmatter）

---
name: my-skill
description: 帮助完成特定任务。当你需要做 X 或 Y 时使用。
---

# My Skill
这里是 agent 的详细指令。

## 何时使用此 skill
- 当...时使用
- 这对...有帮助

## 如何使用
agent 应遵循的分步指导、约定和模式。

• name：唯一标识符（小写、用连字符），缺省时使用文件夹名。
• description：简洁说明功能与使用时机，Agent 是否选用该 Skill 主要看这里。

两类技能的安装位置

• 工作区 skills：当前项目/.agent/skills/，适合项目/团队特定流程（如部署、测试约定）。
• 全局 skills：~/.gemini/antigravity/skills/，适合通用工具（如代码审查、归档模版）。

调用机制（渐进式披露）

1. 对话开始时，Agent 只看到可用技能的名称与描述。
2. 判断相关性后，才读取完整 SKILL.md 并按指令执行。
3. 必要时访问 scripts、resources 等辅助文件。

与现有方式的差异：更结构化、可组合

与 Claude Code Skills 的关系：从落地形态看，二者都属于“结构化提示词 + 可选工具”的范畴；配合 MCP 子代理/命令时，可进一步把复杂动作外包给工具层，Skill 专注于“什么时候怎么做”的规范。

如何创建一个 Skill

1. 在工作区或全局目录下创建文件夹：
   • 工作区：./.agent/skills/my-skill/
   • 全局：~/.gemini/antigravity/skills/my-skill/
2. 添加 SKILL.md，包含 YAML frontmatter（name、description）和明确的任务指令。
3. 按需补充 scripts/、examples/、resources/，为 Agent 提供可执行入口与参考材料。

实测体验与迁移提示

• 简单迁移可行：将一个“代码审查”类技能从其他平台迁到 Antigravity，保留 name/description 与步骤说明即可运行。
• 脚本差异需关注：
  • 路径：工作区与全局目录的相对路径不同，脚本内的文件引用要相对化。
  • 平台：Windows 与类 Unix 环境的 shell、权限、行尾符差异会影响执行。
• 发现性依赖描述质量：description 写得越清晰，Agent 越容易正确选用技能。
• 与 MCP 的配合：当需要访问外部系统或执行复杂命令时，建议将动作下沉到 MCP/工具层，Skill 保持“单一职责”的指令与选择逻辑。

最佳实践（适合团队落地）

• 单一职责：一个 Skill 只覆盖一类任务，避免“万能技能”。
• 清晰描述：description 直指功能与触发时机，避免抽象口号。
• 优先 --help：若包含脚本，引导 Agent 先用 --help 获取用法，减少上下文负担。
• 方法选择指引：复杂技能提供“如何选择分支”的章节，降低误用概率。
• 命名与版本：name 稳定、语义清晰；在 SKILL.md 底部约定版本与变更日志，便于回溯。
• 安全与权限：脚本访问范围最小化；明确输入输出与副作用，避免误操作生产环境。

谁适合用、怎么用得住

• 适合人群
  • 开发与测试：代码审查、变更检查、回归清单、基准测试。
  • 产品与运营：需求模板、复盘框架、数据归档、公告生成规范。
  • 小团队：把“口头约定”沉淀为可复用技能，形成最小化标准流程库。
• 使用门槛
  • 仅文档：低门槛，写清楚步骤与判断即可。
  • 含脚本：需要基础脚本能力与环境管理。

一个精简的示例（代码审查 Skill）

---
name: code-review
description: 审查代码更改中的错误、风格和最佳实践。在审查 PR 或检查代码质量时使用。
---

# Code Review Skill

## 审查清单
1. 正确性：是否按预期工作？
2. 边界与异常：错误条件是否处理？
3. 风格：是否遵循项目约定？
4. 性能：是否存在明显低效？

## 如何提供反馈
- 指出需要改变的具体位置
- 解释原因，而不只是结论
- 提出可行的替代方案

我的结论

从 Antigravity 的原生支持到多平台的兼容性信号，Agent Skills 正在从“提示词工程”过渡到“可治理的知识包”。

对于需要把流程标准化的团队，它提供了一个低门槛、可复用、可组合的中间层；对于需要强集成的场景，可以与 MCP/工作流衔接。

接下来我会把团队常用的评审、发布、例会模板逐步沉淀为 Skills，并做一套命名与版本规范，观察三周后再看使用频率与误触发率。如果你也在评估是否迁移，优先从“无副作用、纯文档类技能”开始，会更稳。