1. 单证处理困境到底难在哪：先认清边界再谈自动化
做了这么多年企业数字化转型咨询，几乎每隔一阵子就会有人拿着"单证处理"的话题来找我聊。这里的单证不只是进出口贸易里的提单、发票、装箱单，还包括合同、报关单、原产地证书、保险单这类"长在业务链条上"的凭证文件。标题里那个"科技云报到"挂在前面，说白了就是行业里对这类问题的关注度已经顶上来了——大量企业卡在同一个地方：数据量越来越大，单据种类越来越多，规则越来越复杂，人工处理速度跟不上，传统自动化又只能解决一部分。
先说一个我接手过的典型项目。某大型贸易公司每天要从千余封邮件、传真、客户门户里下载各类单证和附件，之后由单据组十几个人逐一核对品名、数量、金额、贸易条款、收发货人信息，再把数据录入到ERP系统，最后归档。听起来就是"下载-识别-录入-归档"四步，但真做起来每个环节都有坑。邮件里夹带的扫描件清晰度参差不齐，发票格式每家一个样，有的PDF自带多层图片，有的表格藏在签字盖章下面，还有一批来自不同国家和地区的法定单证，语言、币种、单位习惯都不同。人工处理一单平均需要3到5分钟，遇上争议单据、缺页、要素不一致的情况，一单挂在待处理队列里好几天也不稀奇。
这里面的矛盾不是简单的"人手不够"，而是三个层面的撕裂。第一层是非结构化数据的读取问题。传统OCR已经能识别印刷体文字，但真实单证里大量信息位置不固定、存在水印干扰、印章和文字重叠，"哪段文字代表什么字段"这件事本身就是个判断题。第二层是规则之间的冲突。比如供应商发票上的金额和采购订单对不上，客户合同里要求的贸易条款与报关单不一致，这类异常必须有人去判断谁优先、谁让步、谁需要重新确认。第三层是跨系统流程的断点。单证数据往往同时流经邮件系统、共享文件夹、业务系统、归档系统，十几个节点各自孤立，没有统一调度，流程跑一半就断掉。
很多企业第一反应是上RPA，想着"把人工操作录成自动化脚本不就行了"。这个思路对了一半。RPA在规则明确、输入稳定的场景下非常好用，比如固定格式的Excel数据整理、登录系统逐个页面填写表单、定时下载指定目录文件。但单证处理恰恰是输入极不稳定、规则需要动态判断的场景，传统RPA脚本一旦遇到没见过的新版式、识别置信度低、模棱两可的字段，就会直接报错或按错逻辑跑下去，反而制造更多需要人工擦屁股的中间状态。
所以我的判断很明确：单证处理的破局点不在于换更贵的OCR，也不在于堆更多机器人。关键在于把"确定性执行能力"和"智能判断能力"组合起来——也就是RPA和Agent的融合。接下来我把这套思路、落地路径和实操中踩过的坑展开聊。
1.1 单证处理的全景：从一份采购订单到归档的全流程
要理解融合方案为什么管用，先得把单证处理实际走过的路还原出来。以进口贸易为例，一张进口报关单背后至少串着采购订单、供应商发票、装箱单、提单、原产地证、保险单、外汇申报资料，大约6到8类文件。操作员要做的事情可拆成六个子任务：抓取与下载、分类与归集、字段提取、比对校验、审批决策、归档与分发。
抓取和下载看着简单，但每家客户来源不同，有邮件附件、有FTP、有网页门户、有共享网盘。分类与归集更麻烦，同样是"invoice"这个词，有的指商业发票，有的指形式发票，有的只是内部对账凭证，靠文件名判断根本不靠谱。字段提取环节，每类单据的字段位置不同，需要在整张版面上定位并抽取关键要素。比对校验就是拿着抽取结果和ERP里的业务单据逐项核对，确认金额一致、数量一致、贸易条款一致。到了审批决策阶段，正常单据直接放行，异常单据要分级处理——小问题打回让业务部门确认，大问题升级到主管人工介入。最后则是把全套资料按一定命名规则归档进文档管理系统。
我让团队的几个分析师专门统计过单据组的时间分布，结果很出乎管理层意料：真正"录数据"的时间只占25%左右，剩下75%全耗在了下载等待、反复核对、处理异常、沟通确认上。这意味着即使把录入速度提升一倍，整体效率也只能提高不到15%。真正的瓶颈在于判断类、沟通类、协调类工作，这些恰恰是RPA过去不擅长、Agent开始展现出优势的地方。
1.2 三大痛点：非结构化数据、规则冲突、异常升级
把痛点抽象成三类，才方便设计技术方案。
第一类是非结构化数据。单证里的信息不仅是"文字"，还有空间布局、视觉层级、印章区域、手写批注。A公司的发票里"金额"字段在右上角，B公司的在左下角，C公司的干脆做成表格嵌套。通用OCR能识别出"这些字符是文字"，但要判断"这个数字是单价还是总价"就需要版面理解能力。第二类是规则冲突。一份单据可能同时被采购系统、结算系统、合规系统引用，三个系统对同一个字段的定义口径不一致。比如发票金额含税还是不含税、数量单位是"件"还是"箱"、原产地认定标准按哪个协议执行，这些规则散落在合同条款、内部制度、监管要求里，不可能用几个if-else写全。第三类是异常升级。真正需要人处理的往往不是整单异常，而是在处理路径的某个节点上出现偏差，比如单单不符、单货不符、海关查验、客户临时改单。这些"半路杀出来"的情况没有固定模板，必须有角色能理解语境、搜集上下文、做出决策。
我常打一个比方：传统RPA像流水线上的固定机械臂，设定的轨迹多精准就多精准，但工件一旦歪一点，它不会自己调整。Agent更像一个刚入职的助理，会看文件、能理解规则、能判断异常，但手速慢、容易犯低级错误。把助理的判断能力和机械臂的执行效率组合到一起，才是解决这类复杂流程的正解。
1.3 传统RPA的极限：确定性流程遇上不确定世界的摩擦
不是说RPA过时了，而是需要认清它的能力边界。RPA的本质是"按编排好的脚本，操作现有的用户界面"。它不关心业务含义，只关心动作序列。一旦前置条件变化，比如网页按钮位置改了、弹窗多了一层、文件命名规则调整，脚本就会失灵。在单证处理这个场景里，"输入稳定"恰恰是奢求——供应商会换发票版式，客户会调整PO编号规则，海关会更新申报栏目，监管要求更是年年变。RPA维护团队因此陷入无休止的救火状态。
有人问，那用智能OCR加规则引擎行不行？智能OCR确实解决了版面识别的问题，但OCR输出的是候选字段列表，后续的校验、匹配、决策仍需大量规则配置。规则引擎能覆盖"金额不一致就标红"这类简单判断，但覆盖不了"虽然金额不一致，但合同允许3%以内的溢短装"这类业务理解。规则多了以后，配置和运维成本又直线上升，最终变成一张没人敢碰的规则蜘蛛网。
所以单证处理的正确演进路径，是让RPA继续承担它擅长的确定性执行、让Agent承担动态理解与判断、两者通过流程编排层协同工作。这也是为什么行业内越来越多人把"RPA+Agent融合"视为破局关键，而不是单独讨论某一个产品。
2. RPA和Agent的分工逻辑：手脚与大脑
融合方案要落地，第一步是把两类技术的能力边界划清楚。我在不同场合听过很多混淆的说法，有人觉得"RPA已经能被AI替代了"，有人觉得"Agent是RPA的下一代产品"。这两种理解都不准确。它们解决的不是同一类问题，更像人的"手脚"和"大脑"之间的关系。
2.1 RPA是确定性执行器：擅长什么，不擅长什么
RPA最适合的工作有三个特征：规则明确、步骤固定、输入输出结构稳定。比如每天从邮件下载Excel附件并存入指定目录、按照固定模板把数据填入ERP界面、定时生成报表并发送到群组。这些任务只要跑通一次，之后的风险主要来自环境变化而非理解偏差。
RPA不擅长的也有三类：处理例外、识别模糊、理解业务意图。举个例子，让RPA解析一封带有10个附件的邮件，其中3个附件与主题无关，RPA无法自行判断哪些该下载。再比如，供应商发票上的"Total"旁边既有小写金额又有大写金额还有一条手写备注，RPA不知道应该取哪个。它也不理解"这笔订单已经逾期，需要优先处理"背后的业务紧迫性。
所以，我在设计融合方案时的原则是：能用规则写清楚的事情不要塞给Agent，RPA能稳定执行的任务绝不交给大模型推理。这不是保守，而是对成本、时延和稳定性的基本尊重。
2.2 Agent是推理决策器：擅长什么，风险在哪里
Agent可以理解为大语言模型加记忆、规划、工具调用能力之后形成的智能执行体。它能阅读理解整份单证的语义，把"发票编号"从一段自然语言描述中识别出来；它能根据上下文判断"这个异常该走哪条审批路线";它能基于历史处理记录，给出"可能是单价填错了而不是数量填错"之类的推断。
Agent的短板同样明显。第一是确定性差，同一个输入在不同时间可能给出略微不同的判断，这让追求审计可复现的财务环节很难直接接受。第二是幻觉风险，模型可能一本正经地给出一个看似合理的字段值，实际却是编造的。第三是执行动作不够可靠，让Agent去点击网页按钮、切换窗口，它的准确率和速度远不如RPA。第四是成本高，每一次大模型调用的token费用，比RPA脚本跑一步要贵得多。
2.3 融合的边界：让该确定的确定，让该推理的推理
把两者放在同一个流程里，本质是建立一种"各管一段"的协作模式。我把常见场景归纳成一张对照表，方便判断哪些环节留给RPA、哪些环节引入Agent：
| 环节类型 | 典型动作 | 建议承担者 | 理由 |
|---|---|---|---|
| 采集下载类 | 从邮件/FTP/门户抓取文件 | RPA | 路径稳定、格式固定、需高可靠性 |
| 归类判断类 | 判断附件属于发票、提单还是装箱单 | Agent+RPA | 涉及语义理解，但归类结果需稳定输出 |
| 字段抽取类 | 定位发票号、金额、日期等要素 | 智能OCR+Agent校准 | OCR提供候选，Agent负责逻辑校验 |
| 比对校验类 | 发票金额与采购订单是否一致 | RPA做基础比对，Agent做差异解释 | 基础逻辑用规则，差异需理解合同条款 |
| 异常决策类 | 偏差是否允许、走哪条审批路径 | Agent | 需要上下文理解与策略选择 |
| 审批执行类 | 在ERP中填写审批意见、提交审批 | RPA | 操作界面需确定性执行 |
| 归档分派类 | 重命名文件、归入文件夹、通知相关人 | RPA | 简单重复，规则明确 |
这个表格也是每次和客户交流时的"破冰工具"。很多管理者看了之后就明白，融合不等于全部智能化，而是重新切割分工图谱，让每种技术做自己最擅长的事。
我在实际项目中还发现一个规律：Agent的判断结果最好以结构化数据的形式交给后续环节，而不是直接让它操作业务系统。也就是说，让Agent输出一个JSON对象，里面包含"文件类别、字段提取结果、差异说明、建议处理动作、置信度"，再由RPA根据这个结构化结果去执行具体操作。这样做的好处是，既保留了Agent的理解能力，又让执行环节保持RPA的确定性和可审计性。
3. 融合落地的三条可行路径
讲完原理，说点能直接照着做的。RPA加Agent融合不是一个产品功能，而是一种架构选择。我过去半年在几个模拟项目里反复试验，总结出三条落地路径，企业可以根据自身系统成熟度挑选。
3.1 路径一：RPA执行+Agent判断的"混合流水线"
这条路径适合已有RPA流程、希望在不推翻现有体系的前提下引入智能能力的团队。做法是在原有RPA流程的关键节点上插入"Agent判断服务"。以发票自动入账为例：RPA先从邮件下载发票PDF并调用OCR识别，OCR得到的候选字段直接交给Agent校验；Agent检查字段之间的逻辑关系，比如发票号格式是否正确、税率是否在合理区间、金额大小写是否一致，输出"通过"或"异常原因"；RPA根据Agent的结果决定继续录入还是挂起。
这条路径改造量最小，RPA厂商和Agent框架之间通过HTTP接口或消息队列对接即可。我在一个模拟项目里试过，把原来自带的简单规则校验替换成Agent校验后，发票字段错漏率下降超过六成，而RPA脚本本身几乎没动。关键在于Agent判断接口要设计成"输入结构化、输出结构化"的黑盒服务，尽量避免把大段提示词和业务流程耦合同居在同一个代码库里，否则后续改任何一端都会牵一发动全身。
3.2 路径二：Agent编排+RPA调用的"任务分发式架构"
这条路径适合从零设计新系统，或者业务流程本身复杂度高、变化频繁的团队。架构上不再是"RPA为主、Agent点缀"，而是让Agent作为流程编排中枢，负责理解任务、拆分步骤、派发动作；RPA作为Agent的工具之一，被远程调用执行具体界面操作。
实现上可以想象成这样逻辑：Agent先读取任务队列，比如一封新邮件携带的提单、发票和检验证书；它规划出处理步骤清单；然后逐项调用RPA去操作ERP、调用OCR去识别文件、查询业务数据库获取历史记录；每一步的结果回传给Agent，Agent根据反馈决定下一步动作。这套模式的好处是极高灵活性，供应商换版式、新加一类单据、调整校验优先级，只需要调整Agent的规划逻辑和提示词，不用重写一整套RPA脚本。
系统层面要搞清楚的是任务状态管理。Agent编排的任务往往跨多个系统、跨越较长周期，如果一条任务跑到一半进程重启，必须能从断点恢复。我建议用数据库表维护任务状态，字段至少包含：任务ID、步骤编号、输入数据、输出结果、执行状态、失败原因、重试次数。Agent每次执行前后都向状态表写入当前进度。这个状态表是整个分布式编排模式的基石，没有它，再聪明的Agent也只是个"烂尾项目制造机"。
3.3 路径三：人机协同兜底与回滚机制
无论走哪条融合路径，都不能漏掉人工兜底。单证处理牵涉真金白银，错误成本很高。我把这个思路叫作"人机协同三层漏斗"。第一层是全自动处理，Agent和RPA能够高置信度完成的单据直接走完流程；第二层是半自动复核，Agent发现异常或置信度中等时，先把单据挂到复核队列，由人通过一个简洁的界面确认是否放行；第三层是完全人工，Agent判断该单涉及重大争议、法规风险或者历史相似案例很少时，必须交给专人处理。
有一个让我印象很深的教训：某次模拟中，Agent对一张金额差异异常的单据给出了"允许通过"的建议，原因是历史数据里确实存在类似情况，但这个历史记录本身就来自一次人为错误。所以融入了"回滚机制"——当Agent的建议与经验库中记录的正确模式冲突时，强制降级到人工复核。宁可在第二层多花人力，也不能在第一层放跑不该放跑的单据。
4. 实操阶段的关键细节：评估、调试与验收
方案讲得再好，落地时总有一堆细节决定成败。这一章的经验全部来自实际操作，尤其是那些容易被宣传材料带偏的坑。
4.1 先给业务环节做个"可自动化+可智能化"双维评分
动手之前，先别急着选型，把现有单证流程里的每个环节拿出来打分。我常用两个维度：规则稳定度和理解复杂度。规则稳定度高、理解复杂度低的环节，比如下载附件、文件重命名、数据录入，直接安排RPA；规则稳定度低、理解复杂度高的环节，比如异常判断、争议识别，安排Agent；介于中间的部分采用协作模式。
例如"提取发票日期"这个环节，规则稳定度中等，因为不同发票位置不同；理解复杂度中低，因为日期格式相对统一，适合OCR加轻量Agent校准。"判断该不该接受一份无合同编号的采购订单"这个环节，规则稳定度低，因为要靠上下文理解；理解复杂度高，必须Agent介入。
我建议以周为单位统计每个环节的日常处理量和异常率，做成矩阵后和业务负责人逐条对齐。这套评分表既是技术选型的依据，也是后续评估改进效果的基线，没有基线的自动化改造很容易变成"凭感觉说效率提升"。
4.2 让Agent处理单证的提示词与上下文策略
Agent在处理单证时的提示词设计，远不止写一段"请帮我提取字段"。我实际用下来效果不错的做法，是把提示词拆成四段结构。上下文段描述当前业务场景和单据类型，说明这封邮件来自哪个业务伙伴、对应的订单号、涉及的贸易条款；任务段列出需要输出的字段清单，每个字段给出明确的数据格式；示例段提供一份真实单据的示例，让模型理解"这个字段在这个版式里长什么样";输出约束段规定仅返回JSON结构，指定字段名和容错策略。
上下文策略里有个关键细节——把与当前单据相关的历史处理记录拼进上下文，而不是只让Agent看这张单据本身。比如一条单据需要判断"这种提单上的发货人缩写是否可接受"，如果Agent只知道当前提单信息，它很难判断缩写是否属于常用别名；如果把该客户过去半年的提单数据进行汇总，告诉Agent"该客户历史提单中发货人字段有70%采用长名称、30%采用缩写"，判断准确率会明显提升。这个做法有点像给新人入职培训时先把过往项目档案丢给他看，信息越充分，判断越靠谱。
{ "task_id": "doc-20241101-0038", "doc_type": "commercial_invoice", "context": { "po_number": "PO-20241015-008", "supplier": "sample_vendor", "trade_terms": "FOB Shanghai" }, "extract_fields": [ {"name": "invoice_no", "type": "string", "required": true}, {"name": "invoice_date", "type": "date", "format": "YYYY-MM-DD"}, {"name": "total_amount", "type": "decimal", "scale": 2}, {"name": "currency", "type": "string", "enum": ["CNY", "USD", "EUR"]} ], "validation_rules": [ {"check": "total_amount > 0"}, {"check": "currency in ['CNY', 'USD', 'EUR']"} ], "output_format": "json_strict", "fallback_action": "pending_manual_review" }上面这段是我常用的一种任务定义样例。注意"fallback_action"这一项，它决定了Agent无法高置信度判断时该干嘛。我强烈建议所有字段都设置兜底动作，而不是让模型硬选一个结果。
4.3 上线验收：测试集、指标与灰度方案
第一次上线融合流程时，测试集不能只用几张"干净"的样例。我在项目里会专门构造一个"魔鬼测试集"，包括模糊扫描件、印章遮挡的金额、手写备注、中英混合单据、故意漏页的PDF、以及部分供应商独有的版式。每个测试样本都要预先标注"标准答案"，用于对比Agent输出。
评估指标我优先看三个。字段级准确率，即每个字段提取正确的占比，要分字段统计，不能只有一个总体准确率；端到端通过率，即无需人工干预直接走完全流程的单据占比，这个比例直接影响成本；平均处理时长，对比改造前人工处理时间和改造后全流程处理时间。我在一个模拟项目里看到端到端通过率从0提升到65%左右，看起来好像还有35%的单据要人工处理，但实际人力成本下降了六成左右，因为剩下的单据大多只需快速确认而非从零录入。
上线节奏上务必走灰度。先用10%的真实流量跑两周，观察异常率、Agent误判类型、RPA失败点，再逐步放大。直接全量切换基本上都会在某个"意外版式"面前现原形，比如一家新供应商的发票编号规则和模型见过的完全不一样。灰度期还要安排最有经验的单据员参与复核，他们的直观判断往往是发现方案漏洞最快的途径。
5. 常见问题与排查经验
融合方案上线后，日常运营中的问题排查比开发调试更考验功底。这里整理几类我反复遇到的情况和处理思路。
5.1 吞吐量上不去：确定流程也要考虑并发
有次模拟环境里，RPA脚本串行处理邮件附件，一单流程走完要2分钟，每天几百单根本处理不完。排查发现卡点不是Agent调用，而是RPA脚本把"下载附件"和"识别录入"放在了同一条串行链路里。优化方式是把流水线改造成并行队列：RPA只负责快速下载和粗分类，下载完成即投递到消息队列，下游由多个OCR实例和Agent服务并发处理。
从这个教训里提炼出的原则是：在融合流程设计中，不要把Agent调用夹在RPA脚本内部的同步循环里，否则Agent的一次推理延迟会拖慢整条流水线。更好的做法是引入中间队列，把"采集"和"处理"两个阶段解耦，让各部分按自己的节奏并行推进。好比餐厅里点单、后厨、传菜各干各的，而不是传菜员站在后厨等菜炒好。
5.2 Agent误判导致环节流转错误
一次模拟中，Agent把一张"形式发票"误判为"商业发票"，导致系统按错误单据类型走了正式合同的校验流程，整单被打回。排查后发现，误判原因不是模型能力不够，而是提示词里对"形式发票"的说明不足，样例也偏少。解决办法有两步：一是扩充提示词中的单据类型定义，明确每种类型的功能差异；二是把分类决策从Agent的直接输出改成"Agent给出各类别可能性，由规则层根据业务上下文二次决策"。
比如可以要求Agent输出的不是"商业发票"一个字符串，而是"类别概率分布"和"关键依据"。规则层再结合发件人邮箱域名、邮件主题、历史单证归类记录做最终决策。这等于给Agent的判断加了一道规则闸门，既能利用模型的语义理解，又避免了单一判断的偶发性错误。
5.3 权限与审计如何补位
融合了Agent之后，最容易在审计环节被挑战的问题是"这个操作是谁做的？判断依据是什么？"传统RPA时代，日志记录每步操作鼠标点击位置、屏幕截图即可，但Agent的判断过程是黑盒，很难直接拿出证据。
我建议从第一天就建立三层审计机制。操作层由RPA记录执行细节，包括时间戳、界面截图、输入输出数据。决策层由Agent输出推理摘要，包括"基于哪些字段得出该结论""参考了哪些历史案例""置信度多少"。流程层把整个单据处理链路的完整轨迹存档，包括中间队列流转记录、状态变更记录、人工复核意见。这些数据要存成结构化日志，至少保留半年以上，以备审核。
有一次客户在外部审计时被问到"为什么允许这笔金额偏差通过"，我们直接从系统里调出Agent的判断摘要，显示"偏差率为2.8%，未超过合同约定的3%浮动区间，基于采购订单XX条款"，审计人员当场确认通过。这件事让我更确定：融合方案必须把"决策可解释"当作一等公民功能来设计，而不是事后补丁。
6. 一些个人体会与方向判断
做了一系列单证处理项目之后，我最大的体会是：RPA和Agent融合不仅在技术层面成立，更重要的是它改变了团队对自动化的预期管理。过去上RPA，大家期待的是"机器完全替代人"；实际上线后，人们往往因为异常层出不穷而失望。现在换到融合框架，预期变成了"机器处理常规，人专注例外"，这个表述更贴近现实，团队成员接受度也高很多。
如果你所在的团队正准备启动类似改造，我给三点建议。第一，不要执着于让Agent一步到位解决所有问题，先把"分类和异常识别"这两个高频场景打通，积累经验后再扩展。第二，给Agent建立"拒答"权限，遇到不确定的情况允许说"我不确定，需要人来看"，宁可增加人工复核量也不要硬猜。第三，周期性地复盘Agent的错误案例，每个错误都是一个改善提示词或调整规则的机会，拼到最后比的就是谁的错误反馈闭环更短。
这个方向还远没到天花板。随着模型上下文窗口扩大和多模态能力的增强，Agent对复杂单证的理解会越来越接近有经验的单据员。但无论技术怎么演进，有一条不会变：把确定性的执行交给RPA，把不确定性的判断交给Agent，再把关键环节留一道人工复核闸门。遵循这个原则去做，大概率不会跑偏。
