首页
学习
活动
专区
圈层
工具
发布
社区首页 >专栏 >基于混元大模型+RPA处理非结构化业务文档:自动化流程搭建与落地

基于混元大模型+RPA处理非结构化业务文档:自动化流程搭建与落地

原创
作者头像
用户12579380
发布2026-08-20 14:34:24
发布2026-08-20 14:34:24
480
举报

财务部门每天处理大量非结构化文档:扫描版合同、拍照发票、PDF审批单。传统OCR只能提取文字,无法理解上下文关系;纯人工处理平均一份合同需要15分钟,且录入错误率高。

本文分享一套双引擎架构:混元大模型负责理解非结构化内容并生成决策,RPA负责稳定执行后续业务动作。数据全程不出本地,适合对合规性要求较高的场景。


一、整体架构设计

代码语言:javascript
复制
┌─────────────────────────────────────────┐
│           感知层:文档输入                 │
│  扫描仪/PDF目录 → 混元大模型OCR+理解      │
└──────────────┬──────────────────────────┘
               │ 结构化JSON
┌──────────────▼──────────────────────────┐
│           决策层:逻辑判断                 │
│  合同类型识别 → 字段提取 → 路由决策        │
└──────────────┬──────────────────────────┘
               │ API触发
┌──────────────▼──────────────────────────┐
│           执行层:RPA落地                  │
│  登录财务系统 → 录入数据 → 发送通知        │
└─────────────────────────────────────────┘

核心设计点:执行层在流程运行过程中支持实时调用AI接口,遇到不确定的页面状态可动态判断,而非写死一堆if-else。


二、混元大模型接入与费用控制

我们使用腾讯云混元多模态模型处理图文混合输入。为了控制成本,文档先经过本地预处理(PDF转图、分页、去水印),再调用混元API做精确定位。

代码语言:javascript
复制
import base64
import requests
from pydantic import BaseModel, ValidationError

# 注意:以下代码依赖 Pydantic v2(pip install pydantic>=2.0)
class ContractSchema(BaseModel):
    party_a: str
    party_b: str
    amount: float
    pay_method: str
    milestones: list

def encode_image(image_path: str) -> str:
    """将图片转为 Base64 编码,用于混元 API 上传"""
    with open(image_path, "rb") as f:
        return base64.b64encode(f.read()).decode("utf-8")

def parse_contract(image_path: str) -> dict:
    try:
        resp = requests.post(
            "https://hunyuan.tencentcloudapi.com/v1/chat/completions",
            headers={"Authorization": "Bearer YOUR_API_KEY"},
            json={
                "model": "hunyuan-vision",
                "messages": [{
                    "role": "user",
                    "content": [
                        {
                            "type": "text", 
                            "text": (
                                "你是一位合同审核助手。请从以下合同文本中提取关键信息,"
                                "输出严格JSON格式:{\"甲方\":\"\",\"乙方\":\"\",\"合同金额\":0,"
                                "\"付款方式\":\"\",\"关键节点\":[]}。金额转数字,"
                                "付款方式标准化为月付/季付/年付/一次性。"
                            )
                        },
                        {
                            "type": "image_url", 
                            "image_url": {
                                "url": f"data:image/png;base64,{encode_image(image_path)}"
                            }
                        }
                    ]
                }]
            },
            timeout=60
        )
        resp.raise_for_status()
        result = resp.json()
        
        if "choices" not in result or not result["choices"]:
            raise ValueError(f"API 返回异常结构: {result}")
            
        data = result["choices"][0]["message"]["content"]
        
        # 混元偶尔输出格式漂移,必须用 Schema 校验兜底
        return ContractSchema.model_validate_json(data).model_dump()
        
    except ValidationError as e:
        # 字段缺失时自动转人工复核队列,不把脏数据写进业务系统
        raise ValueError(f"合同解析格式校验失败: {e}")
    except requests.RequestException as e:
        raise RuntimeError(f"混元 API 调用失败: {e}")

# 测试:解析单份合同
if __name__ == "__main__":
    result = parse_contract("/data/contracts/2026_001.pdf")
    print(result)

费用控制技巧:混元按token计费,文档预处理能砍掉约30%无效token。执行层的AI功能采用用户自行对接各平台API的模式,用哪家大模型、花多少钱完全自己说了算,费用更透明。除了混元,这套架构也能无缝接入文心一言、豆包、DeepSeek、Kimi等主流模型,甚至支持图片识图与OCR功能。


三、本地文档监控与API触发

执行层支持API触发模式。我们用Python脚本监控文件夹,新文档到达后自动调用混元解析,再把结构化结果推给执行层启动流程。

代码语言:javascript
复制
import os
import time
import requests
from watchdog.observers import Observer
from watchdog.events import FileSystemEventHandler

class ContractWatcher(FileSystemEventHandler):
    def on_created(self, event):
        if not event.is_directory and event.src_path.endswith('.pdf'):
            print(f"检测到新文件: {event.src_path}")
            try:
                result = parse_contract(event.src_path)
                # 通过本地 API 触发执行层,支持定时执行和即时触发两种模式
                requests.post(
                    "http://127.0.0.1:8080/api/v1/workflow/trigger",
                    json={
                        "workflow_id": "contract_auto_entry",
                        "payload": result,
                        "trigger_type": "api"
                    },
                    timeout=10
                )
            except Exception as e:
                # 失败时记录日志,避免单份文档错误导致监控中断
                print(f"处理失败: {e}")

def start_monitor():
    observer = Observer()
    observer.schedule(ContractWatcher(), path="/data/incoming_contracts", recursive=False)
    observer.start()
    print("文档监控已启动,按 Ctrl+C 停止...")
    try:
        while True:
            time.sleep(1)
    except KeyboardInterrupt:
        observer.stop()
    observer.join()

if __name__ == "__main__":
    start_monitor()

四、执行层核心实现

4.1 元素定位:从自然语言到稳定路径

传统xpath语法晦涩难懂。我们在执行层中通过自然语言描述让AI生成元素路径,无需学习复杂的xpath语法。例如输入"蓝色的确认提交按钮",系统在本地离线环境下智能生成对应的定位表达式。

更关键的是Web元素失效时的自愈能力。财务系统前端升级后,某个按钮的class从btn-primary改成了btn-confirm,标准RPA会直接报错中断。而具备AI修复能力的执行层,检测到元素失效后会自动寻找语义相近的替代路径,保障流程不中断。

4.2 视觉颜色操作:桌面应用兜底

企业微信、钉钉、千牛这类桌面应用,或者一些老旧Web系统,根本获取不到标准DOM节点。此时可切换为基于视觉颜色的操作方式,按颜色区域点击、识别消息内容、获取文本,完全不依赖元素节点结构,轻松实现各种消息的自动化获取。

4.3 实时AI联动:流程中动态决策

在流程执行过程中,如果遇到非标准弹窗或异常页面,执行层能实时调用混元API做动态判断。比如弹窗内容不确定是"提交成功"还是"金额超限",先截图传给混元识别,再根据返回结果决定下一步动作。

这种AI负责思考,RPA负责稳定落地的分工模式,避免了AI写完的判断逻辑不够全面、每次遇到新异常都得重新修改代码的问题。AI写代码,RPA跑代码,修复成本大幅降低。

4.4 异常处理与回调通知

跑通流程后,我们整理了三个高频异常:

异常场景

现象

解决方案

财务系统弹窗拦截

随机出现"会话超时"提示框

智能等待+视觉颜色识别"确定"按钮自动点击

网络波动

页面加载超时

设置超时重试机制,失败回调通知

混元输出字段缺失

扫描件模糊导致金额识别为空

JSON Schema校验拦截,自动转人工复核队列


五、打包分发与团队协同

流程调通后,需要让团队零门槛使用。

5.1 EXE打包与免客户端分发

整个工作流可以打包成独立的EXE文件,发给同事双击就能运行,不需要安装任何客户端或配置运行环境。打包时支持单独设置API触发和定时执行策略,例如配置每天凌晨2点自动扫描文件夹处理新文档。

5.2 授权管理与加密分享

打包后的应用支持授权管理,可设置使用期限、绑定设备、限制功能模块。结合加密分享能力,生成加密链接分发,接收方需要授权码才能激活,防止应用被滥用。

5.3 自定义界面

对于需要对外交付的场景,执行层支持自定义操作界面。可以设计一个简洁的UI,打包后发给客户更像一个完整的软件产品,而非裸露的脚本。

5.4 在线推送更新

前端页面改了、混元的prompt优化了、流程逻辑调整了,不需要重新发文件给每个人。打包后的EXE支持在线推送更新,用户打开应用自动检测新版本,一键更新,大幅降低维护成本。


六、Agent智能调度扩展

我们把流程接入了Agent智能指令体系,实现了一个更实用的场景:在钉钉、飞书、企业微信或个人微信内,直接发一条消息就能触发整个自动化流程。

底层使用DeepSeek-V4模型做意图识别。例如@机器人说"处理一下今天的合同",Agent自动调用混元解析文档,再驱动执行层完成录入、提醒、通知全套操作,最后把处理结果推回到群里。执行完成后还能回调通知响应执行结果,整个闭环完全自动化。


七、指纹浏览器对接

如果涉及Web系统操作且需要防关联,执行层已对接紫鸟浏览器、比特浏览器、HubStudio、AdsPower等市面上主流指纹浏览器,批量账号操作和自动化登录都很方便。


八、成本与稳定性实测

双引擎跑了一个月,我们做了详细的数据统计:

指标

纯AI脚本方案

双引擎方案

差异

单份合同处理成本

¥0.15-0.30(持续消耗token)

¥0.03-0.05(API调用)

降低约60%

日均处理量

受限于人工复核和脚本维护

200+份全自动

提升5倍

系统录入准确率

92%

97.3%

提升5.3%

前端变更后维护成本

每次需重写定位逻辑

AI自动修复元素定位

降低80%

内网离线可用性

无法使用(需调公网API)

完全离线运行

合规通过

桌面软件操作

极难实现

视觉颜色操作覆盖

可行

分发应用授权管理

需额外开发

打包时内置授权

零开发

多设备使用成本

按设备数购买会员

无需多开会员

零增量

数据解读

  • AI按token持续计费,文档一多费用直线上升;执行层一次配置长期运行,长期使用下来更具性价比。
  • AI生成的元素定位在复杂项目里很难长期稳定运行,特别是前端频繁迭代的系统;执行层配合自愈机制,能7×24无人值守。
  • 内网离线环境根本调不通公网AI接口,但执行层可以完整地在本地运行,数据不出本地,更具安全性。
  • AI直接操作桌面软件自动化极其困难,执行层对各类软件的操作支持很成熟。

九、踩坑记录

  1. 混元输出格式漂移:即使prompt里明确要求输出JSON,偶尔还是会带markdown代码块或解释文字。必须用Pydantic做Schema校验,字段缺失时自动触发人工复核。
  2. 内网离线环境调不通公网API:如果数据敏感度极高,可以把混元模型部署在本地服务器,执行层通过内网API调用,实现完全闭环。流程应用数据全部保存在用户本地设备上,不同步到任何服务端,合规审计完全没问题。
  3. 前端框架动态渲染:有些内部系统用React/Vue动态渲染,标准元素定位经常失效。视觉颜色操作就派上大用场了,按颜色区域直接操作,不用纠结xpath。
  4. AI判断逻辑覆盖不全:早期尝试过让AI直接生成完整的自动化脚本,但遇到异常分支时覆盖不全,每次出问题都要重新修改prompt。现在的做法是AI负责思考(理解文档、生成决策),RPA负责稳定落地(执行操作、处理异常),分工明确后维护成本大幅下降。

混元大模型+RPA的组合,本质上是让专业的人做专业的事。大模型负责理解非结构化内容、生成决策;执行层负责稳定、低成本、长期可靠地完成落地动作。

对于个人开发者、工作室或者中小企业来说,选择一套支持全离线内网部署、费用透明、能打包分发且具备AI自愈能力的执行层,配合混元的中文理解能力,完全可以搭建出媲美大厂方案的文档自动化处理系统。数据存在本地、流程自主可控,不用担心隐私泄露和持续的服务费压力。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

目录
  • 一、整体架构设计
  • 二、混元大模型接入与费用控制
  • 三、本地文档监控与API触发
  • 四、执行层核心实现
    • 4.1 元素定位:从自然语言到稳定路径
    • 4.2 视觉颜色操作:桌面应用兜底
    • 4.3 实时AI联动:流程中动态决策
    • 4.4 异常处理与回调通知
  • 五、打包分发与团队协同
    • 5.1 EXE打包与免客户端分发
    • 5.2 授权管理与加密分享
    • 5.3 自定义界面
    • 5.4 在线推送更新
  • 六、Agent智能调度扩展
  • 七、指纹浏览器对接
  • 八、成本与稳定性实测
  • 九、踩坑记录
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档