AI智能体（Agent）和机器人流程自动化（RPA）都在做自动执行，但两者的内核差别很大。RPA模拟人的键盘鼠标操作，把既定业务流程固化成一步步可重复的动作；Agent则依靠大模型理解任务目标，在每一步根据环境反馈决定下一步该做什么。一个更像严格执行标准作业程序的员工，一个更像能根据现场情况调整方案的协调者。真正有价值的项目，通常不是二选一，而是让Agent负责判断和拆解，让RPA负责稳定执行。
一、执行逻辑的本质差异：固定流程与目标驱动
RPA的执行逻辑建立在确定性流程之上。设计者通过录制或拖拽画布，明确每一步操作对象、输入值和等待条件。比如打开ERP系统、点击采购订单、输入供应商编号、导出Excel、发送邮件。流程中可以有条件分支和循环，但这些分支在设计期就已穷举，运行期不会有新的路径产生。这种确定性带来两个直接好处：一是结果可预期，适合财务、审计等强合规场景；二是部署简单，不需要训练模型，只需要保证界面元素稳定。
AI智能体的执行逻辑完全不同。它接受自然语言目标，例如把今天的供应商对账单整理成异常清单。Agent会先理解目标，把它拆成若干子任务：读取邮箱附件、从PDF提取表格、识别金额差异、生成汇总表。然后它根据可用工具列表选择合适的工具，执行后观察返回结果，再决定下一步。如果PDF解析失败，Agent可以尝试换用OCR工具；如果金额差异规则不明确，它可以先运行一个小样本并请求人工确认。这种目标驱动的循环让系统具备动态应对能力，但同时也带来不确定性：每一步都依赖模型推理，可能出现错误工具选择或幻觉。
从控制论角度看，RPA是开环或半闭环系统，偏差处理靠预设规则；Agent是带反馈的闭环系统，偏差处理靠模型推理。理解这一点，就能避免把Agent简单当作更聪明的RPA。
二、场景边界：哪些任务适合RPA，哪些适合Agent
判断一个任务该用RPA还是Agent，可以从四个维度看：规则清晰度、输入结构化程度、流程稳定性和异常频率。
- RPA更适合：操作路径固定、数据字段明确、系统界面长期不变、需要频繁重复执行。例如每日从银行下载流水、批量查重发票、向多个部门汇总Excel报表。这些场景中，RPA的执行成本低、速度快，且每一步都能留下操作日志。
- Agent更适合：任务目标明确但步骤不固定、输入包含大量非结构化内容、需要跨多系统判断和工具组合。例如合同条款初审、客服工单分类并给出处理建议、根据邮件内容判断是否触发退款流程。这些场景中，规则很难穷举，Agent的语义理解能力可以显著降低人工筛选量。
- 二者结合的场景：流程大部分步骤固定，但个别节点需要智能判断。比如订单处理中，正常订单走RPA自动录入，异常订单由Agent读取备注、判断原因并决定是转入人工还是自动补录。这种混合模式在真实业务中占比最高。
不要用单一标准做绝对划分。一个任务开始时可能适合RPA，当业务规则频繁变化或输入格式开始多样化，再引入Agent处理变化部分。反过来，如果一个Agent方案里大量操作是固定点击，不如把那部分下沉给RPA，降低模型调用成本和响应延迟。
三、融合架构：让Agent做决策，RPA做执行
融合的关键不是技术叠加，而是把决策权与执行权分离。比较稳定的架构有三层：感知层负责把PDF、图片、邮件、OCR结果转成结构化信息；决策层由Agent根据目标和当前状态生成计划；执行层由RPA或API完成具体操作。RPA在这里被封装成一个或一组工具，暴露标准接口给Agent调用。
下面是一段简化的Agent调用RPA工具的代码示例，展示了工具注册、规划循环和结果反馈：
import json
def run_agent_task(goal, tools):
context = {"goal": goal, "history": [], "max_steps": 8}
for step in range(context["max_steps"]):
plan = llm_plan(context)
action = plan.get("action")
if action == "call_rpa":
flow_id = plan["flow_id"]
params = plan.get("params", {})
result = tools["rpa_run"](flow_id, params)
context["history"].append({
"action": action,
"flow_id": flow_id,
"result": result
})
if result.get("status") == "failed":
context["last_error"] = result.get("message")
elif action == "call_api":
result = tools["api_call"](plan["api_name"], plan.get("params", {}))
context["history"].append({"action": action, "result": result})
elif action == "finish":
return result
return {"status": "pending", "message": "达到最大步数，需要人工介入"}
这段代码里的rpa_run工具把RPA流程封装成普通函数，输入流程ID和参数，返回结构化结果。Agent根据历史记录决定调用哪个流程，并在失败时拿到错误信息重新规划。需要注意的是，RPA流程本身要设计成原子操作，比如只做下载文件或只做数据录入，不要把一个包含大量判断的复杂流程塞给Agent。
另一种融合方式是在RPA设计器里嵌入AI节点。流程执行到某个步骤时，调用大模型对当前数据进行分类、提取或异常判断，然后把判断结果作为变量继续执行后续步骤。这种方式适合已有大量RPA流程、不希望推翻重来的团队。缺点是AI节点的输入输出需要严格定义，调试相对复杂。
四、落地时的关键点与常见误区
实际项目中，融合架构的失败很少来自模型能力不足，更多来自工程化设计缺失。第一个关键点是任务粒度。给Agent调用的RPA流程必须参数清晰、耗时可控、结果可验证。例如将发票查重设计为check_invoice(invoice_number)，返回{status: "duplicate", matched_id: "INV20240101"}，而不是让Agent自己去打开网页逐项操作。
第二个关键点是幂等与回执。Agent可能在超时后重新发起同一个RPA任务，如果RPA流程不具备幂等性，可能出现重复录入或重复发送。解决方案是每次调用生成唯一run_id，RPA端在执行前先检查该run_id是否已经完成，完成则直接返回结果。
第三个关键点是权限与审计。RPA通常使用高权限账号执行跨系统操作，Agent的决策过程又具有不确定性，必须把两层日志关联起来。至少要记录每次调用的目标、计划、工具名、参数摘要、结果状态和耗时。出现问题时，能快速判断是模型规划错误，还是RPA执行错误，或者业务系统数据本身有问题。
常见误区有三个：一是试图用Agent完全替代RPA，导致高频固定操作被大模型低效处理，成本高且不稳定；二是把RPA流程做得过粗，Agent只能调用一两个超大流程，失去动态编排意义；三是忽略人工兜底。Agent在低置信度、高风险操作或连续失败时应当转入人工确认，而不是继续自动重试。融合方案的目标不是无人值守，而是把人工从重复操作中解放出来，把注意力放在异常判断上。
RPA与Agent的关系会在很长一段时间内保持互补。RPA继续负责与老旧系统、封闭界面打交道，Agent负责理解目标、编排工具和处理变化。能把两者的边界和接口设计清楚，自动化项目才可能从演示进入真实生产。
