一张图看懂轻易云智能对账系统：双子计划 × 集成中心 × AI Agent 三大引擎

摘要：电商财务选对账工具时，最常听到的形容词是「智能」「自动化」。但真正拆开看，这些形容词背后都是三个具体的引擎在协同：双子对账计划引擎负责把钱算清楚、集成中心引擎负责把钱交出去、AI Agent 引擎负责把人从脚本里解放出来。这篇文章把这套系统的产品矩阵摊成一张图 + 三段拆解——每个引擎讲清楚它做什么、不做什么、为什么是这种形态、踩过哪些坑。

关键词：智能对账系统、电商对账软件、电商财务系统、ERP 集成、AI 对账

为什么是「三个引擎」，不是「一个平台」？

2026 年的电商财务团队面对的工具市场可以分成两类：

• 单点工具——只做账单解析、只做对账、只做凭证生成。3-5 套拼起来，月结靠 Excel 拼。
• 传统大平台——功能齐全但重到需要 3 个月实施，按人天计费，账面成本是工具预算的 3 倍。

真正能让 CFO 松一口气的形态，是「分工明确的引擎协作」。这就是为什么本文不写「这套系统能做什么」的功能清单，而是写「三个引擎各自管什么」的设计纪律：

每个引擎独立演进、独立配置、独立部署，但通过统一的数据模型（BillRow / IncomePlanItem / SupplyOrder）和统一的状态机串成一条流水线。下面用一张业务模块架构图把三个引擎的物理位置锚定，再逐个拆解。

这张图把整个产品切成「平台基座 + biz_reconciliation 业务层」两大块。基座负责通用能力（鉴权、网关、队列、Prisma 多文件 schema、Redis 缓存），业务层负责具体的对账业务——其中双子对账计划引擎、集成中心引擎、AI Agent 引擎正好分布在业务层的三大区域，三者共用基座、不互相耦合。

关键设计：三个引擎不是简单的功能分类，而是产品对外的三种「承诺」——双子引擎承诺「算清楚」、集成中心承诺「交出去」、AI Agent 承诺「少写代码」。每承诺都对应一类独立的失败模式。

引擎一 · 双子对账计划：把电商财务的钱算清楚

双子对账计划引擎是产品的「心脏」——所有对账的逻辑、状态、差异归类都从这里发起。它的全称是「收入对账计划 × 费用对账计划」，两套并行但不互斥的计划共用 plan_source_relations 桥表。

双子架构：为什么不是「一个计划」？

2025 年之前的传统对账工具普遍是「一个对账计划」——收入、费用、差异全塞一份 Excel。三个问题随之而来：责任不清（对账师不知道这一行的差异是收入侧还是费用侧）、状态机混乱（「成功/失败」含义模糊）、公摊难做（跨订单的费用分摊需要拆到 SKU 级）。

v3 重构后定下来的方案是「双子分立 + 桥表穿透」：

• 收入对账计划（IncomeReconciliationPlan）：以业务订单号为聚合键，自动匹配供应链订单（SupplyOrder），按 customerCode + businessOrderNo 双码匹配；判定结果只有 SUCCESS / FAILURE 两种。
• 费用对账计划（ExpenseReconciliationPlan）：以核算项目为聚合键，不强制匹配供应链；用户对每个核算项目的体行做整体确认；状态机是 5 态（pending → ready → confirmed / failed / cancelled）。
• 桥表（plan_source_relations）：5 字段最小化（planId + planType + billRowTable + billRowId + contributedAmount），把两个计划的体行挂回到原始账单行。

这种设计的好处是责任链路清晰：收入对账的失败模式是「账单和供应链对不上」，费用对账的失败模式是「账单项没法归到核算项目」，两件事互不干扰，通过桥表可联合查询。

23 个 diffReason 业务标签码：差异的「机读 + 人读」

为什么需要 23 个标签码而不是「成功 / 失败」二选一？因为电商对账里，对平 ≠ 真对平。京东 POP 整单轧差时，账单净额 245.04 和供应链净额 245.04 完全相等是「成功」；但如果差额是 65.92 元（恰好等于「联合优惠券/立减」承担的金额），也算成功——只是要打上 MARKETING_COUPON_DIFF 标签。这就是「机读 + 人读」的双轨设计：机读侧在 8 步骤判定链上做精确相等比对，命中一档就贴一个机读码；人读侧让财务看到 MARKETING_COUPON_DIFF 标签就理解「这一单是平台券冲抵差异」，不需要再去翻账单。

23 个标签码按业务域分 5 组：取消/退货类 4 个、金额/价差类 5 个、营销/补贴类 4 个、状态/配对类 5 个、其他 5 个。每个标签码都对应一个 diffDisposalSuggestion 字段，可选 4 种处置（AUTO_SUCCESS / MANUAL_CONFIRM / AUTO_TRANSFORM_TO_AR / RESEARCH）。这种「机读码 + 处置建议」的组合让 AI Agent 可以直接消费 diffReason 字段——告诉 AI「这单是 CROSS_PERIOD_REFUND」，AI 就知道该往跨期结算逻辑里查。

公摊反写：双子之间的桥梁

双子引擎另一个关键能力是公摊费用反写。一笔广告费打进费用对账计划后，需要按 SKU / 按订单 / 按店铺分摊到具体收入计划。反写有 2 种模式：E1 实时反写（费用计划体行被确认后立刻回写，CONFIRMED 闸触发）、E11 覆盖式反写（撤旧重跑时强制覆盖，按 SKU 级契约 E7/E8 防双计，尾差容差 0.01）。

实战场景：某店铺的广告费 13,537.38 元需要在 8 个 SKU 间按销售额比例分摊。双子引擎跑下来：费用计划确认 → 触发 E1 反写 → 找到 8 个 SKU 关联的 6,030 个收入计划体行 → 按销售额比例分配广告费 → 校验总和不超 0.01 元尾差 → 反写结果直接扣减该收入行的「净收入」，让毛利计算一次到位。

这一步是双子引擎区别于「单计划工具」的核心——没有双子 + 公摊，对账就只是数字游戏，毛利永远算不准。

引擎二 · 集成中心：把钱交到 ERP

集成中心引擎是产品的「手」——双子引擎算清楚的钱，最终要变成金蝶里的应收单、应付单、银行转账单。集成中心负责这个「交付」动作的全部细节。

它的核心能力可以分成 3 段：PULL（拉）、PUSH（推）、集成转换（中间层）。

PULL：从 ERP 拉数据参与对账

第一个动作是从 ERP 拉数据。为什么要拉？因为对账的「对手方」不只是平台账单，还包括 ERP 系统的暂估应收单——金蝶在订单发货时就会生成一张暂估单，对账系统需要拉回来作为「供应链订单」的来源之一。

以金蝶云星空为例，PULL handler 是 ar-receivable.pull：

1. 调金蝶 AR_receivable 接口（HMAC 双签名）；
2. 翻页拉取（ExecuteBillQuery 自动翻页，v7 起改为后置入队）；
3. handler 内硬代码 ETL 进标准化 SupplyOrder（v6 一维拍扁）——每行 = 一份 SKU 明细；
4. 落 integration_tasks 记录任务状态，原始响应写 rawData JSONB。

整套机制的关键设计是「handler 内硬代码 ETL，不发明 ETL 配置化框架」——v3 决策之后，集成中心不再有「画布式 ETL 配置」，而是 30-50 行 TypeScript 代码搞定一个 handler。这条决策让金蝶拉取 12 个字段映射只用了 45 行代码，而不是一个 3 个月的实施项目。

PUSH：把对账结果写到 ERP

第二个动作是把对账结果推回 ERP。这一步有两条典型路径：ar-fin-receivable.push（暂估→财务应收 Push 下推，对账体行确认后生成财务应收单 AR_receivable|YSD01_SYS|FIN_FROM_HOOK，调金蝶 Save → Submit → Audit 三段式，回写 externalBillNo）和 ap-other-payable.push（应付单 Save，费用侧用于暂估转应付、平台扣点补差）。

集成中心 9 个 handler 的全景视图：

9 个 handler 覆盖 5 大场景：PULL 健康检查（health_check）+ 拉暂估应收（ar-receivable.pull）、PUSH 银行转账单 / 销售收款单 / 应收单 / 财务应收单暂估下推 / 应付单。所有 handler 默认 configJson.simulate=true（挡板防误推），切真实推送在集成中心 UI 配置（重启不覆盖）。

集成转换：双子与集成中心之间的第四类沙箱

双子引擎算完钱后并不是直接交给集成中心。中间还有一道「集成转换」环节——这就是第四类沙箱：集成转换脚本（Transform Script）。

为什么需要第四类？因为对账结果「长什么样」和 ERP 单据「长什么样」是两回事：对账结果是「业务订单号 + 收入 245.04 + 差异 0.00」；金蝶应收单是「客户编码 22000001 + 单据类型 AR_receivable + 币种 CNY + 汇率 100 + 体行 2 条」。集成转换沙箱的作用就是把前者转成后者，按 INCOME / EXPENSE 严格分离脚本类型，批次级单次执行。

集成转换脚本的设计哲学有 4 个关键点：scriptKind 严格分离（INCOME 和 EXPENSE 不能混用）；documents 头 + 体行骨架（10+ 头字段 + N 条体行，PUSH handler 直接读）；payload JSONB 灵活字段（脚本可塞任意中间数据，集成中心不解析只透传）；columnSchema / editableFields 声明（金额字段默认禁改，避免脚本运行时金额被覆盖）。

集成中心的整体架构图如下，可以看到 PULL × PUSH × 集成转换三股力量的协同：

集成中心的核心价值可以用一张价值图表达：

这张图回答了一个 CIO 必问的问题：「这套系统能不能接我们家的 ERP？」答案是：已经接好的看 handler 列表，规划中的看厂商矩阵。金蝶云星空 9 个 handler 已落地；用友 YonBIP / SAP B1 在规划中；金蝶云星辰 / 金蝶 EAS 在延展。每一个新 ERP 不是「集成中心改一遍」，而是「新增一个产品目录（apps/api/src/integrations/<erp-product>/），不动通用层」。

这就是集成中心引擎的设计哲学：按产品切分目录，不抽象基类，不发明配置化框架。这种哲学和双子引擎的「平台聚合范式」一脉相承——都是 v3 重构后「去过度设计」的具体落地。在轻易云智能对账系统的整体产品矩阵里，集成中心是负责「交出去」的引擎——前一个引擎（双子对账计划）算清楚后，由它负责把结果交到 ERP。

引擎三 · AI Agent：把财务人员从脚本里解放出来

第三个引擎是 AI Agent 引擎——也是最容易被误解的一个。它的真实定位是「业务 Agent + 通用 Agent + 知识库」，目标是让财务业务人员不再需要手写对账脚本。

如果对照市面上一边鼓吹「智能」、一边让财务自己写脚本的工具，你会发现 AI Agent 引擎的存在本身就是一种态度：让写脚本这件事从「人干」变成「机器干」——这是电商财务场景第一次有可能把 80% 的脚本维护工作量从业务团队转移到 AI。在轻易云的产品矩阵里，AI Agent 被定义为三大引擎之一而非附加工具，正是因为它是构成对账自动化闭环的关键一环。

4 个 Agent 的分工

AI Agent 引擎有 4 个 Agent，分工非常清晰：

3 个业务 Agent 各自负责一类脚本，1 个通用 Agent 负责答疑、引导、必要时把任务派发给业务 Agent。这种「专业分工 + 通用引导」的设计来自一个真实诉求：财务业务人员看不懂脚本代码，但看得懂业务含义。

4 Agent 协作的架构如下：

SKILL 与知识库的分工

AI Agent 引擎有一个特别值得讲的点：SKILL 装「不变的契约」、知识库装「会长的例子」。

SKILL 是 markdown 文件，6 节骨架固定（角色与边界 / 业务背景 / 脚本契约 / 编写规范 / 工作流 / 参考示例），改 SKILL = 改代码 = 走 git 评审。SKILL 永远确定性注入 system 消息，每次 run 都在场。

知识库（KnowledgeChunk + searchKnowledge）装的是「会长的例子」——比如「京东 POP 账户流水的『收入金额』列在哪一行」「支付宝资金账单的『业务订单号』长什么样」。这些知识可以热更新、可以向量检索，但不能替代 SKILL 的契约。

这种分工带来的工程优势：脚本契约稳定（SKILL 一改，三类业务 Agent 同步演进）；平台差异灵活（新接一个平台只需往知识库塞示例和历史脚本）；冷启动友好（业务 Agent 第一次写脚本时通过 RAG 检索相关平台历史脚本，能立刻进入「模仿 + 微调」模式）。

触发类工具的安全模型

AI Agent 引擎有一个非常克制的设计：业务 Agent 拿足够大的权限自主干活（勘察、编写、测试、保存全部自主完成），但唯一人工触点是 trigger。

工具风险分级：read 类无管控，自由调；test 类无确认（沙箱执行、不落库、30s 闸）；write 类无确认（history 可回滚），authorize 限 ADMIN；trigger 类对话内一句业务语言确认，authorize 限 ADMIN。

这意味着 Agent 给你写脚本、跑测试、保存脚本——全部自主完成。但当 Agent 说「我现在要触发 600 行账单的真实解析」，财务说一句「跑吧」才真正执行。

这种「自主干活 + 唯一人工 trigger 触点」的设计，是 2026 年 AI 落地财务场景里最务实的方案——既不让财务变成审码器，也不让 AI 失控批量改业务数据。

知识库 RAG：检索质量可观测

每一次 RAG 检索都会落一条 KnowledgeQueryLog——记录用户问题、检索关键词、命中 chunk ID、相似度分、最终是否被 Agent 采纳。它是评估 AI Agent 表现的第一手数据：发现某个常见问题反复检索失败时，看「未命中」记录 → 找到平台知识缺口 → 补 seed 到 seeds/knowledge.ts → 重新部署触发 post-deploy-knowledge 自动同步。

这条闭环让知识库不是「建完就烂」，而是有自我修复能力。AI 的「准确率」不是上线那一刻定的，是上线后 3-6 个月靠知识库运维慢慢涨上来的。

三大引擎如何协作？

最后回答一个 CIO/CTO 必问的问题：这三个引擎怎么连起来？

连接它们的不是某个「中央调度器」，而是共享的数据模型：

用一个具体的 5 步骤 E2E 流程展示三个引擎的协作：

1. AI Agent 引擎（bill-parse-agent）写账单解析脚本 → 用户触发 triggerParse → BillRow 落库，状态 PARSED；
2. AI Agent 引擎（reconcile-script-agent）写收入对账脚本 → 用户创建 IncomePlan → 异步比对 → IncomePlanItem 写入（带 diffReason），状态 reconciled；
3. AI Agent 引擎（expense-allocate-agent）写费用分摊脚本 → 用户创建 ExpensePlan → runExpenseAllocate 触发分摊 → 公摊反写到收入计划；
4. 双子引擎确认后 → 用户点「生成转换批次」 → transform_documents 落库（DRAFT）；
5. 集成中心引擎 PUSH handler 调金蝶 Save/Submit/Audit → externalBillNo 回写 → 状态 PUSHED。

5 步走完，一笔电商订单从「平台账单」到「金蝶应收单」端到端打通。财务人员只在确认转换、触发生成批次两个节点介入——其余 3 步都由 AI Agent 引擎自主完成。

这就是「三大引擎协作」的真正含义：不是三个工具拼起来，而是一个有机体，各管一摊、协同运转。对应到本文讲解的整套产品矩阵，每个引擎的边界清晰、责任独立——这正是对账自动化应有的形态。

选型清单：三个引擎，五个判断点

如果你正在评估一套对账系统是否真的能跑通电商财务业务流，可以从这五个判断点对照：

1. 有没有双子对账计划引擎？还是只有「一个对账计划」？前者支持店铺级 / SKU 级毛利核算，后者只能算到订单级。
2. 有没有集成中心 9 个 handler？还是只支持一个 ERP？前者表明「按产品切分目录」的工程纪律成熟，后者大概率只能靠人工导 Excel。
3. 有没有 23 个 diffReason 业务标签码？还是只有「成功 / 失败」？前者把 5% 的人工兜底变成「按标签决策」，后者逼财务每行都看。
4. 有没有 3 个业务 Agent + 1 个通用 Agent？还是只有「智能问答」？前者能写脚本、自迭代，后者只是个聊天框。
5. 有没有知识库 RAG + KnowledgeQueryLog？还是只有「内置 FAQ」？前者有自我修复能力，后者上线即腐化。

每一个判断点都是「已实现」。但更重要的是，这五个判断点的组合，是一个有机的产品形态，而不是五个孤立的功能点。当 CIO/CTO 在选型会议上把这五个问题问出来，90% 的传统对账工具都会露出「功能堆砌」的本来面目。

如果你想走系统化这条路，可以考虑「三个引擎」产品矩阵——双子对账计划 + 集成中心 + AI Agent，对应「算清楚 / 交出去 / 解放人」三类核心承诺。这套产品矩阵的对应实现已经在前文逐个拆解完。

收尾 · 三个引擎，一套纪律

回到最初那张业务模块架构图——三个引擎在图的右半部分布得很开：双子引擎在中部（biz_reconciliation 业务层核心）、集成中心在下部（IntegrationsModule，含 kingdee-cloud-galaxy/ 产品目录）、AI Agent 在左侧（AgentsModule，含 4 Agent）。它们共用平台基座的 Queue / Prisma / Redis / Auth / Settings，靠 NestJS DI 容器装配，不强耦合，但强协同。

整套产品的工程纪律可以浓缩成一句话：去过度设计，专注该做的事。

每个引擎都在「该做的事」上做到了行业天花板的高度——双子引擎的 7+5 态机、集成中心的 9 handler + 4 类沙箱、AI Agent 的 4 Agent + RAG——但没有一项是为了「显得高级」而存在的。

这才是「三个引擎」这个产品名背后的真实含义：用对账计划算清楚、用集成中心交出去、用 AI Agent 解放人——把电商财务的事做对、做完、做简单。

每个引擎的深度实现细节可参考项目内的开发规范：

• 双子对账计划的 7 态机 / 5 态机设计与状态迁移规则，参见 income-reconciliation-development
• 集成转换脚本的 scriptKind INCOME/EXPENSE 严格分离、批次级单次执行、documents 头 + 体行骨架，参见 integration-transform-script-development
• AI Agent 的 SKILL 注入、工具契约、4 Agent 协作，参见 ai-agent-development