Agent 和传统 RPA 差在哪？

结论前置：界面稳定、流程固定的活，传统 RPA 仍是好选择；页面多变、需要理解内容再动手的，智能体（Agent）更合适。核心差异一句话——RPA 认坐标，智能体认语义。

RPA 像背熟了路线的司机，每一步点哪里、输什么都是录好的，页面一改版就迷路；智能体像认路的乘客，看懂页面在说什么，再决定点什么。类比失效之处在于，智能体的「看懂」依赖模型，偶有看走眼的时候，稳定场景反而不如背路线的靠谱。

一个认结构一个认坐标

RPA 的脚本绑定控件位置或固定选择器，好处是快而准，坏处是脆，目标网站改个按钮位置就得返工。智能体拿到的是页面的结构化描述和文本内容，靠理解定位目标，容忍一定程度的布局变化。豆包、智谱清言等模型驱动的浏览器智能体，走的正是语义理解路线。

出错时的自我修正能力

RPA 遇到意外弹窗就卡住，除非脚本里预先写了处理分支；智能体能读懂弹窗在说什么，多数情况自行关掉或绕开。这份纠错能力是理解带来的，但也是双刃面：它可能自作主张走偏，所以关键动作仍要加约束，见Agent 的安全边界怎么划？一次划清。

部署方式和运行环境

RPA 常部署在办公电脑或专门的服务器上，模拟真人操作界面，账号体系沿用现成的；智能体更多跑在云端服务里，既可走界面也可走接口，接口优先时的取舍见浏览器操作和 API 调用差在哪？。执行环境是否隔离，风险差别很大，见沙箱执行和直连执行有什么区别？

怎么搭配着用

两者不是二选一：稳定环节保留 RPA 脚本，多变环节交给智能体；或让智能体做总调度，把录好的 RPA 当成它的一个工具调用。选择留人把关的位置同样适用于两者，见人工在环和全自动有什么区别？各自的适合场景。

Agent 与 RPA 对照表

• 页面稳定选 RPA，页面多变选智能体
• RPA 靠坐标与选择器，智能体靠语义理解
• RPA 意外即卡住，智能体多数能自行绕过
• 混搭用法：智能体调度，RPA 当工具

一句话记住：界面会变，选型要跟着变化承受力走。

能力组合的方式还影响架构选择：需要多个执行体配合时见单 Agent 和多 Agent 差在哪？。把 RPA 脚本纳入智能体的工具箱，是许多团队平滑过渡的务实做法：老脚本继续跑稳定环节，新需求由智能体消化。

两条路线的学习曲线也不同：RPA 的门槛在录脚本和写选择器，工具链成熟，资料多；智能体的门槛在提示词设计和流程理解，工具链还在快速变化。存量脚本多的团队不必急着重写，让智能体接管新需求、老脚本自然退役，是最平稳的节奏。评估页面变化风险时有个实用指标：过去半年这个页面的改版次数，改版频繁的系统，脚本维护成本会吞掉自动化省下的时间，这种场景基本不用犹豫。另外注意授权差异：RPA 模拟真人操作，账号是真实账号；智能体走接口时用的是应用授权，两者的权限边界和审计要求不一样，接入前先和系统管理方确认。把页面变化的耐受度当成选型的第一问，后面的问题都会简单很多。

换个问法再问Agent与RPA三句

• RPA 会被智能体淘汰吗？：短期不会，超高确定性的流程里脚本更快更省，两者按场景分工。
• 智能体操作界面会不会更慢？：通常慢一些，理解需要时间，换来的是对变化的耐受力。
• 老 RPA 团队转型难吗？：流程梳理经验直接可复用，补的是模型调用与提示词设计这些新件。