1.4 从 RPA 到智能体：自动化为什么换代
1.4 从 RPA 到智能体：自动化为什么换代
本节摘要：让机器替人操作软件，RPA 已经做了二十年，为什么还需要智能体？本节讲清 RPA 的"规则录制"与智能体的"目标驱动"是两代自动化范式，给出各自的适用边界与一份选型判断清单——结论不是谁取代谁，而是按任务的确定性分家。
最初做办公自动化的那批工具，思路很朴素：把人的操作录下来，回放。点哪个按钮、填哪个输入框、按什么顺序，全部固化成脚本。这套思路（行业里叫 RPA，机器人流程自动化）到今天仍在财务对账、数据搬运、批量录入这些岗位上大规模服役，而且干得不错。那智能体凭什么进场？
一次典型的 RPA 断裂
RPA 脚本的命门在于它按位置记忆世界。看一个典型的网页操作脚本片段：
# RPA 风格：按选择器坐标/路径操作，路径一变即断裂 def export_report(): browser.click("#menu-report") # 依赖菜单 id 不变 browser.click("li:nth-child(3) a") # 依赖"导出"排第三位 browser.select("#format", "xlsx") # 依赖下拉项文案不变 browser.click("button.primary") wait_download("/downloads/report.xlsx") # 依赖默认下载目录
这套代码在页面改版当天集体失效：菜单换了 id、"导出"挪到了第四位、下载目录被安全策略改掉——任何一个变动都让脚本当场断裂，而维护者要逐行排查是哪一处。据行业里反复验证的经验，RPA 项目的年度维护成本常常达到初始建设的一半以上，全花在追着界面变化补窟窿上。
智能体处理同一个任务时，记忆的不是位置而是意图：
目标: 从报表系统导出上月的销售报表（xlsx 格式） 思考: 页面变了，先找报表入口。 行动: read_page() # 读当前页面结构 观察: 页面有"数据中心"导航和"报表中心"入口 思考: 报表中心应当是入口。 行动: click(text="报表中心") 观察: 出现报表列表与筛选栏，含"导出 Excel"按钮 思考: 目标达成路径找到，继续。
界面怎么改版，只要"导出报表"这个意图在页面上仍可达成，智能体就能重新找到路径。代价是每次执行都要"看一遍页面再想"，慢且贵。两代范式的本质区别就一句话：RPA 把过程固化，智能体只固定目标。
两代范式的系统对照
| 维度 | RPA | 智能体 |
|---|---|---|
| 驱动方式 | 录制的固定步骤 | 目标 + 现场理解 |
| 界面变化 | 断裂，需人工修脚本 | 多数可自行适应 |
| 执行速度与成本 | 毫秒级，边际成本近零 | 秒到分钟级，每步消耗模型调用 |
| 结果确定性 | 完全确定 | 概率性，需评测与护栏 |
| 处理例外 | 没录制过的=不会 | 可尝试新路径，也可能尝试出错 |
| 审计友好度 | 高（步骤即日志） | 需专门记录决策轨迹 |
| 适用任务 | 高频、稳定、规则明确 | 多变、含判断、长尾例外多 |
注意"结果确定性"这一行：财务清算这类任务，错一分钱都不行，概率性输出是硬伤——这是 RPA 至今统治这类场景的根本原因，不是技术怀旧。
选型判断清单
接到自动化需求，按顺序问四个问题：
- 任务步骤是否完全确定？ 完全确定且界面稳定，RPA 更快更省，别犹豫。
- 输入是否标准化？ 输入格式五花八门（不同供应商的发票模板、不同写法的邮件），需要"理解"环节，智能体或"模型 + RPA"混合。
- 例外频率多高？ 例外多于两成，维护 RPA 例外分支的成本会吞掉收益。
- 出错的代价多大？ 代价不可逆（打款、删库、对外发布），无论选谁都要加人工审核位。
实践里存活率最高的形态是混合：模型负责"看懂"（解析五花八门的输入、判断该走哪条流程），RPA 负责稳定执行已被确认的操作序列。模型当大脑，RPA 当一双便宜且稳定的手——这个分工本身就是第 2 章工具调用思想的直接应用：工具不必是花哨的 API，一个可靠的旧脚本就是好工具。
⚠️ 常见坑：用智能体重写所有 RPA 流程。有团队把已经跑了三年、稳定运行的对账脚本推倒重来换成模型驱动，结果换来不确定性、更高的单次成本和一轮新的评测负担。自动化的第一原则是稳，已有的稳定资产应当被智能体调用，而不是被替代。
常见问题
问：界面高度稳定、任务单一的场景，智能体还有优势吗？
答：几乎没有。智能体的价值随"变化"与"例外"增长。一个每天固定导出报表的岗位，RPA 脚本三行搞定的事，没必要引入概率性组件。
问：混合方案里，模型判断错了怎么办？
答：和所有智能体一样——靠护栏。判断错误的兜底是"置信度低就转人工"，这是第 7 章护栏三道闸的核心议题之一。
问：两个团队能共用一套工具吗？
答：应该共用。智能体调用的工具（查库存、建工单）和 RPA 操作的界面，背后是同一批业务系统。工具层设计得好，两代自动化可以共享同一套地基。
本节要点回顾
- 两代范式：RPA 固化过程，断在界面变化；智能体固定目标，能适应变化但慢且贵。
- 确定性是分水岭：结果必须分毫不差的任务归 RPA，含理解与判断的任务才轮到智能体。
- 最优解常是混合：模型负责理解与判断，RPA 或脚本负责稳定执行，工具层统一。
- 别为换而换：稳定运行的自动化资产是资源不是包袱，智能体的正确用法是调用它。
到此，第一章把"差距"讲完了：模型会什么（1.2）、不会什么（1.3）、以及为什么必须用新范式补（1.4）。下一章进入补短的第一站——给模型装上双手。
成本账：换代的经济逻辑
选型争论绕不开成本，把账摊开看会更清醒。RPA 的成本曲线是前期重、后期飘：录制与调试脚本的人力集中投入，运行期边际成本趋近于零，但维护成本随界面改版不定期脉冲式出现。智能体的成本曲线是前期轻、后期匀：搭建快，但每次执行都消耗模型调用与时间，任务量越大总成本越高。两条曲线存在交点——任务量小或界面频繁变化的场景，智能体的总持有成本反而更低；任务量巨大且界面稳定的场景，RPA 的零边际成本无可撼动。
还有一笔隐性账：例外处理的人力。RPA 的例外走人工通道，例外率一高，"自动化"就退化成"半自动化加一个盯着的人工岗"；智能体的例外多数能自己绕过去，人力岗可以撤掉或缩编。评估时把这笔人力也算进去，很多原本"不划算"的智能体方案会翻盘。
一个渐进迁移的路线图
对已有大量 RPA 资产的组织，推倒重来既不经济也不必要。更务实的迁移分三步走：第一步，旁路试点——挑一个例外率高、维护痛的流程，让智能体作为"例外处理员"并行运行，RPA 主流程遇到例外时转给智能体试解，解不了再回人工；第二步，理解层替换——把 RPA 流程里靠固定模板解析输入的环节（读发票、读邮件）换成模型解析，流程骨架不动；第三步，意图层迁移——对界面变化最敏感的流程，改为"智能体定路径、脚本执行动作"的混合形态。三步走完，团队既保住了稳定资产的收益，又积累了智能体工程的经验，组织能力的迁移与技术的迁移同步发生。