1. 项目缘起为什么一家千人集团决定把财务流程交给AI1.1 一个很现实的起点十家主体、六套流程、一堆重复劳动先交代一下背景。这家集团大概1000人规模旗下有10家独立法人主体业务线横跨制造、贸易和服务。财务共享中心大概二十来号人日常要处理六类核心流程费用报销审核、应付账款对账、应收账款催收提醒、资金日报归集、发票查验与入账、月度管理报表初稿编制。听起来不算多但真正做过集团财务的人都知道麻烦不在流程数量而在“主体数量乘以流程数量”这个乘法效应。同一笔差旅费A主体和B主体的科目映射规则不一样同一张发票C主体要求三单匹配D主体只要求两单资金日报要把10家主体的银行流水汇总到一张表上每天光复制粘贴就要花掉一个多小时。我们最初算过一笔账共享中心人均每天花在“跨系统搬运数据、核对规则、填写固定模板”上的时间大约占全部工时的55%到60%。这部分工作有几个共同特征——规则明确、重复度高、容错要求高但创造性极低。说白了这就是典型的“适合交给机器”的活。1.2 为什么是“智能体”而不是传统RPA一开始我们考虑过传统RPA。RPA的好处是稳定、可控、实施快但它的死穴也很明显它只能处理“界面不变、规则不变、数据结构不变”的场景。而财务场景恰恰是规则经常变、单据格式经常变、异常情况特别多的领域。举个例子。费用报销里有一类“跨主体分摊”的单据一张报销单可能同时涉及三家主体的成本分摊分摊比例还跟项目归属有关。传统RPA遇到这种单据要么直接报错要么需要人工预先拆单。而基于LLM的智能体可以理解单据上的自然语言描述结合知识库里的分摊规则自动判断该怎么拆。这就是我们决定走“财务智能体”路线的核心原因我们需要的不只是一个“执行器”而是一个能理解语义、能调用工具、能在规则边界内做判断的“数字员工”。1.3 六个流程的优先级排序逻辑六个流程不是一起上的。我们按“规则清晰度、数据可得性、容错空间、业务痛感”四个维度做了排序流程规则清晰度数据可得性容错空间业务痛感优先级发票查验与入账高高中高P0费用报销审核中高高中高P0应付账款对账高中低中P1资金日报归集高高高中P1应收账款催收提醒中中高中P2月度管理报表初稿低中低低P2P0的两个流程先上因为规则相对清晰、数据都在系统里、出错后有人工兜底。P2的两个流程最后上因为管理报表涉及大量判断和口径选择智能体只能做初稿最终还是要人来定稿。这里有个经验不要一上来就挑最难的流程做。先做“规则清晰、数据齐全、错了能改”的流程跑通技术链路、建立团队信心比什么都重要。2. 技术架构财务智能体到底是怎么搭起来的2.1 整体架构三层结构各司其职我们的架构分三层第一层是交互层。财务人员通过企业微信、网页端和邮件三个入口跟智能体交互。企业微信用于日常审批提醒和简单查询网页端用于复杂任务配置和结果查看邮件用于自动发送日报和催收提醒。第二层是智能体编排层。这是核心。我们用了“主智能体子智能体”的多AI协作模式。主智能体负责理解用户意图、拆解任务、分发给子智能体子智能体各自负责一个具体流程比如“发票查验子智能体”“报销审核子智能体”“对账子智能体”。第三层是工具与数据层。包括ERP系统、发票查验平台、银行流水接口、知识库、规则引擎。智能体不直接操作数据库而是通过封装好的API和工具函数来调用。这个架构的好处是每个子智能体可以独立迭代主智能体只负责路由和协调。某个流程的规则变了只需要更新对应的子智能体不影响其他流程。2.2 为什么选LLM做核心推理引擎财务场景对准确率要求极高为什么还敢用LLM我们的判断是LLM不是用来做最终决策的而是用来做“语义理解”和“工具调用编排”的。具体来说LLM在里面的作用有三个第一理解非结构化输入。比如报销单上的“备注”字段员工可能写“这是跟XX项目相关的招待费需要分摊到三个主体”这种自然语言描述传统规则引擎很难处理但LLM可以提取出关键信息。第二决定调用哪个工具。智能体收到一个任务后需要判断该查发票、该对账、还是该发提醒。这个“路由决策”由LLM来做比写一堆if-else要灵活得多。第三生成人类可读的输出。比如催收提醒邮件LLM可以根据账龄、金额、历史沟通记录生成不同语气和内容的邮件而不是千篇一律的模板。关键原则LLM负责“理解和编排”规则引擎负责“判断和执行”人工负责“异常和终审”。三者边界清晰才能保证系统稳定。2.3 流程引擎与Agent的配合方式我们用的流程引擎负责管理“长流程”的状态。比如应付账款对账可能涉及“拉取数据→匹配→生成差异→人工确认→调整→归档”六个步骤中间可能隔好几天。流程引擎负责记录当前走到哪一步、下一步该谁处理、超时了该提醒谁。Agent则负责每个步骤里的“智能处理”。比如“匹配”这一步Agent会去理解为什么有些单据匹配不上——是金额差几分钱还是科目选错了还是发票号录错了。它会给出一个“差异原因推测”帮助人工快速定位问题。两者配合的方式是流程引擎管“流程状态”Agent管“步骤内容”。流程引擎触发一个任务Agent处理完返回结果流程引擎再决定下一步。2.4 知识库的设计规则、案例、口径三库分离财务智能体最怕什么最怕“规则打架”。同一个费用税务口径、会计口径、管理口径可能不一样。如果把这些规则混在一起塞给LLM它一定会懵。我们的做法是建三个独立知识库规则库存放硬性规则比如“差旅费住宿标准一线城市不超过500元/晚”。这些规则用结构化方式存储LLM只读不写。案例库存放历史处理案例比如“某次跨主体分摊的报销单是怎么处理的”。这些案例用于few-shot提示帮助LLM理解类似场景。口径库存放不同报表口径的说明比如“管理报表中的‘人力成本’包含社保和公积金但不包含外包费用”。三个库分开维护更新频率不同责任人不同。规则库由财务经理维护案例库由共享中心主管维护口径库由FPA团队维护。3. 六个流程的落地实录从发票查验到报表初稿3.1 发票查验与入账从“逐张核对”到“批量秒验”这是第一个上线的流程也是效果最立竿见影的。原来的做法是共享中心收到发票后人工登录查验平台逐张输入发票代码和号码核对开票日期、金额、税额然后在ERP里手动录入。一张发票平均耗时2到3分钟一天几百张发票光查验就要花掉一个人大半天。智能体的做法是发票扫描件上传后OCR先提取关键字段LLM做字段校验和异常判断然后自动调用查验接口查验通过后自动写入ERP。整个过程从“人工逐张”变成“批量自动”。这里有个细节发票查验接口有频率限制不能并发太高。我们的做法是加了一个队列智能体按批次调用每批50张间隔2秒。实测下来500张发票大约15分钟全部查验完毕准确率99.2%。那0.8%的异常是什么主要是发票模糊导致OCR识别错误或者发票状态异常比如已作废。这些异常会自动推送给人工处理并附上“异常原因推测”。实操心得OCR的准确率再高也要保留人工复核入口。我们的做法是“金额超过5万”或“OCR置信度低于90%”的发票自动转人工。这个阈值可以根据实际数据动态调整。3.2 费用报销审核规则引擎LLM双保险费用报销是六个流程里最复杂的因为涉及大量判断这个费用该不该报、该报多少、该记到哪个科目、该分摊到哪些主体。我们的审核逻辑分三步第一步规则引擎做硬性校验。比如“发票是否重复”“金额是否超标”“报销人是否有权限”。这些是硬规则不通过直接驳回。第二步LLM做语义理解和软性判断。比如报销单上写“客户招待”但发票开的是“办公用品”LLM会标记为“事由与发票内容不符”转人工确认。第三步人工处理异常。只有前两步都通过或者异常被人工确认后才进入付款流程。这里的关键是LLM不做“通过/不通过”的二元判断而是做“风险标记”。它输出的是一个风险评分和风险原因列表最终决策还是由规则引擎和人工来做。我们统计过上线三个月后报销审核的人工介入率从100%降到了23%。也就是说77%的报销单可以自动通过只有23%需要人工看一眼。3.3 应付账款对账差异原因自动归因应付对账的痛点是“差异多、归因难”。供应商发来的对账单和ERP里的应付明细经常对不上。传统做法是人工逐条比对找出差异后还要打电话跟供应商确认。智能体的做法是自动拉取双方数据做匹配对不上的生成差异清单然后用LLM分析差异原因。LLM会看采购订单、入库单、发票、付款记录推测差异是“时间性差异”还是“实质性差异”。比如供应商说我们欠他10万但我们系统里只有8万。LLM会去查是不是有一张发票还没入账是不是有一笔付款供应商还没确认是不是有退货没处理它会给出几个可能的原因并按可能性排序。这个功能上线后对账人员从“找差异”变成了“确认差异原因”效率提升非常明显。3.4 资金日报归集从手工汇总到自动生成资金日报原来是最枯燥的活。10家主体每家2到3个银行账户每天要把流水导出来汇总到一张表上计算当日余额、当日收支、可用余额。智能体直接对接了银行流水接口通过企业网银的授权方式每天定时拉取数据自动汇总生成日报早上8点前发到财务总监邮箱。这里有个坑不同银行的流水格式不一样有的用“收入/支出”有的用“借方/贷方”有的金额带负号有的不带。我们的做法是写了一个标准化层把不同格式统一成“日期、主体、账户、金额、方向、摘要”六个字段再交给智能体处理。注意事项银行接口的稳定性是个大问题。我们做了重试机制和降级方案——如果接口拉取失败自动切换到“邮件解析”模式从银行发的对账单邮件里提取数据。虽然麻烦一点但保证日报不断档。3.5 应收账款催收提醒分级策略个性化话术催收提醒这个流程难点不在“发提醒”而在“发得恰到好处”。发太频繁客户反感发太少回款慢。我们的策略是分级账龄30天以内不发提醒只在系统里标记。账龄30到60天发温和提醒语气客气。账龄60到90天发正式催收函抄送销售负责人。账龄90天以上升级处理自动生成“催收任务”派给销售和财务。LLM在这里的作用是生成个性化话术。它会参考历史沟通记录、客户类型、欠款金额生成不同语气的邮件。比如对老客户语气委婉对新客户语气正式对大额欠款语气紧迫。3.6 月度管理报表初稿智能体做80%人做20%管理报表是最难自动化的因为涉及大量判断和口径选择。我们的定位很明确智能体只做初稿不做终稿。智能体负责从各系统拉取数据、按模板填充、计算同比环比、生成文字说明初稿。财务分析师负责审核数据、调整口径、补充业务解释、定稿。实测下来智能体可以完成80%的数据处理工作分析师只需要花20%的时间做判断和润色。原来需要3天完成的月报现在1天就能出初稿。4. 踩过的坑与排查技巧实录4.1 LLM“幻觉”在财务场景的典型表现LLM幻觉在财务场景里非常危险。我们遇到过几种典型情况第一种数字幻觉。LLM在生成文字说明时会“编造”一个数字。比如实际毛利率是18.3%它写成18.5%。这种错误如果没被发现直接发出去就是事故。我们的对策是所有数字必须从结构化数据里取LLM只负责“描述趋势”不负责“提供数字”。文字说明里的数字用占位符最后由程序替换。第二种规则幻觉。LLM会“发明”一条不存在的规则。比如它说“根据公司规定差旅费住宿标准是600元”但实际规定是500元。对策是规则库用结构化存储LLM只能引用不能生成。如果LLM的输出里出现了规则库以外的规则系统自动标记为“待确认”。第三种工具调用幻觉。LLM会调用一个不存在的工具或者用错误的参数调用工具。对策是工具调用加一层校验参数格式不对直接拒绝并返回错误信息让LLM重新调用。4.2 多主体规则冲突的解决思路10家主体规则不可能完全一致。比如A主体要求“所有报销必须附发票”B主体允许“500元以下可以凭收据报销”。我们的解决思路是规则按主体隔离智能体按主体加载。每个主体有自己的规则配置文件智能体在处理任务时先识别主体再加载对应规则。如果一笔业务涉及多个主体比如跨主体分摊智能体会分别加载各主体的规则然后做“规则交集”或“规则并集”判断。具体用交集还是并集取决于业务类型。实操技巧规则冲突时不要试图让LLM“自己判断”。正确的做法是把冲突点列出来让LLM生成一个“冲突说明”推送给人工决策。人工决策后这个案例进入案例库下次遇到类似情况LLM可以参考。4.3 接口不稳定时的降级方案财务系统对接的接口稳定性参差不齐。银行接口、税务接口、ERP接口都可能出问题。我们的降级策略分三级一级降级重试。接口超时或返回错误自动重试3次间隔递增。二级降级切换数据源。比如银行接口挂了切换到邮件解析模式。三级降级转人工。如果自动方式都失败生成“待处理任务”推送给人工并附上失败原因。这套机制上线后因为接口问题导致的流程中断从每周3到4次降到了每月1到2次。4.4 常见问题速查表问题现象可能原因排查步骤解决方案发票查验失败率突然升高查验接口限流或发票集中异常查看接口返回码、检查发票批次降低并发、分批处理、人工复核异常发票报销审核通过率下降规则库更新或LLM提示词漂移对比规则库版本、检查LLM输出回滚规则库、重新校准提示词对账差异归因不准案例库不足或数据缺失检查案例库覆盖度、核对源数据补充案例、修复数据接口资金日报数据缺失银行接口故障或格式变化检查接口日志、对比历史格式切换降级方案、更新解析规则催收邮件语气不当LLM提示词需要调整抽查邮件内容、收集反馈调整提示词、增加人工审核环节4.5 智能体安全与权限控制财务智能体涉及资金和敏感数据安全是底线。我们做了几件事第一最小权限原则。每个子智能体只能访问它需要的系统和数据。发票查验子智能体不能访问银行流水对账子智能体不能访问报销数据。第二操作审计。智能体的每一次工具调用、每一次数据读写都记录日志。日志保留至少一年支持按时间、按主体、按操作类型检索。第三敏感操作二次确认。涉及付款、冲销、调整的操作智能体不能直接执行必须生成“待确认任务”由人工确认后才能执行。第四输入输出过滤。智能体的输入和输出都经过敏感词过滤和格式校验防止注入攻击或数据泄露。5. 上线后的效果与团队变化5.1 效率数据不是“替代”是“重新分配”上线半年后我们做了一次全面复盘。几个关键数据发票查验从日均处理200张提升到日均处理800张人工介入率从100%降到8%。费用报销审核周期从平均2.3天缩短到0.7天人工介入率从100%降到23%。应付对账对账周期从每月5天缩短到2天差异归因时间从平均30分钟/条降到5分钟/条。资金日报从每天1.5小时人工汇总降到每天10分钟自动生成人工复核。应收催收提醒覆盖率从60%提升到100%回款周期平均缩短4.2天。管理报表初稿编制时间从3天降到1天。但更重要的是共享中心的人没有减少而是把时间从“搬运数据”转移到了“异常处理、规则优化、业务支持”上。用财务总监的话说“以前是人在伺候系统现在是系统在伺候人。”5.2 团队能力结构的变化智能体上线后团队需要的能力变了。原来最吃香的是“Excel熟练、录入快、细心”的人现在最吃香的是“懂业务、能写规则、会分析异常”的人。我们做了几件事来帮助团队转型第一内部培训。每周一次“智能体使用与优化”分享会让团队成员讲自己遇到的案例和解决方法。第二角色重新定义。把共享中心的人分成三组规则维护组、异常处理组、业务支持组。规则维护组负责更新规则库和案例库异常处理组负责处理智能体转来的异常业务支持组负责跟业务部门沟通需求。第三考核指标调整。从“处理量”转向“准确率”和“优化贡献”。比如谁发现了一个规则漏洞并修复了谁就获得奖励。5.3 业务部门的反馈业务部门一开始是观望态度觉得“财务又搞新花样”。但用了几个月后反馈明显变好。最大的变化是“透明度”。以前报销单交上去不知道走到哪一步了现在智能体会自动推送进度。以前对账差异要打电话问财务现在系统里直接能看到差异原因。还有一个意外收获智能体在审核报销时会标记“事由与发票内容不符”的单据。这个功能上线后业务部门的报销规范度明显提升因为大家知道“系统会看”。6. 后续扩展方向与个人体会6.1 从六个流程到更多场景六个流程跑通后我们开始考虑扩展。几个方向第一税务申报辅助。智能体可以自动归集进项销项数据生成申报表初稿人工确认后提交。第二预算执行监控。智能体可以实时监控各主体的预算执行情况超预算时自动预警。第三合同财务条款审核。智能体可以读取合同文本提取付款条件、发票要求、违约责任等财务相关条款辅助财务审核。第四审计支持。智能体可以自动整理审计所需的凭证、合同、流水减少审计期间的资料准备工作。6.2 个人体会智能体不是“万能药”做了这个项目我最大的体会是智能体不是万能药它解决的是“规则明确但重复度高”的问题。对于“规则不明确、需要大量判断”的场景智能体只能做辅助不能做替代。另外智能体的效果高度依赖“数据质量”和“规则清晰度”。如果源数据一团糟规则天天变再好的智能体也跑不起来。所以上智能体之前先把数据治理和规则梳理做好比什么都重要。最后不要指望智能体“一次上线就完美”。它是一个持续迭代的过程。我们的智能体上线半年规则库更新了47次提示词调整了23次案例库从0条积累到300多条。每一次迭代都是业务人员和技术人员一起打磨的结果。如果你也在考虑上财务智能体我的建议是从小处着手选一个规则最清晰的流程先跑通建立信心积累经验再逐步扩展。不要一上来就搞“大而全”那样大概率会失败。这个项目后续还可以这样扩展把智能体的能力开放给业务部门让业务人员在提交报销前就能自查或者把智能体的异常处理经验沉淀成培训材料帮助新员工快速上手。财务智能体的价值最终不在于“省了多少人”而在于“让财务人员能做更有价值的事”。