执行节点与流程资产，一套流程怎么在多台机器上稳定跑
同一份流程在开发机上跑得稳，搬到同事电脑就卡在第二步，根子在于流程跑在哪台机器上。这篇讲 RPA执行节点和流程资产统一管理怎么落地，分清本地节点与远程执行节点各管哪一段，环境一致性里最容易漏的变量，浏览器和驱动版本怎么钉死，节点健康检查看哪几层，扩容之前先想清楚扩的是什么。也写清哪几种情况这套东西不值得上。
同一份流程，三个人跑出三种结果
做自动化的同事大概都遇到过这种事。流程在开发机上录了两天，回放十遍都稳，交给同事用。第二天对方回一句，跑不动，卡在第二步。
打开远程协助看，同事那台电脑装的是 Chrome 126，开发机是 131。流程里定位按钮用的是一段 XPath，页面结构差两个版本就移位了。同事登录的是另一个账号，页面上多出一行权限提示，整个 DOM 往下挪了一截。
改完发过去，这次卡在第四步。脚本里写死了下载目录，同事重装过系统，桌面搬到了 D 盘。
三次之后，团队里开始互相提醒，发流程的时候附一句「先装这几个东西」。再后来就没人愿意把自己写的流程给别人用了，自己也不敢动，因为不知道哪台机器上能跑。
这件事的根子不在流程写得好不好，在于流程跑在哪台机器上。那台机器就是 RPA执行节点。执行节点和流程资产这两样不理顺，流程写得再漂亮也只是长在个人电脑里的一段录像。
节点要解决的是三件事
先说清楚 RPA执行节点存在的意义，免得把它想得太玄。它要解决的就三件。
第一件，运行环境在哪台机器上，这件事得写下来。每条流程都得有一个明确的落地位置，是某台固定机器，还是调度器分派出来的执行实例。以前靠口头约定，现在应该是配置里的一行。
第二件，流程跑在哪台机器上，那台机器跑之前得是什么样。浏览器版本、系统版本、分辨率、字体、时区、登录态，这些都会直接影响页面渲染和元素位置。
第三件，流程出错了，在哪台机器上出的错，日志在哪儿。几台机器几十条流程的时候，这条决定你是十分钟定位还是折腾半天。
三件都是琐碎的，但省不掉。省掉之后的表现形式，就是开头那个「三个人跑出三种结果」。
本地节点和远程执行节点各管一段
这两个词经常被混着讲，其实是两种分工方式。
本地节点指流程跑在发起任务的那台电脑上，人坐在机器前面，流程在屏幕上一步一步走。远程执行节点指流程跑在数据中心或者另一台机器上，人不在这台机器前面。
本地节点适合三类活。调试新流程，出问题能立刻看到界面反应，元素位置不对当场就改。操作本机的桌面软件，有些客户端程序没法在服务器上跑。以及需要人盯着才能往下走的流程，比如弹窗要人点确认，或者要读本地的 U 盾。
远程执行节点适合另外三类。它不占人的机器，夜里跑批不耽误白天干活。多个人共用一个节点池的时候，任务可以排队，机器闲下来就接。它也是唯一撑得住「一套流程在多台机器上稳定跑」的做法，因为环境可以做成一模一样的。
容易出问题的是混着来。有些公司一开始所有流程都在本地跑，跑到几十条的时候发现没人说得清哪条流程依赖哪台机器的什么软件。后来改远程，远程又做不动，因为有几条流程天生要在人前跑。
比较稳的做法是先把边界划出来。哪些流程必须在本地跑，列一张清单，写清原因。剩下的全部上远程。清单上的流程也别放弃管，给它们单独一台专机，别跟日常办公机混用。
环境一致性，坑在想不到的地方
做 RPA执行节点最容易低估的一件事，是把「环境一致」理解成「装了同样的软件」。
真正让流程跑偏的，通常是下面这些。
浏览器版本。同一份流程，Chrome 从 125 升到 131，页面上的元素属性就可能变了。浏览器自动升级之后，某天早上全公司流程集体失灵，排查半天，发现是浏览器昨晚自己更了版本。
分辨率和缩放。元素坐标是按像素记的，1920 的机器装到 1440 的笔记本上，坐标全偏。Windows 显示缩放设成 125%，页面看起来没变，实际渲染出来的位置不一样。
字体。Linux 上没装中文字体的时候，文字宽度会变，一个固定宽度的按钮撑开了，旁边的按钮就跟着移位。
时区和系统语言。日期格式、货币格式、首字母语言都会影响页面显示。同一个页面，en-US 和 zh-CN 下按钮位置不一样是常事。
登录态和权限。测试环境的账号和生产账号菜单结构经常不一致，同一条流程在两边的页面上找的是不同的元素。
多显示器和主副屏顺序也会影响坐标。这类变量很少有人主动想到，出问题时更没人会往那边查。
把这些列出来会看到一条规律。环境一致性是个一长串需要逐个对齐的变量，没有一个开关能一次解决。对齐的办法只有一个，就是把节点做成不可变的镜像，用哪台都一样，而不是靠人记着「这台要装什么」。
浏览器和驱动版本要钉死
把浏览器和驱动单独拎出来说，因为这是自动化里最容易踩、也最难查的一类坑。
浏览器自动升级这件事，对普通用户是好事，对自动化是灾难。版本一变，页面 DOM 可能变，驱动和浏览器的兼容关系也可能变。Chrome 的 DevTools 协议版本跟浏览器版本是绑着的，新浏览器配老驱动，轻则一条警告，重则直接连不上。
做法上有两条。节点的浏览器版本固定，升级走人工流程，验证通过再统一推。驱动跟着浏览器一起固定，两个版本写在节点配置的同一个地方，不要分开记。
还有一条经验，同一条流程尽量只用一种浏览器。企业微信、Chrome、Edge、Firefox 各写一套选择器，维护成本直接翻倍。真需要跨浏览器，就在跑的时候指定浏览器，别让流程自己判断。
流程资产统一管理，做成能发布的
环境对齐了，流程本身还得管起来。流程资产统一管理的核心，是让一条流程有明确的版本、明确的依赖、明确的发布路径。
版本这件事很朴素，每次改动留一个记录，能回到任意一个历史版本。技术门槛不高，很多团队没做，原因是改流程的时候直接覆盖。等发现改坏了想回退，只能从头再录一遍。
依赖要做成显式的。流程用到了哪些系统、哪些接口、哪些文件、哪些本机软件，登记在流程自己的描述里。新人接手的时候看描述就知道要准备什么，不用靠问。
发布路径是把「开发」和「运行」分开。开发机上的流程是草稿，能改能试。发布到节点上的流程是版本，不能随便动。改完走一次回归，验证通过再发布。发布要有记录，谁在什么时候发了哪个版本。
这三件做到位，流程资产才算资产，不再是散落在各人电脑里的录像。
有个配套动作值得单独提一句，就是流程要能被打包带走。流程文件加上描述、依赖清单、关键截图，合成一个包。装到任何满足条件的节点上直接跑，不依赖开发机上留着什么历史。
节点健康检查，别等任务挂了才知道
节点是执行体，它挂了，上面的流程全停。健康的节点要有几种状态能被看见。
最基础的是活着没有，心跳。节点定时上报一次，超过阈值没上报就判为失联。这一条挡不住「进程还在但浏览器起不来」的情况，所以还要往下一层。
再下面是就绪度。节点上的浏览器能不能起，磁盘空间够不够，必要的本地软件在不在，这些在接任务之前查一遍。不就绪的节点直接摘出池子，不给它派活。
然后是执行结果。任务在节点上跑起来没有，是成功还是失败，失败在哪一步，日志落在哪。日志要在节点本地留一份，同时汇总到能查的地方，不然出了问题没法集中看。
最后是资源占用。内存涨了、CPU 长期占着、浏览器进程没退干净，这几种都会让节点慢慢变慢，最后变成任务跑一半卡死。定期重启比不停排查省事，很多团队最后都走向了固定周期重启这条路。
这几层做下来，节点从一个黑盒变成了能监控的东西。排查的时候先看节点状态，再看任务日志，顺序跟人查问题一样。
扩容之前先想清楚扩的是什么
任务排不开了就加节点，但加之前有几个问题得先想。
第一个，瓶颈在节点还是在业务系统。很多时候任务堆着，原因是某个系统的接口限流了，或者人工审核环节卡着。这时候加节点只是让更多任务一起排队等。
第二个，流程能不能并行。有些流程之间有依赖，前一个没跑完，后一个不能开始。这种情况下节点加到十台，执行的还是串行。
第三个，状态放在哪。流程跑到一半，状态存在节点内存里，节点一重启就没了。要能扩容，状态就得放到外面去，节点本身保持无状态。
这三个都想清楚了，扩容就只是加机器。节点用同一套镜像，配好凭据，挂在同一个调度器下面，完事。
反过来，如果这三个没想清楚，加机器只会让问题更难查。任务分散在更多机器上，偶尔失败，偶尔重跑，最后没人说得清哪一次的结果算数。
什么情况下别上
有几类情况，做节点这套东西的收益抵不过成本。
流程只有两三条，人就在公司旁边，桌面伸手就够。这时候搞节点池、镜像、调度、健康检查，是拿一套系统去解决一个手动启动的问题。跑不起来的时候还得先找机器在哪。
执行环境没法标准化。有些任务依赖特定硬件，或者依赖某个只能在某台电脑上打开的软件。这种情况远程执行节点做不了，只能老老实实本地跑，节点这套东西剩下的价值就只有统一管理。
团队只有一个人，而且这个人就是唯一的流程开发者。版本管理、发布流程、回归验证这三件事一个人做不划算，容易变成走过场，反而比不管更容易出错。
另外提醒一句，节点数量上去之后，一定要有一条清晰的归属记录。每条流程属于哪个节点、依赖什么、谁负责。不然半年以后没人说得清某条流程为什么只能在某台机器上跑。
把上面这些理顺，一套流程在多台机器上稳定跑这件事才算有底。剩下的就是加节点了。
延伸阅读