一笔业务在多个系统里各有一份记录，系统之间靠接口同步状态。接口都返回成功，业务上却可能出现上游已记账、下游没收到这类缺口。这类问题平时看不出来，一到对账期就集中暴露。
一、先给结论
结论是：跨系统的单据状态要靠"对账任务"兜底，不能只靠接口回调。对账任务按固定周期比对双方状态，把不一致的挑出来进缺口队列，再由人工或规则分派处理。企业级智能体自动化里的凭证链路，几乎都是这样跨多系统衔接的。
二、状态机要先画再接
一笔单据在一侧的状态是有限的，例如已创建、处理中、已确认、已否决、已作废。把这些状态画成一张有向图，标清哪些流转是合法的、哪些是终态。接口对接前先出这张图，能挡掉大半的同步异常。图上没画到的流转，一律视为异常。状态数量也不宜膨胀，每多一个中间态，同步路径就要多一条分支，实际维护中一般控制在 5 到 7 个以内。顺带一提，状态命名要与实际业务用词保持一致，同一件事不要在两个系统里叫两个名字，否则对账时还要先做一次翻译。
三、缺口分三类，处理路径也不同
一是状态缺口，一侧已流转另一侧仍是旧状态，属于同步延迟，等待重试即可。二是数据缺口，一侧有记录另一侧没有，属于投递失败，需要补发。三是结论缺口，两侧状态一致但结论矛盾，例如一方否决另一方通过，这类必须人工判断。三类分开放置，能自动处理的不会被压住。
四、回捞要有边界，不能无限捞
缺口回捞按时间窗推进，每次只捞固定长度的区间，比如往前翻 30 分钟，捞完推进窗口。窗口外的缺口不自动捞，避免把历史问题一次性翻出来。同时回捞次数要有上限，连续多次仍失败的转人工。我们通常设 3 次，每次间隔按分钟级递增，第三次之后不再自动捞。缺口队列还要设存量上限，超过 500 条就暂停自动处理，先让人清理，避免越滚越大。
五、我们踩过的三个具体坑
只信接口回调。回调丢了就没有第二次，一直查不到状态。补上对账任务后才闭环。
缺口不分类型混在一个队列。需要人工判断的被自动处理淹没，人工侧根本看不到。分开之后处理效率明显提升。
回捞没有时间窗。一次回捞把几个月前的数据全翻了出来，队列直接爆掉。加上窗口推进才正常。
六、行业里已经跑到什么规模
跨系统对账在流程密集型企业里已经比较常见。某大型产业集团公开的纳税计算从 30 分钟压到 3 分钟，涉及 500 个以上单位；某股份制银行公开的流程数量在 500 条以上、覆盖 35 个部门；某印刷包装企业的入离职处理从 15 到 20 分钟压到 3 分钟。业务跨的系统越多，对账就越不可缺少。
七、怎么验证这套机制真的生效
缺口发现时长：从状态不一致到被对账挑出来的平均时长。
自动闭环率：无需人工介入就处理完的缺口占比。
结论缺口存量：需要人工判断的缺口数量，应当收敛。
回捞重复率：同一缺口被重复捞起的次数。
这四项里，缺口发现时长是核心，它决定问题暴露得早晚。
检查清单
是否先画出状态机再对接接口。
缺口是否分状态、数据、结论三类存放。
回捞是否按时间窗推进并设次数上限。
是否同时有接口回调与对账任务两套机制。
结论缺口是否强制人工判断。
