企智社 
我得先承认一件让我们团队尴尬的事。做了那么多年的 To B 数字化项目，我们最喜欢听客户说“流程不规范、系统太老旧”，这样就能顺势卖一套新系统。但去年接账期协同这个需求时，客户随口说了一句：“流程都上系统了，但账期这件事，还是得靠人。”这句话让我意识到，问题根本不在于系统多少，而在于业务流程中那些靠人脑记忆、口头传递、线下裁决的“灰空间”。
客户是一家有几百家供应商的制造企业，ERP 上线超过十年，OA 审批也齐全。但每个月的应付账期核对，仍然是财务部最头疼的事。采购员跟供应商口头承诺“货到两个月内付款”，合同里写的却是“发票入账后次月月底付款”；财务拿到发票时可能已经晚了一个月。供应商打电话问付款进度，采购员夹在中间两头解释。财务总监说，他们不缺付款的钱，缺的是能让供应商信任的“唯一答案”。
我们一开始想做一个简单的对账系统，但越调研越发现，真正的痛点是账期规则散落各处——合同附件、采购员备注、甚至微信聊天记录里。要解决这个问题，不是一个报表能搞定的。我们要做的，是把这些分散的知识和流程，沉淀成一个可对话、可执行的智能体。
账期协同为什么这么难
“你帮我查一下，XX 材料那批货到底什么时候付款？”这是供应商最常问的话，也是采购员最怕听到的话。因为要回答这个问题，采购员得先登录 ERP 查采购订单，再去 OA 里翻审批状态，然后问财务发票到账没有，最后还要凭记忆加一句“大概还要两周”。整个过程少则十分钟，多则半天。如果遇到采购员请假，供应商就会陷入电话无人接听的焦虑。
难的不只是查询难，而是规则本身存在冲突。我们用了一周时间把客户的账期条款做了梳理，发现至少存在六种不同表述：月结 30 天、月结 60 天、货到票到后 30 天、次月 25 日付款、按项目尾款比例付款，还有“长期合作供应商可适当提前”这种模糊条款。模糊条款最可怕，因为它完全依赖经办人主观理解。同一个供应商，问采购 A 和采购 B，得到的付款时间可能差出半个月。
而且，账期不仅仅是时间概念，还关系到分账——也就是一批货对应多张发票，或者一张发票跨多个采购订单时，钱该怎么拆。手工核对时，财务会因为某一张发票金额对不上，而把整批付款压住。这种“一票否决”式的连锁滞留，让供应链资金效率变得极低。我们跟十位供应商代表聊天时，有六位提到“我们不怕晚付，怕的是不知道什么时候付”。
问题识别到这里，我们意识到：与其做一套厚重的可视化大屏，不如先给业务人员一个能自己问、自己答、还能直接发起动作的帮手。换句话说，我们要做一个账期协同的智能体。
智能体不是聊天，是执行
很多同行把智能体理解为“长得像 ChatGPT 的客服”。但我们的账期协同智能体完全不同。它是一个带有决策和执行能力的业务入口。供应商也好，采购员也好，只要在聊天窗口里问一句“那张发票的付款进度”，智能体就会自动执行一个多步动作：先从合同库中抽取账期条款，再核对采购订单与收货单数量，然后校验发票三单匹配状态，最后计算出预计付款日，并附上计算依据。
比如供应商问：“9 月那批阀门的付款时间能提前吗？”智能体会先检索该供应商的账期主数据，发现账期是“货到票到后 45 天”，若票到未满 45 天，它会给出当前状态和预计最早付款日，同时触发一个“提前付款申请”的流程。这个申请会按预设规则自动流转到采购部门审批，而不是直接答应或拒绝。这背后的关键在于，智能体不是一个问答工具，而是把对话转化成结构化指令，并调用现有系统的 API 去执行。
我们使用了大模型来处理自然语言，但真正让这个智能体可落地的，是底层的规则引擎和数据模型。账期规则被拆解成多个因素组合：付款起始时间、账期天数、付款窗口、金额阈值、供应商分类。原来的模糊表述“长期合作供应商可适当提前”被改写成了可计算的规则：连续合作满三年且近一年无对账异常，可在账期基础上最高提前 10 天。这个规则是通过和采购、财务一起头脑风暴沉淀出来的，而不是智能体自己编的。
智能体还有一层能力是“主动触达”。当一批订单发生异常，比如入库数量与发票数量不符，智能体会自动生成一条待办，推送给相关采购员，并在供应商下次询问前就先让内部人员知道：“这条付款可能会卡住，原因是什么”。这种从“人等事”变成“事找人”的转变，是账期协同里最让客户满意的地方。
链上分账：让资金分配有据可循
账期确认了，钱怎么分？这就是链上分账方案的切入点。我们并不建议客户把全部 ERP 数据上链，那既不现实也没必要。我们只做了两件事：第一，把每笔付款申请的拆分逻辑和分账结果存证到联盟链上；第二，把资金分配流程变成一个可被审计的智能合约事件。
具体是什么场景呢？一张发票可能对应多笔采购订单，而每笔订单所属的供应商账户可能还不一样——比如集团内有多个法人主体。以往财务只需把总金额打给开票方，再由他们自己内部拆账。但如果开票方是核心企业的关联公司，拆账不清会导致下游小供应商迟迟拿不到钱。我们用智能体把分账指令生成后，提交到一个资金管控平台，平台上设定资金锁定和划转规则。当智能体校验通过、财务审批完成，链上的智能合约就会基于已完成存证的付款明细，指示银行通道进行定向分账。
这个过程中，供应商不需要安装任何区块链节点。他们只需在收到付款后，通过智能体查到一个存证编号，就能在链上核对该笔分账是否与合同条款一致。一旦有争议，这个存证就是最客观的沟通依据。我们避开了一个大坑：不要一开始就要求各方数据全部上链。先让智能体把账期算清楚、把分账明细跑通，区块链只是做“见证者”，而不是做“主导者”。
实施中，我们还发现一个特别有价值的细节：分账方案在执行前，可以先由智能体模拟一遍。比如一笔数十万元的付款要拆成五份，其中有份金额对不上，智能体能在提交前标记出来，而不是等银行返回失败后再人工排查。这个“预演”能力让财务有了兜底，他们把错误拦截在通知供应商之前。
四个比技术更深层的坑
复盘这个项目，我整理了四个常见误区，希望能帮同行避免。
第一，误以为智能体是零代码拖拽就能生成的。实际上，如果底层没有清洗过的账期主数据，智能体再聪明也只会一本正经地胡说八道。我们在项目前两周只做数据清洗、规则梳理和干系人访谈，根本没碰模型。曾有人建议用 RPA 模拟采购员操作，但后来我们发现，规则本身不统一，自动化程度越高，错误放大得越厉害。
第二，误以为链上分账必须要供应商深度配合。其实供应商只关心钱到没到、到得对不对。链上方案藏到后台，让他们使用体验无感，才能推广得动。我们的做法是，供应商通过微信公众号或小程序入口就能用智能体，链上存证信息只在付款后回执中体现。没有供应商愿意为了配合核心企业，去额外购买硬件或学习复杂的节点操作。
第三，误以为所有异常都要自动化。账期协同中总会遇到发票缺失、收货未确认、供应商银行账户变更等边缘情况。智能体面对这些情况时，最好的做法不是自作主张，而是自动生成求助工单并标注置信度。当置信度低于 80%，直接转人工审批。这既保留了效率，也守住了合规底线。记得上线初期，智能体曾把一张重复报销的发票当成新付款提交，幸好置信度不高，转给了人工，才避免一笔失误。我们因此给智能体加了一条硬规则：任何超过供应商历史平均金额两倍的付款申请，必须人工复核。
第四，误以为智能体是一个一次性项目。账期规则会随采购策略变化，供应商也会新增、变更、退出。因此我们为智能体设置了持续学习反馈闭环：每次人工审批的处理结果都会回填为训练数据，让智能体慢慢学会什么类型的“提前付款”申请更容易被财务接受。它不是从第一天就完美，而是越用越贴合这家公司的风格。
常见问题 FAQ
问：供应商账期协同智能体适合什么规模的企业？
答：当供应商数量超过一百家，或者每月应付账款笔数多到财务需要专门安排专人核对时，就值得认真评估。如果供应商只有二三十家，直接用一张共享表格可能更划算。判断标准不是企业大小，而是账期复杂度是否已经超过人工处理的舒适区。
问：链上分账是否会把业务搞得很复杂，供应商需要重新注册或安装软件吗？
答：不需要。链上分账在后台运行，供应商仍使用日常的微信或企微入口与智能体交互。唯一的变化是，付款后能多收到一个存证凭证，用于核验分账结果。整个上链过程对业务人员是无感的，供应商不接触区块链术语，也不承担额外操作成本。
问：数据在智能体和区块链上流转，会不会增加数据泄露风险？
答：智能体的知识库实施了租户级隔离，供应商只能查询自己的数据。链上存证默认只存哈希值，不存完整合同文本。同时，所有链上写入动作都有权限控制，审计日志不可篡改。这些措施比很多企业现有的财务文件管理方式还要保守，主要目的不是防黑客，而是防止内部流程纠纷。
回顾这个项目，我终于理解了客户那句“流程都上系统了，但账期这件事还得靠人”的真正含义。系统只记录了结果，却没有沉淀做事的方法。而当我们把那些藏在采购员脑子里、聊天记录里、合同缝里的账期知识，变成一个可对话、可执行的智能体时，账期协同才第一次真正地“上了系统”。也许下一代企业服务的核心竞争力，不是把工具做得更快更强，而是让知识找到它该去的地方。这种感觉，超出了写代码本身的成就感。
