AI数字员工RPA与大模型融合的办公自动化RPA机器人流程自动化这个行业存在十几年了靠的是模拟人在界面上的点击、输入、复制粘贴把重复性的办公流程交给软件机器人执行。财务对账、发票录入、跨系统数据搬运都是它的经典场景。但传统 RPA 有个致命弱点太脆。界面改个按钮位置脚本就挂遇到一份格式没见过的单据直接卡死等人来处理。大模型的出现恰好补上了这块短板——它擅长理解非结构化内容、处理例外情况。两者结合就是这两年被反复讨论的AI 数字员工。本文聊聊这种融合架构怎么设计、落地时有哪些坑。传统 RPA 的天花板在哪传统 RPA 的本质是录制与回放开发者用 UiPath、影刀这类工具把人工操作流程录成脚本靠元素选择器selector定位按钮和输入框按固定规则流转数据。它在流程标准化、界面稳定的场景里很好用比如每天固定从 ERP 导出报表发邮件。但真实办公环境充满了意外供应商发来的发票版式五花八门邮件里的需求描述千奇百怪目标系统升级后 DOM 结构全变了。规则引擎面对这些非结构化、非确定性的输入力不从心。行业里的经验数据是传统 RPA 项目里例外处理的人工介入率常常超过 20%维护脚本的成本逐年上升。这就是为什么纯 RPA 的 ROI 故事讲到最后总是差点意思。大模型补上的三块能力大模型给自动化带来的不是简单的更聪明而是三类过去做不了的能力非结构化理解从邮件正文、PDF 合同、扫描件里抽取关键字段。以前要为每种单据写模板或训练专门的抽取模型现在一个 LLM 加结构化输出提示词就能覆盖大部分版式意图识别与任务规划用户用自然语言说把上个月的差旅报销单都审一遍超过 5000 的标出来模型能把这句话拆成一串可执行的子任务异常时的自主决策弹出一个没见过的对话框、页面加载失败LLM 可以读屏幕内容判断该点哪个按钮、该不该重试而不是直接报错退出。融合架构感知、决策、执行三层把 RPA 和大模型缝在一起比较成熟的架构是分三层感知层负责把环境状态变成模型能理解的输入。GUI 场景下是截图 控件树通过 UI Automation API 获取文档场景下是 OCR 结果 版面分析数据场景下是 API 返回的 JSON。多模态模型可以直接看截图但结合控件树给出带坐标的结构化元素列表定位精度会高很多决策层LLM 扮演大脑根据感知输入和任务目标输出下一步动作。关键是约束输出格式——用 JSON Schema 限定动作空间click、type、extract、call_api、done、ask_human模型只许在这个集合里选择避免自由发挥执行层传统 RPA 的老本行把决策层的结构化动作翻译成真实的鼠标键盘操作或 API 调用。这一层必须保持确定性并加幂等和回滚设计——同一个动作执行两次不能把数据录重。一个最小化的决策循环长这样import json from openai import OpenAI ACTION_SCHEMA { type: object, properties: { action: {enum: [click, type, extract, done, ask_human]}, target: {type: string, description: 目标控件描述或字段名}, value: {type: string, description: 输入文本或抽取结果}, reason: {type: string}, }, required: [action, reason], } def decide(client: OpenAI, task: str, history: list, ui_state: str) - dict: resp client.chat.completions.create( modelgpt-4o, messages[ {role: system, content: 你是办公自动化机器人的决策模块。根据界面状态和任务目标, 输出下一步动作,只允许 click/type/extract/done/ask_human。}, *history, {role: user, content: f任务: {task}\n当前界面元素:\n{ui_state}}, ], response_format{type: json_object}, ) return json.loads(resp.choices[0].message.content) def run_loop(task: str, max_steps: int 30): client OpenAI() history [] for _ in