财务部门每天处理大量非结构化文档:扫描版合同、拍照发票、PDF审批单。传统OCR只能提取文字,无法理解上下文关系;纯人工处理平均一份合同需要15分钟,且录入错误率高。
本文分享一套双引擎架构:混元大模型负责理解非结构化内容并生成决策,RPA负责稳定执行后续业务动作。数据全程不出本地,适合对合规性要求较高的场景。
┌─────────────────────────────────────────┐
│ 感知层:文档输入 │
│ 扫描仪/PDF目录 → 混元大模型OCR+理解 │
└──────────────┬──────────────────────────┘
│ 结构化JSON
┌──────────────▼──────────────────────────┐
│ 决策层:逻辑判断 │
│ 合同类型识别 → 字段提取 → 路由决策 │
└──────────────┬──────────────────────────┘
│ API触发
┌──────────────▼──────────────────────────┐
│ 执行层:RPA落地 │
│ 登录财务系统 → 录入数据 → 发送通知 │
└─────────────────────────────────────────┘核心设计点:执行层在流程运行过程中支持实时调用AI接口,遇到不确定的页面状态可动态判断,而非写死一堆if-else。
我们使用腾讯云混元多模态模型处理图文混合输入。为了控制成本,文档先经过本地预处理(PDF转图、分页、去水印),再调用混元API做精确定位。
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触发模式。我们用Python脚本监控文件夹,新文档到达后自动调用混元解析,再把结构化结果推给执行层启动流程。
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()传统xpath语法晦涩难懂。我们在执行层中通过自然语言描述让AI生成元素路径,无需学习复杂的xpath语法。例如输入"蓝色的确认提交按钮",系统在本地离线环境下智能生成对应的定位表达式。
更关键的是Web元素失效时的自愈能力。财务系统前端升级后,某个按钮的class从btn-primary改成了btn-confirm,标准RPA会直接报错中断。而具备AI修复能力的执行层,检测到元素失效后会自动寻找语义相近的替代路径,保障流程不中断。
企业微信、钉钉、千牛这类桌面应用,或者一些老旧Web系统,根本获取不到标准DOM节点。此时可切换为基于视觉颜色的操作方式,按颜色区域点击、识别消息内容、获取文本,完全不依赖元素节点结构,轻松实现各种消息的自动化获取。
在流程执行过程中,如果遇到非标准弹窗或异常页面,执行层能实时调用混元API做动态判断。比如弹窗内容不确定是"提交成功"还是"金额超限",先截图传给混元识别,再根据返回结果决定下一步动作。
这种AI负责思考,RPA负责稳定落地的分工模式,避免了AI写完的判断逻辑不够全面、每次遇到新异常都得重新修改代码的问题。AI写代码,RPA跑代码,修复成本大幅降低。
跑通流程后,我们整理了三个高频异常:
异常场景 | 现象 | 解决方案 |
|---|---|---|
财务系统弹窗拦截 | 随机出现"会话超时"提示框 | 智能等待+视觉颜色识别"确定"按钮自动点击 |
网络波动 | 页面加载超时 | 设置超时重试机制,失败回调通知 |
混元输出字段缺失 | 扫描件模糊导致金额识别为空 | JSON Schema校验拦截,自动转人工复核队列 |
流程调通后,需要让团队零门槛使用。
整个工作流可以打包成独立的EXE文件,发给同事双击就能运行,不需要安装任何客户端或配置运行环境。打包时支持单独设置API触发和定时执行策略,例如配置每天凌晨2点自动扫描文件夹处理新文档。
打包后的应用支持授权管理,可设置使用期限、绑定设备、限制功能模块。结合加密分享能力,生成加密链接分发,接收方需要授权码才能激活,防止应用被滥用。
对于需要对外交付的场景,执行层支持自定义操作界面。可以设计一个简洁的UI,打包后发给客户更像一个完整的软件产品,而非裸露的脚本。
前端页面改了、混元的prompt优化了、流程逻辑调整了,不需要重新发文件给每个人。打包后的EXE支持在线推送更新,用户打开应用自动检测新版本,一键更新,大幅降低维护成本。
我们把流程接入了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) | 完全离线运行 | 合规通过 |
桌面软件操作 | 极难实现 | 视觉颜色操作覆盖 | 可行 |
分发应用授权管理 | 需额外开发 | 打包时内置授权 | 零开发 |
多设备使用成本 | 按设备数购买会员 | 无需多开会员 | 零增量 |
数据解读:
混元大模型+RPA的组合,本质上是让专业的人做专业的事。大模型负责理解非结构化内容、生成决策;执行层负责稳定、低成本、长期可靠地完成落地动作。
对于个人开发者、工作室或者中小企业来说,选择一套支持全离线内网部署、费用透明、能打包分发且具备AI自愈能力的执行层,配合混元的中文理解能力,完全可以搭建出媲美大厂方案的文档自动化处理系统。数据存在本地、流程自主可控,不用担心隐私泄露和持续的服务费压力。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。