把自动化做“看得见”：小企业也能用的可观测性

自动化出问题时，最贵的成本往往不是“修复”，而是你根本不知道它什么时候开始出问题。

我见过太多小团队的自动化工作流是这样运转的：一套 Power Automate 流程负责客户线索分配、报价审批、开票提醒；一台无人值守的桌面机器人（RPA）每天去老系统里导出报表；再加一个 AI 语音助手帮老板在路上口述创建任务、查询订单状态。平时很顺，直到某天财务说“怎么这周的发票提醒没发？”或客服说“线索分配又卡住了”。这时候大家才开始翻聊天记录、翻邮箱、翻运行历史。

微软在 2025 年公布的 Power Automate 可观测性增强（Automation Center 与 Power Platform Admin Center/PPAC 的监控能力升级）指向一个很现实的方向：自动化要像业务系统一样可观测，而且要能跨环境、近实时、还能给出“下一步怎么修”。这套思路不只适用于大型企业，小企业更该借鉴——因为你的人更少、容错更低。

（本文基于微软 Power Automate 官方更新整理与扩展： https://www.microsoft.com/en-us/power-platform/blog/power-automate/enhanced-enterprise-automation-observability/ ）

可观测性不是“看报表”，而是能快速止损

可观测性的核心不是“有数据”，而是用数据回答三个问题：现在是否健康？哪里出问题？下一步怎么处理？

很多团队把监控理解成“每天看一眼成功率”。但自动化工作流的真实复杂度在于：一个云流程触发桌面流程；桌面流程排队等机器；机器上又可能因为用户会话锁定导致无法启动；最后一个 UI 选择器变动就会让机器人卡死。你只看一个成功率指标，根本抓不到链路上的断点。

微软这次更新抓住了关键：

• 在 PPAC Monitoring Hub 里支持跨环境监控 Power Automate 资源健康
• 在 Automation Center 里用**分层运行历史（hierarchical run history）**把依赖关系摊开
• 桌面流程 Logs V2 支持近实时日志与更大的 action log 容量
• 在 Managed Environment 下提供更“可操作”的推荐（recommendations），甚至能联动 Copilot 做修复建议

对小企业来说，这些能力的价值很直接：更快发现故障、更快定位故障、更少靠“某个懂的人”。

从大企业学到的第一课：跨环境监控才能管住“碎片化自动化”

一个常见误区是：小企业环境少，不需要跨环境监控。现实往往相反。

随着业务增长，你的自动化会自然分裂：

• 生产环境跑核心流程（线索、合同、账单）
• 测试/沙箱环境做新流程试验
• 部门自建环境跑临时流程（运营活动、仓库盘点、客服回访）

问题也跟着分裂：你可能在生产上看到失败，但根因出现在某个共享连接器的策略变更、某台机器队列拥堵、或某个部门流程“误触发”导致配额被打满。

微软在 PPAC Monitoring Hub 给到的方向是：用统一的监控视图，把云流程与桌面流程放在同一张健康地图里，并且能看到跨环境的成功率、桌面流程机器排队等待时间（machine wait time in queue）等信号。

小企业怎么用？给你一个实操的“监控最小集”

我建议别一上来追求全量指标，先建立 5 个最小监控点：

1. 关键流程成功率（按天/按小时）
2. 失败 Top 3 的错误类型（连接失败、权限、超时、UI selector 等）
3. 桌面流程排队等待时间（机器不够 or 被锁会话）
4. 运行量突增（异常触发、循环触发、活动期激增）
5. “无人认领”的失败（失败后没有进入工单/Teams 通知）

这 5 个点能覆盖 80% 的运营事故。尤其是第 5 点：很多自动化不是“修不好”，是“没人知道”。

第二课：分层运行历史把“连锁失败”摊开给你看

自动化故障最让人抓狂的一点是：你看到的失败经常是“最后一环”。

比如一个典型链路：

• 云流程：收到表单 → 写入 CRM → 创建 Teams 通知 → 触发桌面流程去 ERP 建单
• 桌面流程：登录 ERP → 填单 → 导出单号 → 回写 CRM

当 ERP 登录页改版、selector 失效时，最终你看到的是“回写 CRM 失败”或“未获取单号”。没有分层视图，你需要在多个 run history 里跳来跳去，靠经验拼图。

Automation Center 的 hierarchical flow runs view 的价值是：它把依赖的 runs 以层级方式展示，你能一眼看到：

• 哪个父流程触发了哪些子流程
• 失败是否集中在某一段依赖链
• 同一故障是否导致一批 run 连锁失败

把它和 AI 语音助手结合，会发生什么？

这就接上了我们这个系列（人工智能在机器人产业）一直在讲的“人机协作”：机器人做执行，人做决策，AI 做编排。

想象一个更实用的场景：老板在车上对 AI 语音助手说：

“帮我看看今天的开票自动化有没有异常，异常就给财务负责人发消息，并创建一个修复任务。”

如果你的自动化平台提供可观测性数据（成功率、失败原因、队列等待、推荐措施），语音助手就不只是“查状态”，而是能把信息变成行动：

• 汇总异常 runs（按影响客户数/金额排序）
• 自动生成简短事故说明（发生时间、影响范围、错误类型）
• 在 Teams/企业微信里通知责任人
• 在你的项目管理工具里创建修复任务并附上 run 链路截图/日志

这里的关键不是语音，而是可观测性让语音助手有“可信上下文”。

第三课：近实时桌面流程日志，决定了你能不能“在线救火”

桌面流程（RPA）的问题往往比云流程更“脆”：UI 改动、窗口弹框、网络抖动、会话锁定都可能让它卡住。

微软这次把 Desktop flow logs V2 的两个点推到了更可用的层级：

• 近实时 action log 更新（对长时间运行的云触发桌面流程尤其重要）
• 更大的 action log 容量（意味着你能保留更多细节，而不是被截断）

这对小企业的意义非常直接：你不需要等流程跑完才知道它中途卡在哪里。长流程（比如批量对账、批量开票、批量同步库存）最怕“跑了两小时最后失败”。近实时日志至少让你能：

• 尽早识别卡住的步骤
• 判断是环境问题（网络/权限）还是 UI 变化
• 及时切换到人工兜底（把“全失败”变成“部分完成”）

一句话：实时性越强，止损越早。

第四课：推荐（Recommendations）才是“可观测性落地”的最后一公里

很多监控产品的问题是：告诉你红了，但不告诉你怎么绿回来。

微软在 Managed Environment 的推荐机制，以及桌面流程的高级推荐，代表了一个更务实的趋势：把故障从“诊断”推进到“处置”。文章里提到两个很典型的桌面流程推荐方向：

1）会话/编排类问题：排队但启动不了

当无人值守桌面流程排队却无法启动，原因可能是同一用户在机器上的会话锁定或断开。新的“Desktop flows not running”推荐会在 Automation Center 里列出受影响的 runs，并给你一个10 分钟的纠正窗口去处理。

对小企业来说，这类问题非常常见，因为你往往只有 1-2 台机器跑 RPA，用户会话更容易被“人”占用。

2）UI 选择器类问题：Repair with Copilot

无人值守桌面流程最常见的失败原因之一就是 selector 找不到。Repair with Copilot 的思路是：当流程因为 UI/浏览器自动化动作存在失败风险时，给出 selector 修复建议，并在 Automation Center 里以推荐/修复请求的方式出现。

我对这类能力的评价很明确：它不会消灭 RPA 的脆弱性，但能显著降低修复门槛。对没有专职 RPA 工程师的小企业来说，这一点很关键。

把“可观测性”落到你的 AI 语音助手与自动化工作流里：一个三步方案

你不需要把自己变成大企业，才能用上大企业的方法。更现实的做法是把可观测性当成自动化项目的一部分交付。

第一步：先定义“业务级 SLO”，不要只盯技术成功率

技术成功率 99% 可能仍然很糟糕：如果 1% 刚好是 VIP 客户的订单同步。

给每条关键自动化设一个业务 SLO（服务目标）：

• 线索分配：10 分钟内必须入库并通知负责人
• 开票提醒：工作日 17:00 前必须发送，漏发要自动升级
• ERP 建单：失败不得超过连续 3 次，否则切换人工

第二步：把监控信号接到“语音助手的任务系统”

自动化监控与 AI 语音助手的任务管理是互补的：监控负责发现异常，语音助手负责把异常转成任务与沟通。

你可以设计一套简单的事件到动作映射：

• 指标退化（成功率下降、等待时间上升）→ 自动创建“检查任务”
• 特定错误（权限/连接器/selector）→ 指派给对应角色（IT/业务/运营）
• 连续失败阈值触发 → 通知 + 启动人工兜底 SOP

第三步：每月做一次“自动化事故复盘”，像运营机器人一样运营流程

这也是本系列和机器人产业最相通的一点：机器人系统需要持续运维。别把自动化当一次性项目。

每月 30 分钟就够，复盘三件事：

1. 哪三条自动化最不稳定？根因是什么？
2. 哪些失败是可以通过推荐/规则提前预防的？
3. 有没有流程应该从 RPA 改为 API/连接器，减少 UI 依赖？

你会发现，自动化的“稳定性”不是靠更努力，而是靠更可见。

你真正需要的不是更多自动化，而是更可控的自动化

当 AI 语音助手开始进入一线工作流（创建任务、查询状态、推动协作），自动化的数量只会继续增长。没有可观测性，你会越来越依赖“某个懂流程的人”；有了可观测性，你才能把自动化变成一种可运营的能力。

如果你正在把 AI 语音助手接入 Power Automate、桌面机器人或其他自动化工作流，我的建议很简单：**先把监控和推荐做好，再扩规模。**这会让你的团队少救火、多产出。

接下来你可以做一件小事：选出你最关键的 3 条自动化，给它们加上业务 SLO、失败通知与责任人，并在 Automation Center/PPAC 里建立固定的健康检查视图。做完这一步，再问自己一个更有价值的问题：

你希望你的语音助手只是“帮你查”，还是能在自动化出错时主动帮你把事情推进？