1. 项目缘起为什么一家千人集团决定把财务流程交给AI1.1 从“月底加班地狱”说起先交代一下背景。这家集团体量不算小1000人左右旗下有10家独立法人主体业务横跨制造、贸易和一部分服务类收入。财务共享中心大概20来号人要同时应付10套账、10套税务申报口径、10套内部管理报表。每个月末到次月10号整个财务团队基本处于“白天开会、晚上做账”的状态。真正压垮他们的不是做账本身而是跨主体的数据搬运和核对。举个最典型的场景一笔内部交易A主体开票给B主体B主体认证抵扣月底还要做内部往来对账、抵消分录。这套动作在10个主体之间两两组合理论上最多有90组往来关系。财务经理跟我说过一句话我印象特别深“我们不是不会做账是没时间思考全耗在找差异上了。”这就是他们决定上财务智能体的直接动因——不是赶AI的时髦而是流程性、重复性、规则明确但数据分散的工作已经把人逼到墙角了。1.2 六个流程是怎么选出来的他们没有一上来就“全面AI化”而是先做了一轮流程盘点。盘点维度有三个发生频率、规则明确度、数据可获取性。三个维度都高的流程优先上任何一个维度低的先放一放。最终选定的六个流程是流程频率规则明确度数据可获取性优先级费用报销审核每日高高P0发票查验与入账每日高高P0银行流水对账每日高高P0内部往来对账每月中高中P1税务申报数据准备每月中中P1管理报表生成每月中中P1这个排序逻辑很实在先把每天都要干、规则又死板的活儿交出去让团队先尝到甜头、建立信心再啃月度级别的硬骨头。我特别认同这个节奏很多项目失败就失败在一上来就挑最复杂的流程结果三个月看不到效果预算和耐心一起耗尽。1.3 一个关键决策不做“全自动”做“人机协同”这里有个很重要的取舍。市面上很多方案鼓吹“端到端全自动”但这家的财务总监很清醒财务是有法律责任的出了事签字的人要担责。所以他们的定位是“AI做初筛和准备人做终审和决策”。具体来说AI负责数据抓取、规则匹配、异常标记、草稿生成、差异定位。人负责异常复核、例外审批、最终过账、对外报送。这个边界划得很清楚后面所有的技术选型和流程设计都围绕这个原则展开。我的经验是财务场景里“全自动”是个伪命题。不是技术做不到是责任链条不允许。把AI定位成“超级助理”而不是“替身”项目反而更容易落地。2. 技术架构LLM、Agent和流程引擎怎么搭2.1 整体架构分层他们的架构不是那种“一个大模型包打天下”的思路而是分了三层各司其职第一层是流程引擎层用的是成熟的工作流引擎他们选的是开源方案自建负责编排、调度、状态管理、人工节点插入。这一层不碰AI就是老老实实做流程控制。为什么因为流程的可靠性要求远高于智能性用确定性系统管流程用概率性系统做判断这个分工不能乱。第二层是Agent层每个财务流程对应一个或多个Agent。Agent的职责是接收流程引擎派发的任务、调用工具查数据库、调OCR、查发票接口、调用LLM做推理、返回结构化结果。这里用的是多Agent协作模式不是单个大Agent。第三层是LLM层负责语义理解、异常判断、报告生成这类需要“理解”的任务。他们同时接了多个模型按任务类型路由结构化抽取用轻量模型复杂推理用大模型成本敏感的场景用本地部署的开源模型。2.2 为什么用多Agent而不是一个大Agent这是我在整个项目里最想展开讲的一点。很多人做Agent项目习惯写一个巨大的Prompt把所有规则、所有工具、所有场景都塞进去指望一个Agent解决所有问题。这家一开始也试过结果就是Prompt越来越长准确率越来越低调试越来越难。后来改成多Agent按流程拆分报销审核Agent只负责报销单的合规性检查工具就是查制度库、查历史报销记录、调OCR识别票据。发票Agent只负责发票的查验、去重、入账建议工具是税务查验接口、发票池数据库。对账Agent只负责银行流水和账面记录的双向匹配工具是银行接口、总账查询。往来Agent只负责内部往来的配对和差异定位工具是各主体往来明细。税务Agent只负责申报数据的归集和勾稽检查。报表Agent只负责从各模块取数、生成管理报表草稿。每个Agent的Prompt控制在合理长度工具集精简职责单一。好处是调试的时候能快速定位是哪个Agent出了问题坏处是需要一个协调层来处理Agent之间的依赖。他们的做法是让流程引擎充当协调层Agent之间不直接通信都通过流程引擎传递数据。这个设计牺牲了一点灵活性但换来了可观测性和可维护性。2.3 Agent的记忆设计Agent记忆这块他们分了短期和长期两层。短期记忆就是当前任务上下文比如这次报销单的所有字段、OCR结果、制度匹配结果存在流程引擎的上下文对象里任务结束就释放。长期记忆存的是三类东西一是历史处理案例比如某类特殊报销以前怎么批的二是规则库的版本变更记录三是Agent自己的“经验”——哪些判断被人工纠正过。第三类最有意思他们做了一个纠正反馈闭环人工在复核时如果改了Agent的判断这个修改会被记录下来定期用来优化Prompt和规则库。这里踩过一个坑一开始他们把长期记忆直接塞进Prompt结果上下文爆炸成本和延迟都上去了。后来改成检索式记忆——只在需要的时候检索相关历史案例而不是全量加载。这个改动让单次调用的token消耗降了大概60%。2.4 流程引擎与Agent的接口设计接口设计上他们定了一个原则Agent对流程引擎只暴露两个方法——execute(task)和validate(result)。流程引擎不关心Agent内部怎么实现只关心输入输出。任务对象的结构大概是这样{ task_id: reimb-202405-00123, task_type: expense_audit, payload: { reimbursement_id: BX20240500123, applicant: 张三, amount: 3560.00, items: [...], attachments: [...] }, context: { applicant_history: {...}, policy_version: 2024Q2, related_transactions: [...] } }Agent返回的结果也是结构化的包含判断结论、置信度、依据、建议动作。流程引擎根据置信度决定是直接通过、转人工、还是打回补充材料。置信度阈值是可以按流程配置的比如报销审核要求0.95以上才自动通过报表生成0.8以上就可以出草稿。3. 六个流程的落地实录3.1 费用报销审核从3天到4小时报销审核是第一个上线的流程也是最容易看到效果的。原来的流程是员工提交→财务初审→财务经理复审→出纳付款平均耗时3天高峰期一周。Agent上线后的流程变成员工提交→Agent初审秒级→低风险直接通过进入付款队列高风险转人工→人工只处理异常件。Agent的审核逻辑分四步票据合规性调OCR识别发票查验真伪检查抬头、税号、金额是否与报销单一致。制度匹配根据费用类型匹配报销标准比如差旅住宿标准按城市级别分档超标自动标记。历史行为分析查该员工历史报销记录有没有频繁拆单、有没有同类费用重复报销。异常评分综合以上结果给出风险分低于阈值自动通过高于阈值转人工。实测下来大约78%的报销单可以自动通过剩下22%转人工。财务经理说现在他们团队早上花一两个小时处理异常件就完事了剩下的时间可以做分析工作。实操心得制度匹配这块最大的坑是制度本身的模糊性。比如“业务招待费需提前审批”但什么叫“提前”提前一天还是提前一小时这种模糊规则必须在上线前跟业务部门对齐清楚否则Agent会频繁误判人工纠正量反而更大。3.2 发票查验与入账把重复劳动彻底干掉发票处理是财务最枯燥的活儿之一。原来一个会计一天要处理两三百张发票查验、去重、匹配合同、生成凭证眼睛都看花。Agent的做法是批量接收发票影像或电子发票文件→OCR识别→税务接口查验→发票池去重→匹配采购订单或合同→生成入账建议→人工确认。这里的关键技术点是发票去重。同一张发票可能被不同部门、不同时间重复提交传统做法是靠发票号码人工比对效率低还容易漏。Agent用的是多字段联合去重发票代码号码金额开票日期销方税号五个字段组合唯一。实测下来去重准确率接近100%。另一个技术点是入账科目推荐。Agent根据发票内容商品名称、销方经营范围和历史入账记录推荐会计科目和辅助核算项。这个推荐不是瞎猜是基于历史数据的相似度匹配。会计只需要确认或修改不需要从头选科目。3.3 银行流水对账从半天到十分钟银行对账原来是个体力活。10个主体、20多个银行账户每天下载流水跟账面记录逐笔勾对。一个会计半天时间就耗在这上面。Agent的做法是自动拉取银行流水通过银企直连接口→拉取总账银行科目明细→双向匹配→标记未达账项→生成余额调节表草稿。匹配逻辑分三层精确匹配金额、日期、摘要完全一致直接勾对。模糊匹配金额一致但日期差一两天或者摘要有差异用相似度算法匹配。人工兜底前两层都匹配不上的标记为异常转人工处理。实测下来精确匹配能覆盖85%左右的流水模糊匹配再解决10%真正需要人工的只有5%左右。原来半天的活儿现在十分钟就能搞定会计只需要复核那5%的异常项。注意事项银企直连的稳定性直接决定这个流程的体验。他们一开始用了一家小银行的接口经常断连后来换成主流银行问题就少了。选银行的时候一定要确认接口的稳定性和文档质量。3.4 内部往来对账最难的骨头内部往来对账是六个流程里最复杂的也是最后上线的。难点在于10个主体之间的往来关系是网状的而且各主体的入账时间不一致。比如A主体1月31日确认收入B主体2月1日才确认成本月底对账时就会出现时间性差异。传统做法是发对账函、人工核对、调差异一轮下来要好几天。Agent的做法是数据归集从10个主体的总账系统分别拉取内部往来明细。配对按交易对手、金额、业务类型进行配对。差异分类把差异分成时间性差异、金额差异、科目差异、遗漏差异四类。差异定位对每一类差异Agent给出可能的原因和建议处理方式。生成对账单自动生成各主体的对账确认函草稿。这里用到了多Agent协作每个主体对应一个子Agent负责本主体的数据准备和初步配对一个协调Agent负责跨主体的全局配对和差异分析。协调Agent会把配对结果分发给各子Agent确认形成闭环。实测下来往来对账的时间从平均3天压缩到半天而且差异定位的准确率比人工高——人工对账容易漏掉一些隐蔽的差异Agent是逐笔扫描不会漏。3.5 税务申报数据准备勾稽关系自动检查税务申报的数据准备难点不在计算在勾稽关系。增值税申报表、附加税申报表、企业所得税预缴表之间有一堆勾稽关系填错一个数后面全错。Agent的做法是从总账和发票池取数→按税种归集→生成申报表草稿→自动检查勾稽关系→标记异常→人工复核。勾稽检查这块他们整理了大概40多条规则比如“销项税额开票收入×税率未开票收入×税率”、“进项税额转出要与相关科目发生额匹配”等等。Agent逐条检查不通过就标记出来附上差异说明。这个流程上线后申报数据准备的时间从2天压缩到半天而且因为勾稽检查自动化了申报错误率明显下降。3.6 管理报表生成从“取数三天”到“草稿十分钟”管理报表原来是最耗时的——要从10个主体的系统里分别取数汇总、抵消、生成报表一套下来三天。而且每次老板要个新口径就得重新来一遍。Agent的做法是定义好报表模板和数据映射规则→Agent自动从各主体取数→执行汇总和抵消→生成报表草稿→人工调整和确认。这里的关键是数据映射规则。每个主体的科目体系不完全一致需要映射到集团统一口径。这个映射表是人工维护的Agent负责执行。映射规则变更时只需要改配置不需要改代码。报表生成后Agent还会做一个合理性检查比如收入环比波动超过30%就标记毛利率与历史均值偏差超过5个百分点就标记。这些检查帮财务在提交报表前就发现异常。4. 踩过的坑与排查技巧实录4.1 LLM幻觉在财务场景的典型表现财务场景对准确性要求极高LLM的幻觉问题在这里特别致命。他们遇到过的典型幻觉包括编造科目代码Agent推荐了一个不存在的科目代码幸好人工复核时发现了。错误理解制度把“住宿标准500元”理解成“住宿标准500元以下”导致超标报销被误判为合规。数据串行把A主体的数据算到了B主体头上因为上下文里主体标识不够明显。应对措施有三条关键字段强制校验科目代码、金额、税号这类字段Agent输出后必须跟数据库比对不存在就报错。制度条款引用Agent做判断时必须引用具体的制度条款编号人工可以快速核对。主体隔离每个主体的数据在上下文里用明确的标签包裹Prompt里反复强调主体边界。我的体会是不要指望LLM不犯错要设计让错误能被发现的机制。财务场景里置信度、依据引用、强制校验这三样东西比模型本身的能力更重要。4.2 Agent超时与重试策略Agent调用LLM和外部接口超时是家常便饭。他们的策略是分级超时LLM调用超时30秒外部接口超时10秒数据库查询超时5秒。有限重试超时后重试2次每次间隔递增1秒、3秒。降级处理重试仍失败降级到备用模型或转人工不让流程卡死。幂等设计所有Agent操作必须幂等重试不会产生重复数据。这里有个坑一开始他们没做幂等重试导致同一张发票被重复入账。后来在流程引擎层加了任务去重锁同一个task_id只能执行一次问题才解决。4.3 人工复核的“疲劳阈值”人工复核是最后一道防线但人是有疲劳阈值的。他们发现如果一个复核员一天要处理超过50个异常件从第30个开始准确率就明显下降。应对办法异常分级把异常分成高、中、低三级高级异常必须复核中级抽样复核低级批量确认。轮换机制复核员定期轮换流程避免长时间做同一类判断导致麻木。复核质量抽检每周抽检已复核的case发现漏判及时纠正。4.4 常见问题速查表问题现象可能原因排查方向解决措施Agent频繁转人工置信度阈值过高查看置信度分布调整阈值或优化Prompt同一任务重复执行幂等未生效检查任务锁加任务去重锁数据串主体上下文隔离不足检查Prompt主体标识加强主体标签接口频繁超时外部服务不稳定查看接口日志加重试和降级制度匹配错误制度条款模糊核对制度原文细化规则或转人工报表数据对不上映射规则错误检查映射表修正映射配置5. 上线后的真实收益与团队变化5.1 量化收益上线运行半年后他们做了一次复盘几个关键数据报销审核周期从平均3天降到4小时自动通过部分秒级。发票处理效率单人日处理量从200张提升到800张。银行对账时间从半天降到10分钟。内部往来对账从3天降到半天。税务申报准备从2天降到半天。管理报表生成从3天降到半天草稿阶段。财务共享中心人数没有增加但业务量增长了约30%。5.2 团队角色的变化最有意思的变化是人的角色变了。原来财务团队80%的时间在做账、对账、审单现在这些活儿大部分交给Agent了人的时间转向了异常处理处理Agent标记的异常件这需要更高的专业判断力。规则维护维护制度库、映射规则、Prompt模板。业务分析有时间做真正的财务分析了比如成本结构分析、现金流预测。Agent训练给Agent提供反馈优化它的判断准确率。财务经理说了一句话我觉得很到位“以前我们是操作工现在我们是教练。”5.3 一个意外的收获上线三个月后他们发现Agent积累的处理数据本身很有价值。比如通过分析报销异常的模式他们发现某个部门的差旅费异常偏高深入调查后发现是出差审批流程有漏洞。这种从数据中主动发现管理问题的能力是原来人工做账时完全不具备的。6. 给准备上财务智能体的团队几点实在建议6.1 先修流程再上AI这是我最想强调的一点。这家集团在上AI之前先花了两个月做流程标准化——统一科目体系、统一报销制度、统一审批流程。如果流程本身是乱的AI只会把混乱放大。Agent需要明确的规则才能工作规则不清晰Agent的判断就会摇摆人工纠正量反而更大。6.2 从高频简单流程切入不要一上来就啃最复杂的流程。先做报销审核、发票处理这种高频、规则明确的流程快速看到效果建立团队信心积累Agent调优经验。等团队对Agent的能力边界有感觉了再上往来对账、税务申报这种复杂流程。6.3 人机边界要清晰哪些事Agent做哪些事人做这个边界必须在项目启动时就定清楚并且写进流程文档。边界模糊会导致两个问题一是Agent做了不该它做的事出了事没人担责二是人不知道该复核什么要么全复核累死要么全不复核风险大。6.4 置信度机制是核心Agent的判断必须带置信度流程引擎根据置信度决定下一步动作。置信度阈值要按流程配置高风险流程阈值高低风险流程阈值低。这个机制是平衡效率和风险的关键。6.5 反馈闭环不能少人工每次纠正Agent的判断都应该被记录下来定期用来优化Prompt和规则库。没有反馈闭环Agent的准确率就停在原地不会自己变好。6.6 技术选型不要追新他们用的技术栈其实不新开源工作流引擎、主流LLM API、自建的Agent框架。没有用什么花哨的新技术。财务场景要的是稳定和可维护不是技术炫技。选型的时候优先考虑社区活跃度、文档质量、团队的学习成本。6.7 安全合规是底线财务数据敏感Agent的权限要严格控制。他们的做法是Agent只能读数据不能直接写数据库所有写操作必须通过流程引擎经过人工确认。另外所有Agent的操作日志完整保留可追溯、可审计。7. 后续可以怎么扩展这套架构搭好之后扩展性其实不错。他们接下来计划做的几件事一是把Agent扩展到预算管理做预算执行的实时监控和预警。二是接入更多数据源比如把ERP、CRM的数据也接进来让Agent的判断依据更全面。三是做跨流程的Agent协作比如报销Agent发现异常时自动触发审计Agent做进一步核查。四是把Agent的能力开放给业务部门让业务人员也能通过自然语言查询财务数据。不过这些都是后话。眼下最重要的是把已经上线的六个流程跑稳把准确率再往上提一提把团队的Agent运营能力建起来。财务智能体这事儿急不得但也确实值得做。