企业智能体与RPA的边界与协同：同一流程里怎么分工-软盟

内容摘要

当企业RPA已覆盖财务对账、订单录入等确定性流程，是否还要上智能体？文章指出，问题不是二选一，而是决策与执行的分工。RPA负责脚本化执行，智能体处理规则写不完的判断。通过任务契约、权限控制和验收指标，把判断交给智能体、执行留给RPA，才能避免重复投入。你的流程里，哪一段该交给谁？

— 软盟官方网站文章导读

当一家企业已经把RPA跑在财务对账、订单录入和报表搬运上，接下来最典型的纠结不是"要不要用AI"，而是"再上一套智能体，会不会和现有自动化重复投入"。这个问题问错了方向。RPA与AI智能体不是同一层能力的替代关系，而是决策与执行的分工关系；真正需要判断的，是哪一段流程适合脚本化执行，哪一段适合交给智能体做判断与协调，以及两者交接处如何治理。

边界：先看触发方式，再看规则确定性

把两者放在一张表里对齐，比讨论"谁更先进"更有用。边界的分水岭通常出现在触发方式与规则确定性上：RPA由定时、事件或固定入口触发，沿着预设路径执行；智能体由目标触发，自行拆解步骤并选择工具。

对比维度	RPA（脚本化执行）	AI智能体
任务触发	定时、事件、固定入口	目标驱动，可自主拆解步骤
规则确定性	依赖明确规则和稳定的界面或接口	允许模糊输入和规则未覆盖的情况
异常处理	未预设的异常通常中断，靠不断增加分支兜底	可识别异常并尝试替代路径，但结果不稳定
系统对接	界面模拟、API、文件交换	通过工具调用、API和知识库协同，一般不直接操作界面
输出特征	结果确定、可重复	概率性输出，需要校验和护栏
运维成本	上游界面或流程变更时脚本易失效，分支膨胀	依赖提示、工具和模型版本管理，评测与护栏成本较高

这张表也解释了为什么"用智能体全面替换RPA"往往不成立：执行层需要的是确定性和可重复性，而不是灵活性。反过来，把判断类工作硬写成RPA分支，也会随着例外增多而维护成本失控。合理的做法是保留RPA作为执行层，在它不擅长的判断和协调环节补上智能体。

用四个流程特征判断该用谁

选型判断不应按部门划分，也不应按技术偏好划分，而应按流程特征划分。可以先用四个问题快速定位：输入是否结构化、分支和例外是否可穷举、结果是否容易校验、上游系统是否稳定。

流程特征	主要承担者	典型场景
输入结构化、分支少、结果可校验	RPA	数据录入、系统间对账、报表搬运、批量通知
输入非结构化、需要理解	智能体判断 + RPA执行	邮件与PDF信息抽取后回填业务系统
分支多、例外多、规则写不完	智能体处理，必要时人工兜底	客诉分级、异常订单处置、合同条款初筛
需要对话或生成内容	智能体	内部知识问答、工单摘要、回复草稿

判断时还要看一个隐性条件：错误成本。金额小、可回滚、可抽检的环节可以放心让智能体先跑；一旦涉及资金支付、主数据变更或对外承诺，就需要把人工复核节点设计进去，而不是指望模型自己收敛。

同一流程里的三种分工模式

模式一：前置判断，后置执行

智能体负责读懂请求、分类、提取关键字段，输出结构化的任务指令，RPA按指令完成系统操作。这种模式对既有RPA资产改动最小，适合先做单点验证，例如把客服工单分派给对应系统流程。

模式二：前段采集，后段分析

RPA按既定节奏从多个系统收集和整理数据，智能体消费这些结构化数据，做异常检测、趋势归纳和说明生成。它适合已经有稳定数据搬运自动化的企业，把"采集"升级为"采集加解读"。

模式三：并行分流，统一编排

定型任务继续走RPA，非定型任务交给智能体，两者由统一的任务队列和路由规则管理。这种模式治理要求最高，但如果企业内部流程差异大，它比强行统一成一条路径更现实。

无论哪种模式，交接处都应有一份显式的任务契约，而不是让智能体直接去点击界面。任务契约把"要做什么"和"怎么做"分开：

{
  "task_id": "invoice-20240513-001",
  "action": "create_voucher",
  "params": {"amount": 12800, "vendor_code": "V-1023"},
  "idempotency_key": "invoice-20240513-001",
  "callback": "task_result_queue",
  "requires_human_review": false
}

参数结构化、幂等键去重、回执可追踪，这三件事决定了混合编排是否可维护。智能体只负责生成这样的任务单，执行由RPA或接口层完成，出错时也能明确是哪一层的问题。

治理重点：权限、复核点与可回放审计

混合编排上线后，风险往往不在模型能力，而在权限与流程边界。

权限最小化：RPA执行账号只拥有完成该任务所需的操作权限，智能体不直接持有高权限凭证，通过任务队列间接调用。
人工复核节点：对金额或数量超过阈值、涉及对外发送、变更主数据、模型置信度偏低的请求，强制进入人工确认。
幂等与去重：同一任务重复触发时不得产生重复记录，这是自动化流程最常见的隐性事故来源。
审计与回放：每一次判断的输入、输出、调用的工具和最终执行结果都要留痕，能够在事后还原完整链路。
版本与变更管理：RPA脚本、提示模板、工具接口都应纳入版本管理，避免出现离职后无人能维护的"野良机器人"。

上线验收：用可回退的指标验证分工

验收不应只看"节省了多少人力"，而要看分工是否稳定、可回退。建议在试点流程上同时观察以下维度，具体阈值由业务方根据风险偏好定义。

指标	说明	验收方向
端到端成功率	无需人工介入即可完成的占比	在试点范围内稳定达标
异常拦截率	被识别并转人工的高风险任务占比	不漏放高风险任务
人工介入率	人工处理环节占总量的比例	较上线前下降，但不以归零为目标
结果准确率	抽样复核后的判断与字段正确率	达到业务可接受阈值
变更响应时间	上游界面或规则变化后的恢复时长	不依赖个别人员
回退能力	关闭智能体后RPA是否可独立运行	保留降级路径

影子运行是降低风险的有效方式：让智能体在真实数据上给出建议，但不直接执行，与人工结果比对一段时间后再逐步放开。这种做法比直接切换更容易被业务部门接受。

落地路线与常见误区

推进顺序可以概括为四步：先盘点现有RPA流程，按上述四个特征分类；再挑一条判断密集、错误成本可控的流程做混合试点；然后建立任务契约和统一队列，把试点经验沉淀为编排规范；最后才考虑横向扩展，并把权限、复核和审计纳入日常运维。

常见误区有三个。第一，把智能体当作RPA的替代者，导致执行环节失去确定性。第二，让智能体直接操作界面，短期见效快，长期无法治理。第三，只核算人力节省，忽略异常处理和复核带来的新工作量。

回到最初的问题：已有RPA还要不要上智能体，取决于流程里是否存在靠规则写不完的判断。如果有，合理的答案不是二选一，而是把判断交给智能体、把执行留给RPA、把关键决策留给人，并用任务契约、权限控制和验收指标把这条分工线固定下来。这样，选型讨论就从"上不上"变成了"哪一段交给谁"，投入是否重复也就有了可验证的答案。