财务自动化里最容易低估的那一块
把多模态Agent塞进报销、记账、应付应收流程，听起来是件轻松事：把票据拍下来，让模型把金额、抬头、税号、开户行这些字段读到结构化结果里，直接丢给ERP。但实际跑三个月，财务负责人的反馈通常不是"识别率99%"，而是"总有几张没过"。
这几张没过，往往是手写、模糊、折痕、订书钉遮挡、还有发票被咖啡渍泡过边角的那一批。它们在测试集里只占5%，进了真实业务流，就变成每天几十张卡进人工兜底槽的票据。
更值得警惕的是，多模态模型在这一类困难样本上的错误，不像普通OCR那样是"字符识别错误"，而是"看起来读对了，其实上下文语义错位"——这正是后处理链路最难兜住的部分。
三个最常见的翻车现场
先描述三种典型失败，再讨论怎么改。
第一种：手写体数字串错位。一张餐饮发票上的"金额"被识别成另一个数字，模型在字段抽取阶段从未报错，结果金额直接进账。Anthropic和阿里云开发者社区在近一年的OCR改造实践里都反复提到，多模态模型对手写金额的稳定性弱于印刷体，原因在于手写体训练样本本身偏稀疏，再加上折痕破坏了笔画。火山引擎开发者社区在2025年3月的总结里也把"手写数字漂移"列为多模态大模型相对传统OCR的优势反转区。
第二种：折叠痕迹被读成字符。发票对折后压出的折痕，在黑白二值化阶段会被识别为「/」「一」之类字符，常常出现在税额和备注字段。同笔金额，前一秒识别正常，后一秒同一张图因为拍摄角度变化识别失败，给后端造成了不可解释的随机性（这是调试最头疼的部分）。
第三种：跨字段语义串位。一张开票人和抬头不一致的专票，模型把"购买方"和"销售方"下的字段识别反了。如果下游没有发票三要素比对校验，它会顺利进账，等税务稽核才发现。腾讯云开发者社区在2026年公开的OCR大模型演进材料里，把这种"形对义错"现象定义为下一代多模态OCR必须攻坚的方向。
这三类错误的共同点：单看识别输出，置信度可能很高，肉眼复核也未必发现得了，模型会用一个看起来合理的错误，把财务流程带入隐蔽风险。
Prompt优化：先把识别结果逼问两次
针对多模态Agent处理票据，Prompt层面有三个值得在生产环境固化的技巧。
第一，让模型先输出原始OCR文本，再抽取字段。很多团队习惯直接让VLM返回结构化JSON，结果模型为了"答齐字段"会把不可读的字符用学到的上下文补全（比如"0"和"8"分不清时直接补成常见金额）。分两步走，先强制输出一段"逐字符读到的原文并标出不确定字符"，再让模型基于原文抽字段，能显著降低幻觉补全率。这一思路在阿里云2025年6月公开的Qwen-VL票据抽取案例里被作为关键改动。
第二，强制字段级置信度标注。Prompt里显式要求模型对每个字段给出0–1的置信度，并对低于阈值的字段标注"疑点原因"（如"金额末位模糊，识别置信度0.62"）。这一段元数据不进ERP，但进校验队列，是后续人工复核节点的依据。
第三，对容易出错的字段做交叉校验。比如税额 = 金额 × 税率这个恒等关系，让模型在结果中显式做一次交叉验证。如不一致，则整张票据直接进人工复核，省掉一次下游错误扩散。这种"模型自身做算法式校验"的做法，和电网AI调度员让模型自检误报的思路（详见《16分钟定位故障之后，电网AI的数据账怎么算》）属于同一类工程取舍。
后处理校验：上下文增强纠错 + 企业规则库
OCR硬识别之外，多模态模型的真正增量在于"上下文增强纠错"。合合信息在2026年5月披露的技术资料里，明确把这一能力列为Agent OCR相对传统OCR的关键差异：模型能够基于语义逻辑，把模糊、畸变、缺字的字符反向补正为业务相关术语（比如把"浙讠"识别回"浙江"）。
但这条能力同样是把双刃剑——它会让模型在票据业务里"自作聪明"地补字。因此，企业侧必须叠加一层业务规则库校验，至少包含：
- 发票代码位数和行政区域代码校验
- 税号长度和底纹逻辑匹配
- 金额精度（角分位）与中文大写金额的"一一对应"校验
- 供应商主数据匹配，命中后才允许自动过账
这套规则本身就是企业过去手工做票据审核时的"老师傅经验"。把它从人脑规则表沉淀成SQL脚本或规则引擎，再接进Agent的Tool Calling层，是把"识别准确率"换算成"过账准确率"的关键。
人工复核节点：不卡死流程，但要在关键路径上
即便把前三层全部做好，仍然要预留一条人工复核通道。这里有个工程上常犯的错：把人工复核放在流程最末，所有票据通过后才复核——这等于把人工放在了"无效检索"位置。
更合理的做法是把置信度阈值分档：高置信度（>0.9）直接过账；中置信度（0.6–0.9）只在规则库校验触发可疑条件时进入复核队列，例如"供应商不在主数据"、"金额大于5000元"、"税额恒等关系不成立"等；低置信度（<0.6）必入复核。
这条保留人工的链路不仅是兜底，也是反馈采集入口。低置信样本和被规则触发的中置信样本，是下一轮模型再训练的高价值样本。需要注意的是，人工复核一旦成为流程常态，必须在合同和SLA里写清楚复核时效，避免单据积压反过来拖垮整个财务周期。这一点和《具身智能进厂巡检，交付为何卡在防爆认证》里讲的"交付链路要预留验收机制"是同一个逻辑。
部署层：模型规模和并发不要被宣传数字带偏
最后说个容易被忽略的前提。当下不同多模态模型对票据的处理能力参差不齐，宣传资料里"识别率99%"通常对应清晰印刷体标准测试集。把它直接放进模糊手写票据的生产线，再好的Prompt和校验规则也救不回来那种"本身就识别错"的情况。
选型阶段要看三件事：模型对中文手写体的训练样本分布、对表格结构（而不是单行字符）的还原能力，以及在错误样本上的已知缺陷清单。后者在公开资料里常常缺位，需要企业自己做抽样盲测。
至于推理部署成本，企业若考虑本地化部署，可参考《Qwen3-Max显存占用降60%，本地部署成本真能减半吗》里提到的思路，显存、量化、KV Cache、并发四个口径分清楚，不要被单点数字带跑。OCR任务对显存没那么敏感，但对CPU解码吞吐和网络存储读取敏感，部署前实测比读财报更重要。
不是取代财务，是给财务减负
把多模态Agent放进财务自动化的真实意义，不在于彻底取代人工，而在于把那些"机器能稳定做好的80%"批量处理掉，把老师傅从重复劳动里解放出来，专心处理那20%真正需要判断的复杂异常。
这个80/20的拆分，前提是"机器识别的部分真的能信"。三件事缺一不可：分步Prompt避免幻觉、规则库做业务校验、分级人工复核做兜底。少任何一层，票据自动化的账就会在某个月突然对不上，需要更长的时间去溯源。
采购合同里把这些写明白，比追求一个虚高的识别率数字重要得多。
