让 AI agent 在云上干活，难的不是"能不能调 API"——MCP 协议已经把工具通道打通了——而是 agent 不知道一次规范的云上交付长什么样：先评估还是先迁移、部署完怎么验证、配额不够该查哪里。微软把这个缺口做成了开源产品：官方 GitHub Copilot for Azure 仓库 以 agent plugins 的形式提供一整套 Azure 技能，把部署、诊断、合规乃至 Azure Foundry 上 agent 应用的端到端管理，都打包成 coding agent 可以按需加载的"操作手册"。本文按"目录组织 → 安装 → 技能清单 → Foundry 实战 → 架构解读"的顺序拆解这个项目，看看云厂商如何把运维判断力产品化。
1、项目概述
这个仓库的自我定位是"一组面向 Visual Studio、VS Code 与 Claude Code 的扩展，用于简化 Azure 上的开发"。但它的交付物不是传统插件那种按钮和面板，而是给 agent 消费的结构化技能：每个技能面向一个明确任务——目标是什么、分几步做、每步怎么验证——agent 在合适的时机加载它，再调用工具去执行。
两点值得注意：
- 官方一手维护：微软把自家云的领域知识直接开源，技能随 Azure 产品持续演进，仓库提交已过千次
- 多端分发：同一份技能资产同时服务 Copilot CLI、Claude Code、VS Code、IntelliJ、Gemini CLI、Cursor、Codex 等客户端
换句话说，它的用户不是坐在 IDE 里的人，而是人背后的 agent。人只负责提需求，"懂 Azure"这件事由技能资产承担。
2、技能目录组织
仓库的顶层容器是 plugins/，每个插件是一个自包含目录，目前共五个：
azure-skills：主力插件，收纳 28 个通用技能foundry-iq-skills：面向 Azure Foundry 上 agent 应用的全流程azure-cost：成本方向azure-kusto-graph-skills与azure-local-skills：Kusto 图查询与本地场景
每个插件目录里除技能外，还带三份面向不同客户端的清单（.claude-plugin/、.cursor-plugin/、.plugin/）、hooks 定义、.mcp.json 与版本文件。单个技能的内部结构如下，摘自官方 Onboarding 文档：
plugins/<plugin>/skills/<skill-name>/
├── SKILL.md # 技能定义（必需）
├── LICENSE.txt # 许可文件（如有）
├── references/ # 补充参考文档
└── scripts/ # 辅助脚本
SKILL.md 是唯一必需的入口，但官方给它定了硬预算：正文控制在 5000 token 以内，放不下就挪进 references/，且单个参考文件不超过 2000 token，换算口径约 4 字符等于 1 token。这是典型的渐进式披露设计——技能描述常驻上下文供 agent 检索，正文按需读取，细节懒加载，避免撑爆共享上下文窗口。文档还专门提醒：技能描述字段已逼近部分客户端的字符预算，写长了会被截断。
3、安装与客户端支持
以 Copilot CLI 为例，三条斜杠命令完成安装与更新：
/plugin marketplace add microsoft/azure-skills
/plugin install azure@azure-skills
/plugin update azure@azure-skills
三条命令分别完成市场注册、安装与升级，全程在会话内进行，不需要离开终端。Claude Code 一侧走官方市场：/plugin install azure@claude-plugins-official。VS Code 安装官方扩展后技能会提示自动安装，也可以在命令面板里选 @azure: Install Azure Skills Globally 装到用户目录，或选 Locally 装到当前工作区。
环境有两个前置依赖：Git（用于拉取市场插件，缺失时报 spawn git ENOENT）与 Node.js（用于启动 Azure MCP 服务，缺失时报 npx: command not found）。各客户端的功能支持如下：
| 客户端 | 技能 | MCP | Hooks | 状态 |
|---|---|---|---|---|
| Copilot CLI | 有 | 有 | 有 | 完整支持 |
| Claude Code | 有 | 有 | 有 | 官方市场分发 |
| VS Code | 有 | 有 | 有 | 扩展自动安装 |
| IntelliJ | 有 | 有 | 无 | hooks 开发中 |
| Gemini CLI | 有 | 有 | 无 | 已接入 |
| Cursor | 有 | 有 | 部分 | hooks 施工中 |
| Eclipse | 无 | 有 | 无 | 仅 MCP |
4、技能清单速览
azure-skills 主插件的 28 个技能按生命周期归类如下：
| 方向 | 技能 |
|---|---|
| 上云准备 | azure-prepare、azure-cloud-migrate |
| 应用入驻 | azure-app-onboard、azure-app-onboard-prereq |
| 部署交付 | azure-deploy、python-appservice-deploy |
| 容器 | airunway-aks-setup、azure-kubernetes |
| 稳定治理 | azure-diagnostics、azure-reliability、azure-compliance、azure-quotas |
| 资源操作 | azure-resource-lookup、azure-resource-visualizer |
| 基础设施 | azure-compute、azure-storage、azure-kusto、azure-messaging |
| AI 与可观测 | azure-ai、azure-aigateway、appinsights-instrumentation |
| 升级验证 | azure-upgrade、azure-validate |
| 规划身份 | azure-enterprise-infra-planner、entra-app-registration、entra-agent-id |
| 元技能 | discover-azure-skills、microsoft-foundry |
命名直白到可以顾名思义，覆盖"准备—入驻—部署—诊断—治理—升级"的完整闭环。最有意思的是 discover-azure-skills 这个元技能：它教 agent 如何发现并选用其余技能，相当于给技能库配了一个内置检索员——技能数量上来之后，"找到对的技能"本身也成了需要产品化的问题。
5、Foundry Agent 实战
foundry-iq-skills 插件最能体现这个项目的野心：它把 Azure Foundry 上 agent 应用的完整生命周期做成了技能，一条链路走到底：
- 本地构建 Docker 镜像
- 推送到 Azure Container Registry
- 创建 hosted agent 或 prompt agent
- 启动容器运行
- 批量评估（evals）验证效果
前四步是常规交付流水线，最后一步才是关键：把评估做成技能，等于把"agent 上线前必须跑批量评估"这条工程纪律固化进了 agent 自己的操作流程。而且这套纪律是自反的——仓库顶层有独立的 evals/ 目录，官方用 Vally 做技能路由评估和端到端测试，技能本身的质量也走评估管线，贡献新技能的 PR 同样要过这一关。
6、三层架构解读
第三方分析把这套体系归纳为三层：Skills 层负责判断与知识（知道该做什么），MCP 层负责工具执行（真的去做），编排层即 agent 本体负责串联流程，一句话概括是"把云上判断力注入 AI agents"。技能与 MCP 的配合在配置上看得最清楚：插件自带的 .mcp.json 指向 @azure/mcp 官方包，默认连 Azure 公有云；要连主权云，改一行参数即可：
{
"mcpServers": {
"azure": {
"command": "npx",
"args": ["-y", "@azure/mcp@latest", "server", "start",
"--cloud", "AzureChinaCloud"]
}
}
}
改完再执行 az cloud set --name AzureChinaCloud && az login 完成 CLI 侧认证，PowerShell 用户则用 Connect-AzAccount -Environment AzureChinaCloud。这个例子恰好划出了三层的边界：连哪个云是 MCP 配置的事，而在世纪互联环境里部署要注意什么，是技能层的事。云环境差异的更多细节可查 Azure 官方文档。
7、优势与注意事项
先说优势：
- 判断力来源可靠：官方技能与 Azure 产品同步演进，比社区拼凑的提示词靠谱
- 资产复用率高：一份技能覆盖八类客户端，不锁定单一 agent
- 工程化彻底：token 预算、自动版本脚本、hooks 遥测、评估管线一应俱全，hooks 机制文档对复用遥测 hook 有专门说明
- 门槛不高：
npm run plugin:new一条命令生成插件骨架，照着azure-skills抄就能贡献自有技能
再说注意事项：
- 主权云支持要手改
.mcp.json，没有界面可点 - hooks 能力各客户端参差，IntelliJ 与 Codex 暂缺，跨端流程别依赖它
- 技能描述逼近客户端字符预算，自研技能不注意会被截断
- 强依赖本地 Git 与 Node.js 环境，CI 容器里要预装
技能不是越多越好：每份
SKILL.md都在消耗 agent 的共享上下文窗口，官方因此把 token 预算写成硬约束。这条经验对任何自建技能库同样成立。
8、总结
回顾要点：GitHub Copilot for Azure 把 Azure 领域知识组织成 plugin 与 skill 两级结构，azure-skills 主插件的 28 个技能覆盖上云全生命周期，foundry-iq-skills 把 agent 应用的构建、部署与批量评估串成一条链，三层架构里技能管判断、MCP 管执行、agent 管编排。它示范了云厂商的新打法：不卖面板卖判断力，把"老手才知道的操作顺序"变成 agent 可加载的资产。对于在 Azure 上做日常交付的工程师，建议装上 Copilot CLI 或 Claude Code 的插件，从 azure-deploy 与 azure-diagnostics 两个高频技能用起；对于自建 agent 平台的团队，建议直接借鉴它的 SKILL.md token 预算、references 分层与评估管线，这是目前把"技能工程"做得最规矩的公开范本。
