AI Agent 对账落地:如何把对账周期从几天压到几小时
背景:人工对账撞上了规模天花板
某大规模电商企业,多平台多店铺经营,月度单据量达到 10 万级。财务团队的对账方式是典型的"人工导表 + Excel 核对":每月初从各平台后台导出账单,几名财务花数天时间逐平台核对,差异原因靠翻聊天记录排查,公摊费用(物流、仓储、推广)靠拍脑袋分摊。对账周期长倒在其次,更难受的是过程不可追溯——任何人问起一笔差异,都要从头查一遍。
方案:事实层打底,Agent 干活
该企业上线轻易云智能对账平台,整体架构分三层:
1. 事实数据层
各平台 Excel / CSV 账单一键导入,异步任务自动落库。每个平台 × 每种账单类型有独立事实表(全平台共 24 张),原始行快照(rawData)完整保留,金额精度 Decimal(20,4)、单价 Decimal(20,6)。任何一条对账结果都能通过最小桥表反向追溯到原始账单行——可追溯性是后面一切自动化的前提。
2. 智能对账引擎
对账拆成两个并行的"双子计划":
- 收入对账计划:平台账单与供应链订单按双码(平台订单号 + 业务内码)逐条自动比对,差异金额与原因逐行落库,物料明细匹配成功即自动反写;
- 费用对账计划:采用"计划 → 聚合 → 分摊明细"三层架构,公摊费用由沙箱分摊脚本自动计算,实时反写收入对账明细。
整个引擎跑在 BullMQ 异步队列上,以 7 态状态机驱动,大批量账单处理不阻塞业务操作,每一步状态可查、可重跑。
3. AI Agent 矩阵
这是把"系统能力"变成"业务人员能用"的关键一层:
| Agent | 职责 |
|---|---|
| 账单解析脚本工程师 | 解析脚本的新增、编辑、测试与触发,自动识别业务订单号与核算项目 |
| 对账脚本工程师 | 对账脚本编写与测试,驱动收入对账计划执行并验证结果 |
| 费用分摊脚本工程师 | 分摊脚本全生命周期管理,执行公摊分摊并反写收入明细 |
| 通用 AGENT · 总参谋 | 全局问答 + 只读状态查询,单向一层派发给专业 Agent |
财务人员用自然语言提需求,例如"帮我把这个新平台的账单解析规则建起来",Agent 按五步标准工作流走:需求对话 → 自动勘察 → 编写脚本 → 沙箱测试 → 启动执行。勘察、编写、测试、保存都由 Agent 自主完成,人只需在启动执行前用一句业务语言确认。
安全设计:Agent 不发明第二条写路径
财务场景对 AI 的顾虑主要是"乱动数据"。该平台的设计底线是:Agent 的一切业务副作用必经"脚本 + JobTask + BullMQ"既有执行链路,不绕过脚本直接改业务数据;测试不落库;脚本版本历史可回滚;全部工具调用落审计表。沙箱采用 isolated-vm + 独立子进程双层隔离,用户脚本跑不出隔离环境。
效果:从"几天"到"几小时"
上线后,该企业的月度对账形态发生了根本变化:
- 对账周期:账单导入、解析、比对、费用分摊全链路异步自动执行,过去以"天"计的核对过程压缩到以"小时"计,财务的工作从"逐行核对"变成"看差异、做确认";
- 新平台接入:过去新平台账单格式接入要排期开发,现在业务人员和账单解析 Agent 对话,当天即可建规则、沙箱验证、上线;
- 差异可追溯:任何一条差异都能反查到原始账单行和当时的脚本版本,月结审计从"翻文件"变成"点链接";
- 费用分摊:公摊费用从拍脑袋变成沙箱脚本自动计算并反写,口径固定、过程可重跑。
经验总结
- AI Agent 落地财务场景,前提是有一个可信的事实数据层——精度、快照、桥表溯源缺一不可;
- Agent 的价值不在替代系统,而在让业务人员绕过排期直接驱动系统;写路径收敛到既有链路,是获得财务与审计信任的关键;
- "轻确认"是可行的:自主完成勘察与测试,仅执行前确认一次,效率与安全可以兼得。