Power Automate 与 PowerShell+任务计划程序的使用场景划分 ── 不混用自动化工具，物尽其用地对接

「财务服务器上从近十年前就开始运行着 PowerShell 的夜间批处理。而最近，业务一线的负责人又开始用 Power Automate 制作申请流程和通知流程。明明同样是『自动化』，制作方式和存放位置却完全不同的两套体系在公司内部不断增加，新的自动化到底该用哪种工具制作、又或者说到底还有没有人能掌握全局，都渐渐说不清楚了」。最近，我们经常从已经导入 Microsoft 365 的中小企业那里收到这样的咨询。

PowerShell+任务计划程序与 Power Automate，都是「自动完成既定工作」的工具，但两者擅长的领域几乎不重叠。正因为不重叠，勉强把工作都堆到某一边就会变得吃力，而不划定边界地混用则会拼凑出无法维护的缝合体。本文将先整理两者性格上的差异，再说明该用哪种工具制作的判断标准，以及混用时的对接模式。Power Automate 整体的设计思路，我们在《用 Power Automate 实现业务自动化 ── 云端流程与桌面流程的分工，以及错误处理设计》中讨论过；PowerShell 本身的入门内容，则在《PowerShell 命令基础 ── 应先掌握的操作与安全使用方法》中讨论过，因此本文聚焦于「该用哪个工具的判断」与「联动」这两点。

1. 先说结论

• 判断的首要标准是对象位于何处。如果对象是本地文件・共享文件夹・服务器・操作系统，基本原则是用 PowerShell+任务计划程序；如果对象是 SharePoint・Outlook・Teams 等 Microsoft 365 上的数据以及通知・审批，基本原则是用 Power Automate。
• PowerShell 的弱点在于面向人的通知。曾经的常用做法 Send-MailMessage 已被官方标记为不推荐使用（obsolete），PowerShell 内部没有直接的替代方案。¹ 把通知・审批交给 Power Automate 来做成本更低。
• Power Automate 的弱点在于触达本地环境和处理大批量数据。要让云端流程触达公司内部的文件服务器，需要本地数据网关或桌面流程联动，二者都在 Microsoft 365 附带使用权之外（属于高级功能）。²³⁴
• 如果要把两者连接起来，首选方案是让 PowerShell 把结果文件放到 SharePoint，由 Power Automate 用「文件创建时（仅属性）」（英文界面为 When a file is created (properties only)）触发器进行检测，并接入通知・审批，实现松耦合。⁵
• Power Automate for desktop 中有「运行 PowerShell 脚本」操作，可以从流程中调用已有脚本。不过从云端流程发起调用属于高级功能，还需要管理执行用的机器。⁶⁴
• 云端流程的执行历史默认只能查看28 天以内的内容。⁷ 需要留痕的处理，应通过 PowerShell 一侧的日志文件或写回 SharePoint 列表来保留证据。
• 最后，很多时候正确答案并不取决于技术，而是由能够维护的人在哪一边来决定。无论用的是哪种工具，只有创建者本人才能修复的自动化都是同样的风险。

2. 两种工具的性格

首先要确认的是，两者是站在不同舞台上的工具。

对表格中「变更管理」一行做个补充。导出流程的操作是：登录 Power Automate 门户，在左侧导航的「我的流程」>「云端流程」中选中目标流程，然后在菜单「导出」旁边的向下箭头中选择「打包 (.zip)」。取得的是 zip 打包文件，并不适合像脚本那样进行逐行的差分评审。此外还有一项限制：只有流程的所有者或共同所有者才能导出。如果希望进行持续的版本管理，Microsoft 推荐的做法并非打包的导出/导入，而是使用基于 Dataverse 解决方案的 ALM。⁸

重要的是，在这张表的左右两侧，「执行位置」和「制作者」这两点都不相同。PowerShell+任务计划程序在公司内部的机器上运行，由会写代码的人来制作，并作为代码进行管理。Power Automate 在云端运行，即使是熟悉业务的一线人员也能制作，而且不需要照看执行基础设施。也就是说，这两者的混用并不只是工具的重复，而是「信息系统部门的自动化」和「业务一线的自动化」这两种文化的并存。正因如此，仅凭一声号令强行统一到某一边，大多都会失败。

3. 该用哪种工具制作的判断表

在接受咨询时，我通常会从「对象位于何处」「由谁来制作与维护」「是否需要面向人的通知・审批」这三点来做区分。用具体的业务示例来看会更直观，因此整理成了下面的判断表。

纵向浏览这张表可以发现，几乎是与「对象」这一列一对一地决定了该用哪种工具。例外是最后一行这种「处理在本地、通知在云端」横跨两者的情况，这正是第 6 章联动模式登场的地方。

反过来，以下这几种选择方式后期会很吃力。

• 仅仅因为想要通知，就把文件处理也一并塞进 Power Automate。为了触达本地环境而引入网关或 RPA，会增加许可证与管理对象（第 5 章）。
• 一线使用的 SharePoint 申请流程，由信息系统部门用 PowerShell 来做。虽然能做出来，但用代码编写 SharePoint 写入和 Teams 通知，投入产出比很低，还会变成一线人员无法自行修改的孤品。
• 因为两种工具都能做，就由各负责人各自随意选择。这会直接导致第 7 章提到的维护问题。只要事先定下一条「对象在这里就用这个工具」的公司规则，就能大幅抑制混用带来的混乱。

4. PowerShell 的局限

邮件・Teams 通知很吃力

当 PowerShell 的夜间批处理被提出「结束后请用邮件通知我」这样的需求时，事情会一下子变得棘手起来。多年来一直被使用的 Send-MailMessage 命令行程序，由于无法保证与 SMTP 服务器之间的安全连接，已被官方正式标记为不推荐使用（obsolete），警告文字中明确写着「PowerShell 内部没有直接的替代方案」。作为替代方案被推荐的是第三方的 MailKit 库，或者面向 Exchange Online 用户的 Microsoft Graph PowerShell SDK（Send-MgUserMail）。¹

通过 Graph 发送确实可行，但需要向 Microsoft Entra ID 注册应用、授予权限（范围）、管理证书或密钥，仅仅为了发一条通知就要承担相当多的准备工作。向 Teams 发通知也是同理，要直接从代码调用，认证方面的门槛偏高。在这一点上，建议干脆把通知交给 Power Automate 来处理。使用标准连接器的 Outlook・Teams 操作，无需额外的应用注册，几分钟就能搭建完成。

在负责人电脑上运行的「野生任务」

任务计划程序自动化中常见的事故，是任务并未设置在服务器上，而是被埋在了负责人的电脑里。一旦关机下班，任务就不会运行；执行用户的密码变更或人员离职，也会让任务悄无声息地停止。而且任务计划程序是各台机器本地的东西，公司内部到底在哪里运行着什么，根本没有一个可以统一查看的地方。

对策虽然朴实无华，但有以下三点：（1）把需要定时执行的任务集中到固定的服务器上（如果没有，就集中到一台常开的管理用电脑上）；（2）把任务的清单以及各自的目的・负责人整理成文档；（3）把任务定义本身以 Register-ScheduledTask 之类的脚本形式保留下来，做到即使更换机器也能重现。⁹ 即使只对脚本本体做了 Git 管理，如果任务计划程序一侧的设置（启动时间・执行用户・工作文件夹）仍然靠手工操作，环境依然无法重现。

凭据的保存

当脚本需要连接数据库或外部服务时，密码该放在哪里的问题必然会出现。直接写死在 .ps1 里自不必说是不可取的，PowerShell 的标准答案是 SecretManagement 模块+SecretStore 扩展。可以把密钥在本地加密保存，脚本再通过 Get-Secret 取出来使用。¹⁰ 官方也提供了在任务计划程序无人执行场景下使用该模块的配置方法（在自动化账户的用户上下文中进行设置）说明。¹¹ 另外需要说明的是，这一系列模块目前处于「功能完成」状态，已停止新功能开发，但安全修复方面的支持仍在继续。¹⁰

另一方面，Power Automate 由平台一侧保管连接器的连接（身份验证）信息，因此制作者不必操心这个问题。这是 Power Automate 隐藏的优势，但反过来说，连接与流程所有者的账户绑定，又会带来另一个管理问题。这一点在《Power Automate 的人员依赖对策 ── 所有者・连接・交接的设计》中有说明。

5. Power Automate 的局限

无法触达本地文件・本地环境

云端流程运行在 Microsoft 的云端，因此无法直接触达公司内部网络中的共享文件夹或本地数据库。触达手段主要有两种。

1. 本地数据网关。在公司内部安装一个常驻应用，充当与云端之间的桥梁。由于不需要开放入站端口、只依靠出站方向的连接即可工作，因此安全性较高。¹² 借助网关可以连接到文件系统或 SQL Server 等，但使用网关需要相应的许可证。²
2. 通过桌面流程（RPA）。从云端流程调用运行在 PC 上的桌面流程，把本地处理交给它去做。这种「从云端流程触发・按计划执行」本身就是一项高级功能。⁴

重要的是，这两种方式都在 Microsoft 365 附带的 Power Automate 使用权之外。Microsoft 365 附带的使用权（seeded license）中，不包含高级连接器・本地网关・RPA 中的任何一项。³ 也就是说，「想用 Power Automate 处理共享文件夹里的文件」这个需求，实际成本比看起来要高。许可证层级以及标准/高级的边界，我们在《Power Automate 的许可证与标准/高级连接器的边界》中做了整理，请在做判断之前先确认一下。

不追加费用的现实解法有两种：要么把处理对象的文件存放位置迁移到 SharePoint/OneDrive，要么把共享文件夹一侧的处理交给 PowerShell，Power Automate 只负责云端一侧的工作。后者就是下一章要讲的联动模式。

大批量数据・复杂逻辑很吃力

把数十万行的 CSV 用流程的循环逐行处理，这类工作不在 Power Automate 的设计范围之内。而且每种许可证都有每天可执行操作次数的上限，在 Microsoft 365 附带的使用权下为每用户每天 6,000 次操作。³ 大批量数据的核对・汇总・转换，用 PowerShell 或 .NET 来写，往往几分钟就能完成。具体写法可以直接沿用《PowerShell 实用命令合集 —— 积累日常工作中常用的小工具》中介绍的 Group-Object 与 Compare-Object 组合。

此外，条件分支层层叠加的逻辑，在流程的画面上很难读懂，也无法编写测试。云端流程「单次执行最长 30 天」的限制¹³会影响到等待审批这类场景，但在此之前，「把分支画在纸上一张 A4 都放不下的逻辑」本身就属于代码的领域。

执行历史仅保留 28 天

云端流程的执行历史，默认只能显示 28 天以内的内容。⁷ 「想在三个月后确认那天的批处理是否运行过」这种需求，执行历史是满足不了的。如果是 PowerShell，可以自己写日志文件，保留多少年都可以（这方面的设计已经在日志整备文章中详细说明）。如果 Power Automate 一侧也需要留痕，可以在流程本身中加入把处理结果写回 SharePoint 列表的步骤。包含出错时通知与重试在内的具体搭建方法，请参考《Power Automate 的错误处理与重试设计》。

6. 混用时的对接模式

既然两者擅长的领域并不重叠，「处理交给 PowerShell、通知・审批交给 Power Automate」这种横跨两边的业务必然会出现。对接模式有三种。

模式 a：通过文件实现松耦合（推荐）

由任务计划程序运行的 PowerShell，把处理结果（结果 CSV・摘要）放到 SharePoint 库中，Power Automate 一侧则用 SharePoint 连接器的「文件创建时（仅属性）」触发器进行检测，并接入通知或审批。这个触发器是实际存在的标准连接器触发器，变更大致会在数分钟以内被捕捉到（因为是通过轮询确认 SharePoint 一侧变更的方式，所以并非即时）。⁵

如果租户的显示语言是英语，就无法用这个名字搜索到，因此这里一并列出英文界面下的名称。在触发器列表中查找时，请以此为准。⁵

另外，名字相似的「文件创建时（文件夹内）」（When a file is created in a folder）已被标记为不推荐使用，还存在不会在子文件夹中触发等限制，如果是新搭建，请不要选择它。⁵

下图展示了这种模式的流程。任务计划程序在凌晨 2 点启动 PowerShell 脚本 → 脚本进行汇总・文件处理・日志输出，输出结果 CSV 与摘要 → 将其放置到 SharePoint 库中 → 「文件创建时」触发器检测到该放置动作，云端流程随之启动 → 流程查看摘要内容，若正常结束则向 Teams 发送完成通知，若存在错误则通知负责人，必要时转入审批・处理流程，这是一个单向的流程。

flowchart TD
    T[任务计划程序凌晨2点启动] --> PS[PowerShell 脚本<br/>汇总・文件处理・日志输出]
    PS --> OUT[输出结果 CSV 与摘要]
    OUT --> UP[存放至 SharePoint 库]
    UP --> TRG[云端流程启动<br/>文件创建时]
    TRG --> CHK{摘要内容}
    CHK -- 正常结束 --> OK[向 Teams 发送完成通知]
    CHK -- 存在错误 --> NG[通知负责人<br/>必要时转入审批・处理流程]

从 PowerShell 向 SharePoint 放置文件的方法，要根据任务的执行方式来选择。最简单的方法是把输出目标文件夹设为 OneDrive/SharePoint 的同步对象（脚本只需写入本地文件夹即可），但同步客户端是一款依赖登录用户会话来运行的应用。对于设置了「无论用户是否登录都执行」的夜间任务，或者没有任何人登录的服务器，同步不会运行，于是就会出现写入本地的文件没有被上传、流程也不会启动这种落空的情况。如果是白天在有人值守的电脑上运行的小规模场景，同步就足够了；但如果前提是夜间・无人执行，就需要使用 PnP.PowerShell 或 Graph API 从脚本直接上传的方法，或者准备一个持续登录用于同步的会话并将其纳入监控对象。虽然会增加身份验证方面的准备工作，但可以从机制上杜绝「本该放置的文件却没有」这种情况。

PnP.PowerShell 是一款用于操作 SharePoint Online、Teams 等 Microsoft 365 的社区制作（并非 Microsoft 官方产品）的开源 PowerShell 模块。它具备超过 700 个命令行程序，可以直接从脚本中执行文件上传或列表操作。不过，以前那种可以用共用的 Entra ID 应用轻松连接的方式，在 2024 年 9 月因该应用被废止而不再可用，此后必须由使用者自行注册 Entra ID 应用。已经不再是「装上模块就能立刻用」的状态，因此在做导入决策时，请把这部分应用注册与权限授予的工作量也一并计入。¹⁴

推荐这种模式的理由在于，边界会以文件这种肉眼可见的形式被固定下来。PowerShell 一侧不知道 Power Automate 的存在，Power Automate 一侧也不知道脚本的内部内容。当有一方出问题时，只要看 SharePoint 中是否存在文件，就能立刻切分出问题出在哪一侧。负责人也可以分开：脚本由信息系统部门负责，通知流程由熟悉业务的一线人员负责，这样的分工可以原样成立。此外，放置的文件本身还能作为弥补执行历史 28 天问题⁷的证据发挥作用。

模式 b：从 Power Automate for desktop 调用 PowerShell

Power Automate for desktop（PAD）中有一个「运行 PowerShell 脚本（Run PowerShell script）」操作，可以在桌面流程中执行任意的 PowerShell 代码，并通过变量（PowershellOutput）接收输出结果。⁶ 由于可以把已有的脚本资产作为流程的一个部件来调用，因此可以搭建出「处理主体仍然是脚本本身，只把启动和前后的画面操作交给 PAD」这样的架构。

这个操作的设置项只有三个。⁶

输出通过 PowershellOutput（脚本的输出）与 ScriptError（执行过程中出现的错误）这两个变量来接收。要把值返回给流程，官方写法是在 PowerShell 一侧传给 Write-Output。⁶

# 假设粘贴到 PAD 操作设置「PowerShell code to run」栏中的最小示例。
# %InputFolder% 是 PAD 一侧的变量，会在 PowerShell 运行前被替换为字符串
$targetFolder = '%InputFolder%'
$count = (Get-ChildItem -LiteralPath $targetFolder -Filter '*.csv' -File).Count

# 用 Write-Output 返回的内容会进入 PowershellOutput 变量
Write-Output $count

也就是说，从 PAD 一侧来看，这个部件的入口只有「嵌入代码正文的变量」，出口也只有「PowershellOutput 的字符串」这一个。由于返回值不是结构化的、而是以字符串形式返回，如果想返回多个值，就需要设计成汇总为一行 CSV 或 JSON、再由后续步骤解析 PowershellOutput 的方式。再加上默认超时只有 10 秒，这个操作并不适合「把夜间批处理主体整个搬到这个操作里」这样的用法。较长的处理，请结合接下来列出的注意事项再做判断。

不过有三点需要注意。第一，这个操作在内部启动的是 powershell.exe，也就是 Windows PowerShell 5.1。¹⁵ 按 PowerShell 7 的前提编写的脚本，原样使用可能无法运行。第二，存在超时设置（默认值 10 秒），如果要调用耗时较长的批处理，需要明确延长或设为不限制。⁶ 第三，如果想让它无人值守地定时执行，从云端流程触发属于高级功能⁴，还需要无人执行的许可证以及对执行用机器的管理。「用 PAD 代替任务计划程序做定时执行」是否值得为此追加付费，最好冷静地权衡一下。对于已经在用 PAD 运行 RPA（画面操作）、执行基础设施已经齐备的公司来说，这是一个可选项；否则用模式 a 就足够了。

模式 c：接收 HTTP 请求的自建 API

用云端流程的「收到 HTTP 请求时（When an HTTP request is received）」触发器让流程拥有一个 URL，再由 PowerShell 一侧用 Invoke-RestMethod 调用它来启动；或者反过来，在公司内部搭建一个小型 Web API，由流程去调用。这个触发器属于高级的 HTTP 请求/响应连接器。¹⁶ 系统还提供了可以配置调用方限制（仅限租户内用户等）的 OAuth 身份验证机制。¹⁷

这是实时性最高、也能传递参数的最灵活的模式，但 URL 的管理・身份验证・出错时的重发，需要考虑的事情一下子就进入了开发的领域。到了这一步，这已经不再是「Power Automate 与 PowerShell 的联动」，而是一个小型系统开发，需要判断是自行内部承担，还是交给外部来评审设计。

总结来说，首选模式 a，如果已经有 PAD 的基础设施就选 b，只有在实时性需求明确时才选 c。松耦合的设计思路适用于文件联动的一般场景，互斥控制与交接方式在《文件集成互斥控制基础知识 - 文件锁与原子 claim 的最佳实践》中也有介绍。

7. “没有两者都精通的人”问题

到这里为止，我一直是从技术角度来写判断标准的，但在实际现场，最后起决定作用的是「谁能维护」。信息系统部门里有一个人会写 PowerShell，业务一线有一个人会用 Power Automate，而两者都懂的人是零——在中小企业里，这是很正常的状态。

正因如此，即使从技术上讲更适合用 PowerShell 处理的业务，如果会写代码的人即将离职，那么改用 Power Automate 来制作（或者反过来）也是十分合理的判断。比起工具孰优孰劣，五年后公司里是否还有人能修它才更重要。判断表（第 3 章）是「以有能够维护的人为前提的最优解」，如果没有这样的人，就应该让最优解迁就于人，而不是相反。

在此基础上，无论用哪种工具，都有两件共通且必须做的事。

• 清点存在的自动化。把任务计划程序的任务清单（在哪台机器・什么时间・做什么・由谁管理）与 Power Automate 的流程清单（所有者・连接・目的），汇总到同一张台账中。两套体系混用的公司最可怕的地方，就是一套体系对另一套体系是不可见的。
• 以可交接的形式保存。脚本存入 Git，任务定义存为注册脚本⁹，流程则通过共同所有者设置与导出来保存。没有说明文档的自动化，就等同于批量生产没有源代码也没有文档的系统的缩小版。流程一侧具体的交接设计，已经整理在人员依赖对策文章中。

8. 总结

PowerShell+任务计划程序与 Power Automate 并不是相互竞争的工具，而是守备范围几乎不重叠的两种不同工具。本地・服务器・文件・大批量数据交给 PowerShell，Microsoft 365 上的数据以及通知・审批交给 Power Automate。按照这条基本原则，大多数自动化都能确定该放在哪一边。

横跨边界的业务，不要勉强靠拢到哪一边，而是以放置在 SharePoint 上的文件为边界进行松耦合对接，这种做法无论在许可证层面还是维护层面都更为稳妥。PowerShell 在通知方面的痛点（Send-MailMessage 不推荐使用）与 Power Automate 在触达本地环境方面的痛点（网关・RPA 属于高级功能），恰好可以由对方擅长的领域各自弥补。

而且，「由谁来维护」「哪里正在运行着什么」这些问题，应该和工具选型一样受到重视，并在一开始就确定下来。两套自动化体系并存这件事本身是健康的，问题只在于无秩序地混用。从想要整理公司内部自动化全貌，到希望针对个别情况判断该用哪种工具制作，我们都可以在这个阶段提供咨询。

相关文章

• 用 Power Automate 实现业务自动化 ── 云端流程与桌面流程的分工，以及错误处理设计
• 任务计划程序的任务不执行、以 0x1 结束 ── 原因排查与安全的运维设计
• PowerShell 脚本进阶 ── 安全地实现日志排查、归档与报表自动化
• Power Automate 的许可证 ── Microsoft 365 里能免费到什么程度，什么时候需要 Premium
• Power Automate 的人员依赖对策 ── 让创建者离职后流程也不会停止
• 用 Power Automate 设计定期执行流程 ── 月末处理・营业日判定・提醒的实务

相关咨询领域

合同会社小村软件（合同会社小村ソフト）提供从 PowerShell 编写的公司内部批处理整备，到包含 Power Automate 在内的自动化基础架构设计评审的咨询服务，也包括「该用哪种工具制作」这类判断在内。

• 技术咨询・设计评审
• Windows 应用开发
• 联系我们

参考链接

相关文章

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

相关主题

与本文相近的主题页面。以本文为起点，可以进一步了解相关服务和其他文章。

与本主题相关的服务

本文与以下服务页面相关联，欢迎从最接近的入口查看。

常见问题

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

Power Automate 和 PowerShell 到底该用哪个来做自动化？

基本的判断依据是对象所在的位置。如果对象是本地文件・共享文件夹・服务器・数据库・操作系统操作等公司内部的 Windows 环境，PowerShell+任务计划程序往往更稳定、更易于维护。如果对象是 SharePoint、Outlook、Teams 等 Microsoft 365 上的数据以及通知・审批，则更适合使用 Power Automate 的云端流程。把处理主体和通知分开来考虑，让繁重的处理交给 PowerShell、把面向人的通知与审批交给 Power Automate 分工，也是一种现实可行的做法。

从 PowerShell 向邮件或 Teams 发送通知很难吗？

以往常用的 Send-MailMessage 命令行程序，由于无法保证与 SMTP 服务器之间的安全连接，已被官方正式标记为不推荐使用（obsolete），在 PowerShell 内部也没有直接的替代方案。虽然可以用 Microsoft Graph PowerShell SDK 的 Send-MgUserMail 来发送，但需要事先完成应用注册和权限授予等准备工作，仅仅为了发通知就用它，门槛偏高。在实务中，让 PowerShell 只负责把结果写入文件、把检测与通知交给 Power Automate 来完成，这样的架构更容易处理。

Power Automate 可以处理本地共享文件夹里的文件吗？

可以，但要让云端流程触达公司内部网络中的文件，需要导入本地数据网关，而使用网关的权利并不包含在 Microsoft 365 附带的 Power Automate 使用权中，需要更高等级的许可证。从云端流程调用桌面流程（RPA）的架构同样属于高级功能。如果想在不追加许可证的情况下解决问题，现实的做法是先考虑把处理对象的文件迁移到 SharePoint/OneDrive 一侧，或者把共享文件夹一侧的处理交给 PowerShell+任务计划程序来完成。

让 PowerShell 的夜间批处理与 Power Automate 联动，最简单的方法是什么？

推荐通过文件实现松耦合。让由任务计划程序运行的 PowerShell 把处理结果的 CSV 或摘要文件放到 SharePoint 库中，Power Automate 一侧则用「文件创建时（仅属性）」触发器进行检测，并接入通知或审批，这就是一种架构。由于两套机制都不需要了解对方的内部结构，即使有一方出问题也容易切分排查，还可以分别指派不同的负责人。也有通过 Power Automate for desktop 的「运行 PowerShell 脚本」操作直接调用的方法，但这样会增加许可证和机器管理方面的前提条件。

作者简介

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

Go Komura

小村软件有限公司 代表

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