it_fly的专栏

整个算法思路打个比方：各个Woker好比车库，不同的类型的RPA任务好比不同的车位（电瓶车位、小轿车车位，大巴车位），并为领导和客户预留了一些专用车位，最后专用车位根据运行状态在车库中动态分配，故此算法命名为“动态车位”-智能RPA任务调度算法。4) Master接受各种动态触发器发来的RPA任务，按照不同类型批量进行调度：根据各Worker当前使用资源以及最大可用资源进行动态调度，5）另外为手动调度的不同RPA程序预留相应的资源数量，最后剩余资源所在的Worker停止接受此类任务。

大多数原生 RPA 自动化都是基于 GUI 的，花点时间让大家了解一下，基于 GUI 的自动化，包括指示机器人通过 UI 与另一个程序通信，这类似于强迫两个相同母语的人用猜字谜的方式来进行交流。基于 GUI 的自动化终归是一种妥协，因为在底层总是有更有效的方法来执行相同的任务

尽管 RPA 提供了清晰的技术能力和为旧系统和流程注入活力的真正优势，但它并没有激发企业重新优化其业务流程——它实际上只是帮助企业更快地在公司内部转移数据，并且减少手工干预。此外，大多数已签署的“RPA”约定不是针对无人参与的流程的，而是针对机器人桌面自动化（RPA）部署的。参与 RDA 需要一个人机交互的循环来完成任务。这些约定并不是我们所发明的 RPA 的初始模型——它们是一群形形色色的脚本和宏，它们为凌乱的桌面应用程序和进程添加了一些附加功能，以维护原有的做事流程。当然，这通常会带来对劳动力需求的减少

数字员工领域模型分析

数字员工之“哑铃理论”

2.无头浏览器机器人：通过直接访问浏览器的dom元素，可以对无形的UI元素进行操作，此种机器人工作深入“肌肤”，在虚空中操作，属于盲打。此种机器人工作在“腠理”，一台电脑同时只能运行一个机器人，且容易被各种外在因素打断（如弹窗）；此种机器人工作在“脏腑”甚至“骨髓”，可以完全自由并发，不受外在的UI任何干扰。GUI机器人和无头浏览器机器人可以并称为前端机器人，前者有形，后者无形。后端机器人对第三方系统有一定的侵入性，执行效率相比前端机器人要高效的多。

这种设计方式有很大弊端：非常的低效和不稳定，比如不稳定的弹框问题，就会让人头痛不已难以解决、而且也难以复用如java等强大的技术生态、究其根本还是设计思路上出了问题：人类生活在物理世界，所以需要屏幕、键盘、鼠标等媒介来查看和操作虚拟世界的元素，但是机器人本身就存在于虚拟世界，何必要模拟人类去借助屏幕、键盘、鼠标来查看和操作界面呢，应该直接用自己的方式操纵，无头操作系统和无头浏览器才是地道的解决方案。无头系统通常通过网络连接控制，但也有部分无头系统的设备需要通过RS-232串行连接进行设备的管理。

笔者之前使用RPA工具-来也Uibot给公司人事开发了一款岗位薪酬爬虫程序，感觉这种工具还是是给不太懂开发的大众小白用的，不太灵活，也没有强大的技术栈做支撑，后来发现了谷歌的puppeteer技术，非常喜欢，感觉这才是程序员需要的开发工具，但puppeteer 只支持NodeJs,对于C++、Java、Python技术栈的我来说，感觉还是不够方便，再后来又遇到了PlayWright：Puppeteer团队跳槽到微软开发的同类技术，但除了Js还支持Java，Python和C#等多种语言。测试运行，一切OK。