1. 项目缘起为什么一家千人集团决定把财务流程交给AI1.1 一个典型的“大而不强”财务中台困境这家集团的情况很有代表性1000人左右的规模旗下10家独立法人主体业务横跨制造、贸易和少量服务。财务共享中心一共22个人要同时应付10套账、10套税务申报口径、10套内部管理报表以及集团层面的合并报表。每个月1号到10号是“结账地狱”加班到凌晨是常态最夸张的一次因为一家子公司的银行流水对不上整个合并报表拖到15号才出。我介入这个项目的时候财务总监给我看了一张表6个核心流程平均每个流程每月消耗的人工工时加起来超过340小时。这6个流程分别是费用报销审核、银行流水对账、发票查验与入账、往来款核对、税务申报数据准备、管理报表数据归集。说白了这6件事有一个共同特征——规则明确、重复度高、跨系统操作频繁但又不是完全不需要判断。这正是财务智能体最合适的切入场景。1.2 为什么不是RPA而是Agent很多人第一反应是这不就是RPA干的活吗我一开始也这么想。但实际调研后发现传统RPA在这家集团会撞上三堵墙。第一堵墙是系统异构。10家主体用了3套不同的ERP还有2家在用老旧的单机财务软件银行有7家不同银行的企业网银。RPA靠界面元素抓取界面一改就崩维护成本极高。第二堵墙是非结构化数据。费用报销里有大量手写单据、PDF电子发票、微信截图、甚至拍照的纸质出租车票。RPA对这类输入基本无能为力。第三堵墙是判断分支。比如一笔差旅费住宿标准是否超标、是否跨月、是否需要分摊到多个项目这些规则有例外、有优先级、有历史惯例。RPA只能写死if-else规则一多就变成意大利面条。Agent的优势恰好在这三点上LLM负责理解非结构化输入和模糊判断工具调用负责跨系统操作流程引擎负责编排和容错。所以最终方案是Agent为主、RPA为辅——把RPA降级为Agent的一个“手”专门处理那些必须点界面的老系统。1.3 六个流程的优先级排序逻辑六个流程不可能同时上我们按“价值密度×可行性”排了序。价值密度看的是节省工时和风险降低可行性看的是数据可得性和规则清晰度。流程月均工时规则清晰度数据可得性优先级发票查验与入账60h高高P0银行流水对账55h高中P0费用报销审核80h中高P1往来款核对50h中中P1税务申报数据准备45h中低P2管理报表数据归集50h低低P2P0的两个流程先上因为规则最清晰、数据最容易拿到能在两个月内跑出可见成果为后续争取预算和信任。这个排序策略后面被证明是对的——先做出成绩再谈扩展比一上来就啃硬骨头明智得多。2. 整体架构设计财务智能体到底怎么搭2.1 三层架构交互层、编排层、执行层整个系统我把它拆成三层这个分层方式参考了Agent架构的通用范式但针对财务场景做了裁剪。交互层负责和财务人员打交道。不是做一个聊天窗口就完事而是嵌入到现有工作流里。比如费用报销会计还是在ERP里点“审核”按钮但按钮背后触发的是Agent。发票查验则是Agent主动跑批结果推到企业微信。交互层的核心原则是不改变用户习惯只改变背后谁在干活。编排层是大脑用的是流程引擎加LLM调度。流程引擎负责确定性步骤的顺序、重试、超时、人工介入点LLM负责需要理解的那部分比如“这张发票的抬头和报销单上的公司名是不是同一家”。这里有个关键设计LLM不直接操作数据库所有写操作都通过工具调用工具是预先定义好、有权限校验、有审计日志的。执行层是各种工具和连接器。包括ERP的API连接器、银行流水的文件解析器、发票查验的OCR服务、RPA机器人用于没有API的老系统。执行层的每个工具都是幂等的这是容错的基础。2.2 为什么选LLM做“判断层”而不是规则引擎有人会问财务规则这么明确为什么不用规则引擎我的回答是规则引擎处理“明确规则”确实好但财务的痛点恰恰在“明确规则之外的例外”。举个例子一张住宿发票金额800元员工出差3天。规则引擎只能判断“800标准600超标”。但实际情况可能是该员工出差地是旺季公司有临时上调标准的口头通知或者这800元包含了两天的住宿实际日均400元没超标。这些判断需要理解上下文规则引擎写不出来LLM可以。我们的做法是规则引擎兜底、LLM处理例外。先用规则引擎过滤掉80%的明确合规单据剩下20%有疑问的交给LLM判断LLM判断不了的再转人工。这样既保证了效率又控制了LLM的调用成本和幻觉风险。2.3 多Agent协作还是单Agent多工具这是架构选型时争论最久的问题。多Agent协作听起来很美——一个Agent管发票、一个管对账、一个管报表各司其职。但实际落地时我们发现财务流程之间的耦合度比想象中高。比如对账发现的差异会影响往来款核对发票入账的科目会影响报表归集。最终我们选了单Agent多工具的方案但用“技能”做了逻辑隔离。一个主Agent加载不同的技能包发票技能、对账技能、报表技能技能之间通过共享的上下文内存传递信息。这样做的好处是状态一致、调试简单坏处是单点复杂度高。为了缓解我们把每个技能做成独立的微服务Agent只是调度器。提示如果你的团队规模不大、流程耦合度高单Agent多工具是更务实的选择。多Agent协作的调试成本在财务这种强一致性场景下会被放大。2.4 容错设计Agent出错时谁来兜底财务场景对错误的容忍度极低一分钱的差异都不能放过。所以容错设计是重中之重我们做了四层防护。第一层是工具幂等。所有写操作都带唯一业务ID重复调用不会产生重复数据。第二层是关键节点人工确认。比如超过5万元的付款、跨主体的往来调整Agent只准备数据最终确认必须人工点。第三层是全链路审计。Agent的每一步思考、每一次工具调用、每一个输入输出都落库出问题可以完整回放。第四层是影子模式。新流程上线前先跑两周影子模式Agent只出结果不执行和人工结果对比准确率达标才切换。这四层里我认为最重要的是影子模式。它让我们在正式切换前发现了大量边界问题比如某家银行的流水格式和其他家不一样、某类发票的OCR识别率特别低。这些问题如果上线后才发现代价会大得多。3. 六个流程的实操拆解3.1 发票查验与入账从OCR到自动凭证这个流程是P0里最先上线的因为它规则最清晰、见效最快。完整链路是收票邮箱/扫描/拍照→ OCR识别 → 发票查验税务接口→ 查重 → 匹配报销单或采购单 → 生成凭证 → 推送ERP。OCR这块我们踩过坑。一开始用通用OCR手写发票和褶皱发票的识别率只有70%左右。后来换成财务专用OCR模型加上图像预处理去噪、纠偏、增强对比度识别率提到95%以上。预处理这一步很关键很多团队直接跳过结果在OCR上反复调参其实问题出在输入图像质量。发票查验是调用税务的公开接口这里要注意频率限制和重试策略。我们设了令牌桶限流每秒不超过5次失败后指数退避重试最多3次。查验结果要缓存同一张发票不要重复查验。查重逻辑是发票代码号码金额开票日期四要素哈希。但实际中会遇到“同一张发票被两个员工重复提交”的情况这时候Agent会标记冲突转人工处理而不是自动选一个。生成凭证是最考验规则的部分。我们维护了一张“科目映射表”把发票的商品服务名称映射到会计科目。这张表是财务同事手工维护的Agent只负责匹配匹配不上的标记待处理。这里有个经验映射表不要追求100%覆盖覆盖80%高频项就够了剩下的长尾人工处理反而更准。# 发票查重的核心逻辑简化版 def check_duplicate(invoice): key f{invoice.code}_{invoice.number}_{invoice.amount}_{invoice.date} if redis.exists(key): return {status: duplicate, original: redis.get(key)} redis.setex(key, 90*24*3600, invoice.id) # 90天过期 return {status: ok}3.2 银行流水对账7家银行7种格式的统一对账这个流程技术难点不在算法在数据清洗。7家银行7种流水格式有CSV、有Excel、有PDF、还有需要从网银导出的加密文件。我们写了一个“格式适配器”层每种格式一个解析器统一输出标准结构交易日期、金额、对方户名、摘要、流水号。对账算法本身不复杂以金额日期为主键辅以对方户名模糊匹配。但实际中会遇到“一对多”和“多对一”的情况比如一笔收款对应多个订单或者多笔付款合并成一笔。这时候用LLM做摘要理解就很有用——把银行摘要和业务单据的备注一起给LLM让它判断是否匹配。对账差异的处理是重点。差异分三类时间性差异银行已入账企业未入账、金额差异手续费、汇率、真实差异错账、漏账。Agent对前两类自动标记并生成调整建议第三类转人工。这里的关键是不要试图让Agent自动调账调账涉及会计判断必须人工确认。注意银行流水涉及资金安全Agent的权限要严格限制为“只读建议”绝不能给写权限。我们见过有团队让Agent自动调账结果因为一笔手续费判断错误导致连续三个月的银行余额都不对。3.3 费用报销审核规则引擎与LLM的分工费用报销是六个流程里最复杂的因为规则最多、例外最多。我们的分工是规则引擎处理“硬规则”LLM处理“软判断”。硬规则包括发票真伪、金额是否超标按职级和城市、是否在报销时效内、是否重复报销。这些用规则引擎毫秒级出结果。软判断包括事由是否合理、费用归属是否正确、是否需要分摊。这些交给LLM它会结合历史报销记录和公司政策文档做判断。LLM判断的prompt设计很讲究。我们不是简单问“这笔报销合规吗”而是给它一个结构化的判断框架先看事由与费用的相关性再看金额与标准的偏离度最后看历史类似案例的处理方式。这样输出的判断更稳定也更容易解释。人工介入点设在“LLM判断置信度低于阈值”和“金额超过1万元”两个条件。置信度阈值我们设的是0.75这个值是跑了500笔历史数据调出来的。太低会漏掉问题太高会频繁打扰人工。3.4 往来款核对跨10家主体的对账网络10家主体之间的往来款核对本质是一个N×N的对账网络。A欠B、B欠C、C又欠A环环相扣。传统做法是每家主体各自对账然后集团汇总经常出现“三方对不上”的情况。Agent的做法是全局视角对账。把所有主体的往来明细拉到一起用图算法找闭环。比如A记应收B 100万B记应付A 100万匹配但如果A记100万、B记95万差额5万就要追查。Agent会自动生成差异报告标注可能的原因在途、汇率、科目错配。这个流程的难点是数据权限。10家主体财务人员只能看自己主体的数据但Agent需要全局数据。我们的方案是Agent用服务账号访问数据仓库但输出结果时按主体过滤每个财务只看到和自己相关的部分。审计日志记录Agent访问了哪些数据确保合规。3.5 税务申报数据准备从账到表的自动化税务申报的数据准备说白了就是把账上的数据按税务口径重新归集。难点在于会计口径和税务口径的差异比如业务招待费、广告费、职工福利费都有扣除限额需要纳税调整。Agent在这里做的是“数据准备”不是“申报”。它把需要调整的项目列出来算出调整金额生成申报底稿但最终的申报表还是人工填、人工审。这个边界很重要税务申报的法律责任在人不在Agent。我们维护了一张“税会差异映射表”记录每个差异项的调整规则。Agent按表逐项计算遇到表里没有的项目就标记出来由税务专员补充规则。这张表是活的随着政策变化不断更新。3.6 管理报表数据归集让Agent理解“管理口径”管理报表和财务报表最大的区别是“口径”。财务报表有准则管理报表看老板想看什么。这家集团的老板关注的是“分产品线、分区域、分客户”的盈利情况但ERP里的数据是按法人主体记的需要重新切分。Agent的做法是先定义一套“管理维度标签”给每笔收入、每笔成本打标签。标签的来源有合同信息、项目编号、客户主数据。打标签的过程用LLM辅助比如从合同文本里提取产品线和区域。标签打完报表就是简单的聚合。这个流程我们放在最后做因为它最依赖前面的数据质量。如果发票入账的科目不对、往来款没核对清楚管理报表就是空中楼阁。所以数据治理是管理报表的前置条件这一点顺序不能乱。4. 落地过程中的坑与排查技巧4.1 LLM幻觉在财务场景的三种表现LLM幻觉在财务场景特别危险因为它会“一本正经地胡说八道”。我们总结了三种典型表现。第一种是数字幻觉。让LLM算一个合计数它可能给出一个看起来合理但完全错误的数字。对策是所有计算必须用工具LLM只负责决定调哪个工具。我们写了一个计算器工具LLM传参数进去结果由代码算。第二种是规则幻觉。LLM会“发明”一条不存在的公司政策。比如它可能说“差旅住宿标准是500元”但实际是600元。对策是把公司政策文档作为检索源LLM的回答必须引用文档原文引用不上的标记为“不确定”。第三种是匹配幻觉。在对账时LLM可能把两笔不相关的交易说成是匹配的。对策是匹配结果必须给出匹配依据比如金额相同、日期相近、摘要关键词重合依据不充分的降级为“疑似匹配”转人工。4.2 流程引擎的超时与重试策略财务流程经常涉及外部系统超时是常态。我们的策略是区分可重试错误和不可重试错误。可重试的网络超时、接口限流、临时性服务不可用。这类错误用指数退避重试最多3次间隔1s、4s、16s。不可重试的参数错误、权限不足、业务规则冲突。这类错误直接失败转人工。重试还有一个坑非幂等操作不能盲目重试。比如“生成凭证”这个操作如果第一次调用超时但实际成功了重试会产生两张凭证。所以所有写操作都必须带幂等键服务端根据幂等键去重。4.3 数据权限与审计的合规红线财务数据敏感权限设计是红线。我们的原则是最小权限全程审计。Agent的服务账号权限严格按流程需要分配。发票查验只需要读发票表和写查验结果表就不给其他表的权限。对账需要读银行流水和账务数据但不给写权限。所有权限变更走审批流程记录在案。审计日志记录谁哪个Agent、什么时候、访问了什么数据、做了什么操作、结果如何。日志保留至少3年满足审计要求。这里有个细节日志本身也要防篡改我们用了只追加的存储写入后不可修改。4.4 人工介入点的设计原则人工介入点设计不好要么Agent频繁打扰人工要么出了问题人工不知道。我们的原则是按风险和不确定性分级。风险等级不确定性处理方式高高必须人工确认高低自动执行事后抽查低高Agent建议人工确认低低全自动高风险的例子大额付款、跨主体调账、税务调整。低风险的例子小额费用报销、标准发票入账。这个分级不是拍脑袋是财务和风控一起定的每季度review一次。4.5 常见问题速查表问题现象可能原因排查方向解决方案OCR识别率突然下降发票版式变化/图像质量差抽样看原始图像更新OCR模型/加强预处理对账匹配率低银行流水格式变化检查解析器日志更新格式适配器LLM判断不一致prompt漂移/上下文过长对比不同时间的prompt固定prompt版本/压缩上下文流程卡住不推进外部系统超时/幂等键冲突查流程引擎日志手动重试/清理幂等键凭证科目错误映射表缺失/LLM匹配错查映射表覆盖率和LLM日志补充映射表/调整prompt5. 上线后的效果与持续优化5.1 六个月后的真实数据上线六个月六个流程全部跑通。最直观的变化是月结时间从平均12天压缩到5天财务共享中心22个人里有6个人转岗到了业务财务分析不再做重复劳动。具体到每个流程发票查验与入账的自动化率到了92%剩下8%是特殊发票和异常情况银行流水对账自动化率88%差异处理时间从平均2小时降到20分钟费用报销审核自动化率75%因为软判断部分还是需要人工兜底往来款核对自动化率85%税务申报数据准备自动化率70%管理报表数据归集自动化率60%这个最低因为管理口径还在不断调整。5.2 准确率与人工干预率的变化曲线准确率不是一上线就高的。第一个月发票入账准确率只有82%主要错在科目映射。我们花了两周时间把映射表从300条扩充到800条准确率提到95%。第二个月对账准确率从79%提到91%靠的是优化模糊匹配算法。人工干预率的变化更有意思。第一个月干预率35%第二个月降到22%第三个月降到15%之后稳定在12%左右。这12%里大部分是高风险操作的人工确认属于设计内的干预不是Agent出错。5.3 下一步从“执行”走向“预测”现在Agent做的是“执行”——把已经发生的事处理掉。下一步想让它做“预测”——比如根据历史数据预测下个月的现金流、预测哪些客户可能逾期、预测哪些费用会超标。这需要把Agent和数据分析能力结合目前还在探索。另一个方向是多Agent协作。现在六个流程是一个Agent在跑未来如果流程更多、更复杂可能需要拆成多个专业Agent用一个“调度Agent”来协调。但这是后话现阶段单Agent够用不为了架构而架构。5.4 给同类项目的三条建议第一条先做数据治理再做Agent。数据质量不行Agent再聪明也是垃圾进垃圾出。我们花在数据清洗上的时间比花在Agent开发上的还多。第二条人工介入点宁多勿少。上线初期多设人工确认等准确率稳定了再逐步放开。财务场景出错代价高稳比快重要。第三条把财务同事拉进项目组。Agent的规则来自财务判断标准来自财务最终用户也是财务。没有财务深度参与的项目做出来一定不好用。我们项目组里有两个财务同事全职参与这是成功的关键因素之一。最后分享一个实操中的小技巧给Agent的每个判断都加上“置信度”和“依据”。置信度低的转人工依据不充分的也转人工。这个设计让财务同事对Agent的信任度大幅提升因为他们知道Agent什么时候“不确定”而不是盲目自信。信任建立起来了后续的推广就顺了。