LLM+RAG+RPA 企业级智能体架构落地：从知识检索到流程执行的全链路实践

关键词： RAG RPA融合、Agentic RPA、本地知识库自动化、大模型流程编排、企业智能体架构

一、为什么单独用RPA或LLM都不够？

去年给一个制造业客户做项目，他们有两个痛点特别典型：

痛点A： 产线设备报修了，工程师得先翻纸质手册、再查历史工单、最后才能判断故障原因。平均响应时间40分钟。

痛点B： 公司买了RPA做订单录入，但业务规则总在变，每次改流程都要找开发重新配置，IT部门快被业务拖垮了。

这两个问题暴露了一个事实：RPA擅长执行，但不擅长理解；LLM擅长理解，但不擅长执行。

单独用RPA，流程是死的，规则一变就崩溃。单独用LLM，它能告诉你"应该怎么做"，但真让它去ERP里点按钮、填表单，它干不了。

RAG+RPA的本质，就是让LLM先"查清楚"，再让RPA"干明白"。

二、RAG+RPA 架构拆解：三层协作模型

整个架构可以拆成三层，每层各司其职，通过API串联。

第一层：RAG 知识检索层

负责理解用户意图 和召回精准知识。

向量数据库：把企业内部文档（SOP、工单、产品手册）切成chunk，生成Embedding存入Milvus/Qdrant
重排序模型：初召回Top10，再用Cross-Encoder精排，确保给LLM的上下文最相关
查询改写：用户问"机器响了怎么办"，自动改写为"设备异常噪音故障排查流程"

关键代码片段（Embedding生成）：

复制代码

from sentence_transformers import SentenceTransformer

model = SentenceTransformer('BAAI/bge-large-zh-v1.5')
chunks = ["设备异常噪音排查：1.检查皮带张力...", "工单处理流程：第一步登录ERP..."]

embeddings = model.encode(chunks, normalize_embeddings=True)
# 存入向量库，后续RAG检索用

第二层：LLM 决策推理层

负责基于检索结果生成可执行指令。

这里不是让LLM直接生成代码，而是生成结构化任务描述（JSON格式），让下游RPA能解析执行。

Prompt设计核心：

复制代码

你是一个企业流程助手。请根据以下检索到的知识，判断用户请求对应的RPA流程：
[检索到的SOP文档片段]

用户请求："帮我提交一个产线A3区的设备报修单"
请输出JSON格式：
{
  "flow_name": "设备报修流程",
  "params": {
    "area": "A3",
    "type": "设备故障",
    "priority": "普通"
  },
  "next_action": "open_erp_repair_form"
}

关键点： LLM只负责"决策"，不直接操作UI，避免幻觉导致系统风险。

第三层：RPA 流程执行层

负责解析LLM指令并驱动真实业务系统。

RPA引擎接收JSON指令后，自动完成：

打开ERP系统 → 登录 → 导航到报修模块
按params填充表单字段
上传附件（如有）
提交并返回工单号

RPA流程伪代码：

复制代码

def execute_flow(flow_json):
    flow = load_flow_template(flow_json['flow_name'])
    for step in flow.steps:
        if step.type == 'ui_click':
            rpa.click(step.target, method='smart_locator')
        elif step.type == 'input':
            rpa.input(step.target, flow_json['params'][step.field])
        elif step.type == 'api_call':
            requests.post(step.endpoint, json=flow_json['params'])
    return rpa.get_result()

三、实战案例：智能客服工单自动处理

拿我之前做的项目举例，完整链路跑通后的效果：

场景： 客户通过企业微信发消息："我买的批次20250615A的货，质检报告有问题，要退货。"

Step 1：RAG检索

查询改写："批次退货流程 + 质检异常处理"
向量召回：《退货SOP v3.2》、《质检异常处理规范》
精排后Top3上下文送入LLM

Step 2：LLM决策

理解意图：退货申请 + 质检异常关联
判断需要执行：1.查订单 2.创建退货单 3.通知质检部门
输出结构化指令，包含3个子流程

Step 3：RPA执行

子流程1：登录OMS → 查批次20250615A → 确认订单状态
子流程2：打开退货系统 → 填充退货原因"质检异常" → 关联质检报告编号
子流程3：发送企业微信通知给质检主管

全程耗时： 从用户发消息到工单创建完成，2分15秒。原来人工处理平均25分钟。

四、技术选型与踩坑记录

向量数据库选型对比

方案	优势	劣势	适用场景
Milvus	分布式、亿级向量、社区活跃	部署较重	中大型企业
Qdrant	轻量、Rust性能高、易部署	生态稍弱	中小团队/私有化
PGVector	与PostgreSQL一体	百万级后性能下降	已有PG基础设施
阿里云向量检索	免运维、云原生	成本较高、数据出域顾虑	上云企业

我的建议： 如果客户要求内网离线部署，选Qdrant单机版；如果上云，直接用阿里云向量检索服务。

踩坑1：RAG检索不准，LLM乱决策

早期直接用Embedding召回，Top1经常跑偏。比如用户问"怎么退货"，召回的是"怎么换货"。

解决： 加了一层查询意图分类器（轻量BERT模型），先判断意图类别（退货/换货/维修/咨询），再在对应类别文档里做RAG，准确率从67%提到91%。

踩坑2：RPA元素定位失败导致流程中断

LLM生成的指令是对的，但RPA执行时网页改版了，按钮XPath变了，流程卡死。

解决： RPA层引入智能元素定位 ，支持多策略降级（XPath → CSS Selector → 图像匹配 → OCR文字定位），同时加异常重试机制，失败时自动截图+通知人工介入。

五、私有化部署方案（内网离线）

很多金融、制造业客户要求数据不出域，这套架构必须能离线跑。

最小化部署清单：

LLM：本地部署Qwen2.5-14B或DeepSeek-R1-32B（用vLLM加速推理）
RAG：Qdrant单机版 + BGE-M3 Embedding模型（本地推理）
RPA引擎：蓝印RPA（支持内网离线运行，无需连公网授权）
中间件：FastAPI做编排层，Redis做消息队列

架构图示意：

复制代码

用户请求 → FastAPI网关 → 意图分类 → RAG检索(Qdrant+BGE) 
                                          ↓
LLM决策(Qwen2.5-14B) ← 上下文组装 ← 向量召回
       ↓
JSON指令输出 → RPA引擎(蓝印RPA) → 业务系统操作
       ↓
结果返回 ← 异常处理/日志记录

蓝印RPA在私有化场景的优势：

单机授权，不依赖云端验证
支持EXE打包分发，交付给客户后零配置运行
元素定位支持本地智能生成，可根据生成结果选择合适稳定的元素路径

六、总结与展望

RAG+RPA不是简单的技术叠加，而是认知层+执行层的闭环。

RAG解决"知不知道"：让LLM有企业私有知识，不胡说
LLM解决"怎么决策"：理解复杂意图，输出结构化指令
RPA解决"怎么执行"：打通最后一公里，操作真实业务系统

2026年这个方向正在快速演进，下一步是Agentic RPA------RPA不再被动等指令，而是主动感知业务事件（如库存预警、订单异常），自动触发RAG查询+LLM决策+自主执行。