你接手过一个跑了两年、换过三拨人的 Azure 资源组吗？我接过。打开门户那一刻的感觉很具体：三十多个资源摊在列表里，名字一个比一个抽象，谁连着谁全靠猜。Wiki 里那张架构图是半年前画的，图上还有两个已经被删掉的存储账户。
这种”看得到资源、看不清关系”的状态，是云上最常见的盲区。资源组本身是平的，它只记录”有哪些东西”，不记录”这些东西怎么咬合”。真要排障或者做安全评审，你得上上下下点十几个资源的网络配置，才能拼出一张脑内拓扑。效率低还在其次，漏看一条私有端点才是要命的。
市面上不是没有解法。Azure Monitor 有拓扑视图，Workbooks 能拖可视化，但要么得手动点，要么得写 KQL，而且产出的东西很难带走、很难进版本库。很多人最后还是回到画图工具手绘，画完又立刻过期。
github/azure-resource-visualizer 这个 Smithery skill 走了一条更直接的路：它不替你打开画图工具，而是让 Agent 去读 Azure 的真实状态，自动生成一张 Mermaid 架构图，连关系一起画出来，再落成一个 markdown 文件。本质上，它是把”理解资源组”这件事，从人力活变成了 Agent 的一次分析任务。
说实话，我一开始对这类”诊断型 skill”是存疑的。它不跑业务、不改资源，听起来像个锦上添花的玩具。但真正用它扫了一个资源组之后，我的判断变了：在云治理这种”先得看清现状才能动手”的场景里，一个只读的、准确的、可版本化的现状图，价值比很多花哨的自动化组件都实在。
使用场景
最典型的现场，是某人把生产资源组丢给你，说”帮我看看这堆东西是怎么连的”。没有这个 skill，你会陷在点资源、翻网络配置、记笔记的循环里。有了它，Agent 先把资源组里的资源全量拉出来，按网络、计算、数据、安全几层归好类，再把连接关系标在图上。
一个值得说的中间步骤是”选资源组”。如果用户没指定，skill 不会瞎猜，而是先列出当前订阅下的所有资源组，带上位置，让你按编号选。这个交互设计我挺认可，它避开了 Agent 最常犯的错误：在没确认范围时就对着整个订阅开扫，token 和输出都炸。
复杂架构是第二个现场。当资源组超过五十个资源，一张图会糊成一团。skill 的处理是建议按层拆多张图（网络一张、数据一张），而不是硬塞进一个画布。我在看一个四十多资源的组时，第一次体会到”分层”不是美观问题，是可读性问题：不分层的图，人眼根本追不动连线。
第三个现场是交接和评审。生成的 [rg-name]-architecture.md 是个纯文本文件，图是 Mermaid，能直接 commit 进仓库。这意味着架构图第一次有了”和代码一起演进”的可能，而不是躺在 Confluence 里慢慢腐烂。这一点对需要过安全或合规评审的团队尤其有用，评审人不用登 Azure，看文件就行。
# skill 在底层实际驱动 Agent 执行的典型命令（以 Azure CLI 路径为例）
az group list --output table
az resource list --resource-group rg-prod-app --output json
az network vnet show --resource-group rg-prod-app --name vnet-prod
az resource show --resource-group rg-prod-app --name kv-prod --resource-type Microsoft.KeyVault/vaults
技术架构与设计决策
这个 skill 的本体是一份 SKILL.md，也就是一段注入 Agent 上下文的指令，不是带运行时依赖的程序。它定义了一套四步工作流，并规定了每一步该产出什么。理解它的设计，得先理解它刻意不做的事：它只读，不写。
“只读”是整份设计的锚点。skill 明确列出”永不修改或删除 Azure 资源”，所有操作都是 list 和 show。这把它的风险面压到了最低，也让它能在权限受限的环境里跑。对比那些会顺手帮你”顺调一下配置”的 Agent 组件，这种克制反而更让人敢用。
它的图是用 Mermaid 生成的，而非图片或专有格式。这个选择我越想越对：Mermaid 是文本，能被 Git 跟踪、能在任何支持 Mermaid 的渲染器里出图、diff 得出来。一张架构图从此有了版本历史，哪次变更动了拓扑，blame 一下就知道。文本化还意味着它可以进 PR 评审流程，而不是事后补文档。
关系识别是它真正吃功夫的地方。skill 要求 Agent 不只列出资源，还要标出五种连接：
-
网络：VNet 对等，子网，NSG，私有端点 -
数据流：App 到 DB，Function 到 Storage -
身份：托管身份连资源 -
配置：App Settings 指向 Key Vault -
依赖：父子与必需资源
最难也最容易错的是”配置连接”，比如一个 App Service 的 connection string 指向哪个库，这种隐性依赖光看资源列表是看不出来的，得读配置。
# skill 要求产出的 Mermaid 片段（节选自其示例，展示分层与连线标注）
graph TB
subgraph "Network Layer"
VNET[Virtual Network<br/>10.0.0.0/16]
SUBNET1[Subnet: web<br/>10.0.1.0/24]
end
subgraph "Compute Layer"
APP[App Service<br/>Plan: P1v2]
FUNC[Function App<br/>Runtime: .NET 8]
end
subgraph "Data Layer"
SQL[Azure SQL Database<br/>DTU: S1]
end
APP -->|"HTTPS requests"| FUNC
FUNC -->|"SQL connection"| SQL
VNET --> SUBNET1
SUBNET1 --> APP
节点标签的颗粒度也值得提。它要求把 SKU 与层级写进节点，运行时、冗余也一并标注。比如 App Service 标 Plan: P1v2，SQL 标 DTU: S1。这让图不只是拓扑，还是一份带容量的速览。我后来发现，恰恰是这些标签，让评审人能一眼揪出”生产环境怎么还用 Basic 层”这类问题。
洞察与反思
它的强项很突出：只读所以安全，Mermaid 所以可版本化，分层所以可读，关系识别覆盖到配置级所以比人肉点资源更全。对”模型天天跟 Azure 打交道、又总看不清资源关系”的团队，装上它几乎零成本换来了现状透明。
但暗坑得摊开说，主要有四处：
-
依赖前置：skill 自己不连 Azure，它靠 Agent 去调 Azure MCP 或本地 az。如果你没装 Azure MCP、也没登录az，它什么也干不了。它解决的是”看不清”，不是”连不上”，这两个坑得分清楚。 -
关系推断的可靠性边界：skill 反复强调”不要凭假设标关系，要验证”，但隐性连接（尤其是配置里的 connection string、跨资源组的依赖）靠的是 Agent 读配置的能力。配置读不全或读错，图上的线就是错的，而且错得很隐形，因为图看起来”很完整”。 -
规模上限：它自己写了”50+ 资源考虑拆多张图”，但即便拆了，超大型资源组的图依旧难读，生成时间随资源数线性上涨。它适合”看清一个组的现状”，不适合”俯瞰整个订阅的全局拓扑”。 -
最容易被忽略的一点：它生成的是”现状图”，不是”应有图”。它不评价架构好坏，不指出反模式，不给你优化建议，只忠实反映当前状态。价值在”看清”，不在”改对”。
几类方案在要害维度上差别其实挺大：
| 维度 | azure-resource-visualizer | Azure Monitor 拓扑/Workbooks | 手绘 draw.io | IaC 图（Bicep/Terraform graph） |
|---|---|---|---|---|
| 数据来源 | 真实运行状态 | 真实运行状态 | 人脑记忆 | 代码定义 |
| 是否只读 | 是 | 是 | 不适用 | 是 |
| 版本可控 | 是（Mermaid 进 Git） | 否（门户内） | 是（文件） | 是（代码即图） |
| 自动关系推断 | 中（依赖 Agent 读配置） | 中（靠监控数据） | 否 | 高（代码即真相） |
| 反映真实态 | 是 | 是 | 否（易过期） | 否（反映期望态） |
| 上手门槛 | 低（装 skill 即可） | 中（需点门户/写 KQL） | 高（手动画） | 高（需懂 IaC） |
最清晰的结论是：如果你已经有 Bicep/Terraform，那”代码即图”比任何事后可视化都准，因为代码才是真相源。但这个 skill 的价值在另一个区间，那些资源是点出来的、没走 IaC、或者 IaC 和现实已经漂移的环境。它补的是”真实态”这最后一公里。
资源地址
-
Smithery 技能页：https://smithery.ai/skills/github/azure-resource-visualizer -
安装命令： npx skills add https://smithery.ai/skills/github/azure-resource-visualizer -
Azure MCP Server（skill 首选数据源，需单独配置）：https://github.com/Azure/azure-mcp -
Azure CLI 文档：https://learn.microsoft.com/cli/azure
总结
我的建议很直接：如果资源是手动在门户里点出来的，没走 IaC，或者 IaC 已经和现实对不上，又经常需要跟人讲清”这堆东西怎么连的”，装这个 skill 是稳赚的。它不神奇，就是一次只读的现状扫描加一张可进版本库的图，但”看清现状”这四个字，在交接、评审、排障现场值很多钱。
判断装不装，看一个指标就够了：你一季度里需要向别人解释或评审这个资源组的次数，超过三次吗？超过，它回本极快；偶尔才动一次，翻门户也来得及。它最大的价值在”需要把云上现状摊开给人看”这个动作，出了这个区间，边际收益迅速归零。
如果你团队已经全面 IaC，别急着上它。先把 terraform graph 或 Bicep 的可视化用顺，那边的图更准、更不会和现实漂移。这个 skill 适合的是 IaC 覆盖不到、或者覆盖已失真的那部分真实云。把它当”真实态快照器”，而不是”架构治理终局”，这个定位才准。
只是别把它当银弹。它依赖 Azure MCP 或 az 已就绪，关系推断有读配置的能力边界，超过五十资源要手动拆图，而且只画现状不评好坏。把它用在”看清”这一步，再把”改对”交给评审人和 IaC，才是合理的拼法。这个判断会随 Azure MCP 的成熟度变化，半年后值得再评估一次。