Power Automate 租户级监控实战：基于 FlowStudio MCP 缓存存储与 awesome-copilot 技能-二趣网

Power Automate 租户级监控实战：基于 FlowStudio MCP 缓存存储与 awesome-copilot 技能

【免费下载链接】awesome-copilotCommunity-contributed instructions, agents, skills, and configurations to help you make the most of GitHub Copilot.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-copilot

FlowStudio MCP 的store_*缓存存储将 Power Automate API 每日扫描结果落地为可快速读取的租户视图，让 Agent 绕过 PA API 速率限制直接完成失败率统计、运行健康趋势、制作者清单与合规报告的聚合分析。本文以 skills/flowstudio-power-automate-monitoring/SKILL.md 为骨架，结合仓库中 FlowStudio 技能家族的源码级细节，完整讲解缓存监控的工作原理、全部store_*工具、响应结构、Store 与 Live 的分工边界，以及可直接照搬的监控工作流。

前置条件（Pro+）：本技能调用的store_*工具仅对FlowStudio for Teams 或 MCP Pro+ 订阅者开放。若用户没有 Pro+ 权限，第一次调用store_*工具会返回 403/404。遇到该情况时：立即停止调用 store 工具 → 告知用户该功能需要 Pro+ 订阅 → 引导查看定价页 → 若用户的问题可以用实时工具回答（如"列出单个环境中的流"），则改用 skills/flowstudio-power-automate-mcp/SKILL.md 技能。

监控是如何工作的

FlowStudio 每天为每个订阅者扫描一次 Power Automate API 并将结果缓存。监控分为两个层级：

所有流都会获得元数据级扫描：流定义、连接、所有者、触发器类型，以及聚合运行统计（runPeriodTotal、runPeriodFailRate等）。环境、应用、连接和制作者（maker）同样会被扫描。
被监控的流（monitor: true）会额外获得逐次运行详情：单条运行记录的status、duration、失败动作名称和修复提示（remediation hints）。这正是get_store_flow_runs和get_store_flow_summary的数据来源。

数据新鲜度：通过get_store_flow返回的scanned字段判断流上次被扫描的时间。如果该字段过旧，说明扫描管道可能未在运行。

启用监控：通过update_store_flow设置monitor: true，或在 FlowStudio for Teams 应用中配置。

标记关键流：对业务关键流使用update_store_flow设置critical=true。这会启用治理技能的告警规则管理，自动为关键流配置失败通知。

工具全景

本技能使用的工具全部是store_*缓存读取工具：

工具	用途
`list_store_flows`	列出带失败率与监控过滤条件的流
`get_store_flow`	完整缓存记录：运行统计、所有者、层级、连接、定义（含`triggerUrl`字段）
`get_store_flow_summary`	聚合运行统计：成功/失败率、平均/最大耗时
`get_store_flow_runs`	逐次运行历史：耗时、状态、失败动作、修复提示（过滤`status="Failed"`可只看错误）
`update_store_flow`	设置监控标记、通知规则、标签、治理元数据
`list_store_environments`	所有 Power Platform 环境
`list_store_connections`	所有连接
`list_store_makers`	所有制作者（公民开发者）
`get_store_maker`	制作者详情：流/应用数量、许可证、账户状态
`list_store_power_apps`	所有 Power Apps 画布应用

启停流请使用monitor-flow工具包中的set_live_flow_state（通过tool_search query: "select:set_live_flow_state"加载），缓存会在下次扫描时自动同步。旧的set_store_flow_state便捷封装已废弃。

工具发现方式

本技能与仓库中其他 FlowStudio 技能一样，推荐通过元工具tool_search而非tools/list加载工具 schema（skills/flowstudio-power-automate-mcp/references/MCP-BOOTSTRAP.md 记录了完整的发现流程）：

冷启动：调用list_skills查看可用的 bundle（build-flow、create-flow、debug-flow、monitor-flow、discover、governance）；
加载监控常见工具：tool_search传入query: "select:list_store_flows,get_store_flow_summary"；
加载完整治理工具集：query: "skill:governance"—— 服务器的 governance bundle 覆盖了大部分监控读取，本技能与 skills/flowstudio-power-automate-governance/SKILL.md 共享同一底层工具家族。

本技能补足的是tool_search无法给出的内容：响应形状、行为注意点和工作流模式。如果本文档与实际 API 响应冲突，以 API 为准。

Store 与 Live：何时用缓存，何时用实时

问题	用 Store	用 Live
有多少流在失败？	`list_store_flows`	—
30 天内的失败率是多少？	`get_store_flow_summary`	—
展示某个流的错误历史	`get_store_flow_runs`（过滤`status="Failed"`）	—
谁构建了这个流？	`get_store_flow`→ 解析`owners`	—
读取完整流定义	`get_store_flow`已包含（JSON 字符串）	`get_live_flow`（结构化）
检查某次运行的 action 输入/输出	—	`get_live_flow_run_action_outputs`
重新提交失败的运行	—	`resubmit_live_flow_run`

Store 工具回答"发生了什么？"和"它有多健康？"，Live 工具回答"到底哪里出错了？"和"现在就修复它。"

如果get_store_flow_runs或get_store_flow_summary返回空结果，请检查：(1) 该流是否设置了monitor: true？(2)scanned字段是否足够新？用get_store_flow同时核验这两点。

从仓库技能家族的分工（skills/flowstudio-power-automate-mcp/SKILL.md 中的"Which Skill to Use When"表格）可以确认：监控与治理共享 Store 工具家族，差异在于视角——监控面向运维（读健康度），治理面向合规（写元数据）。而深度根因排查应切换到 skills/flowstudio-power-automate-debug/SKILL.md，那里使用get_live_flow_run_error+get_live_flow_run_action_outputs的组合定位真实错误。

响应结构详解

`list_store_flows`

直接返回数组。过滤器：monitor（布尔）、rule_notify_onfail（布尔）、rule_notify_onmissingdays（布尔）。

[ { "id": "Default-<envGuid>.<flowGuid>", "displayName": "Stripe subscription updated", "state": "Started", "triggerType": "Request", "triggerUrl": "https://...", "tags": ["#operations", "#sensitive"], "environmentName": "Default-aaaaaaaa-...", "monitor": true, "runPeriodFailRate": 0.012, "runPeriodTotal": 82, "createdTime": "2025-06-24T01:20:53Z", "lastModifiedTime": "2025-06-24T03:51:03Z" } ]

id格式为Default-<envGuid>.<flowGuid>，按第一个.切分即可得到environmentName和flowName。
triggerUrl和tags是可选字段。部分条目很稀疏（只有id+monitor）——跳过没有displayName的条目。
list_store_flows上的tags是从流的description字段自动提取的（制作者写的#operations这类 hashtag）。通过update_store_flow(tags=...)写入的标签是分开存储的，只会在get_store_flow上可见，不会出现在列表响应中。

`get_store_flow`

完整缓存记录，关键字段按类别划分：

类别	字段
身份	`name`、`displayName`、`environmentName`、`state`、`triggerType`、`triggerKind`、`tier`、`sharingType`
运行统计	`runPeriodTotal`、`runPeriodFails`、`runPeriodSuccess`、`runPeriodFailRate`、`runPeriodSuccessRate`、`runPeriodDurationAverage`/`Max`/`Min`（毫秒）、`runTotal`、`runFails`、`runFirst`、`runLast`、`runToday`
治理	`monitor`（布尔）、`rule_notify_onfail`（布尔）、`rule_notify_onmissingdays`（数字）、`rule_notify_email`（字符串）、`log_notify_onfail`（ISO）、`description`、`tags`
新鲜度	`scanned`（ISO）、`nextScan`（ISO）
生命周期	`deleted`（布尔）、`deletedTime`（ISO）
JSON 字符串	`actions`、`connections`、`owners`、`complexity`、`definition`、`createdBy`、`security`、`triggers`、`referencedResources`、`runError`—— 全部需要`json.loads()`解析

时长字段（runPeriodDurationAverage、Max、Min）单位是毫秒，换算秒要除以 1000。
runError以 JSON 字符串形式保存最近一次运行错误，用json.loads(record["runError"])解析，无错误时返回{}。

`get_store_flow_summary`

按时间窗口（默认最近 7 天）聚合统计：

{ "flowKey": "Default-<envGuid>.<flowGuid>", "windowStart": null, "windowEnd": null, "totalRuns": 82, "successRuns": 81, "failRuns": 1, "successRate": 0.988, "failRate": 0.012, "averageDurationSeconds": 2.877, "maxDurationSeconds": 9.433, "firstFailRunRemediation": null, "firstFailRunUrl": null }

当窗口内无运行数据时返回全零。
使用startTime和endTime（ISO 8601）参数改变统计窗口。

`get_store_flow_runs`

直接返回缓存运行记录数组。参数：startTime、endTime、status（数组——传["Failed"]只看错误，["Succeeded"]只看成功，省略则返回全部）。窗口内无数据时返回[]。

Trigger URL

直接从get_store_flow（缓存）或get_live_flow（实时）读取triggerUrl字段。非 HTTP 触发器时为null。

启停流

使用monitor-flow服务端 bundle 中的set_live_flow_state。缓存会在下次每日扫描时追上；如果需要在下次扫描前获得更新的缓存，可以在状态变更后调用get_live_flow确认，并等待下一次扫描同步。

`update_store_flow`

更新治理元数据。只有传入的字段会被更新（合并语义），返回完整更新后的记录（与get_store_flow形状相同）。

可设置字段：monitor（布尔）、rule_notify_onfail（布尔）、rule_notify_onmissingdays（数字，0=禁用）、rule_notify_email（逗号分隔）、description、tags、businessImpact、businessJustification、businessValue、ownerTeam、ownerBusinessUnit、supportGroup、supportEmail、critical（布尔）、tier、security。

注意security字段的陷阱：治理技能中明确警告（skills/flowstudio-power-automate-governance/SKILL.md），get_store_flow的security字段包含结构化 JSON（如{"triggerRequestAuthenticationType":"All"}）。向其中写入纯字符串（如"reviewed"）会覆盖原有结构。要标记流已通过安全审查，应使用tags而非security。

`list_store_environments`

直接返回数组：

[ { "id": "Default-aaaaaaaa-...", "displayName": "Flow Studio (default)", "sku": "Default", "type": "NotSpecified", "location": "australia", "isDefault": true, "isAdmin": true, "isManagedEnvironment": false, "createdTime": "2017-01-18T01:06:46Z" } ]

sku取值：Default、Production、Developer、Sandbox、Teams。

`list_store_connections`

直接返回数组，可能非常大（1500+ 条）：

[ { "id": "<environmentId>.<connectionId>", "displayName": "user@contoso.com", "createdBy": "{\"id\":\"...\",\"displayName\":\"...\",\"email\":\"...\"}", "environmentName": "...", "statuses": "[{\"status\":\"Connected\"}]" } ]

createdBy和statuses是JSON 字符串，需用json.loads()解析。

`list_store_makers`

直接返回数组：

[ { "id": "09dbe02f-...", "displayName": "Sample Maker", "mail": "maker@contoso.com", "deleted": false, "ownerFlowCount": 199, "ownerAppCount": 209, "userIsServicePrinciple": false } ]

已删除的制作者会返回deleted: true，且没有displayName/mail字段。

`get_store_maker`

完整制作者记录。关键字段：displayName、mail、userPrincipalName、ownerFlowCount、ownerAppCount、accountEnabled、deleted、country、firstFlow、firstFlowCreatedTime、lastFlowCreatedTime、firstPowerApp、lastPowerAppCreatedTime、licenses（M365 SKU 的 JSON 字符串）。

`list_store_power_apps`

直接返回数组：

[ { "id": "<environmentId>.<appId>", "displayName": "My App", "environmentName": "...", "ownerId": "09dbe02f-...", "ownerName": "Catherine Han", "appType": "Canvas", "sharedUsersCount": 0, "createdTime": "2023-08-18T01:06:22Z", "lastModifiedTime": "2023-08-18T01:06:22Z", "lastPublishTime": "2023-08-18T01:06:22Z" } ]

常见监控工作流

发现不健康的流

1. list_store_flows 2. 过滤 runPeriodFailRate > 0.1 且 runPeriodTotal >= 5 的流 3. 按 runPeriodFailRate 降序排序 4. 对每个候选流调用 get_store_flow 获取完整详情

检查某个特定流的健康状况

1. get_store_flow → 检查 scanned（新鲜度）、runPeriodFailRate、runPeriodTotal 2. get_store_flow_summary → 聚合统计（可指定时间窗口） 3. get_store_flow_runs(status=["Failed"]) → 逐次失败详情及修复提示 4. 如需更深入诊断 → 切换到实时工具： get_live_flow_runs → get_live_flow_run_action_outputs

在流上启用监控

1. update_store_flow 设置 monitor=true 2. 可选：设置 rule_notify_onfail=true、rule_notify_email="user@domain.com" 3. 下次每日扫描后运行数据才会出现

每日健康检查

1. list_store_flows 2. 标记 runPeriodFailRate > 0.2 且 runPeriodTotal >= 3 的流 3. 标记 state="Stopped" 的受监控流（可能表示自动挂起） 4. 对关键失败 → get_store_flow_runs(status=["Failed"]) 获取修复提示

制作者审计

1. list_store_makers 2. 识别仍拥有流的已删除账户（deleted=true, ownerFlowCount > 0） 3. 对特定用户调用 get_store_maker 获取完整详情

资产清点（Inventory）

1. list_store_environments → 环境数量、SKU、位置 2. list_store_flows → 按状态、触发器类型、失败率统计流数量 3. list_store_power_apps → 应用数量、所有者、共享情况 4. list_store_connections → 每个环境的连接数量

底层调用细节：MCP Helper 与解析技巧

监控技能本身专注"工作流叙事"，而调用管道由基础技能 skills/flowstudio-power-automate-mcp/SKILL.md 提供。编写脚本时需注意：

认证头是x-api-key: <JWT>，不是Authorization: Bearer；JWT 保持原样，不做任何处理或加前缀。
MCP 协议为 JSON-RPC 2.0 over HTTP POST，所有工具结果都是result.content[0].text中的 JSON 字符串，需要二次解析。
list_store_flows、list_store_environments、list_store_makers、get_store_maker、list_store_power_apps、list_store_connections这些缓存读取工具不需要environmentName参数（多数实时工具则需要），这使租户级聚合调用更加轻量（见 skills/flowstudio-power-automate-mcp/references/MCP-BOOTSTRAP.md）。
聚合读取通常只需一次list_store_flows就能拿到runPeriodFailRate等核心指标；只有需要owners、connections等 JSON 字符串字段时才逐流调用get_store_flow——大型租户下这会消耗较多时间，应限定在受监控流范围内（治理技能中的 Connector Audit 工作流就明确建议：尽量限定到monitor=true的流，因为每次get_store_flow调用都耗时）。

企业官网建设流程全解析