事情的开始是这样的，客户有对某个网站登录之后进行小规模数据获取的需求，本质上是做一个例行的每日任务脚本来进行自己公司的数据监控。但是问题来了，这个网站为了防止爬虫抓取，是没法用selenium来做自动操作的，里面对webdriver的检测做的很好。
所以花了一两周的时间，做了一个PIL + opencv + pyUserInput的小脚本。用PIL来截屏，用opencv中的模板匹配来寻找目标元素在屏幕中的位置，然后用pyUserInput去点击或者操作键盘来完成操作。
写这个脚本的时候，还特意写了模拟人类的鼠标轨迹的函数，以及给每个键盘操作都加了一些抬起按下的随机值，也没事让鼠标在屏幕上瞎划拉一下。肉眼难辨真假，基本上可以完成这个数据采集任务了。
后来发现，原来这个套路，叫RPA机器人，已经有一些A轮B轮公司出来了。目标也是一些基本的页面操作流程，能够被自动化。其实IT产业发展到现在，数据孤岛一直是一个恒久的问题，而且目前看不到能够在未来被解决的可能，除非选择RPA。
因为，现有的企业信息化，不可能只靠一个产品来支撑，而采购或者自研的每个产品，都是有独立的数据体系，并且很少愿意把自己的控制接口开放出来。就算都是自家的产品，各部门都愿意开放出来接口，也很难保证这个接口是吻合业务需要的，最近几年大公司火热的中台化，也最终容易发现中台提供的支撑能力不足，接口不满足快速变化的业务奇葩需求，中台设计太考验抽象业务的能力了。而凡是太考验个人能力的高级工作任务，在大组织中都很难实现。
那既然接口无法吻合业务需要，直接开数据库的读写权限得了？想要什么自己查，想做什么服务自己基于数据做API就好，但是这听起来也不是一个好的路子，理解一个接口协议本身就需要一定的学习成本了，更何况理解系统底层数据结构了。而且这个接口在后端服务中还能被各种流程保护，做各种安全检查，不熟悉系统的人瞎写瞎读底层数据，问题很大。
所以这么看，RPA几乎是唯一一条打破数据孤岛的路了。
因为，RPA是几乎没有学习成本的，你会用这个系统，你就能自动化这个系统。编程都不需要会。道理是简单的，就是user interface 也是一个interface嘛，而且这个接口的安全性是最好的，学习成本是最低的。因为这个接口处于系统的最上层，有着最自然的调用方法。
但是，RPA的问题在于，他无法像调用接口那样快速且大规模，一个接口会在500ms内就返回需要的数据，而且可以大规模调用，qps上百轻松。但是用RPA机器人来控制浏览器里的一个网页的操作，总要是要花个几秒钟才能完成一个获取数据的任务。
这个时间花在哪里了？调用接口发送一条微信消息（假如是语音），只要1s钟上传录好的语音文件就可以了。人，或者RPA机器人，是需要按住发送键，然后朗读或者播放语音（内放）才能发送出去，60s的语音就需要60多秒。大量的时间是浪费在界面操作本身上的，操作完界面，才成功调用原本系统的接口去获取数据。而且这个操作界面的速度是很难大幅度提升的。
不过也幸好只是有十倍到几十倍之间的差异。在目前这个算力过剩的年代，靠加机器就可以了。最近花了600元买了个win10电脑，胜任微信聊天，网页浏览，基本办公完全没有问题。十台电脑构建一个集群，能做的任务肯定比一个月薪6k的白领干的多多了（仅指标准化无脑工作任务）
理想中的RPA技术架构应该是怎样的？
首先可以明确的就是，RPA一定是一个手与眼联动的系统，手就是鼠标，键盘，剪切板，还有外设控制（比如打印机）。眼就是截屏，元素识别，ocr等。手眼联动，再做一个任务管理队列来调度，监督机器人任务的执行，做点断点重启，任务调度之类。也就差不多了。
之前走过一段时间弯路。就是沉迷图像处理中了。我总想让脚本自己能够发现一个页面上哪些是按钮，哪些是背景区域，背景色是什么，在视觉上对界面进行理解，能够生成类似DOMTree一样的结构。但是水平不够没研究出来，当然后来发现感觉不是很有必要。因为我们大部分的RPA需求，其实都是定制化需求，能够快速的定制化一下，也就差不多了。比如录屏操作流程并自动记录点击过哪些元素。这些做一些辅助操作工具更好。
计算机并不需要理解界面本身的结构，而是知道要操作的元素在哪里。毕竟就算了理解了界面的结构，还是需要人工来指定点击动作这个任务的。这部分的代码也省不了。
RPA机器人，好的架构可能是做好底层手眼框架之后，用低代码来定义任务。然后对于专门的广泛使用的界面，比如微信，专门再做一个中间层，然后对上提供更高抽象级别的接口，也就够了。用不着太追求所谓智能。
技术上遇到的一些困难点
其实应该没有什么理论的困难点。以前做游戏外挂和自动化测试的人估计很早就弄明白了。只是我水平有限在做的时候会有一些工程上的难点。比如说，用PIL来做截屏，并做模板查找，这个0.5s就可以完成，在一般的业务中是足够用的。但是如果是ocr的话，就要再花0.5-1秒的时间。如果对界面中的文字的感知能力超过1s，很多良好的体验就无法实现了。比如说，用户在操作微信的时候，点击一个好友，RPA可以马上识别点击的是谁，并把此人的详细资料在旁边的界面上展现，这是个很酷很有用的功能。但是我在mac上，这个过程长达4秒，0.5秒可以勉强称之为流畅，而4秒就不可用了。
目前找到的优化方向是windows直接走win32Api截屏，可以做到20ms一次，mac下也有类似pyobjc的实现来实现几十毫秒级别的截屏，然后尽量少IO到硬盘上，直接在内存中进行ocr处理，chineseocr_lite提供了本地的web接口，直接传递图片的base64，本地传数据没有网络IO开销，看着可能能行。
另外ocr本身的效果还需要定向训练。飞桨ocr和chineseocr_lite都有一些生僻字无法识别。而最好系统的识别准确率能够接近百分之百，由于界面上的字体基本都是恒定的，所以专项优化下应该能行。
什么是良好的体验的RPA机器人？
首先，支持人机协作，单纯的人不够自动化，单纯的机器不够灵活。所以一定是个人机结合的，比如说微信聊天，标准化问题机器回复，个性化问题人来回复。比如数据收集，结构化数据好模式识别的机器自动收集，需要人来理解的数据人来收集。
第二，有尽量统一而低调的交互界面。人机协作时候的人机交互界面的统一性，是指随着业务的变化，我的人机交互界面不用发生变化。比如数据收集，我要收集的数据变了，但是我的人机协作的UI应该不变，或者说，我要增加一个功能，可以给客服人员进行沟通方向的提示，这时候尽量都不要改UI。这样可以快速灵活的响应业务变化。要不然难道变个业务需求，还要改个前端再给排个期的，黄花菜都凉了。
在这部分，我觉得类似slack，或者IM类似的体验比较好。好像一个全知全能的业务leader，在旁边盯着你的电脑屏幕，然后把他给你的指导，或者让你干的事情，都在旁边的小界面里实时展现着。无非是机器给人发消息，和人给机器发消息而已，天然就很像IM
第三，高度抽象的对外接口，可以方便灵活的定制，任务是有变化的，代码只要描述任务本身就好。比如抓取任务，有类似selenium那样的接口就很棒了，一小时的开发量就可以定义好一个任务。
第四，好部署，RPA机器人一定是大量跑在各种端上的，安卓，廉价的win，mac之类，所以一定要方便部署，拷个文件就直接部署那种。幸好有docker。
RPA与企业信息化
这是最诱人的前景。当信息孤岛能够被RPA机器人解决的时候，初创企业就可以低成本的通过整合大量的免费软件或者云服务来实现内部的信息化，而非靠自己开发系统，开发高质量的内部信息系统，成本实在是太高了，而开发团队大了以后，部门墙带来的数据孤岛问题一样也不少。
一旦数据孤岛问题解决了，原有无法收集数据的场景的数据能收集了，这时候带来的数据赋能对效率的提升是巨大的。一个商业组织本质上是一个感知终端用户行为并影响终端用户行为的信息系统，强化了感知能力的系统，才是一个具备智能性的系统。
其实互联网+在这五年的发展并不是太好，并不是数据促动业务本身的问题，也不是精细化运营带不来好的效果，而是就是数据收集成本太高，和协调一线人员做任务，执行服务SOP太难。眼睛感知不到，手管理不到，自然这个系统也是没有脑子的。
所谓，让人真正兴奋的RPA机器人不应该只是点点网页，简单的一个自动化的效率提升工具而已，而应该是一个在真人旁边进行伴随的，像一个助理一样的产品，并一边做助理一边监督和规范真实员工执行时候的SOP，一边低成本的收集数据到数据中心，并通过数据中心的意见反向影响这个真实一线员工的行为，让他的行为体现整体商业组织的智能性。
就好比，真人客服记不住每个服务对象的购买记录之类，但是电脑记得住，并且能够告知客服今天该与谁沟通，能够命中复购周期。
这时候原有互联网的那些数据分析的方法论才真的能发挥价值，谁越早掌握这一套，谁越能赢。
网友评论