企业级 AI 代理的长期痛点并非模型能力不足，而是提示词膨胀（Prompt Bloat）—— 当系统提示词从 200 词膨胀到 4000 词，代理在每次调用时都需消耗大量上下文窗口解析指令，导致留给实际任务的推理预算被严重挤压。Google 在 Cloud Next '26 发布的 Agent Skills 框架，正是针对这一问题的官方解决方案。与社区驱动的技能框架不同，Google 的版本深度集成其技术栈，提供从边缘到云端的三层协同架构。
三层架构：组织、项目与个人的协同模型
Google Agent Skills 采用分层组合模型（Layered Composition Model），在企业级治理与个人实验之间建立平衡：
组织层（Organization Level） 通过 Gemini Enterprise 管理全球标准、品牌调性与合规规则。这一层确保跨团队的代理遵循统一的安全基线与审计要求，技能在此层级作为一等公民（First-Class Product Feature）存在，与 Agent Designer、安全沙箱和中央监控 Inbox 形成完整的企业代理操作系统。
项目层（Project Level） 依托 Agent Registry 实现客户特定的约定与工作流模式管理。Registry 不仅是一个技能目录，更是治理基础设施 —— 它索引每个内部代理、工具和技能，回答 "哪个技能被加载" 这一关键的审计问题。当技能目录超过 50 个时，描述重叠导致的 ** 技能冲突（Skill Collision）** 风险显著上升，Registry 的元数据管理能力成为必需。
个人层（Personal Level） 通过 Agents CLI 支持个体实验与本地化调整。开发者可使用 uvx google-agents-cli setup 快速启动 ADK 代理，或运行 npx skills add google/skills 安装官方技能包。这一层的设计哲学是：允许快速迭代，但确保可审计的技能最终能向上游贡献。
渐进式披露：从发现到执行的上下文管理
Skills 的核心技术创新在于 ** 渐进式披露（Progressive Disclosure）** 机制，将传统的线性上下文加载转变为动态技能调度。该机制分为三个阶段：
发现（Discovery）：代理启动时仅加载技能的元数据（名称与描述），保持极小的内存占用。代理知道技能存在，但尚未加载完整指令。
激活（Activation）：当任务匹配技能描述时，完整的 SKILL.md 指令才被加载到上下文。这一设计避免了 "Lost in the Middle" 现象 —— 当无关指令饱和上下文窗口时，推理能力会显著下降。
执行（Execution）：代理遵循结构化的 Markdown 指令与模板完成工作，可选择执行捆绑的代码或加载引用文件。
这种三阶段机制使代理能够同时掌握大量技能，而仅在需要时支付上下文成本。对于运行 100+ 生产技能的企业场景，这意味着营销审计代理不再需要每次调用都加载 15,000 token 的指令，而是仅在审计任务触发时才激活相关技能。
技能规范：SKILL.md 与 "提示词 Docker"
Google 采用源自 agentskills.io 的开放 SKILL.md 格式，而非专有规范。一个技能是一个包含 SKILL.md 文件的文件夹，可附带 scripts、references、assets 等可选资源。这种设计实现了 **"提示词 Docker"** 的可移植性 —— 在手机上构建和测试的技能，可直接部署到 Vertex AI 上的 Gemini 3.1 实例，无需修改。
官方技能库（github.com/google/skills）在发布时包含 13 个技能，分为三类：
- 产品技能：AlloyDB、BigQuery、Cloud Run、Cloud SQL、Firebase、Gemini API、GKE
- Well-Architected Pillar 技能：Security、Reliability、Cost Optimization、Operational Excellence、Performance Optimization、Sustainability
- Recipe 技能：Authentication、Onboarding、Network Observability
这些技能是面向代理的文档—— 为代理消费而编写，而非人类阅读。它们提供准确的终端命令、无幻觉的 API 调用、无过时的 SDK 语法。Well-Architected Pillar 技能尤其值得关注：它们将 Google 的架构判断编码为可加载的专业知识，而非 200 页无人阅读的 PDF。
多产品协同：MCP、A2A 与技能层的定位
Google 的技术栈采用开放协议优先策略，形成四层协同架构：
| 层级 | 能力 | 类比 |
|---|---|---|
| Tools / MCP | 系统 API 访问（Slack、BigQuery） | 代理的手 |
| RAG | 知识检索 | 代理的图书馆 |
| Skills | 工作流逻辑与 "如何做" 专业知识 | 代理的训练 |
| A2A | 专业代理间的交接 | 代理的团队 |
MCP（Model Context Protocol） 由 Anthropic 发布，Google 选择采用而非自建竞争标准。Managed MCP 服务器已覆盖 Cloud Run、BigQuery、AlloyDB、Cloud SQL 及完整 Workspace 套件。
A2A（Agent-to-Agent Protocol） 由 Google 与 Linux Foundation 的 Agentic AI Foundation 共同治理，已有 150 个组织投入生产使用。
Skills 层则占据关键的中间地带：比提示词更可重用、比微调更轻量、比 RAG 更主动、比工具更丰富。Google 将其从 "侧边栏功能" 提升为 "承载基础设施"，与 MCP 工具形成互补 —— 工具是无状态的机械调用，技能则承载指令、约定与内部逻辑。
企业级治理：版本管理与冲突检测
当技能目录规模扩大，治理挑战从 "如何创建" 转向 "如何管理"。Google 架构提供了基础设施，但企业仍需建立政策层：
模型版本漂移：为 Gemini 2.0 编写的技能在 Gemini 3.1 下可能表现不同 —— 指令相同，但模型解释可能变化。建议将模型升级视为潜在回归风险，使用 google-agents-cli-eval 技能在推广新模型前对技能目录进行基准测试。固定技能（Pinned Skills）—— 锁定到已验证模型版本的专业知识 —— 可能成为企业标准需求。
技能所有权：不应由单一平台团队拥有所有技能。建议按领域划分：基础技能（格式化、代码模式）归平台团队，工作流技能（Jira 约定、入职流程）归领域负责人，个人技能归个体开发者直至向上游贡献。
技能冲突检测：当技能描述重叠时，代理的路由器可能选择错误的技能，导致微妙的高风险错误。前瞻性团队应建立技能排行榜（Skill Leaderboards），跟踪跨模型迭代的成功率，在问题到达客户前捕获冲突。
可落地的实施路径
对于不同阶段的团队，建议采取以下路径：
已有生产代理的团队：审计当前加载的知识。如果专业知识埋藏在 4000 词的系统提示词中且缺乏明确所有权，使用 Skills 将单体分解为可维护、可版本化的单元。从 "提示词工程" 转向 "技能架构"。
正在构建新代理的团队：从 Agents CLI 开始。运行 uvx google-agents-cli setup 启动首个 ADK 代理，探索捆绑的工作流技能。然后安装官方技能包：npx skills install github.com/google/skills。在承担维护 40+ 自定义技能的生产集群之前，先用这些 "训练轮" 学习模式。
关注企业治理层的团队：建立技能分类模型（Green/Amber/Red）评估外部技能风险，实施渐进式披露模式防止上下文淹没代理，并在技能定义中内置所有权归属，确保当代理失败时 "哪个技能被加载" 有明确答案。
资料来源
- GitHub: google/skills — 官方 Agent Skills 仓库
- agentskills.io — Agent Skills 开放标准
- Sonika Janagill, "Instructions. Skills. Tools. How Google Embedded Skills Into Every Layer of Its Agent Stack", 2026
内容声明：本文无广告投放、无付费植入。
如有事实性问题，欢迎发送勘误至 i@hotdrydog.com。