财务智能体实施纪实 一家 1000 人、10 家主体的集团，如何把六个财务流程交给 AI

这不是“教你怎么写个 Agent Demo”的文章，而是一份业务实施纪实：一个 1000 人规模、10 家公司主体、中心集团管控的企业，如何把银行流水、报销付款、开票回款、往来账龄、税负测算、凭证回填这六件最耗人力的财务活儿，从 Excel 搬进对话式智能体，并且真的敢签字用下去。全文以业务实施为主线，工程细节只讲“业务为什么要它”。文中系统截图均已脱敏。

2026 年 9 月 · 实施复盘

目录一、财务卡在哪里二、不改习惯三、上流程四、接系统五、对多账套六、让人敢签七、多 Agent 与安全八、上线与热更新九、收益盘点十、十条军规

一、引子：财务卡在哪里

先把业务底牌摊开：1000 人规模、10 家公司主体、一个中心集团管控。这意味着每一笔业务都要回答两个问题——归属于哪家公司、走哪套账。这两问，是所有财务痛点的源头。

1.1 三个硬约束

把 AI 用进财务，和用在别处完全不是一回事。财务对系统提出三个近乎苛刻的要求：

1. 口径刚性——科目映射、状态口径、模板列，一个字都不能“创造性发挥”。LLM 的幻觉在这里不是笑话，是风险。
2. 全程留痕——每一笔转换、每一次放行都要可审计，出事要能回放。
3. 人工闸门——关键决策（哪笔钱要付、哪个凭证要入）必须停在人手里，AI 只能“预判”，不能“代签”。

所以我们一开始就定下一条原则：LLM 负责理解和整理，规则负责口径和校验，人类负责拍板，流程引擎负责把三者串成一个可回放的确定性过程。

1.2 起点不是“要 AI”，是 Excel 装不下了

在这个规模上，财务团队的日常是这样的：银行流水导出成 Excel 手工归类；报销单在钉钉审批完，导出再整理成付款模板；开票台账靠人对着回款记录一行行核；凭证更是“把单据抄进财务软件”。六个流程，六个 Excel，六套口径。

团队并不是没用过 AI。他们此前已经在用一个对话式助手（内部管它叫 workbody）处理简单表格——洗数、汇总、找差异，确实快。但很快撞上三堵墙：

结论很清楚：业务需要的不是“更聪明的聊天”，而是一个能接系统、留痕迹、守口径、可回放的程序。这就是整个项目的起点。

登录页即产品说明书：开票回款对账、报销付款、往来挂账、税负测算、凭证填充、银行流水——六大场景，同一套流程引擎。

二、第一程 · 不改习惯：把程序藏进对话框

拿到需求后，最容易被忽略、也最贵的一个决策是：交互形态要不要改？

技术直觉会说“做个表单系统、做个工作台”。但放到 1000 人的组织里算账：换一种交互方式 = 换一次全员肌肉记忆，培训、推广、抵触的成本，远大于功能本身的收益。而且这些人已经在用对话式 AI 了——“聊天”就是他们最熟的入口。

所以我们把程序藏进了对话框：

• 对话即入口：一句“我要上传银行流水文件并自动转换，输出流水明细、收支汇总与风险检查结果”，就能拉起整条流程——这句话甚至不用背，系统认意图；
• 九宫格快捷卡：给不想打字的人一个按钮，六大场景摊在首屏，点一下进入对应流程；
• 状态可见：左侧列表里每一条都是一次真实流程，“运行中/已完成”直接对应流程状态——用户不用理解引擎，只需要知道“我的活儿走到哪一步了”。

执行交互台：资金日报、报销直付、业财对账、往来管家、税务雷达、凭证引擎等场景入口；左侧每个会话都是一条流程实例。

左侧任务列表：状态徽标直接映射流程实例状态。这条列表的加载耗时从 17 秒优化到 2~4 秒（见第九章）。

业务侧的感受是： 动作从“打开 Excel → 找模板 → 复制粘贴 → 检查”变成“说一句话 → 在确认卡上点一下 → 下载产物”。学习成本几乎为零。

三、第二程 · 上流程：六大场景从 Excel 走到线上

3.1 六个流程，六套业务口径

六个场景长得完全不一样，但每一套口径都是从财务同事嘴里一条条抠出来的：

这些口径，没有一条是研发能自己想出来的。

3.2 统一骨架：9 条流程、92 个活动节点

六大财务场景加上员工报销、费用审批、月结，共 9 条业务流程定义、92 个活动节点（凭证回填 11 个节点、银行流水 12 个节点、开票回款对账 13 个节点）。它们全长在同一套骨架上——以银行流水（bs）为例：

HUMAN 门（蓝）、LLM 活动（绿）、规则节点（橙）、审计/报告（白）四色分工，六场景同构。统一范式最大的好处是能力只做一遍：进度推送、人工确认、审计报告、产物下载，九个流程共享同一套实现。

3.3 业务现场：从“我要转换”到“上传文件”

下面这张图是银行流水流程的真实运行现场——用户只说了一句话，系统就识别出场景、拆好了步骤，并在“上传门”上停下来等人：

一条消息拉起整条流程：意图识别 → 歧义消解（HUMAN 卡）→ 任务步骤条 2/2 步 → 上传门「请上传银行流水文件」；左下角还挂着“291 秒后超时（需人工处理）”的兜底倒计时——没人接手也不会卡死。

每个人都能看见流程走到哪一步：

任务步骤面板展开到节点级（bs_intent_disambiguate → bs_query_records …）。业务不需要懂流程引擎，但能随时确认“卡在谁那里”。

四、第三程 · 接系统：钉钉 + 有成

“接不上系统”是旧工具的第一大死因。这一步要解决的是：让智能体自己会取数。

两条集成链路：

• 钉钉 OA 审批：拉取“报销单（费用报销）”与开票申请审批实例（按 ≤60 天窗口切段拉取，只取审批通过且已结束的 COMPLETED 实例），规范化成与 Excel 同构的数据行；
• 有成费控（OPENAPI）：拉取昨日单据明细、科目余额表、账套列表（setOfBooksId），并按各公司账套取权威的科目与客户档案——模板是手工导出的快照，会过期；接口取的是当下值。

两条链路最终汇入同一条转换管线，手工上传 Excel、钉钉拉取、有成同步三种入口，出来的付款模板完全一致。

4.1 一个对业务特别友好的设计：mock 开关

集成最怕“等接口开通”。有成接口还没批下来时，我们用结构与真实返回完全一致的本地数据把全流程跑通——业务可以先验收“流程对不对、模板对不对”，等接口开通，改一个配置就切真实联调，流程和数据结构都不用动。

“已从有成导入昨日单据，生成付款模板成功”：同步单据笔数、待支付笔数（状态口径 = 5）、付款行数、模板 ID、下载链接，以及“可继续：下载付款模板 / 查询付款记录 / 查看有成同步单据”三个下一步按钮。左下角能看到同一实例上并行跑着多条流程（报销付款、银行流水、税负测算、往来账龄…）。

五、第四程 · 对多账套：10 家公司、10 套科目表

这是“集团 + 多主体”最硬的地方，也是 AI 最容易翻车的地方。

为保护商业信息，本节起对 10 家主体统一以 A~H 公司代称。

5.1 同一个名字，两个公司

公司识别靠支付账户/单据里的关键词匹配，先命中先返回。而真实公司名天生重叠：

• 母公司与分公司名称互相包含：如「A 公司 B 分公司」的全称里，同时出现母公司关键字“A”与分公司关键字“B”；
• 另一组「C 公司 D 分公司」同样同时含“C”“D”。

顺序写错，就会把分公司的账记进母公司账套——模板、银行科目、辅助核算全错。所以关键词表的顺序即优先级，并在代码注释里写明了顺序理由。

5.2 各家公司，各认各的科目

已知局限（如实告知业务）：E/C/B 公司账套有多个银行明细科目（账号不同），而模板只给科目名称、没有“账号 → 明细科目”对照表，目前统一落基本户。这条局限我们写进了代码注释，也写给了业务：要精确到账号级落科目，需业务提供账号对照表。

5.3 职责交叉：一笔钱有四个人在看

报销人在钉钉提单、财务审核、出纳付款、会计做账——四个角色看到的是同一份数据的四个切面。这直接决定三件事的设计：

• 人工确认按职责落点，不能笼统地“等一个人确认”，而要落在对应环节的人身上；
• 身份口径必须归一：同一批人，在系统里是手机号、在组织架构里是 UUID、系统自身又是 finance-system 这类系统身份——必须在系统边界处统一，否则“流程启动人”都写不进去；
• 状态口径要对齐官方语义：报销状态 1待提交 / 2待审批 / 3驳回 / 4撤销 / 5待支付 / 6完成 / 7拒绝 / 8待处理——业务嘴里说的“待支付”，程序里必须就是那个 5，不能各说各话。

这一幕的体会：业务视角里没有“技术难点”，只有“能不能用、敢不敢签”。上面每一条，用户给的评价标准只有一个——“算得对不对”。

六、第五程 · 让人敢签：人工门、口径外置与全程留痕

6.1 三个放行口，一个兜底

流程里所有关键决策都设计成人工确认节点。但纯人工会话会“哑火”——用户一句“好的继续”，到底走哪个分支？我们给人工门设计了三个放行口，严格程度递减：

1. 输入齐备即放行：用户已明确表态且材料齐全，直接推进；
2. 输入缺失即跳过：用于可选节点；
3. LLM 预判分支（需显式声明）：LLM 从用户消息 + 选项列表预判分支，精确匹配选项才算自动放行；输出模糊、超时 6 秒、任何异常，一律降级为挂起等人。

模糊一律挂起、超时一定兜底——这是“敢签字”的前提。会话里的确认卡就是这些留痕的落点：

顶部是用户诉求横幅，消息流里是系统的确认卡。每一次确认/拒绝都是一条可回放的记录。

6.2 口径外置：让财务专家自己 review

早期业务口径（科目映射、模板列、阈值、审计要点）全部硬编码在系统提示词里，改一个映射要改代码重新发版。后来我们把口径全部外置成 JSON 文件，运行时加载注入：

• voucher-fill-rules.json（凭证口径）、reimburse-pay-rules.json（付款模板）、tax-burden-rules.json（税负）、youcheng-openapi-catalog.json（有成接口目录）等十余个文件；
• 文件缺失/解析失败时，回退到内置兜底口径，行为与改造前一致，可零回归回滚。

真正的价值是协作方式的改变：财务专家可以直接打开口径文件 review 并提修改意见，不用隔着 prompt 字符串和研发排期对话。

6.3 产物闭环：从“流程跑完”到“东西到手”

流程跑完不等于交付完成。财务要的是能下载、能编辑、能存档的产物，所以我们做了三件事：

1. 声明式产物：活动定义里声明 producedOutputs=["auditReport"]，引擎按声明统一生成 .md + .json 双格式审计报告，推 flow_artifact 事件——覆盖全部财务流程，不需要每个场景各写一遍；
2. 统一产物接口：一个接口暴露全部产物（按会话 + 流程实例），下载链接按当前流程实例现算，任何轮次回来都能拿到有效链接；
3. 前端统一入口：对话框上方常驻产物横幅 + 底部「产出物」按钮。

产物横幅带文件名与生成时间（如「往来挂账异常·2026年09月.xlsx 09-27 23:57」），任务步骤显示“4/4 步完成·本轮完成”。左侧列表里同一实例上并行运行着开票回款、报销付款、税负测算、往来账龄等多条流程。

审计报告的内容模板同样来自业务口径：流程名、实例 ID、执行结论、关键统计、校验要点、风险待补、产物清单、证据链接。财务同事第一次拿到自动生成的对账审计报告时说了一句：“格式比我手写的还全。”

七、第六程 · 边修飞机，边大战：多 Agent 群落与商业级安全

必须承认现实约束：没有“停下来重建三个月”的奢侈。业务每天在跑，报销每天在付，我们只能在飞行中换引擎。

7.1 群落，而不是一个大 Agent

• 场景层：六大流程各自是独立执行体，可寻址、可单独发布、互不阻塞；
• 节点层：一条流程内部再分工——LLM 节点负责理解与整理，规则节点负责口径与校验，人工门负责人拍板；
• 实例层：命名空间（场景宿主 / 独立 llm-agent）让同一份能力在两种角色下分开寻址，不再“抢同一个身份”。

“边修飞机”能成立，靠三条护栏：

1. 流程定义是数据不是代码——改分支、加校验，改 JSON 不改引擎；
2. 口径外置成文件——业务专家能直接 review（见 6.2）；
3. 人工门——新版本先“挂起等人确认”，绝不直接放款、直接入账。

再配上一组“保险丝”，让流程不会自己转晕：同一条回环边在同一纪元内只允许自动重入一次，第二次即判定为死循环并置失败；路由跳数超过预算直接熔断；所有外部依赖超时降级、读多写少的地方加短 TTL 缓存。群落的稳定，不靠每个 agent 都聪明，靠每个 agent 只做一件事、边界清楚。

7.2 商业级安全：多 Agent 环境不能裸奔

一旦 LLM 能读数据、能调工具、能跨实例协作，“安全”就从技术洁癖变成业务前提。财务最关心三件事：谁做的（不可抵赖）、能做什么（最小权限）、出了事能不能查（全程留痕）。对应到架构上是四道边界：

四道边界之外还有一条不成文的规矩：AI 不得修改约束自己的那套规则。让 AI 修 bug 可以，让它改“护栏”不行——这是把“最小权限”落到实处。

八、第七程 · 上线与热更新：改一个口径，当天生效

8.1 上线节奏：先并行，再灰度

没有搞“大爆炸”式切换，而是先让 AI 出的结果与人工 Excel 结果对照，一致了才逐步把人工活交出去。财务同事从“复核 AI”过渡到“看 AI 出的报告”。

8.2 平台与业务分离：199.2MB 与 716KB

整套系统切成了两层：

这组数字对业务的直接含义是：

• 财务说“这个科目映射要改” → 改口径文件 → 换一个 716KB 的业务 jar → 秒级重启 → 当天生效；
• 平台能力的演进（月级）与业务口径的调整（天级）解耦，业务不必等平台发版窗口。

代价也必须付：平台与业务必须同版本发布——两边错版会在运行时抛出致命错误，这是“分离”的另一面，所以每次平台改动都要连带重建业务制品。

8.3 生产运维画像

• 实例健康启动约 60 秒，日志按天轮转并保留追加记录，便于取证；
• 每个实例独立数据目录与访问令牌，跨服务调用统一鉴权，避免“测试数据污染生产”；
• 流程定义换装走固定三步（改定义 → 覆盖入库 → 清缓存重启），变更必须重启才生效——宁可麻烦，不要幽灵状态。

九、收益盘点：这 60 天换来了什么

把可核验的收益摊开（以下数据均来自项目过程的实测与实例快照，非估算）：

一句话总结收益：不是“更聪明的 AI”，而是更少的手工、更硬的留痕、更快的响应——再加上一条最实在的：口径改了当天就能上线，不用等研发排期。

十、写在最后：给企业级 Agent 实施者的十条军规

1. 先算业务账，再谈技术选型：换交互形态的成本要按“全员肌肉记忆”计价，能不动就不动；
2. LLM 理解、规则校验、人类拍板、引擎串联——四权分立是财务 Agent 的宪法；
3. 口径外置成数据，让业务专家直接 review，别让他们隔着 prompt 字符串和研发对话；
4. 人工门是必需品：AI 只做高置信精确匹配的预判，模糊一律挂起，超时必须有兜底；
5. 先并行再灰度：让 AI 的结果与人工结果对照一段时间，信任是比出来的，不是承诺出来的；
6. 多主体场景，账套差异必须逐家登记：同名识别要防“分公司记进母公司”，科目编码要按账套实时解析；
7. 身份与状态口径在边界处统一：手机号 / UUID / 系统身份，以及业务状态码 1~8，谁都不能各说各话；
8. 交付闭环才算流程闭环：产物要声明式生成、单接口暴露、前端统一入口；
9. 平台与业务分离：粒度差异（199MB / 716KB）换来的是“改口径当天生效”的自由，但必须同版本发布；
10. 给 AI 上缰绳，给运维留退路：超时降级、缓存、兜底键、回滚备份，都是“希望用不上、用上救命”的东西。

回头看这 60 天，最重要的收获不是任何单个技术点，而是一个认知——

企业级 Agent 的核心竞争力，不是模型能力，而是“把不确定性关进确定性笼子”的工程能力，以及“让业务敢签字”的交付能力。

本文基于真实项目史实整理，2026 年 9 月。