Agent 和 RPA 有什么区别
RPA 按写死的界面路径搬运数据，AI Agent 按企业规则理解信息、作出判断并调用系统完成动作。两者不是替代关系，路径固定的高频搬运仍适合 RPA；关键动作由人工确认后生效。
本文说明两类技术的适用边界，不构成选型结论；具体方案取决于企业现有流程、系统条件与验收标准。
30 秒看懂
Agent 和 RPA 的区别在哪六个维度？
两者都能操作系统完成动作，差别在于「靠什么知道该做什么」。
| 对比维度 | RPA | AI Agent |
|---|---|---|
| 设计前提 | 界面与流程固定不变 | 信息形态与处理路径会变化 |
| 输入 | 结构化字段、确定位置的元素 | 消息、图片、表格、单据等非结构化信息 |
| 判断依据 | 人工预先写死的脚本 | 企业定义的规则，配合语义理解 |
| 遇到没见过的输入 | 报错停下，等人工改脚本 | 按规则判断，不确定时转人工 |
| 界面或流程改版后 | 需要重新录制或改写脚本 | 不依赖界面位置，通常不受影响 |
| 适合的任务 | 高频、路径完全固定的数据搬运 | 有规则但输入形态多样的执行工作 |
第三行是分界线。RPA 的判断藏在脚本里，改一次要动代码；Agent 的判断以规则形式独立存在，业务人员可以查看和调整。判断依据是否显式，决定了这套东西能不能随业务一起长大。
RPA 被淘汰了吗？
没有。它和 Agent 解决的不是同一个问题，现实里往往是配合使用。
RPA 仍然适合
路径完全固定的高频搬运
界面长期不变、每天执行成千上万次、步骤完全确定的任务，用 RPA 成本低、速度快、行为可预测。这类场景没有必要换成 Agent。
Agent 更适合
需要先判断再动手的工作
输入来自聊天消息、图片或多种格式的单据，判断依据有规则但写不成固定路径，还需要跨系统完成一整套动作——这是 RPA 吃力、Agent 顺手的地方。
两者怎么配合
Agent 判断，RPA 执行
常见组合是 Agent 负责看懂输入并作出判断，再把结果交给 RPA 跑完固定动作；或者 RPA 负责采集，把结构化结果交给 Agent 判断。选型看任务，不看概念新旧。
从 RPA 迁移到 Agent，需要重做什么？
如果已经在用 RPA，迁移不是推翻重来，但有五件事必须补齐。
规则要先写下来从代码到条文原先藏在脚本里的判断逻辑，需要显式表达成业务规则与阈值，让业务人员看得懂、改得动
输入要允许变化从定位到语义不再假设字段位置固定，改为按语义识别信息，这一步决定了它对格式变化的容忍度
异常要有人接从报错到转人工需要明确哪些情况停下、转给谁、由谁确认，而不是抛出一个只有技术能看懂的错误
系统接口要打通从界面到接口从模拟点击转为接口调用，稳定性与速度都会提升；没有接口的部分仍可保留原有操作路径
验收标准要重定从跑通到准确验收口径从「流程能跑完」改为「结果准确、可追溯、异常有出口」
已经跑顺的 RPA 流程不必推倒。务实的做法是把最容易因格式变化而失效的那一段先换掉，其余保留。
关于 Agent 与 RPA，哪些说法是误解？
误解Agent 会取代 RPA。
实际两者解决的不是同一个问题。路径固定的高频搬运，RPA 依然是更经济的选择；Agent 补的是输入不规整、需要判断的那一段。企业里通常两段都存在。
误解RPA 加一个大模型就是 Agent。
实际加一层模型只解决了「看懂输入」，没有解决「按企业规则判断」和「出错有人兜底」。判断依据是否显式、异常是否有出口，才是分界线，而不是有没有用上大模型。
误解自动化和 AI 是一回事。
实际自动化是把已经确定的路径重复执行；AI 处理的是路径本身不确定的情况。前者要求流程先固定下来，后者要求规则先写清楚——两者对企业的要求正好相反。
一项工作该用 RPA 还是 Agent？
拿一项具体工作逐条对照，落在哪边就选哪边。
- 输入每次都在同样的位置、同样的格式 → 优先考虑 RPA
- 输入形态经常变化，或来自聊天消息、图片、手写单据 → 优先考虑 Agent
- 处理路径完全固定、多年不变 → 优先考虑 RPA
- 需要先判断情况，再决定走哪条路 → 优先考虑 Agent
- 出错后必须有人确认才能继续 → Agent 的确认与留痕机制更贴合这类设计
- 现有 RPA 脚本经常因为界面改版而失效 → 可以先用 Agent 替换这一段
现实中一项工作往往两种都需要：Agent 负责看懂和判断，RPA 负责把固定动作跑完。不必二选一。
关于 Agent 与 RPA，还有哪些常被问到的问题？
AI Agent 和 RPA 的区别是不是就是有没有用大模型？
不是。用不用大模型只影响「能不能看懂不规整的输入」。真正的分界在于判断依据放在哪里、异常有没有出口：RPA 把判断写死在脚本里，遇到没见过的输入只能报错；Agent 把判断表达成业务规则，不确定时转人工。有没有大模型是表象，规则是否显式才是实质。
RPA 会被 AI Agent 替代吗？
不会整体替代。路径完全固定、界面多年不变、每天执行成千上万次的任务，RPA 成本更低、行为更可预测。被替代的是那些原本就不适合 RPA、却硬用 RPA 去做的场景——例如输入来自聊天消息、格式每次都不一样的工作。
已经在用 RPA 的企业要不要换成 Agent？
看现有的 RPA 是不是经常坏。如果脚本稳定运行多年、几乎不需要维护，没有换的必要。如果经常因为界面改版或输入格式变化而失效，维护成本已经超过收益，那部分流程适合用 Agent 重做。
Agent 一定要调用接口吗？还能不能操作界面？
接口优先，但不是必须。有接口时调用接口，速度和稳定性都更好；没有接口的部分，也可以保留原有的操作路径。区别在于 Agent 的处理逻辑不依赖界面元素的固定位置，因此界面小改版通常不会导致整体失效。
从 RPA 迁移到 Agent 要多久？
取决于要补齐的规则有多少，而不是代码量。原先藏在脚本里的判断需要被整理成业务人员看得懂的条文，异常出口需要和业务方约定清楚。规则清晰、接口齐备的流程，迁移通常比新建一条 RPA 流程更快。
RPA 和 Agent 可以同时用吗？
可以，而且这是常见的组合方式。Agent 负责理解输入与作出判断，把结果交给 RPA 执行固定动作；或者 RPA 负责采集数据，把结构化结果交给 Agent 判断。两者通过接口或任务队列衔接，各做各自擅长的一段。
哪种任务用 RPA 更划算？
输入位置与格式固定、处理路径完全确定、执行频次高、出错后果可控的任务。这类任务用 RPA 建设成本低、运行速度快，而且行为可预测，不需要引入判断与确认机制所带来的额外复杂度。
Agent 处理不了的输入会怎么样？
会停下来，而不是猜。规则未覆盖、信息缺失、多个来源互相冲突的情况，会被标记出来转给指定的人处理。这个「停下来」的机制是刻意设计的：宁可多问一句，也不让不确定的判断直接变成业务记录。
没有上过 RPA 的企业能直接上 Agent 吗？
可以。RPA 不是前置条件。直接上 Agent 反而少了一层需要拆掉的旧脚本，但要求企业能把现有的判断依据讲清楚——这一步无论走 RPA 还是 Agent 都绕不过去。
Agent 和自动化脚本有什么本质区别？
脚本处理的是「已经知道该怎么做」的情况，Agent 处理的是「知道判断标准、但每次情况不完全一样」的情况。脚本把人的决定固化成代码，Agent 把人的决定表达成规则并保留人在关键节点的确认权。
先看这项工作是怎么做的，再决定用什么。
把一项正在用人工或脚本处理的工作讲清楚：输入从哪来、什么情况算异常、出错谁确认。我们先判断它属于路径固定还是需要判断，再谈具体方案。