关于 AI 智能体和 RPA 的关系，常见两种极端说法：一种认为大模型来了，RPA 就该被淘汰；另一种认为 RPA 更稳定可靠，智能体只是噱头。两种说法都忽略了重点——它们解决的是两类不同的问题，真正的难点在边界怎么划。
先分清两类任务
把企业里的工作按"是否需要理解"划分，界限会清楚很多。
需要理解的环节：客户这句话到底在问什么、这封邮件是投诉还是咨询、这份合同的条款有没有风险、这条数据异常该不该报警。这类任务的共同点是输入不规范、判断依赖上下文、规则难以穷举。它们适合交给智能体。
需要执行的环节：把数据从 A 系统填进 B 系统、按固定规则生成报表、批量下载对账单、在指定时间提交单据。这类任务的共同点是规则明确、步骤固定、重复频率高。它们适合交给 RPA。
关键在于：真实业务流程中，这两类环节交替出现。一个完整的售后处理流程可能是：理解客户诉求（智能体）→ 查询订单与政策（智能体 + 接口）→ 在系统里创建退换单（RPA 或接口）→ 判断是否需要人工审批（智能体）→ 通知客户（智能体）。任何单一技术都覆盖不了全流程。
三种典型的组合模式
模式一：智能体在前，RPA 在后
这是最常见也最容易见效的组合。智能体负责理解与决策，把非结构化的输入转化成结构化指令，交给 RPA 执行。
例如处理客户邮件：智能体读邮件、判断意图、提取关键字段（订单号、问题类型、诉求），输出一份结构化任务；RPA 拿着这份任务去订单系统里查询、创建工单、发送通知。人只处理智能体标记为"不确定"的那部分。
模式二：RPA 在前，智能体在后
适用于数据分散、需要先汇总再分析的场景。RPA 负责从多个系统把数据抓取汇总，智能体负责从汇总结果里找异常、写分析、生成报告。
例如月度经营分析：RPA 从财务、销售、库存系统分别导出数据并合并成一张表；智能体读取这张表，识别异常波动，生成一份带结论的分析初稿，交给分析师修改确认。人的工作从"找数据、做表格"变成了"判断结论对不对"。
模式三：智能体作为调度层
当自动化流程变多之后，需要一个统一的入口来决定"这件事该走哪个流程"。这个调度角色适合由智能体承担：它理解用户意图，选择对应的自动化流程，必要时组合多个流程完成一个复杂任务。
例如员工在企业内部助手里说一句"帮我看看上个月的差旅报销有没有超标的"，智能体会判断需要调用哪个查询流程、用哪些参数、结果如何呈现，而不需要员工知道背后有几个机器人。
一个具体场景的拆解
以电商售后为例，完整的组合方式大致是这样：
- 客户在聊天窗口提出问题。智能体识别意图：是催发货、要退款、还是反馈质量问题。
- 如果是标准问题（比如查询物流），智能体直接调用订单接口取回状态并回复，无需人工。
- 如果需要操作（比如发起退款），智能体校验客户资格与订单状态，生成退款申请。
- RPA 在售后系统里提交这条申请，并按规则判断是否需要人工审批。
- 审批完成后，智能体生成回复话术通知客户，同时把整个处理过程写入工单记录。
在这个流程里，智能体没有去操作界面（那是 RPA 的事），RPA 也不去判断客户说了什么（那是智能体的事）。分工清晰，任何一环出问题都容易定位。
落地的推荐顺序
如果企业刚开始做，建议按这个顺序推进：
- 先做 RPA：规则明确的流程最容易量化收益，也最能建立内部信心。这个阶段的产出是"看得见的效率提升"。
- 再补智能体：当流程跑顺之后，会发现很多环节仍需要人工判断和录入。这时引入智能体处理非结构化输入，价值最明显。
- 最后做编排：当机器人数量和场景数量增长到一定程度，再考虑统一的调度层，避免各流程彼此孤立。
反过来，一上来就做"全能智能体"、试图覆盖所有场景的项目，通常难以收敛，也很难在早期拿出可验证的成果。
小结
智能体和 RPA 的关系不是替代，而是分工。判断一个环节该用哪种技术，问一个简单的问题就够：这个环节的核心难点是"想明白"还是"做稳定"。前者交给智能体，后者交给 RPA，把两者串起来的流程设计，才是决定项目成败的部分。
如果你们正在规划自动化项目，可以先画出目标流程，标出每一个环节属于哪一类，再看需要用哪些技术组件。这张图往往比任何技术选型讨论都更有价值。