RPA厂商有哪些这个问题几乎每个刚接触流程自动化的团队都会问一遍。我一开始也以为这就是个查名单的活儿把官网翻一遍、列个表就完事结果真到选型阶段才发现同样一句支持网页自动化有的产品能做到拖拽五分钟出一个流程有的要写一堆选择器还三天两头掉元素同样一个Excel数据处理有的内置几十个现成组件有的得自己封装Python脚本。国内公认的头部玩家大概五家但谁适合你跟你做什么场景、团队里有没有专职RPA工程师、预算走哪个口径关系大得多。这篇我就按自己这些年做项目、陪客户做POC的实际经验,把这五家挨个拆开讲顺带把选型时最容易被忽略的几个坑说透不管你是刚入门还是已经准备上生产应该都能拿到点能直接用的东西。1. 比谁更强更要紧的事先把选型维度定下来很多人一上来就问哪家最强这个问题本身就没法回答。原因很简单RPA不是一个标准品它更像一套开发工具运行环境调度平台的组合不同厂商的产品形态差异极大有的偏重业务人员自助有的偏重IT集中管控。你拿一套适合财务共享中心的方案去跑电商运营后台大概率会骂娘反过来也一样。所以真正该做的第一件事是把评估维度先列清楚再去对号入座。我一般会把评估拆成下面这几块顺序基本就是重要性排序。评估维度具体看什么为什么重要开发门槛是否可视化拖拽、有没有录制、代码块支持程度决定谁能来做流程直接影响人力成本组件生态Excel、网页、桌面软件、数据库、邮件、文件等内置组件数量与开箱可用度决定你 80% 的常见活儿要不要自己造轮子稳定性元素定位方式、异常重试、断点续跑、日志与截图决定流程能不能在生产环境连续跑一年调度与管控控制台排班、队列、并发授权、权限分账决定能不能从个人小工具升级成部门级平台授权与成本计费口径、是否有免费版、AI能力是否额外收费决定三年期的总拥有成本而不是首年报价服务与生态社区活跃度、教程数量、原厂/渠道支持响应决定你遇到问题时要卡多久这里我要特别强调组件生态和稳定性这两项因为它们是最容易被演示视频骗过去的地方。销售演示的时候流程一定跑得漂漂亮亮因为那是为演示专门搭的环境网页结构固定、元素ID唯一、不弹验证码、不进风控。但真实业务里页面上多一个广告弹窗、网络慢半拍加载、日期控件换了皮肤流程就可能直接崩。我见过太多项目在POC阶段一片叫好上线两周后开始天天报错最后运维的人比开发的人还累。另一个容易被忽略的点是**谁来做流程**。这个问题决定了你对开发门槛的要求。如果流程主要由业务部门自己维护那可视化程度和组件的易用性就是第一位写代码的能力反而次要如果是IT部门集中开发、业务只提需求那你对代码扩展性、版本管理、Git集成的要求就会高很多。很多团队选型时只盯着功能清单忘了先回答使用者是谁结果买回来一套偏IT的工具给业务用最后闲置率惊人。还有一条经验别在选型阶段追求全都支持。任何一家头部厂商在宣传材料上都会写支持网页、桌面、Excel、数据库、OCR、AI差异不在有没有而在用起来顺不顺。真正的评估动作应该是拿出你自己最核心的三到五个真实流程让每家现场做一遍看谁的开发耗时最短、跑通率最高、出错时的提示最清楚。这比看一百页PPT都有用。2. 五家头部厂商的出身与产品定位各自在做什么生意国内RPA市场从2018年前后开始升温到现在能稳定接到中大型项目的厂商并不多。下面这五家是我在项目里实际接触或对比过的按我接触的频率排序讲。需要说明的是这里的产品细节以我实际使用和公开资料的印象为准具体版本功能还是以你咨询原厂时的演示为准产品迭代很快我讲的重点是它们各自的性格。2.1 影刀RPA把易用性做到极致的业务人员友好型影刀这两年在中小企业和电商圈子里声量很大核心原因就一个字顺。它的开发者界面是典型的积木式拖拽左侧组件区、中间画布、右侧属性面板逻辑上跟搭乐高差不多。我让完全没写过代码的运营同事上手大概半天就能独立做出一个抓取竞品价格写入Excel的流程这个上手速度在国内产品里确实靠前。它的组件库覆盖得很细尤其Excel数据处理和网页自动化这两块常用操作基本都有现成指令读取区域、写入单元格、筛选、去重、批量替换、循环工作簿网页那边有打开网页、点击元素、输入文本、抓取数据、等待元素出现、滚动加载。对做电商的人来说像批量改价、订单导出、后台批量上架这类活儿用它的组件拼一拼就能跑不太需要自己写脚本。但要注意一点影刀的易用是有代价的。当流程逻辑变复杂比如要处理多层嵌套的JSON、要对接内部系统的私有协议、要做复杂的条件分支和状态机积木式编排反而会显得笨重画布越拉越长维护起来眼睛疼。这种情况下就得靠内置的代码块Python来补而一旦开始大量写代码它相对专业开发型工具的优势就被拉平了。2.2 来也科技UiBot产品矩阵最完整的那一档来也的路线跟影刀不太一样它一开始就带着比较强的企业级平台思路产品线拉得很开设计器、执行机器人、控制台再加上对话机器人、文档处理、AI能力这些东西。UiBot早期靠免费社区版积累了大量开发者这个策略效果很明显我认识不少RPA工程师第一门手艺就是在UiBot社区版上练的。从开发体验看UiBot的设计器同样支持可视化拖拽和录制但在代码友好这条路上走得更远一些对有一定编程基础的人比较友好复杂逻辑写起来更顺。控制台那边对流程的集中管理、任务调度、权限划分做得相对完整适合那种一个部门几十个流程、需要统一运维的场景。它的典型客户偏政务、金融、大型国企这类组织这类客户的需求特点是流程数量多、合规要求高、需要跟既有系统深度集成、采购流程长。来也在这种场景下积累比较厚。对个人开发者或者小团队来说要注意它的商业版授权模式和中大型项目导向不一定是最省钱的选择。2.3 艺赛旗iS-RPA金融行业沉淀深的老牌选手艺赛旗做RPA比较早在金融行业的客户基础很扎实银行、证券、保险这些领域里的案例多。它的产品也是设计器、机器人、控制台三件套的经典架构另外在流程录制、界面元素识别这块有自己的一套积累。这家给我的印象是偏稳。金融行业的业务流程往往长、环节多、对准确性和审计追溯要求高所以艺赛旗在产品设计上会更强调流程的可控性、日志的完整性、异常的可追溯性而不是追求五分钟出一个流程的快感。如果你的场景是财务对账、报表归集、跨系统数据搬运这类要求严谨的活儿它的适配度是不错的。相对的它在中小企业和互联网场景里的声量没有影刀那么大社区教程的丰富程度也有差距。新手如果纯靠自己摸索可能会觉得上手的资料没那么现成这时候原厂或渠道的实施支持就比较关键。2.4 云扩科技Encoo产品化和云原生思路走得比较前云扩的技术路线里云原生和低代码是两个关键词。它的设计器、控制台、机器人这套组合在架构上比较强调云端协同对有多地部署、集中管控需求的团队比较友好。同时它也在低代码方向发力试图把RPA的能力跟更广泛的应用搭建结合起来。我在对比时的一个直观感受是云扩在产品打磨和界面现代感上做得不错控制台的可视化程度较高管理体验相对舒服。它在零售、电商、制造这些行业的落地方案也不少尤其是需要跟业务系统打通的场景。选它要注意的点跟前面类似不同厂商在组件丰富度上的差距主要体现在长尾场景。核心的Excel、网页、邮件、文件操作大家都有但如果你有特别偏门的需求比如某种老旧桌面客户端的操作、特殊的打印控件、非标的数据格式就要在POC阶段实际试一遍别只听介绍。2.5 弘玑Cyclone面向大型企业的全生命周期管理弘玑的定位很明确就是奔着大型企业去的强调RPA的全生命周期管理和AI能力的整合。产品体系同样覆盖设计、执行、调度、分析这些环节并且在流程挖掘、任务编排、AI组件这些方向上有布局。它的优势场景是那种流程数量庞大、需要跨部门协同、需要统一治理的超大型组织。在这类客户那里单纯的开发工具好不好用已经不够了更重要的是平台的治理能力谁能建流程、谁能发布、谁能看到运行数据、异常怎么分级处理、容量怎么分配。弘在这些管理维度上做得比较系统。对中小团队来说这类产品的重可能会成为负担功能多、配置项多、学习曲线相对长如果没有专职的RPA工程师或平台管理员用起来会有点浪费。顺便提两家可以一起放进对比清单的金智维在证券金融领域根基深实在智能在AIRPA的结合上比较有特色尤其是文档理解和智能决策相关的能力。如果你的行业属性强这两家值得额外看看。3. 真正的分水岭Excel、网页、电商这三类高频场景怎么选把厂商名字和定位过一遍之后接下来才是最硬的部分。因为所有人都会说我支持Excel我支持网页自动化差异全在细节里。我按实际使用频率最高的三类场景拆一下讲清楚每类场景下真正该看什么。3.1 Excel数据处理组件数量不等于好用Excel是RPA落地最广的场景没有之一。财务报表归集、订单数据清洗、多表合并、批量填表这些活儿几乎每家公司都有。评估这一项的时候别只看支不支持读写Excel要看下面这些点。第一是格式兼容。xlsx、xls、csv这几类都要能处理尤其要注意WPS的兼容情况——国内很多企业的办公套件是WPS如果你的工具在WPS环境下读写异常那基本等于废了一半。第二是是否依赖本机Office。有的方案是通过调用本机安装的Office程序来操作Excel好处是能跑宏、能用公式计算引擎坏处是机器上必须装Office、多流程并发时容易互相干扰有的是直接解析文件流不依赖本机Office速度快、并发友好但对宏和复杂公式的支持会打折扣。这两种路线没有绝对优劣要看你的场景。第三是大数据量的表现。几百行的表随便怎么都能跑但上万行、几十万行的时候不同工具的效率差异会非常明显。我踩过的一个坑是用循环逐行读取单元格的方式处理五万行数据跑了一个多小时还没完后来改成一次性读取整个区域转成数据结构再批量写回时间直接降到几十秒。这个坑跟工具无关但好的工具会提供区域读写这种批量组件逼着你少走弯路。第四是数据清洗类操作的完备度去重、分组、透视、条件筛选、字符串处理、日期格式转换这些是实打实天天要用的。列个清单让每家现场演示一遍谁的组件能少写脚本谁就赢。3.2 网页自动化元素定位才是稳定性的命门网页自动化是另一个高频场景也是最容易演示时惊艳、上线后崩溃的场景。核心矛盾在于网页是动态的你的流程是静态的。元素定位的方式主要有几类基于DOM结构的XPath/CSS选择器、基于元素属性的ID/名称定位、基于文本内容定位、基于图像识别的视觉定位。前两种精确但脆弱页面结构一改就失效后两种抗变化能力强但速度和准确率会下降。好的产品通常会提供多重定位策略允许你配置备用定位方式主定位失败时自动降级尝试这一点在评估时一定要问清楚。另一个关键点是等待机制。新手最容易犯的错是点击之后立刻找下一个元素结果页面还没加载出来就报错。成熟工具会提供等待元素出现、等待元素消失、等待页面加载完成、等待网络空闲这类指令并且支持超时配置。我个人的习惯是任何一个跨页面的动作之后都强制加一个等待元素可见宁可多等两秒也不要让它随机失败。还有iframe和弹窗的处理。很多后台系统把内容嵌在多层iframe里或者用弹窗做二次确认工具能不能方便地切换上下文、识别并关闭弹窗直接决定流程能不能跑通。这个环节在演示时经常被跳过但在真实系统里几乎百分之百会遇到。3.3 电商场景为什么最刁难工具电商运营后台的自动化几乎把前面所有的难点叠加在一起了页面元素变动频繁、有验证码和风控、有登录态和会话管理、有频率限制、有大量的图片和SKU数据要处理。像批量上架商品这种任务流程要走完登录、选类目、填标题、传图、设价格库存、提交审核这一长串动作中间任何一个元素定位失败整条流程就卡住。这类场景下我会重点看三件事。第一是登录态与会话保持。能不能复用已登录的浏览器会话、能不能处理登录后的滑块或验证码人工介入这直接决定了流程的可用性。第二是频率与异常控制。批量操作时能不能设置操作间隔、能不能在遇到限制时暂停并告警、能不能从失败的那一条继续跑而不是从头再来。第三是数据闭环。上架通常需要从Excel或数据库读商品数据处理完再把结果回写这条数据链路最好能在同一个流程里闭环完成而不是靠人工中转。这里我要说句实在话电商场景的自动化工具只占一半另一半是流程设计。再好的工具如果你不加异常处理、不做失败重试、不做日志记录它照样跑不稳。反过来哪怕工具一般只要流程设计得稳也能跑得不错。4. 授权模式和成本结构报价单上不会写的东西选型谈钱的时候最容易出现的误会就是把首年报价当成总成本。RPA的计费口径跟传统软件差别很大必须先把模型搞清楚。4.1 常见的三种计费口径第一种是按机器人/授权数收费也就是你能同时运行多少个自动化流程实例就买多少个授权。这种模式对流程数量多但并发需求低的场景比较友好。第二种是按用户数收费即多少个人可以使用设计器来开发流程。这种模式适合开发人员多但运行任务不密集的团队。第三种是平台资源包的组合基础平台一个价AI能力、OCR调用次数、存储空间这些按量另算。实际谈的时候几乎都是这几种模式的组合。所以你拿到报价单之后第一个要问的问题不是多少钱而是这个价格包含几个设计器账号、几个运行机器人、控制台是否单独收费、AI组件是否额外计费。成本项常见计费方式容易踩的坑设计器授权按账号数/年以为可以多人共用实际绑定账号运行机器人按并发数/年并发数不等于流程数排队会拖慢业务控制台部分厂商单独收费或分版本基础版功能受限调度能力被阉割AI能力按调用次数或单独模块POC时免费上量后成本陡增实施服务按人天复杂流程的实施费可能超过软件费培训与认证按人次认证不是必须但招聘时有用4.2 那些藏在后面的隐性成本我最想提醒的是维护成本。一个RPA流程上线不是终点而是起点。业务系统会升级、网页会改版、数据格式会变流程需要持续维护。行业里有个粗略的说法是一个流程每年的维护投入大致相当于它首次开发成本的二三成。如果你的流程数量是几十个那就是一个专职岗位的工作量。这笔账在选型时很少有人算但它真实存在。第二块是人员成本。RPA工程师这个岗位这几年需求一直在涨既要懂业务、又要会工具、还得能写点脚本处理异常招人并不容易。如果你的团队打算自建能力那培训投入和人员流失风险都要算进去。这也是为什么很多公司会选择厂商或渠道的实施服务用外部能力换时间。第三块是环境成本。运行RPA的机器、虚拟化资源、需要长期开着的客户端这些都有成本。有的流程必须跑在装有特定业务系统的机器上那就得专门准备环境不能随便塞进一台服务器了事。5. 上手难度与团队角色谁来做比用什么做更重要聊完成本回到人的问题。RPA这个领域有个很有意思的现象同一个工具有人说太简单了有人说根本用不起来。差别往往不在工具而在于用的人是谁、要解决什么问题。5.1 业务人员和RPA工程师需要的能力完全不同如果流程的使用者是业务人员比如运营、财务、HR自己维护一些日常小工具那你的核心诉求是低门槛可视化要彻底、组件要现成、报错提示要人话、调试要所见即所得。这类场景下影刀这类易用性导向的产品优势明显半天培训就能出活。业务人员做的流程通常不复杂也不需要复杂的调度够用就好。如果流程的使用者是专职RPA工程师服务的对象是全公司多个部门那诉求就变了需要代码扩展能力、需要版本管理和团队协作、需要完善的日志和监控、需要能对接各种系统。这时候平台的治理能力和扩展性就成了首位易用性反而排在后面。这两种诉求经常是冲突的。我见过最典型的失败案例是IT部门按技术先进性选了一套偏开发的平台结果业务部门根本用不起来最后所有需求都堆到IT那边排队三个月业务方直接放弃自己动手的念头。反过来也有选了极简易用的工具业务小流程跑得很欢但等到要做部门级平台、需要统一调度和权限管控时发现产品的管控能力跟不上只能推倒重来。我的建议是先明确主场景再选工具。如果短期内就是几个部门的小工具选易用性优先的如果一开始就规划成企业级平台选治理能力强的同时配一个专职的岗位来运营。别指望一套工具同时满足两端那基本不现实。5.2 一条我验证过的学习路线如果你是个人想入行或者想先把能力建起来我分享一条自己带人时用过的路线大概一个月能到能干活的程度。第一周选一款有免费社区版的产品社区版通常够学习和做小项目把官方的基础教程刷完重点是三件事变量和数据类型、条件与循环、异常处理。这三块是所有流程的地基。第二周专攻Excel和网页这两类组件各做三个小练习比如从网页抓取数据写入Excel和从Excel读数据批量填网页表单。做的时候刻意练元素定位把选择器、文本定位、图像定位都试一遍感受它们的差异。第三周开始接触真实场景把你自己日常重复度最高的一件事自动化掉。这一步的价值在于你会遇到真实的失败——页面变了、数据脏了、弹窗跳出来了解决这些问题的过程才是真正的能力积累。第四周学调度和日志把你的流程放到控制台上定时跑学会看日志定位问题、设计重试策略、做失败告警。走完这四步你就具备了基础的RPA工程能力。接下来就是靠项目堆经验尤其是异常处理和流程稳定性设计这两块只能在实战里长出来。6. 落到实处的选型判断一套我自己在用的决策逻辑前面把五家厂商和高频场景都过了一遍这里我把自己的判断逻辑整理出来你可以直接拿去对照。6.1 按场景和团队配置快速定位你的情况优先级最高的方向建议重点看电商/零售运营业务人员自己维护易用性、组件丰富、社区教程多影刀中小企业预算有限从零起步免费或低价入门、上手快影刀、来也社区版中大型企业多部门流程统一管控控制台、权限、调度能力来也、弘玑、云扩金融/政务审计与合规要求高稳定性、日志追溯、行业案例艺赛旗、来也、金智维已有技术团队想深度定制代码扩展、API开放、集成能力弘玑、云扩、来也文档处理、智能识别需求重AI组件、OCR、文档理解弘玑、实在智能、来也这张表只能帮你缩小范围最终还是要靠POC定胜负。6.2 POC阶段我必做的四件事第一用你自己的真实流程测别用厂商的演示案例。真实流程才暴露真实问题尤其是那些又长又啰嗦、中间还穿插人工判断的流程。第二故意制造异常。测的时候手动改一下页面结构、中途断一次网、把Excel文件锁住看流程报错时提示是否清楚、能不能自动恢复、日志里能不能定位到具体哪一步。这一步最能看出产品的成熟度。第三让未来的实际使用者来试。如果最终是业务人员维护就让他们自己动手做一遍你在旁边观察卡在哪里。他们说这个不好用的地方往往就是上线后最大的隐患。第四问清楚授权边界。并发数怎么算、控制台是否单独收费、AI调用是否限量、升级版本是否额外付费、离职员工的设计器账号能不能回收这些问题在签约前问清楚比在合同里扯皮强得多。最后分享一个我自己踩过的坑早期选型时我特别看重功能全不全后来发现真正影响项目成败的是原厂支持响应速度。一个流程卡住三天没人管业务方对RPA的信任就崩了。所以选型的时候不妨给每家的支持渠道发一个真问题看多久回、回得专不专业。这个动作花不了半天但信息量极大。如果你现在的场景是网页自动化和Excel数据处理这种高频任务居多我个人更倾向于先把易用性放在第一位因为这类流程变更多、维护频繁能自己快速改动比什么都重要。等到流程数量上来了、需要统一管了再考虑往平台化的方向升级也是个稳妥的路径。RPA这件事先跑起来再跑稳最后才是跑大。