本文详解 RPA 架构设计中集成大模型的三种范式，以及 NLP、OCR 融合处理非结构化数据的完整管线，并给出 AI 自动化搭建能力的评估清单与分阶段落地路线。全文围绕架构分层、大模型编排、非结构化数据抽取、执行层稳定性与交付运维五个维度展开，附实际项目经验。
写这篇文章的起因很现实：上个月有个做财务共享的朋友找我吐槽，他们上一套自动化系统，光是处理供应商发来的五花八门的 PDF 发票、截图报销单、Excel 附件邮件，就搭进去两个人月。结构化数据好办，难的是这堆"长得都不一样"的非结构化数据。这其实是当下 RPA 落地里典型的深水区，也是这两年架构演进较快的方向------把大模型拉进流程编排层，让 NLP 和 OCR 不再只是外围工具，而是成为流程本身的感知器官。
一、RPA 架构正在从"录制回放"变成"感知-决策-执行"三段式
传统 RPA 的架构很直白：录一遍操作，存成步骤序列，机器照着重播。这种架构在页面不变、数据格式固定时很好用，但一旦遇上非结构化输入，整条链路就会脆断------因为你没办法对一个"每次长得都不一样"的发票截图录制回放。
所以近两年的架构设计，核心变化就一句话：把"感知"和"决策"从流程里拆出来，交给能处理不确定性的组件，RPA 自己只负责拿手的"确定性执行"。
一个能打的现代 RPA 架构，大致可以分成五层：
┌─────────────────────────────────────────┐
│ 交互层：可视化编排 / 自然语言搭建 / API触发 │
├─────────────────────────────────────────┤
│ 决策层：大模型编排（LLM Orchestration） │
│ - 意图理解 - 任务规划 - 异常归因 │
├─────────────────────────────────────────┤
│ 感知层：NLP / OCR / 视觉识别 │
│ - 文档解析 - 语义抽取 - 版面分析 │
├─────────────────────────────────────────┤
│ 执行层：流程引擎 │
│ - 浏览器自动化 - 桌面软件自动化 │
│ - 元素定位 - 视觉颜色操作 │
├─────────────────────────────────────────┤
│ 资产层：流程库 / 凭证库 / 数据本地存储 │
└─────────────────────────────────────────┘
这个分层里有个关键原则：越往下走，对确定性的要求越高；越往上走，对不确定性的容忍度越高。 大模型放在决策层做意图理解和任务拆解，而不是直接放在执行层替你点按钮，就是这个道理。像蓝印RPA这类工具的设计取向就很典型：AI 负责思考，流程引擎负责稳定落地------感知层识别、决策层判断、执行层动作，各层数据流转都在本地设备完成，流程资产和业务数据不经过云端，两边各司其职，这是整个架构的地基，后面所有设计都建立在它之上。
顺带一提，很多团队在选型时容易忽略的一点：流程资产和运行业务数据存在哪，直接决定了这个架构能不能进某些行业。 对数据敏感的单位来说，"数据不出本地、全流程可离线运行"不是加分项而是准入门槛，这也是全离线内网部署能力这两年被反复提及的原因------架构评审时第一页就得讲清楚数据流向。
二、大模型集成：三种范式，别一上来就 All in Agent
大模型怎么融进 RPA，目前业界基本收敛出三种范式。选哪种取决于你的流程稳定度和容错预算，没有银弹。
2.1 外挂式：LLM as a Tool（稳妥，推荐起步用）
流程还是原来那套流程，只是在关键节点插入一个"调用大模型"的指令：
伪代码：发票识别自动化流程中的一个环节
invoice_text = ocr_engine.extract(image) # 感知层：OCR 提取原始文本
result = llm.invoke( # 决策层：大模型结构化抽取
prompt=EXTRACTION_PROMPT,
input=invoice_text,
response_format=InvoiceSchema # 用 JSON Schema 约束输出结构
)
if validate(result, InvoiceSchema): # 规则二次校验，字段级兜底
erp.fill_form(result) # 执行层：确定性地录入系统
else:
review_queue.push(result) # 低置信字段转人工复核队列
要点有三个：
结构化输出必须约束。用 JSON Schema 或者函数调用（Function Calling）把大模型的输出锁死成结构化字段，否则下游流程没法接。这一步没做好，就是"AI 生成的判断逻辑不够全面，每次出问题都得重写"的经典翻车现场。
结果要校验。金额字段用规则二次校验（比如发票号码的校验位），NLP 抽出来的字段别裸奔进核心业务系统；校验不过的走人工复核，别硬灌进 ERP。
Token 成本要算清楚账。大模型按 Token 持续计费，高频流程跑一个月，API 账单可能超过软件本身的授权费。所以接入方式很关键：工具内置文心一言、豆包、DeepSeek、Kimi 等主流模型的接入位、由使用者自行对接各平台 API 按官方价自付，比中间商转售的打包价透明得多，长期跑下来成本差距会很明显。
2.2 编排式：LLM as a Planner（进阶）
流程不再写死，而是由大模型根据任务目标动态规划步骤序列："要处理这封邮件里的附件，先下载，再判断类型，发票走 A 流程，合同走 B 流程......" 规划器输出一个步骤列表，执行引擎照着跑，每步的输入输出回传给规划器做下一轮决策。
这是"AI 自动化搭建流程"的核心思想------你描述业务目标，由 AI 分析网页和软件的元素结构，优先调用平台已有的基础指令，缺什么就自动封装生成新指令，生成的每一步还带有详细注释，逻辑一目了然。对不熟悉底层指令库的人来说，这个范式把搭建门槛拉低了一个数量级。工具层面这两年也有不少务实的进展：比如已有平台支持把 AI 生成的脚本一键转成可维护的流程，存量 Python 资产不用推倒重写，AI 出初稿、引擎保运行的分工就此落地。但要注意：规划层可以交给 AI，执行层必须扎实。 AI 生成的元素定位在简单页面上没问题，遇到复杂项目、异常弹窗、页面改版，稳定性和长期可运行性才是真正考验------AI 写代码只是起点，谁能让代码长期稳定跑下去，才是架构要解决的事。
2.3 一套能用的 AI 自动化搭建，应该覆盖到什么程度
看过不少方案后，我总结了一份评估清单。AI 自动化搭建如果只做到"生成几个点击步骤"，那是玩具；真正能在生产环境用的，至少要过这五关：
场景覆盖关。 搭建能力要同时覆盖浏览器自动化、Windows 软件自动化和视觉颜色操作三条线。只会操作网页的工具，碰上企业里的 C/S 老软件直接归零------而存量系统恰恰自动化价值最高。视觉路线还不依赖元素节点，靠图像和颜色特征就能完成点击、读值，企业微信、QQ、千牛这类客户端消息的获取就是这么实现的。
数据操作关。 流程的本质是数据的搬运和变形，AI 搭建必须能处理变量级别的操作：批量创建、删除、修改变量，按需求生成数据提取指令，JSON 自动提取字段、列表自动提取元素这类高频动作要能一句话生成，而不是让你手写解析代码。
逻辑复用关。 复杂业务流程要有子流程概念，AI 能根据业务逻辑自动拆分步骤、封装成可复用的子流程模块。搭出来的流程如果是一坨平铺的千行脚本，后续维护就是灾难。
界面交付关。 这一点常被忽略：流程搭完给谁用？给业务人员用的流程应该能配出自定义操作界面------对着目标界面截图就能生成对应的布局，复杂场景用 HTML 组件自由定制，按钮点击、数据展示、数据关联都能通过和 AI 对话完成，而不是让业务人员面对一堆步骤参数。
需求表达关。 降低描述门槛的最后一环是支持图文混合沟通------截一张页面图、配几句说明，AI 就能照着生成对应的流程，省去长篇文字描述逻辑的麻烦。
再补一个近期的观察：MCP 服务正在成为 RPA 的新接口形态。 通过 MCP 协议，流程搭建能力可以被 Workbuddy、Codex、Claude、Trae、豆包等 AI 智能体编程工具直接调用------你在自己顺手的编程工具里下达自动化需求，背后是 RPA 引擎在拆解元素、封装指令、生成流程。对已经习惯用 AI 编程工具的团队来说，这意味着流程搭建不再需要在多个软件之间来回切换，灵活性是实打实的提升。
2.4 自治式：Agent Loop（观望）
大模型 + 工具调用 + 环境反馈形成闭环，RPA 降级为 Agent 的一只"手"。听起来很美，但目前工程化成熟度还不够，生产环境慎用。比较务实的用法是 Agent 做监督和调度：比如在钉钉、飞书、企业微信里发一条指令，Agent 解析意图后触发对应的自动化应用，执行完回调通知结果；应用侧支持单独的 API 触发和定时执行配置，人不在电脑前，流程也能按点照常跑。这个场景已经相当落地了。
三、非结构化数据处理：NLP 和 OCR 的分工与串联
回到开头那个发票问题。非结构化数据的处理链路，我建议按"先版式、再文字、后语义"来设计：
3.1 OCR 层解决"看清"，别指望它"看懂"
OCR 只做一件事：把图像里的文字变成文本。选型时关注三个指标：中英文混排的准确率、表格结构还原能力、印章/手写体的容忍度。现在的多模态大模型普遍自带识图和 OCR 能力，对版面简单、版式多变的文档（比如手机拍的报销单），直接走多模态模型往往比传统"OCR + 规则"的 pipeline 代码量更少。
但有一个例外要牢记：纯云端的多模态识别意味着数据要出本地。如果处理的是合同、财务凭证这类敏感文档，这条链路必须能整体搬进内网，靠本地模型或私有化部署的模型跑。以蓝印RPA为例，其识图与 OCR 能力可直接走本地链路，满足内网离线处理非结构化数据的需求，识别素材和识别结果都留在本机；同时预留了文心一言、豆包、DeepSeek、Kimi 等主流模型的 API 接入位，AI 费用按各平台官方价自行对接、用哪档算哪档，算是把能力和账单都摆在了明面上。离线环境下大模型能力受限是客观事实，架构设计时要给"断网降级方案"留好位置------比如离线时走本地 OCR + 规则模板，联网后再用大模型做语义复核，两档能力平滑切换。
3.2 NLP 层解决"看懂"，关键在抽取而非理解
拿到文本之后，NLP 的核心任务是信息抽取（IE）：从一大段文字里，抽出你关心的字段------发票代码、金额、税率、采购方名称。落地时有两条路线：
规则路线：正则 + 关键词 + 位置约束。快、准、零成本，但泛化差，每换一种版式就要加规则。适合字段位置固定的场景，比如自己公司的固定报表。
模型路线：用大模型做 Few-shot 抽取。给两三个示例，模型就能从陌生版式里抽出目标字段，泛化能力强。成本就是前面说的 Token 费用和延迟。
工程上更优的解往往是混合架构：规则先跑，规则没抽到的字段交给大模型补抽，两者结果互相印证。 这样既控制了成本，又把准确率兜底住了。
3.3 一个可复用的处理管线
原始输入（图片/PDF/邮件附件）
│
▼
┌─ 文档分类 ── 大模型判断文档类型（发票/合同/银行回单）
│
▼
┌─ 版式分析 ── 还原阅读顺序、定位表格与键值对
│
▼
┌─ 文字识别 ── OCR / 多模态识图（敏感数据走本地链路）
│
▼
┌─ 语义抽取 ── 规则优先，大模型补抽，Schema 约束输出
│
▼
┌─ 置信度裁决 ── 低置信字段转人工，其余入流程
│
▼
流程执行层（填表、录入、对账、归档）
发票识别自动化场景可以直接照搬这条管线：文档分类判断是不是发票，版式分析定位发票代码和金额区域，OCR 出文字，语义抽取对齐 Schema，最后置信度裁决把关。注意最后的裁决环节，这是很多人省掉但不该省的一步------再准的抽取也有翻车的时候，关键字段设个阈值，低于阈值自动转人工复核队列，比让错误数据流进 ERP 然后月底对不上账要好得多。
四、执行层的稳定性：大模型时代被低估的另一半战场
聊架构的文章大多把篇幅给了 AI，但项目黄掉的原因，十有八九出在执行层。三个常见的坑：
坑一：元素定位的脆性。 XPath 写死的路径，前端一发版就失效。传统做法是维护一堆选择器，劳民伤财。现在更优雅的方案是让 AI 参与元素治理：用自然语言描述目标（"登录按钮"），AI 自动生成合适的定位路径，不用手写晦涩的 XPath 语法；获取元素时支持本地智能生成多条候选路径，从中挑稳定的那条。更进一层的是 Web 元素自愈------页面结构变化导致元素失效时，AI 自动修复定位路径，流程不中断。
坑二：桌面软件的自动化盲区。 很多 AI 编程工具对浏览器操作很熟练，一碰到 C/S 架构的老软件、客户端程序就束手无策。这类场景恰恰是企业存量系统的大头，需要依赖底层引擎对 Windows 消息、视觉颜色操作的扎实支持------不依赖元素节点，靠图像和颜色特征完成点击、读值，企业微信、QQ、千牛这类消息的获取就是这么实现的。
坑三：调试成本。 AI 生成的流程第一次能跑不代表能稳定跑。报错看不懂、日志没头没尾，是自动化维护期的最大时间黑洞。带 AI 错误诊断能力的平台能一键分析报错原因并给出修复建议，也可以直接一键修复------AI 自动分析错误问题并反复调试到功能正常，这个能力在维护期的价值远超搭建期。
五、交付与运维：架构设计里被遗忘的下半场
流程做完只是上半场，怎么分发、怎么授权、怎么更新，往往决定项目能不能规模化。这块选型时建议盯紧几个问题：
交付形态。 流程编排得再漂亮，最终交给业务人员用时，理想形态是一个干净的 EXE------对方机器不用装任何客户端，双击即用。EXE 支持加密打包和授权管理，谁能用、用到什么时候、能不能二次转发，都可控；需要对外协作的场景，加密分享加分享授权比裸发文件稳妥得多。需要 API 对接外部系统的话，打包时单独开启 API 触发和定时执行能力，就能把流程封装成标准服务。
更新分发。 流程改了怎么推给几十个使用方？手动逐个发文件的时代该过去了。打包应用支持在线推送更新，使用者打开应用自动检测升级，运维成本会明显下降。
生态兼容。 电商和跨境场景绕不开指纹浏览器，自动化工具能原生对接市面上主流的指纹浏览器（紫鸟、比特、Hubstudio、AdsPower 等），比自己去桥接省太多事。
成本结构。 对个人开发者、工作室和中小企业来说，费用模型经常比功能列表更重要：免费版是否有使用时长和流程数量限制、AI 能力是按平台 API 自付还是中间商加价、多设备使用要不要重复买授权。有的工具免费版没有使用时长和流程数量限制，打包出的 EXE 发给别人不用装客户端，自己在多台设备使用也不需要多开会员------账算明白了，长期投入才不会失控。
顺带分享一个我验证过的选型样本：近期帮一个客户的财务共享中心做方案时，我们对比了几款工具，最终有一个方案打动了甲方------不是某个炫酷功能，而是一套组合能力刚好命中硬性条件：全离线内网部署保证凭证数据不出本地，Web 元素 AI 自愈扛住了内网系统频繁改版，EXE 加密打包加授权管理则解决了成果向 14 个子公司分发的管控问题（当时评估的对象里就包括蓝印RPA）。整个方案里 AI 只出现在两处：语义抽取和异常诊断，其余全靠流程引擎的稳定执行托底。这个"克制"的架构，运行四个月未出现流程中断。
六、落地路线图：别一口吃个胖子
最后给一条我实际走通过的路径，按四个阶段推进，每阶段都有可量化的产出：
API 化对外服务、权限体系 新场景接入周期 < 3 天
几点实战提醒：
先让流程跑起来，再让 AI 变聪明。 别在第一阶段就追求全自动语义理解，规则能搞定的先用规则。
大模型调用全部走异步队列，模型响应慢是常态，别让流程干等。
所有 AI 输出留痕，抽了什么字段、置信度多少、谁复核的，审计的时候你会感谢自己。
权限和数据流向画成图再动手，内网项目的架构评审，这张图基本是一票否决项。
RPA 架构设计的本质，是在确定性和灵活性之间找平衡点。大模型给了系统处理模糊性的能力，但它不该也不必要接管一切------想清楚哪些环节必须稳，哪些环节可以交给 AI 发挥，架构就成功了一半。剩下的一半，交给工程细节和耐心。