简介:这份PPT聚焦AI人工智能与RPA机器人流程自动化,可作为RPA概念入门、企业案例分析与行业趋势分享的演示素材,适合技术团队、业务管理者及培训讲师快速建立认知框架。文档共包含1个pptx文件,压缩包大小约1.27MB,共11页,版式简洁,以图文和排比形式组织内容,涵盖RPA公司发展历程、自研X5内核在速度与稳定性上的优势、售前技术支持流程、政府招商引资场景以及移动支付与互联网+发展趋势等典型模块。读者可从中了解RPA如何替代重复劳动、提升效率,以及RPA与AI结合后在复杂决策与开放平台战略中的延伸应用。通过浏览这份演示文稿,学习者能快速梳理RPA的应用边界与落地路径,理解RPA在金融、政务、互联网等行业的典型实践,节省自行搜索和整理资料的时间。目前已有867人学习下载,适合用于内部培训、课件优化或方案素材参考。
1. 先说结论:AI+RPA不是概念替换,是给重复劳动装了一套自动驾驶
你有没有见过这样的场景:业务员每天登录五六个后台,把订单导出、清洗、比对、再录进另一个系统,一干就是一上午。AI人工智能和RPA机器人流程自动化这两件事凑到一起,就是为了把这种“规则清晰但步骤繁琐”的活儿接过去。这份PPT资料最实在的地方,是它没有停在概念层,而是把RPA的能力层次、AI介入的方式、流程拆解的顺序都串成了能直接照做的路线。准备人工智能大作业的学生、想转RPA工程师的从业者、负责企业自动化选型的人,都能拿它当第一份实战地图。
2. 先把RPA的底摸清:从规则自动化到AI Agent协作,认清四个能力层
2.1 从“点击模拟”到“目标驱动”:RPA能力分层的四个台阶
很多新手拿到RPA工具的第一反应就是开录制功能,把鼠标键盘操作录一遍,以为这就完事了。这个认知恰恰是项目翻车的起点。常见做法是把RPA能力粗暴分成四层:第一层是人工手动操作,不算自动化;第二层是录制回放式的键鼠模拟,适合临时任务,生成的选择器和固定坐标一换环境就废;第三层是结构化流程自动化,靠元素选择器、数据表、条件判断和循环来编排,生产环境里跑的大多数RPA其实都在这一层;第四层才是智能流程自动化,流程里嵌入了OCR识别、语义判断甚至大模型决策。
我一般会建议初学者先别急着拖组件,先把手上的流程按这个分层对号入座。分辨方法很简单:如果操作步骤能用“如果A成立就做B,循环N次”这样的规则完整描述,那就是第三层的问题,不需要AI;只有遇到“这张图片里有没有异常”“这段留言是什么意图”“这封邮件该分给谁”这种规则说不清的问题,才需要上第四层。资料里提到的组件编排思路,本质上也是在第三层打底座,再在特定节点接上层AI能力。
这个分层还有一个实际用途:想面RPA工程师岗位的话,面试官经常拿“你们项目为什么需要AI介入、不介入行不行”来考察你,能一句话说清层级的候选人通常比背一堆组件名的人更分得清需求边界。
2.2 AI和RPA的分工边界:AI负责看和想,RPA负责点、读、写、发
把AI硬塞进RPA流程的每一步,是另一个极端。正确的分工应该是:AI负责处理非结构化信息,比如票据上的文字、用户留言的情绪、图片里的物体;RPA负责执行结构化动作,比如打开程序、读取单元格、点击按钮、发送邮件。AI的输出必须变成一份确定的指令(通常是JSON或结构化文本),RPA再根据这份指令走下一步,两边才算接上。
举一个实际例子。某电商后台每天有大量买家留言,需要判断哪些留言属于“要求拦截发货”,再对命中订单执行拦截操作。留言是自然语言,用规则枚举关键词会漏,让RPA去逐句理解也不现实。常见做法是:RPA先把留言批量采集下来,调大模型接口做意图分类,返回“是/否拦截+置信度”,置信度超过阈值的,RPA再去后台点击拦截按钮。整套流程里AI只做判断,动手的事全交给RPA组件。
这里有个血泪经验:大模型再能说,本质还是鹦鹉学舌式的模式补全,决策层必须有校验。我一般会要求AI返回结果里强制带confidence字段,低于0.85的统统转人工确认队列,不要让它直接驱动RPA执行,否则一次幻觉判错就把流程带沟里了。
3. 把流程拆成五段来落地:组件编排、参数传递与一个完整实例
3.1 五段式流程框架:识别、编排、参数、兜底、回退
资料里把一条RPA流程拆成五段,这个框架我后来做项目一直在用。先看整张表,每一段对应一组明确的组件职责。
| 段落 | 职责定位 | 常用组件/机制 | 常见误区 |
|---|---|---|---|
| 目标识别 | 确认流程入口和操作对象 | 窗口/元素选择器、页面标题匹配 | 用固定坐标代替选择器 |
| 组件编排 | 把步骤串成可执行的顺序 | 顺序容器、条件判断、循环、子流程 | 一个流程塞几百个步骤不拆块 |
| 参数传递 | 在步骤与子流程间交换数据 | 变量、参数表、全局变量、数据表 | 把单元格内容当数字直接用 |
| 异常兜底 | 处理流程运行中的意外情况 | 异常捕获、重试机制、超时设置 | 不做兜底,挂了才去查日志 |
| 人机回退 | 把机器判断不了的交回给人 | 人工确认弹窗、待办队列、消息通知 | 全自动硬跑,没人监管 |
识别段最容易被忽略。新手总以为打开窗口这个动作“肯定没问题”,但窗口标题变了、按钮换了个位置,选择器就失效了,所以识别段要做的第一件事是确认“对象是否存在”,而不是默认它在。编排段的核心是给流程分层,把稳定的主流程和易变的子流程分开,页面改版时只动一个子流程模块。参数段负责把数据在步骤之间传顺。异常兜底和人机回退是上生产环境的前提,缺了这两段,流程就只能在有人盯着的电脑上跑。
3.2 实战示例:Excel对账差异检测+邮件通知的完整配置
下面这个例子是资料里流程图的典型场景,我按自己在某公司实施过的版本细化了一遍。需求是:每天从系统导出对账单,和本地主数据表的订单金额比对,把差异订单筛选出来发邮件给财务。
| 步骤 | 组件/操作 | 关键参数设置 | 说明 |
|---|---|---|---|
| 1 | 打开Excel工作簿 | 文件路径参数化,超时时间30秒 | 别用绝对路径写死“D:\data\对账.xlsx”,用变量 |
| 2 | 读取主数据表 | 指定Sheet和区域,如A1:C500 | 给明确范围,不要全表扫描 |
| 3 | 读取对账表 | 同上,记录行数到变量rowCount | 行数用于后面的循环次数 |
| 4 | 循环逐行比对 | 循环变量i从1到rowCount,步长1 | 在循环体里做差值计算 |
| 5 | 条件判断 | 判断金额差的绝对值是否大于0.01 | 浮点误差在财务里不能简单用“等于”比 |
| 6 | 写入差异表 | 把差异行追加到新Sheet | 记得先判断目标Sheet是否存在 |
| 7 | 发送邮件 | SMTP服务器、收件人列表、附件路径 | 附件路径必须用上一步实际生成的文件名 |
| 8 | 关闭工作簿 | 保存方式选“另存为”还是“覆盖保存” | 一定要做关闭失败的兜底 |
参数设置里最容易翻车的是第5步。Excel里单元格读出来的值默认是文本,如果直接拿它减另一个单元格的值,要么报类型错误,要么得到不对的结果。我一般会在读取后先做一步类型转换,再进入循环。第4步的循环次数如果从表里读,要小心空行,读到的rowCount可能比实际数据行多,所以要处理“空行跳过”。
3.3 参数传递与三种等待策略:别再用固定sleep扛一切
参数传递这块,资料里用了不少篇幅强调作用域,我在做项目时也确实验证过这个坑。变量作用域分三类:局部变量只在当前流程块里有效,适合临时存储中间结果;全局变量在整个流程里共享,适合存文件路径、账号这类贯穿全程的数据;会话变量则用于跨机器同步,在分布式编排时才需要。
| 类型 | 作用范围 | 典型用途 | 失效场景 |
|---|---|---|---|
| 局部变量 | 当前步骤块 | 循环计数器、临时拼接字符串 | 子流程里读不到 |
| 全局变量 | 整个流程 | 文件路径、登录账号、公共配置 | 并发运行时互相覆盖 |
| 会话变量 | 单次运行会话 | 任务批次号、Token | 系统重启后丢失 |
等待策略是另一个大坑。新手习惯在每一步后面加一个固定等待,比如“等待5秒”,本地跑刚好能过,换一台慢一点的机器就超时。正确的做法是显式等待元素出现,而不是sleep固定时长。组件里一般都有“等待元素出现/可点击”的配置,设置超时时间为30秒,每1秒检查一次,比写死等待时间稳定得多。只有极少数场景,比如等待外部系统异步处理完成,才需要用固定等待,而且要把等待时间参数化,方便上线后调。
注意:三种等待策略的优先级是“显式等待元素状态 > 等待数据条件满足 > 固定sleep”,固定sleep是最后手段,不是默认选项。
4. AI怎么挂进RPA流程:OCR识别、语义分类与大模型兜底的三条接法
4.1 接法A:OCR端点识别,把图片里的文字变成RPA能用的字段
最朴素的接法是OCR。场景是发票、截图、扫码枪无法覆盖的图片信息。常见做法是RPA先截取目标区域图片,保存到临时目录,然后调OCR服务识别,把识别结果按行拆成字典结构返回,RPA再拿字段去做后续判断。
import requests import json # 读取RPA传入的截图路径,调用OCR服务 def ocr_recognize(image_path, ocr_url="http://localhost:8000/ocr"): with open(image_path, "rb") as f: resp = requests.post(ocr_url, files={"image": f}, timeout=30) if resp.status_code != 200: raise RuntimeError(f"OCR service error: {resp.status_code}") data = resp.json() # 返回 {text: "...", blocks: [...]} lines = [b["text"] for b in data.get("blocks", [])] return lines这段代码做的事情是把图片文件送到本地OCR服务,30秒内拿不到结果就抛异常。返回的blocks列表里每一项是一段识别出的文本块,顺序按图像从上到下排列。后面的RPA流程拿到这个列表后,可以按关键词过滤,比如只保留含“金额”“订单号”的行,再做字段抽取。参数说明:ocr_url指向本地服务时用localhost就可以了,如果OCR服务部署在另一台机器,要改成它的局域网IP;timeout不建议超过60秒,识别慢的机器宁可做异步回调也不要死等。
4.2 接法B:用大模型做语义分类,让不确定的判断有置信度
语义分类场景比OCR更常见,比如留言分类、工单分派、舆情分级。RPA把文本内容采集下来,调大模型接口,让模型返回结构化JSON,再根据JSON里的结论决定走哪个分支。
import requests import json def llm_classify(text, llm_url="http://localhost:9000/v1/chat/completions"): prompt = f""" 判断以下用户留言是否需要拦截发货,只输出JSON: {{"need_block": true/false, "confidence": 0.0-1.0, "reason": "简要原因"}} 留言内容:{text} """ payload = { "model": "qwen2.5:7b", # 本地模型名称 "messages": [{"role": "user", "content": prompt}], "temperature": 0, # 分类任务必须设0,关闭随机性 "max_tokens": 300, # 避免回复过长截断JSON "response_format": {"type": "json_object"} } resp = requests.post(llm_url, json=payload, timeout=45) result = json.loads(resp.json()["choices"][0]["message"]["content"]) return result这段代码的设计核心是两点:temperature设为0,模型输出几乎不带随机性,同一个输入每次结果一致,这是RPA流程可复现的基础;response_format强制JSON输出,省去RPA端解析字符串的麻烦。调用失败时,比如超时或者返回内容不是合法JSON,我一般会做三次重试,重试间隔按2秒、5秒、10秒递增,三次都失败就把该条记录写入人工队列。
4.3 接法C:AI Agent编排多个RPA机器人,多AI协作处理跨系统任务
第三种接法层级更高,AI Agent不负责某个步骤,而是负责拆解任务和调度多个RPA机器人。比如用户给Agent一个目标:“把本月所有异常订单整理成报告发给管理层”,Agent先识别出子任务:从订单系统采集数据、从财务系统取对账表、执行差异分析、生成PDF、发送邮件,然后分别调用对应的RPA流程去执行。
| 接法 | 输入类型 | 开发量 | 判断能力 | 适用场景 |
|---|---|---|---|---|
| OCR接法 | 图片/截图 | 低 | 弱(只负责文字提取) | 票据识别、截图数据录入 |
| LLM分类接法 | 文本 | 中 | 中(能理解语义但有幻觉) | 工单分类、留言判断、风险预警 |
| Agent编排接法 | 自然语言目标 | 高 | 强(能拆解和决策) | 跨系统综合报表、复杂任务指挥 |
需要提醒的是,Agent编排目前还不适合关键生产环节,我见过不少把编排跑挂了的情况,原因大多是Agent拆解出的子任务顺序和现实系统有冲突,或者是某个RPA流程执行失败后Agent没有及时切换备选方案。我的建议是:先从前两种接法把AI能力验证清楚,再考虑上Agent编排,不要一上来就追求全自动。
5. 上线前避坑:RPA项目最常见的五个翻车点与排查思路
5.1 元素选择器频繁失效:页面一改,流程就断
现象:RPA流程运行两周后突然在某个点击步骤报“找不到元素”,完全相同的脚本前一天还在跑。
原因:页面改版导致元素的class、id或XPath变化,选择器失去了锚点。这是RPA最普遍的生产事故。
解决:不要在组件里写死单一条目的选择器。常见做法是给关键元素配置多个备选选择器,例如优先用id,找不到再用name,再不行用文本内容匹配,同时把选择器集中放配置文件里,页面改了不用翻几十个步骤去改代码,只动配置。
5.2 流程在自己机器跑得好好的,换一台电脑就罢工
现象:开发机运行零失误,部署到服务器或其他同事电脑上,启动就报错。
原因:环境差异,包括屏幕分辨率不同导致坐标偏移、输入法状态不同导致中文输入异常、Excel版本不同导致COM组件行为不一致、杀毒软件拦截进程。
解决:上线前准备环境检查清单,至少有四项:目标程序版本一致、显示缩放比例设为100%、所有路径改为网络共享路径或UNC路径、在无人值守模式下关闭屏幕保护与自动锁屏。碰到“本地好好的换机就挂”的问题,先从这四条逐项排查。
5.3 固定等待引发的偶发超时
现象:流程偶尔在某一步停住,重跑一遍又好了,让人摸不着头脑。
原因:使用了固定等待,操作执行时上一环节的数据还没加载完。系统响应速度有波动,固定时间无法覆盖高峰时段的慢响应。
解决:把固定等待全部替换为“等待元素出现/可点击”,超时时间设为30秒。如果等待超过10秒仍失败,再捕获取当前界面截图和DOM状态,方便看到底卡在哪一层。
5.4 中文乱码与换行丢失
现象:从网页表格复制到Excel或数据库后,中文显示成乱码,或者多行文本变成一行。
原因:源系统编码是UTF-8,接收端默认GBK或ANSI,两边没对齐;网页里的换行符是<br>标签,RPA读取的却是纯文本,换行信息丢失。
解决:数据传输环节统一转成UTF-8,写入Excel时显式指定单元格文本格式;对<br>标签,在做数据清洗时替换为\n,不要等写入后再处理。排查思路是先确认乱码是发生在“采集时”还是“写入时”,给每个数据节点前后都打一次编码标记。
5.5 无人值守凌晨跑挂了,没人发现
现象:定时任务在凌晨3点执行,中途异常退出,第二天早上才从日志里发现昨晚任务白跑了。
原因:异常兜底只做了一部分,弹窗关闭、重试、失败通知都没配置。流程一旦卡在没有人的弹窗界面上,就变成了黑洞。
解决:全局异常处理器做三件事:第一,把异常截图存档;第二,尝试关闭异常弹窗并记录弹窗标题;第三,发送失败通知到企业微信或邮件。最后再判断是否需要人工介入处理。
| 排查主题 | 现象 | 优先排查项 |
|---|---|---|
| 选择器失效 | 找不到元素 | 页面版本、备选选择器 |
| 环境差异 | 换机就挂 | 分辨率、缩放、输入法、路径 |
| 偶发超时 | 重试即过 | 固定等待、元素等待 |
| 中文乱码 | 写入后乱码 | 编码格式、换行符 |
| 无人值守失败 | 次日才发现 | 异常捕获、失败通知 |
6. 验证与交付:日志埋点、成功率指标和灰度上线技巧
流程写完能跑,和能上生产是两回事。我习惯在交付前给流程做一套“体检”,核心就三个指标:执行成功率(成功次数/总执行次数)、平均耗时趋势、异常恢复率(自动恢复次数/异常总次数)。给它配一张执行记录表,每次运行都往里写流程ID、开始时间、结束时间、结果状态、失败步骤和错误信息。没有这张表,流程一跑挂就只能对着黑匣子猜。
日志埋点有一个很实用的技巧:在关键数据节点记录输入输出的哈希值,比如对读取到的订单行计算MD5,写日志时只记哈希不记原始内容,既避开了敏感数据泄露的问题,又能快速判断两次运行的数据变化点。做AI演示或者项目答辩时,把这些运行记录表和AI判断的命中样例截图放上去,说服力比贴十页流程设计图都强。
灰度上线也有固定套路。先让流程在影子模式下跑一周,也就是只读数据、只写临时表、不触发真实业务动作,统计识别成功率和判定准确率;确认无误后,再挑一个低频业务场景单点上线,持续观察两三天;最后才全量放开定时调度。每一步都保留回滚开关,出问题能一键切回人工流程。
从那以后,我每次交付RPA流程,都强制自己走一遍埋点、异常演练、灰度上线三步,哪怕只是给自己跑的小工具也不偷懒。这套习惯帮我挡住了不少半夜三点的故障电话,也让你手里的这份资料真正变得可落地。希望帮到你。
本文还有配套的精品资源,点击获取