Agent 每天自动处理了哪些业务，怎样和源系统做一份差异对账

Agent每天处理了多少业务，应与源系统应处理集合和目标实际生效集合核对，不能只数成功日志。一次任务可能多次调用，一个对象也可能被人工处理或撤回；没有统一口径，成功次数再多也无法解释业务是否完整。本文提供合成业务对账，不涉及财务结算或会计合规判断。

先定义应处理集合

合成任务每天将符合条件的设备请求整理为待审核草稿。先确定业务期间、时区、适用状态、排除条件和截止后的迟到记录怎样处理。源系统查询结果保存稳定对象号与查询条件，形成这次应处理集合，不能只保存一个总数。

人工已处理、业务已撤回与输入不合法的对象分别列明理由。它们可以不进入自动处理，但不能从数据里消失，否则业务负责人不知道少了一条是漏取还是合理排除。查询权限与分页范围也要明确，不把当前账号看不到的对象当作全系统不存在。

源台账说明应处理什么，任务台账说明Agent尝试过什么，目标台账说明实际产生什么对象。它们用稳定关联键连接，不能把每次重试当作新业务对象。任务状态成功但目标无回执，仍待核对；目标有对象但任务未记录，也要补核对而不是再创建一次。

PostgreSQL聚合函数文档支持集合计数等实现机制；事务隔离说明提醒查询可见性受事务条件影响。具体对账期间与源对象定义属于客户业务合同，不能从SQL函数推导业务处理完整。

下载业务处理三台账与差异样例。合成请求A有目标草稿，B源中存在却没任务记录，C任务标成功但没目标回执，D目标有对象却不在本次源集合，E是已撤回排除项。每一项都有差异类别、下一步和证据栏。

漏任务先检查源查询、触发与队列，不立刻重跑全部；无目标回执先查实际状态；额外对象检查期间、关联键或人工操作，不能默认是重复。已撤回项保留排除依据。报告列对象别名与受控引用，不把完整客户资料放入面向所有人的汇总。

对账本身是只读活动，不自动生成新草稿或删除额外对象。需要补办时，先确认原动作没有生效、对象仍符合条件且当前授权允许，再进入独立执行流程。目标状态未知时继续待核对，不用再做一次来测试是否会重复。

人工处理也要有明确识别方式。目标记录能追溯到人工决定时，将其作为合法去向，而不是把没有Agent任务号的对象全部算异常。没有证据的去向维持未知，由业务负责人补齐说明，不能让模型根据备注推定已完成。

同一业务对象可能在期间内创建、期间后修改。确定对账按创建、受理还是生效时间，并保留来源时点；不同时间口径不能直接相减。迟到进入源集合的记录是否补入上一期或纳入下一期，由合同决定，不由脚本默认现在日期处理。

附件包括跨期间、重复尝试、人工去向和关联键冲突。验收时用合成集合计算差集，核对每个对象能否落到已生效、明确排除、未处理或待核对之一。总数对上但对象对不上仍不算完整，不能靠把未知行归为成功让数字平衡。

报告注明数据截止、查询范围、差异清单与未解决责任人。完成对账表示这次核对有结论，不意味着所有业务都自动修好了。修复后再读取目标验证，保留前后差异，不覆盖原始异常记录。这样下一次发现同类问题时能区分新缺口和旧遗留。

单动作线索可读业务审计字段，期间对账归入流程自动化。通过定制咨询提供脱敏源集合、任务记录与目标回执，可评估关联台账、差异报告和补办边界；集成商可用系统集成协作明确各源责任。