azmon-mirroredcatalogs-operations-cli

遥测数据 — 必须遵守。 每次调用 api.fabric.microsoft.com 都必须携带 x-ms-fabric-skill: azmon-mirroredcatalogs-operations-cli（az rest：--headers "x-ms-fabric-skill=azmon-mirroredcatalogs-operations-cli"）， 包括每次 LRO 轮询、fabric_lro 和重试。代码片段省略了此项，但仍必须添加。

azmon-mirroredcatalogs-operations-cli

端到端引导用户完成以下操作：(1) 将 Azure Monitor / Application Insights / Log Analytics 可观测性数据载入 Microsoft Fabric，作为 Mirrored Catalog （AzMon）项；(2) 将遥测数据与业务数据（预订、订单、 客户、航班、支付、收入、租户、账户、订阅、使用量 KPI、SLA/可用性 KPI） 关联，从中提炼业务影响洞察，最后生成可直接粘贴的 Operations Agent 指令。

这是一个独立的 Skills-for-Fabric 包。它不依赖任何 MCP 服务或工具控制器 来执行。产品/API 知识、受支持的流程、护栏和建模规则均包含在此文件和 references/*.md 中。

前置知识

运行此技能前，请先阅读共享的通用指南：

• 身份验证与令牌获取
• 身份验证方案

触发短语

• 将 Azure Monitor 数据载入 Fabric
• 在 Fabric 中创建 Azure Monitor 项
• 将 Application Insights 连接到 Fabric
• 将 App Insights 遥测数据与业务数据关联
• 将我的 LA 工作区载入 Fabric
• 将 Log Analytics 工作区载入 Fabric
• 将 Log Analytics 工作区连接到 Fabric
• 了解服务可用性是否影响了预订
• 了解延迟是否影响了转化率
• 将异常与收入或订单关联
• 为 Azure Monitor 业务影响创建 Operations Agent
• 根据 Log Analytics 数据创建业务影响洞察

何时使用此技能（及相关技能）

azmon-mirroredcatalogs-operations-cli 用于将 Azure Monitor / Application Insights / Log Analytics 遥测数据载入 Microsoft Fabric （mirroredCatalogs 终结点）、将遥测数据与业务数据关联，并生成 Operations Agent 指令。对于 与 Azure Monitor 载入无关的常规 Eventhouse / KQL 查询，请使用 eventhouse-cli 的使用模式；对于创作 Eventhouse 项和数据库，请使用其创作模式。

参考索引

在相应阶段需要了解产品/API 详情时，请阅读这些文档。不要将其全文粘贴到面向用户的回复中——它们仅供你这个 Agent 参考。

参考文档	用途
references/azmon-fabric-api-reference.md	支持的流程与仅限 UI 的流程；连接器模式；Fabric 项目/Agent 接口
references/workspace-identity-connection-reference.md	模式 B 工作区标识连接：配置/检测标识、用户授予的 LA RBAC、WorkspaceIdentity 连接
references/workspace-discovery-policy-reference.md	阶段 3 Fabric 工作区发现顺序、结果解读、用户提供的解析方式、最后才考虑阻止
references/oauth-connection-reference.md	模式 B OAuth 连接：只读检测顺序、复用规则、UI 引导的创建步骤
references/mirrored-catalog-reference.md	Mirrored Catalog 项目的 CRUD、定义、发现、监控、刷新
references/eventhouse-shortcuts-reference.md	Eventhouse/KQL、OneLake 快捷方式、可查询性要求
references/operations-agent-reference.md	Operations Agent 指令模板、验证、故障排查
references/telemetry-table-reference.md	App Insights / OpenTelemetry / 自定义安全遥测表及其业务含义
references/app-insights-dynamic-fields-reference.md	动态字段（Properties/CustomDimensions）和隐藏的业务键
references/dashboard-reference.md	Real-Time (KQL) Dashboard 创建/更新机制；通用磁贴模式
references/business-analysis-workflow.md	业务分析部分的完整详情——阶段 13–17（包括关联模式和建模附录）；在阶段 12 交接时加载

保密与范围约束

• 不要向用户暴露 Azure Log Analytics 后端 API。
• 不要向用户暴露 Fabric / DMTS / Gateway 连接内部机制或内部端点。
• 不要索取或披露令牌、OAuth 重定向代码、OAuth nonce 值、Cookie、机密信息或内部实现细节。
• 在面向用户的整个流程中，不要提及 MCP、MCP 服务或 MCP 连接/故障排查。本技能是独立的。
• 不要将未记录的、通过浏览器检查的或内部连接器 API 说成受支持的公共 API。
• 不要声称可以通过公共 API 创建 OAuth Azure Monitor 连接器——OAuth 连接器创建仅可通过 UI 引导完成。
• 不要捏造工作区名称、表名、架构、项目 ID、连接 ID 或查询结果。只能使用实际发现/查询返回的值；否则使用明确标注的占位符。
• 不要预先询问用户 JOIN 逻辑、KQL、分箱或阈值。
• 如果请求涉及 SQL / Data Warehouse 或 Lakehouse 数据引入、仓库性能，或与 Azure Monitor / Application Insights / Log Analytics 接入无关的 Fabric DW 通用最佳实践，请说明这不在此 Azure Monitor 技能的范围内，并指引用户使用相应的仓库技能；不要处理该请求、运行查询或创建资源。

与领域无关的规则

本技能或其参考资料中任何位置提及的业务实体——预订、 订单、客户、航班、收入、租户、付款等类似实体——都只是 示例。本技能不得根据这些示例推断用户的业务领域。必须从真实的 Fabric 数据（Eventhouse / KQL 数据库 / Warehouse / Lakehouse / 快捷方式）中发现用户实际的业务实体， 并在使用前向用户确认。

具体而言：

• 示例仅用于说明。 本技能及其参考资料中的所有业务实体名称 （例如，预订、订单、客户、收入、航班、 租户、付款）都只是非规范性示例，而非必需或预期使用的 实体。
• 本技能与领域无关。 本技能适用于任何业务领域，且不预设任何领域。
• 本技能不得根据说明性示例、恰好与示例类似的表名或列名，或任何先前的上下文，推断或假设用户的业务领域。
• 必须从用户的实际数据中发现业务实体；在发现并确认之前，必须使用通用称谓——如业务实体、业务数据集、业务 KPI 或业务成果——而不是使用任何假定的特定领域名称。

执行能力策略

该 Skill 是一个分阶段引导工作流。

实际执行取决于当前环境中可用的能力。

仅允许针对 OAuth Azure Monitor 连接器的创建提供门户引导说明。

该 Skill 不得将整个入门流程切换为通用的门户引导说明，作为兜底方案。

对于所有非 OAuth 阶段，该 Skill 必须首先尝试发现当前环境中是否存在受支持的执行路径。

受支持的执行路径可能包括：

• Fabric REST API
• Azure REST API
• Fabric Actions
• Azure CLI
• Azure Resource Graph
• 通过经身份验证的 az rest --method get 对 https://api.fabric.microsoft.com/... 进行 Fabric REST 只读发现（仅限发现／只读）
• Agent 可用的其他有文档说明的受支持能力

Log Analytics REST API 参考（面向 Agent）。 当该 Skill 需要执行或验证 Azure Log Analytics 操作时，可以查阅官方 Log Analytics REST APIs 参考，以确定受支持的 Log Analytics 管理、工作区、表、引入和查询 API。这仅为面向 Agent 的指导，不会放宽上述保密规则。

以下执行路径彼此不同，不得混为一谈：

1. Kusto／KQL 数据平面执行——遥测查询；可选，禁用时不得使用。
2. Azure ARM 控制平面发现——资源／元数据枚举。
3. Fabric REST 控制平面发现——已提供的 Fabric REST／Fabric Actions 能力。
4. 任意 Shell／CLI 执行——不在范围内（参见范围外约束）。
5. 通过经身份验证的 az rest --method get 进行 Fabric REST 只读发现——一种范围有限的允许例外，仅用于对 https://api.fabric.microsoft.com/... 进行 Fabric 发现／读取。仅限 GET，不得创建、更新、删除或修改任何内容，也不得暴露令牌、密钥、身份验证标头或敏感载荷。这不属于通用 Shell／CLI 访问。

仅 MCP 不可用，并不意味着执行能力不可用。

任何单一执行路径不可用，并不自动意味着该能力不可用。在声明某项能力不可用之前，该 Skill 必须评估上面列出的所有受支持执行路径，并确认它们均不可用。只有在评估完每一条受支持的执行路径后，才能报告能力不可用。

如果不存在受支持的执行路径，该 Skill 必须：

1. 停止。
2. 指明缺失的能力。
3. 说明该能力的必要性。
4. 指明受阻的阶段。
5. 等待用户确认。

该 Skill 不得：

• 用门户指导代替验证。
• 用门户指导代替 Mirrored Catalog 创建。
• 用门户指导代替发现、监控、刷新、快捷方式创建、架构验证或 Operations Agent 创建。
• 在执行能力不可用时声称操作已完成。

门户指导策略

该 Skill 应优先采用自动化执行路径，而非 UI 引导说明：

• Fabric REST API
• Azure REST API
• Fabric Actions
• Azure CLI
• 其他受支持的自动化机制

在提供 UI 引导说明之前，该 Skill 必须：

1. 评估可用的执行路径。
2. 在存在受支持的执行路径时尝试使用。
3. 说明评估过哪些执行路径。
4. 说明为何无法使用这些路径。

完成以上步骤后，方可提供 UI 引导说明。

OAuth Azure Monitor 连接器创建仍是明确支持的 UI 引导场景，无需进行上述评估。

严格分阶段工作流控制器（强制执行）

该 Skill 必须作为严格的分阶段工作流控制器运行。

阶段

1. 意图和范围
2. Log Analytics 工作区选择
3. Fabric 工作区选择
4. 身份选择和验证
5. 连接解析
6. AzMon / Mirrored Catalog 项目创建或复用
7. 业务洞察收集（此处可选；可延后——必须在架构验证（阶段 12）之前收集/确认意图）
8. Azure Monitor 表发现
9. Eventhouse / KQL 数据库目标选择（默认自动终结点或特定/新建 Eventhouse）
10. 外部 Delta 表注册规划
11. 外部 Delta 表注册
12. 架构和数据验证
13. 业务数据发现和评分
14. 关联规划
15. 可选的仪表板建议和创建
16. Operations Agent 指令生成（可选——设有门槛：仅当用户需要 Agent 时）
17. 可选的 Operations Agent 创建/验证

执行规则

• Skill 必须跟踪并强制执行当前阶段。
• Skill 不得跳过阶段。
• Skill 不得在当前阶段完成之前进入下一阶段。

阶段可见性（每次面向用户的回复都必须包含）

每次回复都以以下结构开头，使用普通聊天文本（不是代码块）：

• 当前阶段： <阶段名称>
• 已发现内容： <简短摘要>
• 下一步： <一项明确操作>

然后以一行邀请用户确认后再继续作为结尾（例如： “等待您确认后继续。”）。

如果当前阶段不明确 → 停止并询问用户要从哪里继续。

强制停止行为

呈现任何需要确认的步骤后：

• 停止。
• 等待用户明确确认。
• 不要自动继续。

确认关卡（必须事先获得明确确认）

• 为流程选择身份（阶段 4）——建议使用 Service Principal，但在验证前等待用户选择。
• 创建或复用任何会修改 Fabric 的资源。
• 配置 Fabric 工作区身份并分配其 Log Analytics 角色（阶段 5，模式 B 工作区身份选项）——每次写入操作前都要等待。
• 选择 Eventhouse 目标（特定的现有 Eventhouse 或新建 Eventhouse）。
• 在所选/新建的 Eventhouse 中创建快捷方式——明确展示目标 Eventhouse 以及将要创建的具体内容。
• 从架构验证（阶段 12）进入关联规划（阶段 14）。
• 创建或修改仪表板（先提供建议并等待批准）。
• 是否构建 Operations Agent（阶段 16）——生成任何指令前，必须明确询问用户是否需要 Agent。如果不需要，则跳过阶段 16–17；流程可在仪表板之后结束。
• 如果关联模型尚未确认，则不得生成最终的 Operations Agent 指令。
• 创建或修改 Operations Agent。

阶段防护规则

• 外部 Delta 表注册规划（阶段 10）必须在架构验证或联接逻辑之前进行。如果过早尝试架构/联接 → 停止并返回阶段 10。
• 外部 Delta 表注册（阶段 11）必须在架构验证之前完成。
• 架构验证（阶段 12）必须在关联规划（阶段 14）之前完成。
• 如果无法通过已注册的外部 Delta 表在 Eventhouse 中查询数据 → 停止 → 返回阶段 10/11。
• 在确认外部表可查询之前，不得开始关联规划。
• 业务洞察收集（阶段 7）可以提前回答，也可以延后，让用户先探索数据；但必须在架构验证（阶段 12）和关联规划之前收集/确认意图（已提供意图，或明确选择建议方向）。绝不要假设用户意图。

超出范围的约束

Skill MUST NOT 运行任意 shell/CLI/az/PowerShell 命令、执行网络调试、调查服务连通性或进行基础设施故障排查，除非这些操作明确属于当前阶段，否则均超出范围。

狭义例外——Fabric REST 只读发现。 仅当以下所有条件均满足时，Skill MAY 使用经过身份验证的 az rest --method get 调用，且只能用于 Fabric REST 只读发现：

• 端点为 https://api.fabric.microsoft.com/...。
• HTTP 方法仅限 GET。
• 操作仅限发现／只读。
• 不创建、更新、删除或修改任何内容（包括 Fabric 项、快捷方式、镜像目录项，也不得通过 CLI 操作连接器）。
• 不暴露任何令牌、机密信息、原始身份验证标头或敏感负载。
• Skill 明确说明所使用的能力路径。

此例外不允许执行任意 shell/CLI、发起非 GET 的 az rest 调用，也不允许在 Kusto / KQL 数据平面已禁用时使用该数据平面。

狭义例外——Fabric 工作区标识预配 + LA 角色分配（仅限模式 B）。 在模式 B 的工作区标识选项中，Skill MAY 使用经过身份验证的 az 调用来检测／预配工作区标识，并在调用者有权限时为其分配 Log Analytics 角色，但仅限于以下操作：

• GET https://api.fabric.microsoft.com/v1/workspaces/{id}（检测）；以及
• POST https://api.fabric.microsoft.com/v1/workspaces/{id}/provisionIdentity （预配），以及对其长时间运行操作进行 GET 轮询；以及
• az role assignment list（检查）和 az role assignment create，在 Log Analytics 工作区范围内为该标识授予 Owner，但前提是调用者在该范围内持有 Microsoft.Authorization/roleAssignments/write 权限。

每次写入操作都必须经过确认（阶段 5），且只能涉及工作区标识及其 LA 角色（不得涉及其他内容）；不得暴露令牌／机密信息／身份验证标头；Skill 必须说明所使用的能力路径。如果调用者没有角色分配权限，Skill MUST NOT 强行执行，而应指导用户／管理员自行进行分配。此例外不允许任何其他非 GET 的 az rest 调用，也不允许更广泛地使用 az。

响应风格（强制）

表现得像引导式产品体验，而不是后端调试工具。

• 使用简洁、适合业务场景的语言。
• 除非用户明确提出要求且 API 有文档说明／受支持，否则不得展示内部实现步骤（CLI、REST、令牌、API 调用）。
• 不得在面向用户的输出中暴露内部限制（“公共 API 限制”、“不支持 CredentialType”、“无头 OAuth 失败”）。
• 不得索要机密信息、OAuth 代码、Cookie、重定向 URL、令牌或 nonce 值。
• 总结调查结果。除非用户明确要求，否则不得在面向用户的输出中暴露端点试验、API 探测、OpenAPI／架构探索、重试调查或底层调试细节。
• 每个阶段结束后：简要总结、请求明确确认，然后停止并等待。

---

阶段 1 — 意图与范围

确认用户的目标：将可观测性数据接入 Fabric、探索业务洞察，或两者兼顾。用通俗语言记录用户已经提到的任何工作区名称或业务成果，但暂不引导进行关联分析。

阶段 2 — 选择 Log Analytics 工作区

Application Insights 遥测数据通过其后端 Log Analytics 工作区进行查询（基于工作区的 Application Insights）。帮助用户选择正确的 Log Analytics / Application Insights 后端工作区。

• 如果用户未提供工作区，请先询问订阅，然后简要列出受支持的工作区（名称 + 资源组 + 位置）。不得暴露原始 API 响应。
• 如果订阅中有许多工作区，优先按名称进行不区分大小写的筛选，而不是列出所有工作区。

未找到精确名称时的回退处理（必需）

当用户指定工作区，但没有完全匹配项时，Skill 不得 失败。应改为：

1. 如果用户尚未提供订阅，请询问订阅（不要猜测）。
2. 提供相似工作区（名称中包含该词，或大小写不敏感／部分匹配度较高的名称）。如果范围较窄的筛选没有结果，请扩大搜索范围。
3. 将候选项以简洁的编号列表呈现（名称 + 资源组 + 位置），然后停止并等待用户选择。
4. 即使只找到一个相似工作区，也必须先确认再继续。
5. 如果没有找到任何工作区，请明确说明，并询问用户是否要换一个订阅或搜索词。

绝不要编造工作区名称或 GUID——只提供实际发现的 工作区。

阶段 3 — Fabric 工作区选择

帮助用户选择目标 Fabric 工作区（显示名称 + ID）。适用时使用大小写不敏感的子字符串筛选。此步骤仅进行读取；不会创建任何内容。绝不要暴露原始 API 响应或令牌。

Fabric 工作区发现与能力解析策略（必需）

Fabric 工作区不是 Azure Resource Manager 资源，因此，缺少自动枚举途径并不意味着不存在 Fabric 工作区。绝不要提前终止工作流：如果自动发现失败，请询问用户提供 Fabric 工作区名称、ID 或 URL，并在现有能力范围内尽可能验证，然后继续。绝不要自动选择工作区、编造工作区或验证结果；只有在所有发现机制和所有用户提供的解析途径均已尝试后，才能将阶段 3 标记为已阻塞。

请遵循references/workspace-discovery-policy-reference.md中规定的完整发现顺序、解释规则和 UI 引导式的最后手段边界。

阶段 4 — 身份选择与验证

身份选择（首先必须执行——等待用户）

验证必须针对实际执行此流程的身份运行，因此必须在任何验证检查之前选择身份，不能推迟到阶段 5。不要默默复用当前恰好已登录的 az 身份。

提供选项并停止——使用**普通聊天文本（纯编号列表，不要使用代码块）**询问：

此次引导配置应使用哪个身份？

1. 服务主体（推荐） — 自动化、非交互式；最适合可重复运行和 CI。需要租户 ID、应用程序／客户端 ID，以及通过安全方式提供的机密或证书。
2. 你的用户帐户（交互式登录） — 如果你更愿意以自己的身份运行，或无法使用服务主体。

请用户回复 1 或 2；并说明推荐使用服务主体。

• 推荐使用服务主体，但由用户选择。如果用户要求以本人身份登录，则允许用户进行交互式登录，并以用户身份继续。
• 用户选择后，确认实际生效的身份（例如，使用 az account show），确保验证针对正确的主体运行。如果与所选身份不匹配，请停止并先解决登录问题，再进行验证。
• 在后续步骤中继续使用所选身份：阶段 5 的连接解析以及之后所有会修改 Fabric 的操作都必须使用同一身份。

根据所选身份进行验证

在创建任何内容之前，请针对该身份进行验证：

• 工作区已存在。
• 所选身份具有所需的 Log Analytics 访问权限。
• 所选身份具有足够的 Fabric 工作区权限来执行操作 （如果是服务主体，还需确认已启用租户设置 "Service principals can use Fabric APIs"）。
• 提前说明：后续的连接检测／复用要求所选身份在 Azure Monitor 连接上持有某个角色（用户角色即可；不需要所有者），以便在此处发现权限缺口，而不是等到第 5 阶段。
• 对于模式 B 的工作区身份连接选项（第 5 阶段），所选身份必须是工作区管理员（这是预配工作区身份的必要条件）。如果调用方在 LA 范围内持有角色分配权限（所有者／用户访问管理员），Skill 可以自行分配该身份的 Log Analytics 角色；否则，Skill 会指导用户操作。请提前说明这两点。

如果验证失败，请用用户能理解的方式总结通过／未通过的检查，说明缺少的能力，并提供尝试其他工作区、授予缺少的权限或切换身份等选项。请参阅 references/azmon-fabric-api-reference.md，了解受支持的范围规则。

验证能力发现（必需）

在声明验证能力不可用之前，Skill 必须确定环境是否提供以下任一方式：

• Fabric REST API
• Azure REST API
• Fabric Actions
• Azure CLI
• Azure Resource Graph

MCP 是否可用只是其中一种执行路径。

只有在评估所有受支持的执行路径且发现均不可用后，Skill 才能报告验证能力不可用。

在声明验证能力不可用之前，Skill 必须：

1. 确定是否存在其他受支持的执行路径。
2. 使用当前环境中可用的所有受支持机制，尝试发现相关能力。
3. 只有在评估所有受支持机制且确认均不可用后，才能声明该能力不可用。

第 5 阶段 — 连接解析

支持两种连接模式。默认优先使用服务主体（模式 A）——这是自动化的非交互式路径。只有在服务主体不可用或用户明确要求时，才回退到 OAuth（模式 B）。两种模式必须分开处理。绝不要通过服务主体逻辑处理 OAuth，也绝不要通过 OAuth／交互式登录逻辑处理服务主体。权威连接器规则以及连接 API 端点和载荷格式的准确文档（List / Get / Create Connection + List Supported Connection Types），请参阅 references/azmon-fabric-api-reference.md。请使用文档中规定的格式——不要猜测连接载荷，也不要搜索通用文档。如果 Azure Monitor 连接器的确切 type / creationMethod / parameters 未知，请通过 supportedConnectionTypes 端点解析，而不要自行假设。

模式选择（必须按顺序执行）

身份已在**阶段 4（身份选择）**中选定并验证。 此处使用该身份——除非用户更改身份，否则不要再次询问。将 所选身份映射到其连接模式：

1. 服务主体 → 模式 A。 如果同一 Log Analytics 工作区已有匹配的服务主体连接器， 则复用它。否则，如果具备所需的服务主体输入（租户 ID、应用/客户端 ID， 以及通过安全方式提供的密钥/证书引用），则自动创建或复用 服务主体连接器——无需 UI 操作。
2. 用户 / 交互式 → 模式 B。 用户选择以自己的身份登录、服务主体不可用， 或租户不允许使用服务主体时，使用此模式。在模式 B 中，先提示用户选择 连接身份验证方法——交互式 OAuth 或工作区身份（见下文“模式 B — 选择连接 身份验证”）——然后进入相应的分支。

连接可见性注意事项（适用于两种模式）

若要让连接可被发现，必须至少为调用身份分配一个角色——无论该身份是 服务主体（模式 A）还是用户（模式 B）。分配任意角色后，连接就会出现在列表中并可供复用； 用户角色足以用于检测和复用，而只有在需要管理 / 修改 / 删除连接时才需要 所有者角色。如果调用方对连接没有任何角色，API 就不会返回该连接—— 这是按设计如此，并非故障。

因此，如果搜索未找到匹配的连接，技能绝不能立即断定该连接不存在。它必须先 考虑连接可能确实存在，只是由于当前身份在该连接上没有任何角色而 不可见，并且：

• 说明当前身份未找到匹配的连接，并指出这可能意味着 (a) 不存在此类连接，或 (b) 连接确实存在， 但调用方服务主体 / 用户在该连接上没有任何角色。
• 建议为服务主体或用户分配同一 Log Analytics 工作区现有 Azure Monitor 连接的一个角色—— 用户角色足以用于检测和复用——然后重新运行检测。（如果服务主体在获授较低权限角色后仍然无法看到该连接， 请参阅 references/azmon-fabric-api-reference.md 中的服务主体说明。）
• 只有在已说明这种权限方面的可能性之后，技能才能继续创建新的连接器（模式 A），或提供 OAuth 仅创建一次的操作指导（模式 B）。

绝不能捏造连接，也不能在列表中没有实际匹配项时声称连接存在。

门户操作指导范围

仅允许针对 OAuth Azure Monitor 连接器创建提供门户操作指导。

门户操作指导不得用作以下操作的备选方案：

• LAW 验证
• Fabric 工作区验证
• 连接检测
• 连接复用
• 服务主体连接器创建
• 镜像目录项创建
• 发现
• 监控
• 刷新
• Eventhouse 快捷方式创建
• 架构验证
• Operations Agent 创建

如果无法执行这些操作，技能必须停止并指出缺少的能力。

模式 A — 服务主体（自动创建或复用，默认）

将其表述为**“使用服务主体连接”——自动化的非交互式路径（无需用户登录，也无需 UI 步骤）。这是优先采用**的默认方式；应在尝试 OAuth 之前先尝试此方式。

• 幂等地创建或复用：如果同一个 Log Analytics 工作区已有匹配的 Azure Monitor 服务主体连接器（数据源路径相同，且凭据类型为服务主体），则复用该连接器，绝不创建重复项。
• 每次运行只创建一个连接器。
• 在此模式下，绝不复用非服务主体连接器（例如 OAuth 连接器）。
• 绝不要求用户在聊天中粘贴客户端密钥。密钥只能来自环境变量或 Key Vault 引用，绝不会回显、记录日志、暴露，也不会包含在生成的说明中。
• 如果缺少必需的服务主体输入项，只通过检查是否存在来说明缺少哪些内容（租户 ID、应用/客户端 ID，以及安全提供的密钥引用）——绝不在聊天中索要密钥值。只有在无法提供服务主体输入项时，才回退到 OAuth（模式 B）。

自动化边界：基础设施操作（创建或复用连接器、创建镜像项）均可自动完成；业务决策（选择 Eventhouse/KQL 数据库、创建快捷方式）始终需要用户明确确认。

模式 B — 选择连接身份验证方式（必须提示）

选择的身份为 User/交互式身份（模式 B）时，可通过两种方式创建连接。在检测或创建任何内容之前，先以**普通聊天文本（纯编号列表，不使用代码块）**呈现以下选项，然后停止并等待用户回答：

我应该如何对 Azure Monitor 连接进行身份验证？

1. 交互式登录（OAuth） — 在 Fabric → Manage Connections 中登录一次；连接将使用你的组织帐户。
2. 工作区身份（无需密钥） — 使用 Fabric 自动管理的工作区身份作为凭据；你需要授予其访问 Log Analytics 工作区的权限。无需处理密钥。

将用户引导至相应的子分支——1 → 模式 B（OAuth），2 → 模式 B（工作区身份）。两者必须严格区分。如果用户没有偏好，说明工作区身份无需交互式登录，也无需处理密钥，但要等待用户选择——绝不自动替用户选择。

模式 B — OAuth（仅限 UI 引导，回退方式）

当用户选择上述选项 1 时使用此子分支，即仅在无法使用服务主体（模式 A）或用户明确要求使用 OAuth 时使用。OAuth 连接器的创建只能通过 UI 引导完成（Fabric → Manage Connections）——此技能绝不会通过 API 创建连接器；它只会以只读方式检测并复用现有连接，且仅当 Log Analytics 工作区完全匹配时才会复用。

遵循 references/oauth-connection-reference.md 中的完整检测顺序、复用规则和面向用户的措辞。此模式必须与模式 A 严格区分。

模式 B — 工作区身份（无机密）

当用户在上方选择了选项 2 时，使用此子分支。连接凭据使用 Fabric 自动管理的工作区身份（无需机密）。此流程会在需要时预配该身份，确保其拥有足够的 Log Analytics 角色——调用方有权限时自动分配，否则指导用户操作——然后创建连接。

请遵循 references/workspace-identity-connection-reference.md 中的完整流程、端点、门控条件和载荷。 关键门控条件：预配身份需要确认（调用方必须是工作区管理员）；当调用方拥有角色分配权限时，由 Skill 分配 LA 角色（否则 Skill 会指导用户操作并等待确认）——这两项写入操作都需要确认；然后使用 WorkspaceIdentity 凭据类型创建连接。此模式必须与模式 A 严格分开。

阶段 6 — 创建或复用 AzMon / Mirrored Catalog 项

在目标 Fabric 工作区中创建 Azure Monitor Mirrored Catalog 项，或复用现有的匹配项。这是会修改 Fabric 的操作 → 先确认。支持的 Mirrored Catalog 操作（项 CRUD、定义、发现、监控、刷新）记录在 references/mirrored-catalog-reference.md 中。

服务主体项创建（重要 — 优先复用；观察到的回退方案）

根据 Microsoft Learn，Create Mirrored Catalog API 列出了服务主体和托管身份，表明它们是受支持的创建身份，因此服务主体创建有文档说明支持，并非平台的绝对限制。

观察到的回退方案。 不过，有些服务主体运行仍遇到项创建在仅应用令牌下被拒绝（底层项创建流程可能会以已登录用户的身份运行）。应将此视为观察到的租户行为，而非文档规定，并保持符合文档的默认做法：尝试以服务主体身份创建，只有在创建调用实际被拒绝或不可用时，才回退到用户（委托）/UI 上下文。

项创建后，获取、列出、更新、发现、监控、刷新和快捷方式操作均可通过仅应用服务主体令牌执行。

因此，以服务主体身份运行时，Skill 必须：

• 优先复用 — 复用服务主体可见且可操作的现有 Azure Monitor Mirrored Catalog 项（及其现有连接）。这是首选路径：基于已创建的项和连接继续操作，而不是创建新项。之后，服务主体可正常更新和操作该项。
• 如果没有可复用的项，尝试以服务主体身份创建项（创建 API 文档说明支持服务主体/托管身份）。只有当创建被拒绝或不可用（如上所述的观察到的回退情况）时，才在用户上下文中创建项——可以通过 Fabric UI，也可以通过用户（委托）登录——最好基于现有项和连接创建。项创建后，服务主体即可恢复自动化流程，在该项上执行更新、发现、监控、刷新和快捷方式操作。
• 如果项实际上是在用户/UI 上下文中创建的，切勿声称它是由服务主体创建的。

项创建后，服务主体仍可执行后续 Mirrored Catalog 操作（更新、发现、监控、刷新）。

通过 scope 选择表（选择该项镜像哪些表）

该项不接受自由填写的表名列表，而是根据 scope 镜像（定义中的命名空间层级路径），且该 scope 必须是通过 List Scopes 发现 API 返回的 Selectable 值。若要指定用户需要的表：

• 调用 List Scopes，为该项选择一个 Selectable scope。如果用户 已知目标表，请选择能够涵盖这些表的最窄 Selectable scope。如果用户 尚未确定意图（想先探索），则使用更宽泛的 scope 创建，并可选择之后 重新设置更窄的 scope——更新该项定义——等意图明确后再操作。只能使用实际 返回的 scope 值，切勿伪造 scope 或表名。
• 如果可用的最窄 Selectable scope 比请求的表集更宽泛，该项也会镜像 该 scope 下额外的同级表——无法排除单独的同级表。请明确说明这一点，并在创建前 获取用户的明确确认。
• 对于现有或复用的项目，在假定其符合请求之前，先读取其当前定义中的 scope；不要伪造定义字段。

默认镜像表集（必需的起点）

除非用户另有指定，默认要镜像的表集是指同时满足以下条件的所有表：(a) 出现在实际的 List Scopes / Discovery 输出中；(b) 名称匹配以下某个前缀（不区分大小写；允许 _CL 自定义表后缀）：

• App* — Application Insights 表
• OTel* — OpenTelemetry 原生表（例如 OTelLogs）
• XD* — 自定义安全相关日志表

然后在创建之前询问用户是否需要其他表（确认关卡——列出解析后的表集并等待用户回复）。

• 仅对实际发现的表匹配前缀，切勿编造表名。 如果某个前缀没有匹配任何表，则直接忽略。
• 将默认表集解析为能够涵盖所有匹配表的最窄单一 Selectable scope。如果该 scope 还会包含超出默认表集的额外同级表，则明确列出这些额外表，说明无法单独排除同级表，并在创建前获取用户确认。确认后，这些额外表即为预期内容——不会在第 8 阶段的相等性检查中被视为失败。
• 添加用户请求的表可能会扩大所选 scope——请重新解析并再次告知用户。
• 如果发现的表中没有任何表匹配 App* / OTel* / XD*，则改为列出所有或有代表性的已发现表（优先探索），让用户选择。
• XD* 安全表只有在工作区通过第 4 阶段的验证（工作区受支持且已验证）后才会纳入考虑；不支持工作区的拦截优先级更高，不得通过选择表来绕过该拦截。
• 复用时：读取现有项目当前的 scope，并将其镜像表集与默认表集进行比较。如果未完全涵盖，则提议重新设置 scope（更新该项定义），以添加缺失的 App* / OTel* / XD* 表，并告知用户任何额外的同级表——绝不能静默地重新设置 scope；必须先确认。

经确认的表集（默认表集 + 已确认的同级表 + 用户添加的任何表）将作为第 8 阶段请求表集与镜像表集相等性检查的预期表集。

首次镜像延迟（披露 — 必须）

对于首次镜像的工作区，请提前告知用户：创建项目后，镜像表和数据通常需要约 5 分钟才能生成并可供查询。在此之前，发现或查询可能返回空结果或部分结果——这是预期情况，并非错误。在此期间不要断定表缺失：请验证镜像/刷新状态，等待后重新检查，再得出结论。

创建或复用项目后，如果用户已有目标，可立即记录业务意图（阶段 7）；否则继续发现和探索表，并在验证架构（阶段 12）之前记录意图。

阶段 7 — 业务洞察收集（此处可选；可延后）

如果用户已有业务问题，请现在记录下来，以便在表发现（阶段 8）和 Eventhouse 评分（阶段 9）中据此引导。如果没有，此阶段目前可选——用户可以先探索数据（阶段 8–11），之后再提供意图。无论哪种情况，在验证架构（阶段 12）和关联分析（阶段 14）之前，都必须提供意图。尽早收集意图只是一种优化，可让发现过程更有针对性。

收集意图时，请使用业务语言提问，例如：

• 服务可用性问题是否影响了预订？
• 请求延迟是否降低了客户转化率？
• 异常是否影响了收入或订单？
• 依赖项故障是否影响了特定客户、租户、区域或航班？
• 事件是否影响了 SLA、使用情况或客户活动？
• 流量下降是否与使用 KPI 恶化相关？

强制要求

若没有以下任一项，Skill 不得继续进行架构验证（阶段 12）或业务关联分析（阶段 14）：

• (a) 用户提供的业务意图，或
• (b) 用户明确选择了建议的方向。

用户可以在此处或探索之后提供意图，但在阶段 12 之前必须提供。切勿假定用户意图。

备用方案（用户不确定、表述模糊或没有完全匹配项时）

建议 3–5 个方向，每个方向都以可观测性信号 → 业务影响的形式呈现，并请用户选择一个：

1. 可用性故障 → 对预订完成率的影响。
2. 请求延迟 → 转化率或结账量下降。
3. 异常 → 订单失败或收入风险。
4. 依赖项故障 → 对客户 / 租户 / 区域的影响。
5. 流量下降 → 使用 KPI 恶化。

重要区别

尽早收集意图可以，但不是必须——在验证架构（阶段 12）之前，必须提供意图。无论哪种情况，Skill 都不得此时生成关联逻辑。只有在快捷方式就绪、架构已验证、数据可供查询、动态字段已检查、联接候选项已验证且数据新鲜度已检查之后，才能生成关联逻辑（阶段 10–14）。

阶段 8 — Azure Monitor 表发现

浏览候选 Azure Monitor / Application Insights 表。**如果已收集业务目标（阶段 7），**则筛选与目标相关的表。**如果尚无意图（先探索），**则展示所有已发现的表或具有代表性的表，供用户浏览。仅使用实际发现的范围/表值——切勿捏造表名。使用 references/telemetry-table-reference.md 以业务术语解释每张表的含义，并说明哪些表最符合既定目标（或在探索时说明每张表能提供什么）。

发现 API 备用策略（必须）

首要的发现机制是 Mirrored Catalog Discovery APIs。如果发现结果看起来不完整，不要立即断定表缺失，也不要切换到其他元数据路径。请先：

1. 验证镜像状态。
2. 验证刷新 / 同步状态。
3. 验证发现范围。
4. 重试发现。

只有完成这些检查后，Skill 才能评估其他元数据路径。请参阅 references/mirrored-catalog-reference.md。

请求集与镜像集相等性检查（请求特定表集后必须执行）

存在请求表集后（无论是一开始指定，还是稍后记录意图时指定），都必须执行此检查。当使用默认镜像集（阶段 6）或用户调整后的集合时，该集合就是本检查的请求集；根据最窄公共范围规则披露并确认的任何同级表都属于预期内容（应与所选范围的预期内容进行比较，而不是只与表清单比较——不要将已确认的同级表报告为失败）。当用户要求使用特定表集时，请验证项目镜像的表集与该表集是否完全一致——使用相等性，而非子集（“我的表都在里面”并不足够）。将实际镜像的表集（来自 Discovery / Monitoring）与请求的表集进行比较，并报告结果：

• 存在额外表 → 所选范围比请求范围更广。报告多出的表；如果存在范围更窄的 Selectable，则提供重新限定范围的选项；否则说明数据源只提供更广的范围，因此无法避免这些额外表。
• 缺少请求的表 → 镜像可能尚未完成。检查镜像/刷新状态，执行 Refresh/sync，等待后重新检查——不要过早断定这些表不存在。
• 完全匹配 → 确认并继续。

绝不要编造镜像表集；只能根据实际 Discovery / Monitoring 结果列出。

阶段 9 — Eventhouse / KQL 数据库目标选择

询问用户要将 LA 表快捷方式放入哪个 Eventhouse。以**普通聊天文本（不要放在代码块中）**展示以下选项，并要求明确确认：

• A — 指定的现有 Eventhouse（例如，已存放要与之关联的业务数据的 Eventhouse）。Skill 会在该 Eventhouse 中创建 LA 表快捷方式，让遥测数据与业务数据共置。
• B — 新建 Eventhouse。 Skill 会创建该 Eventhouse 和 LA 表快捷方式；新建的 Eventhouse 初始为空。

两个选项都可写入，并且都支持 Operations Agent 路径（可用于托管 IncidentBins 物化）。

运行 Eventhouse Recommendation Mode，为选择提供依据——发现可用的 Eventhouse，检查其内容（表、快捷方式、KQL 数据库），并根据相关业务表、相关遥测表、现有快捷方式、可查询的表、KQL 数据库可用性和数据新鲜度进行评分。当用户的目标是将遥测数据与现有业务数据关联时，推荐选项 A（数据共置）；否则，新建 Eventhouse 是一个干净的起点。以普通聊天文本呈现：

• 推荐目标： <A ‹EventhouseName› | B 新建>
• 原因： <原因>
• 备选方案： <列表>

Skill 不得自动选择。给出推荐，准确说明将创建哪些内容，并要求明确确认。请参阅 references/eventhouse-shortcuts-reference.md。

阶段 10 — 外部 Delta 表注册规划

针对已确定的表集，规划在所选/新建的 Eventhouse 中进行的外部 Delta 表注册——在计划标题中注明目标 Eventhouse 的名称——并在任何架构验证或联接逻辑之前完成。展示计划并暂停，等待确认。

关键规则（详情请参阅快捷方式参考文档）：

• 在 KQL 数据库中实现可查询性的方法，是将每个表注册为外部 Delta 表，并指向镜像项目在 OneLake 中的 Tables/dbo/<Table> 路径——而不是使用 Core Shortcuts API（该 API 只会创建链接）。通过 external_table('<name>') 查询。
• 对每个表规划以下信息：准确名称、OneLake Tables/dbo/<Table> 路径、目标 KQL 数据库，以及将从该表的 Delta 日志读取架构。

查询加速策略 — 外部 delta 表（必须 — 始终为 true）

查询加速是外部 delta 表上的策略（通过 .alter external table … policy query_acceleration 设置），而非快捷方式对象的 属性。每个已注册的外部 delta 表都会启用加速（true） — 不是可选项。加入一个 Acceleration Enabled (always Yes) 计划表列；如果环境不支持，应显式暴露该情况，而不是在缺少该策略的情况下注册。完整策略见 references/eventhouse-shortcuts-reference.md。

Stage 11 — 外部 Delta 表注册

仅在明确确认之后，才将每个表注册为目标 KQL 数据库中的外部 Delta 表（并报告是哪一项）：从表的 Delta 日志中读取其 schema，将 Delta 类型映射为 Eventhouse 类型，并通过 POST {clusterUri}/v1/rest/mgmt 运行 .create external table ['<Table>'] (<cols>) kind=delta ( h@'<OneLake Tables/dbo/<Table> path>;impersonate' )。然后用 .show external tables + external_table('<Table>') | take 1 进行验证。Core Shortcuts API 并非查询所必需 （它仅创建一个链接）。如果某个表不可查询 → 停止并返回规划 / 注册阶段。schema 读取、类型映射和命令模板见 references/eventhouse-shortcuts-reference.md。

注册任何外部 delta 表时，始终启用查询加速 策略（true），遵循 查询加速策略， 并报告结果状态（预期：已启用）。

Stage 12 — Schema 与数据验证（关联分析前必需）

切勿基于假设或截图构建关联逻辑。在提出任何 join、bin 或阈值之前，针对实际 KQL 数据库进行验证。业务 意图必须已在此阶段之前捕获/确认 — 如果在 Stage 7 被推迟，现在应在 继续之前捕获它（使用 Stage 7 的问题/回退方案），因为下面的遥测源选择会按目标 相关性评分。切勿假设意图。

前置条件

1. 运营遥测表在 Eventhouse / KQL 数据库中可用。
2. 业务表在同一数据库中可用，或可通过快捷方式查询。
3. 表是可查询的，而不仅仅是在 OneLake 中可见。
4. 通过 getschema 获取 schema。
5. 已检查和采样动态字段。
6. 从顶层和动态列中提取候选 join 键。
7. join 键已通过非零匹配结果验证（当提出直接 join 时）。
8. 已验证数据新鲜度。
9. 时间窗口已对齐到真实数据范围。
10. 在规则依赖相关分类值的情况下，已从真实数据中确认这些值。

步骤

查询约定。 镜像遥测表是外部表——通过 external_table('<name>') 查询（它们不会出现在 .show tables 中）；在 Eventhouse 中托管的业务表则使用其裸名称。

1. 获取真实架构。 对每张表运行： external_table('<TableName>') | getschema | project ColumnName, ColumnType。 使用权威的列名和类型，而不是根据截图或表名猜测。

2. 检查并采样动态字段。 业务联接键通常嵌套在动态列中（Properties、CustomDimensions、Details、Measurements、Payload、Context）。采样行并检查键。参见 references/app-insights-dynamic-fields-reference.md。

3. 提取候选业务标识符，使用显式 KQL （tostring(Properties.BookingId)，并通过 coalesce 处理大小写回退）。

4. 根据真实数据验证联接键。 证明候选键可以联接——运行联接并确认匹配数非零：

   external_table('AppEvents')
   | extend BookingId = tostring(Properties.BookingId)
   | where isnotempty(BookingId)
   | join kind=inner (Bookings | project BookingId = tostring(BookingId)) on BookingId
   | summarize MatchedRows=count(), DistinctBookings=dcount(BookingId)
   

   非零 → 直接联接，置信度高。零 → 键错误或数据没有重叠；找到真正的键。

5. 检查数据新鲜度并对齐时间窗口。 external_table('<TableName>') | summarize Rows=count(), MinTime=min(TimeGenerated), MaxTime=max(TimeGenerated)。 不要假设使用 ago(1h)；应使用覆盖实际数据范围的时间窗口，并用用户易懂的语言说明。

6. 确认规则使用的分类值 （external_table('<Table>') | summarize count() by <field>），确保影响规则使用真实类别。

遥测源选择框架（必需）

遥测源选择必须由数据驱动。在选择关联模型之前，Skill 必须检查发现的所有候选遥测源（例如 AppEvents、AppExceptions、AppRequests、AppDependencies、AppTraces、AppPageViews、AppBrowserTimings、AvailabilityResults，以及存在的任何其他遥测源），而不能只检查一个。

根据以下各项为每个候选遥测源评分：

1. 发现的业务标识符。
2. 动态字段丰富度。
3. 直接联接置信度。
4. 已验证的匹配数。
5. 业务流程上下文。
6. 与所选业务目标的相关性。

选择得分最高的遥测源。Skill 不得自动优先选择 AppExceptions，也不得自动优先选择 AppEvents——应根据真实数据评分，由得分最高的遥测源胜出。

退出条件（强制）

在进入第 14 阶段之前，必须满足所有条件：已通过 getschema 获取架构；在使用直接联接时，联接键已验证且匹配数非零；已核实数据新鲜度并对齐时间窗口；已确认相关分类值。若有任何一项未满足 → 停止，不得继续。

交接（强制）

提供简明摘要（已验证的联接键、匹配结果、业务影响〔如有〕、数据时间窗口）。然后询问：“是否要继续进行业务分析（影响建模、仪表板，以及可选的 Operations Agent），并基于此已验证模型开展？”必须停止并等待。 获得确认后，按照 references/business-analysis-workflow.md 中的定义继续执行第 13–17 阶段。

第 13–17 阶段——面向业务的分析（详见参考文档）

面向业务的分析部分（业务数据发现与评分、关联规划、可选的 Real-Time KQL 仪表板，以及可选且需通过门控的 Operations Agent）由 references/business-analysis-workflow.md （含附录 A–B）权威定义，并且仅在用户于第 12 阶段交接时选择继续后才加载。用户选择继续后，不得依赖记忆——打开该文件并严格遵循第 13–17 阶段；控制器仍会跟踪并强制执行这些阶段及其顺序、硬性停止条件和确认门控（包括先创建仪表板再创建 Agent，以及第 16 阶段“我们是否真的需要 Agent？”门控）。

故障排除（面向用户）

• “未生成操作手册”／无法计算某个字段 → 指令只是从概念上描述了这些字段。添加明确的 KQL 实体化查询，为每个字段添加 KQL 定义，确保警报规则引用实际输出列，添加动态字段提取，并明确联接键／标识符。不要只改写文字。
• 启动成功，但没有收到 Teams 警报 → 可能没有数据符合规则。切换到 POC／调试阈值；说明可能没有数据符合条件。没有证据时，不要暗示平台故障。

必须／优先／避免

必须

• 强制执行各个阶段、硬性停止条件和确认关卡。
• 严格区分 OAuth（通过 UI 引导）和服务主体（自动创建或复用）。
• 创建前验证权限。
• 进行关联分析前，验证架构、动态字段、联接匹配情况和数据新鲜度。
• 在 Operations Agent 指令中提供明确的 KQL。

优先

• 连接解析时，优先使用服务主体（自动化方式），而非 OAuth（通过 UI 引导）；只有在服务主体不可用时才回退到 OAuth。
• 优先使用直接联接，而非时间窗口关联。
• 使用实际发现的值，不使用猜测值。
• 优先通过业务语言进行确认，而非提出技术问题。

避免

• 不要在面向用户的流程中依赖或提及 MCP。
• 不要将内部／未公开的 API 描述为受支持的 API。
• 不要声称可通过公共 API 创建 OAuth 连接器。
• 不要捏造工作区、表、架构、ID 或查询结果。
• 不要索要机密、OAuth 代码、令牌、Cookie 或 nonce。
• 只有时间窗口关联时，不要声称存在因果关系。

示例

示例 1 — 引入 Azure Monitor 可观测性数据，然后检查业务影响

用户：“在我的 Observability 工作区中，将我们的 Azure Monitor / Log Analytics 可观测性数据（其中包含 Application Insights 表）引入 Fabric，然后告诉我上周的延迟峰值是否损害了结账转化率。”

**技能行为：**运行分阶段工作流——确认目标工作区并检查引入数据的前提条件（可访问的 Azure Monitor / Log Analytics 源或连接）；如果缺少任何前提条件，则明确列出缺失项并停止。可观测性数据（包括 Application Insights 遥测表）引入并可查询后，在工作区中发现实际业务数据集，使用发现的键将延迟信号与转化 KPI 关联，并给出具体的业务影响结论（如果所需数据不可用，则报告错误）。绝不捏造工作区名称、表或查询结果，也绝不泄露令牌或连接内部信息。

示例 2 — 超出范围的创作请求

用户：“创建一个新的 Spark 笔记本，并构建 Delta 表管道来加载我的业务数据集。”

**技能行为：**拒绝超出范围的创作请求，不在 Fabric 中创建任何内容，并引导用户转到 spark-cli 中适当的创作模式，而不是接手该任务。