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-copilotFlowStudio 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设置criticaltrue。这会启用治理技能的告警规则管理自动为关键流配置失败通知。工具全景本技能使用的工具全部是store_*缓存读取工具工具用途list_store_flows列出带失败率与监控过滤条件的流get_store_flow完整缓存记录运行统计、所有者、层级、连接、定义含triggerUrl字段get_store_flow_summary聚合运行统计成功/失败率、平均/最大耗时get_store_flow_runs逐次运行历史耗时、状态、失败动作、修复提示过滤statusFailed可只看错误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加载工具 schemaskills/flowstudio-power-automate-mcp/references/MCP-BOOTSTRAP.md 记录了完整的发现流程冷启动调用list_skills查看可用的 bundlebuild-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过滤statusFailed—谁构建了这个流get_store_flow→ 解析owners—读取完整流定义get_store_flow已包含JSON 字符串get_live_flow结构化检查某次运行的 action 输入/输出—get_live_flow_run_action_outputs重新提交失败的运行—resubmit_live_flow_runStore 工具回答发生了什么和它有多健康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_errorget_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是可选字段。部分条目很稀疏只有idmonitor——跳过没有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_onfailISO、description、tags新鲜度scannedISO、nextScanISO生命周期deleted布尔、deletedTimeISOJSON 字符串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和endTimeISO 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.mdget_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: usercontoso.com, createdBy: {\id\:\...\,\displayName\:\...\,\email\:\...\}, environmentName: ..., statuses: [{\status\:\Connected\}] } ]createdBy和statuses是JSON 字符串需用json.loads()解析。list_store_makers直接返回数组[ { id: 09dbe02f-..., displayName: Sample Maker, mail: makercontoso.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、licensesM365 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 设置 monitortrue 2. 可选设置 rule_notify_onfailtrue、rule_notify_emailuserdomain.com 3. 下次每日扫描后运行数据才会出现每日健康检查1. list_store_flows 2. 标记 runPeriodFailRate 0.2 且 runPeriodTotal 3 的流 3. 标记 stateStopped 的受监控流可能表示自动挂起 4. 对关键失败 → get_store_flow_runs(status[Failed]) 获取修复提示制作者审计1. list_store_makers 2. 识别仍拥有流的已删除账户deletedtrue, ownerFlowCount 0 3. 对特定用户调用 get_store_maker 获取完整详情资产清点Inventory1. 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: BearerJWT 保持原样不做任何处理或加前缀。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 工作流就明确建议尽量限定到monitortrue的流因为每次get_store_flow调用都耗时。相关技能协作技能定位skills/flowstudio-power-automate-mcp/SKILL.md基础技能连接配置、MCP Helper、工具发现本技能的所有工具调用都建立其上skills/flowstudio-power-automate-debug/SKILL.md深度诊断基于实时 API 的动作级输入/输出找到为什么失败skills/flowstudio-power-automate-build/SKILL.md构建与部署流定义skills/flowstudio-power-automate-governance/SKILL.md治理元数据、打标签、通知规则、CoE 模式与监控共享store_*工具家族选技能的正确姿势不要记忆哪个技能拥有哪些工具而是看用户正在做什么——要租户级健康度与失败率看板就加载本监控技能只读要写入治理元数据、做合规审计就加载治理技能要定位单条失败运行的根本原因就用调试技能。三者可以无缝衔接监控发现可疑流 → 治理打标签分类 → 调试定位根因并修复。【免费下载链接】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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
