用 Power Automate 实现业务自动化 ── 云端流程与桌面流程的分工，以及错误处理设计

「把共享文件夹里积累的 CSV，每天早上整理成 Excel 发给上级」「从多个业务系统手动复制粘贴数值来汇总」。最近经常收到想用 Power Automate 把这类工作自动化的咨询。

最初的小型流程，通常几十分钟就能跑起来。麻烦的是接下来的阶段。正式上线运行一段时间后，开始偶尔因错误而停止；只要目标系统的界面布局稍有变动，流程就会损坏；密码该放在哪里一直没定下来，就先直接写进输入变量里凑合用。明明有「能运行的流程」，一旦出事却没人能修——我见过好几个项目陷入这种状态。

Power Automate 学习成本低，能以无代码／低代码的方式快速上手。正因为这种便捷性，它也是一种容易把设计往后拖、就这样直接送上生产环境运行的工具。本文将按实务中容易踩坑的顺序，依次整理云端流程与桌面流程的区别、与 PowerShell、VBA 之间的角色分工、错误处理、让 UI 自动化稳定下来的思路、凭据信息的处理方式、治理与运维，以及判断何时该超出 Power Automate 范畴的时机。

1. 先说结论

• Power Automate 大致分为 云端流程（通过连接器串联云端服务）与 桌面流程（自动化 Windows 界面操作和桌面应用程序的 RPA）两大体系。首先判断需要哪一种，是最初的设计决策。
• 如果只是想自动化「PC 上的固定作业」，比起 Power Automate Desktop，PowerShell 往往才是优先候选。只要不是非得点击或输入界面，PowerShell 通常更易于维护，也更容易纳入版本管理。
• 选择 Power Automate 最有价值的场景，是需要操作缺乏 API 集成的现有系统界面，或是想用 Microsoft 365 的连接器（Outlook、SharePoint、Teams 等）快速搭建通知、审批流程的时候。
• 要投入生产运行，就必须从一开始就把错误处理（On Block Error）、UI 选择器的稳定化、凭据信息的安全管理，以及基于 DLP 策略的治理这四点纳入设计。事后补救是事故的根源。¹²
• 无人执行（unattended）需要与有人执行（attended）不同的许可证与前提条件。如果把许可证设计往后拖，就会出现验证环境能跑、生产环境却跑不起来的情况。³⁴

2. Power Automate 的整体概览

与其说 Power Automate 是单一产品，更像是把多种自动化手段整合在一起的平台。

flowchart TB
    PA[Power Automate]
    PA --> Cloud[云端流程]
    PA --> Desktop[桌面流程 / RPA]
    PA --> Process[流程挖掘]
    PA --> Builder[AI Builder]

    Cloud --> Auto[自动化流程<br/>事件触发]
    Cloud --> Sched[计划流程<br/>定期执行]
    Cloud --> Instant[即时流程<br/>手动・按钮启动]
    Cloud --> Connectors[连接器<br/>SharePoint / Outlook / Teams / SQL 等]

    Desktop --> Attended[有人执行<br/>在用户眼前执行]
    Desktop --> Unattended[无人执行<br/>在服务器/专用PC上执行]
    Desktop --> UIAuto[UI自动化<br/>界面操作・现有应用集成]

• 云端流程是通过连接器把云端服务彼此串联起来的机制。按触发方式不同，可分为自动化流程（事件发生时）、计划流程（定期执行）、即时流程（手动启动）。
• 桌面流程是直接操作 Windows 上应用程序与界面的 RPA（Robotic Process Automation，机器人流程自动化）。既可以由云端流程调用，也可以单独执行。⁵
• 桌面流程还可再分为由人在界面前操作执行的有人执行（attended），以及在专用 PC 或服务器上无需人员介入即可执行的无人执行（unattended）。⁴

无人执行所说的「专用机器」，并不是指没被锁定就没问题。在 Windows 10/11 上，无论是否是用于连接的用户，只要任何人的会话仍处于锁定状态，无人执行就会失败。Windows Server 的范围稍窄一些，只要用于连接的同一用户的锁定会话仍存在，就无法执行。运维作业或其他管理员通过 RDP 连接之后，往往只做「锁定」或「断开连接」就结束，但必须确保所有人都确实「注销」。⁶

接受咨询时，我会先从「这是云端服务互相对接的问题，还是操作界面的问题」开始区分。仅这一点，就能让后续判断清晰很多。

3. 云端流程、桌面流程、PowerShell、VBA 的分工

同样是「自动化」，各自擅长的领域却相当不同。

实务中常见的误解，是把「想自动化」直接等同于「反正先用 Power Automate」。用 Power Automate Desktop 去 UI 操作一个已经提供 API 的系统，本来就是直接从 PowerShell 或 .NET 调用 API 会更稳定的场景。反过来，如果必须操作没有 API 的旧业务系统或 Win32 应用程序的界面，桌面流程的 UI 自动化就是现实可行的选择。

补充：关于 Excel 与 VBA 的局限性与替换思路，另一篇文章「什么是 VBA——局限性、未来走向、该替换的场景与现实的迁移方式」也有整理，其中还谈到把 Office Scripts 与 Power Automate 组合使用来处理 Microsoft 365 业务流程的模式。⁷

4. 理解许可证

Power Automate 的许可证大致分为以用户为单位的许可证，以及以流程为单位（Process）的许可证。³

这里容易混淆的地方在于，许可证的判断依据不是「谁创建的」，而是「如何执行」。自动化流程与计划流程会以流程所有者的许可证上下文运行，而以按钮启动的即时流程，则会以调用者的许可证上下文运行。如果要以无人执行为前提来设计，就必须在验证阶段先确认许可证需求，否则会在生产环境迁移前卡住。另外，以前的「无人执行附加组件（Unattended RPA add-on）」目前已列为旧版，改由 Power Automate Process 许可证取代。现有的无人执行附加组件已被提升为与 Process 许可证同等的待遇，但新分配时要使用 Process 许可证。³⁸⁴

需要注意的是，仅有 Process / Hosted Process 许可证，并不能替代用户许可证。要把 Process 许可证分配给计算机（无人执行所需），前提是该计算机已由持有 Power Automate Premium 许可证的用户完成注册。此外，如果要从云端流程调用有人执行或无人执行的桌面流程，执行时使用的连接用户也必须拥有 Premium 许可证（或包含桌面流程权益的其他许可证）。如果只确保了 Process 容量，却忽略了运行所需的用户许可证，就会在功能测试阶段卡住。³

5. 实务设计 ── 汇总共享文件夹的 CSV，制作 Excel 报告并发送邮件

以常见的「每日报表制作」作为具体示例。

想要实现的事

1. 收集共享文件夹中当天的 CSV
2. 汇总内容并写入 Excel 报告模板
3. 将报告保存到指定文件夹
4. 通过邮件通知相关人员
5. 失败时通知负责人，并将原因记录到日志中

flowchart TD
    Start([计划启动 06:30]) --> Block[[On Block Error: 汇总处理]]
    Block --> List[List files in folder<br/>获取当天CSV]
    List --> Check{有目标文件?}
    Check -- 没有 --> NoticeEmpty[记录无目标并结束]
    Check -- 有 --> Read[Read from CSV file<br/>逐个文件循环]
    Read --> Agg[汇总数值・累加变量]
    Agg --> Excel[Launch Excel<br/>打开模板]
    Excel --> Write[Write to Excel worksheet<br/>写入汇总结果]
    Write --> Save[保存并关闭 Excel]
    Save --> Mail[Send an email<br/>把报告发送给负责人]
    Mail --> Log[将执行结果追加到日志文件]
    Log --> End([正常结束])
    Block -. 发生错误 .-> Handler[错误处理器]
    Handler --> CloseExcel[若 Excel 仍处于打开状态则关闭]
    CloseExcel --> LogErr[将错误内容记录到日志]
    LogErr --> Notify[向管理员发送失败通知邮件]
    Notify --> End2([记录为异常结束])

主要操作与角色如下。

不要把整个流程做成一长串巨大的操作序列，而是拆分成「获取文件」「汇总」「写入 Excel」「通知」「记录日志」这样的子流程，之后修改或单独重新执行都会更容易。由云端流程负责计划启动，实际处理则交给被调用的桌面流程，这种架构在运维上也更容易处理。⁵

6. 设计错误处理

Power Automate Desktop 提供 On Block Error 操作，可以按代码块（Block）为单位统一设置错误处理。不需要为每个操作分别设置「发生错误时的行为」，而是能把统一的错误处理应用到代码块中包含的所有操作上。¹

[On Block Error] 汇总处理代码块
  ├─ List files in folder
  ├─ Read from CSV file（循环）
  ├─ Launch Excel / Write to Excel worksheet
  └─ Save Excel / Close Excel

[错误处理器]
  ├─ 用 Get last error 操作把错误内容（名称・发生位置・对应操作・详细消息）获取为变量
  ├─ 若 Excel 实例仍处于打开状态就关闭它（越是失败时越不能省略后续清理）
  ├─ 用 Write text to file（Append）记录到日志
  ├─ 用 Send an email（V2）通知管理员
  └─ 选择「从代码块末尾重新开始」或「停止流程运行」

这里有几点需要掌握。

• 单个操作的错误处理，优先于代码块单位的错误处理，因此只想改变特定操作行为时就单独设置，其余的统一交给 On Block Error 处理，这样分工会更清晰。¹
• 使用「Retry action if an error occurs」，可以针对临时性错误（如网络延迟、文件锁定等），按指定次数与间隔自动重试。如果把所有错误都设为重试对象会白白浪费时间，因此要区分该重试的错误与不该重试的错误（如数据不一致等）。¹
• 如果要在错误处理器中引用刚发生的错误内容，需要明确放置Get last error 操作。这个操作会返回一个具有名称・位置・对应操作・所属子流程・详细内容・消息这 6 个属性的变量，并不会自动以隐式变量的方式提供。获取后用「Clear error」选项清除，可以避免之后误用同一个错误值。¹
• 日志不能只记录「成功／失败」，还要保留处理条数、目标文件名、错误消息。事后要排查「为什么会停下来」，唯一的线索就在日志里。
• 作为代码块的后续处理，要明确选择「从代码块末尾重新开始」还是「停止流程运行」。如果让 Excel 实例保持打开状态就停止，下次运行时就会残留旧进程，引发事故，因此发生错误时反而更要意识到后续清理（关闭实例）。¹¹

如果习惯 PowerShell 的 try/catch/finally，可以把 On Block Error 的「代码块」理解为类似 try、错误处理器理解为 catch、后续清理的处理序列理解为 finally，这样设计起来会更容易把握。

7. 让 UI 自动化稳定下来

桌面流程变得不稳定的最大原因，多半出在「UI 元素的识别方式（选择器）」上。

• 默认情况下，UI 元素选择器（UI element picker）会把界面元素记录为 选择器（属性的组合）。如果其中包含容易受应用程序版本升级、显示内容变化影响的脆弱属性（如连续编号索引、动态 ID 等），即使界面外观相同，流程也会损坏。¹²
• 把会变动的属性从 Equals 改成 Contains 或正则表达式，并把依赖前一个操作结果的值改为变量化，就能构建出更动态、更不易损坏的选择器。¹²
• 提前设置多个选择器，当第一个选择器失败时，就会自动回退使用下一个选择器。为重要操作准备备用选择器，可以提升稳定性。¹²
• 选择器损坏时，可以用 Repair selector 功能自动生成修复候选方案。在手动从头重做之前，值得先试试这个功能。¹²
• 界面切换与应用程序启动之间存在时间差。不要只依赖固定的 Wait，要搭配「等待窗口」「等待直到找到 UI 元素」这类条件等待操作，同时也要设置找不到 UI 元素时的自动重试。¹³
• 对于无论如何都无法稳定下来的自动化对象（虚拟化界面、布局频繁变动的界面等），不要死守 UI 操作，应先确认是否有 API、文件集成、数据库访问等更稳定的集成方式可用。

让 UI 自动化第一次跑起来本身并不难。半年后能否仍不损坏地持续运行，几乎完全取决于选择器的构建方式。

8. 安全处理凭据信息

业务自动化中最容易发生事故的，就是凭据信息（密码、API 密钥、连接字符串等）的处理。

• 避免把密码或连接信息直接以数值写进流程的输入变量中。使用Get credential 操作，可以从以 Azure Key Vault 或 CyberArk 作为后端密钥库的「Power Automate 凭据」中安全获取凭据信息，获取到的值会被标记为机密信息，也不会保留在流程的执行日志里。¹⁴¹⁵
• 如果把 Azure Key Vault 用作密钥的存储位置，就能在 Power Automate 端把连接 Key Vault 的信息集中管理在一处，不必让凭据信息分散到每个流程中。¹⁵
• 无人执行用的账户，应准备一个使用范围收缩到必要最小限度的专用账户，不要与人员日常使用的账户共用。账户拥有的权限越广，流程的缺陷或配置错误所波及的范围也就越大。
• 如果以「先让它跑起来」为理由，暂时把密码以明文写进输入变量并就此推进验证，这种做法很容易就这样一直残留到生产环境。从验证阶段起就养成使用 Get credential 操作的习惯会更安全。

9. 治理与运维

当个人或团队各自创建的流程逐渐增多，接下来就需要组织层面的统一管控。

• 数据丢失防护（DLP）策略是把流程或应用可用的连接器分类为「仅限业务数据」「不可用于业务数据」「阻止」等类别，防止业务数据用连接器与不可用于业务数据的连接器在同一个流程内组合使用的机制。这是防止组织数据在无意间外泄到外部服务、最应优先建立的治理措施。¹⁶
• 桌面流程的操作，也能在同样的 DLP 策略框架下分类与阻止，但这项功能默认并未启用。必须在 Power Platform 管理中心的租户设置中一次性开启「Show desktop flow actions in DLP policies」，而且这项设置之后无法还原。启用之后，也只有在策略中明确分类过的模块与操作才会受到管控，因此要注意「创建了 DLP 策略」并不等于「整个桌面流程都已受到统一管控」。²
• 无人执行用的计算机，应以计算机组的方式集中管理，并明确掌握哪个流程会在哪台计算机上执行。
• 执行记录可以从 Power Automate 的管理页面／执行历史中查看。如果把失败时的告警（Teams 通知或邮件通知）内置到流程本身的处理中，就不需要有人手动去检查，也能及时发现异常。
• 如果想从云端流程访问企业内部网络中的数据库或文件共享等云端无法直接访问的本地资源，可以使用本地数据网关。网关不需要在云端侧开放接收端口，仅通过出站方向的连接就能安全地桥接数据。¹⁷
• 把验证用与生产用的环境分开，按环境划分桌面流程与连接信息，可以避免验证中的变更影响到生产环境的流程。

10. Power Automate 的局限与升级判断标准

Power Automate 虽然强大，但并非万能。遇到下列情况时，应考虑切换为 PowerShell 或 .NET 应用程序。

当你觉得「用 Power Automate 做出来的东西发展得过于复杂」时，比起硬撑着继续扩展流程，把核心处理抽离到 .NET 或 PowerShell，让 Power Automate 只专注负责触发和通知的架构，结果往往更容易维护。用 PowerShell 进行日志排查、归档自动化的实际案例，另一篇文章「PowerShell 脚本进阶 ── 安全地实现日志排查、归档与报表自动化」中也有介绍。

11. 结语

Power Automate 在迈出第一步之前，简单得令人惊讶。然而这种便捷性反过来看，也意味着「即使省略设计也能先跑起来」。上线之后的流程能否长期维护下去，几乎完全取决于最初做了多少看似不起眼的判断。

该用云端流程还是桌面流程，哪些处理适合交给 PowerShell 或 .NET。先把这个判断做好，之后的返工就会大幅减少。错误处理、UI 选择器、凭据信息、许可证、DLP 策略，这些「一开始就内置进去」都远比「先跑起来再修正」的成本低得多。而当流程发展得复杂起来时，能否不硬撑扩展、而是把处理转移到 .NET 或 PowerShell，也决定着这套自动化能否长久使用下去。

「先能跑起来的流程」与「能安心托付的流程」之间，就存在着这么多的设计差距。越是涉及现有业务系统或 Excel / VBA 资产的自动化，最初的设计判断就越会大幅决定后续的维护成本。

相关文章

• 什么是 VBA——局限性、未来走向、该替换的场景与现实的迁移方式
• PowerShell 脚本进阶 ── 安全地实现日志排查、归档与报表自动化
• Excel 报表输出的实现方法 - COM / Open XML / 模板

相关咨询领域

小村软件有限公司提供在保留现有 Excel / VBA / Windows 业务资产的前提下，逐步推进自动化与现代化的咨询，以及包含 Power Automate 的自动化基础设施设计评审。

• 存量资产利用・迁移支持
• 技术咨询・设计评审
• Windows 应用开发
• 联系我们

参考链接

相关文章

共享相同标签的最新文章。可以围绕相近的主题进一步加深理解。

常见问题

汇总了咨询这一主题时常见的问题。

云端流程和桌面流程该如何分工？

云端流程是通过连接器把云端服务彼此串联起来的机制，适合审批流程、通知、SaaS 集成，以及 Microsoft 365 周边的业务流程。桌面流程则是直接操作 Windows 上应用程序或界面的 RPA，是没有 API 的旧业务系统，或需要操作 Win32 应用程序界面时的现实选择。接受咨询时，先分清「这是云端服务互相对接的问题，还是操作界面的问题」，能让后续判断清晰很多。

Power Automate 和 PowerShell 该用哪个？

如果只是想自动化 PC 上的固定作业，且不是非得点击或输入界面不可，PowerShell 通常更易于维护，也更容易纳入 Git 版本管理。已经提供 API 的系统，用 UI 操作本来就不如直接调用 PowerShell 或 `.NET` 的 API 来得稳定。数十万行规模的数据处理、需要自动化测试的复杂逻辑，以及高频率的常驻处理，同样适合交给 PowerShell 或 `.NET`。当流程变得过于复杂时，把核心处理抽离出来，让 Power Automate 只专注处理触发和通知，整体会更容易维护。

Power Automate 的无人执行需要什么许可证？

无人执行需要与有人执行不同的许可证，要使用把许可证绑定到流程或计算机上的 Power Automate Process 许可证。以前的无人执行附加组件现已列为旧版，改由 Process 许可证取代。另外，仅有 Process 许可证并不能替代用户许可证，注册计算机仍需要一位持有 Power Automate Premium 许可证的用户。此外，在 Windows 10/11 上，只要有任何人的会话仍处于锁定状态，无人执行就会失败，因此必须让所有人都注销。

桌面流程的 UI 自动化为什么会不稳定？

最大的原因多半出在 UI 元素的识别方式（选择器）上。只要包含连续编号索引或动态 ID 这类易变动的属性，即使界面外观相同，流程也会损坏。对策是把会变动的属性从 Equals 改成 Contains 或正则表达式，设置多个选择器做后备，损坏时再用 Repair selector 功能生成修复候选。不能只依赖固定的 Wait，也要搭配条件等待的操作。半年后能否仍稳定运行，几乎完全取决于选择器的构建方式。

作者简介

本文作者的个人简介页面。

Go Komura

小村软件有限公司 代表

以 Windows 软件开发、技术咨询与故障排查为中心，擅长难以复现的故障调查，以及既有资产仍在运行的项目。