某企业的运营团队月初要用智能体给一百二十多家合作门店推送对账提醒。任务跑完后系统提示处理完成运营同事据此认为通知已经发出。到了月中陆续有门店反馈没有收到提醒人工核对才发现实际只发出去二十来条正好是接口返回的头一页剩下的条目从头到尾都没有被取出来过。团队起初怀疑是接口偶发异常给每个调用都加上了重试重新跑了一遍结果仍只多发出零星几条。排查之后问题不在发送环节而在取数环节剩下的那些门店记录从来没有进入过处理范围重试再多也只是把同一批已经处理过的记录又走了一遍。接口按页返回数据是最常见的取数方式每调用一次只给出一页需要带着游标继续往后取直到没有更多为止。智能体如果只调一次就认为拿到了全部等于把这一页取完了误读成数据取完了。这类偏差在小批量场景里不易暴露一旦目标对象超过一页后面的记录就整批消失而表面上任务依然走完了全部流程。接口的页大小有时由服务端默认值决定并不完全受调用方控制调用方如果把它写死在判断逻辑里页大小一变推断就会跟着失准。完成判定本身也容易出问题。有的流程靠本页返回的条数是否小于页大小来推断是否结束。当总量正好是页大小的整数倍时用这种写法会多发出一次取数请求最后一页为空这是一次多余的往返并不会因此漏掉数据。真正的隐患在另一处若接口因超时或截断偶尔返回不足一页却并非末页按条数判断就会提前收尾丢掉后面的记录。此外也有接口在返回体里带了是否有下一页的标记只是这个字段没有被读取系统转而依赖并不稳妥的条数推断。与其从条数上反复推敲不如显式依赖接口给出的结束标记或下一页游标。更隐蔽的是缺失条目没有对账。任务的进度记录往往只写已处理多少条却没有先登记本批的目标范围或对账基线。没有范围基线少做了多少就无从发现完成状态与真实业务结果之间的差额被悄悄抹平。进度写成了成功对账却对不上业务侧只能等外部反馈来暴露问题。对账也不该只在任务结束时做一次异步返回或延迟落库的结果可能在任务收尾之后才回来需要一次周期性的核对把它们重新纳入统计。数据枚举结束、业务动作处理结束与最终对账通过是不同阶段不应共用同一个“完成”状态。page exhausted ≠ enumeration complete ≠ processing complete ≠ reconciliation passed把其中任意一步当成终点都会让系统早于真实业务结果宣布成功。一种可行的做法是先登记本批的目标范围与可用的对账基线再按游标分批取数并在每批处理后把游标位置与逐条状态分片落库中途中断也能从记录的位置续跑。如果数据源提供与本次查询范围一致且可作为权威基线的总数可以将其登记用于对账如果没有可靠总数则应通过目标清单、稳定快照、游标耗尽状态或其他可核对机制确认本批枚举范围。长批次还应固定本批的数据边界例如记录快照版本、截止水位或查询截止时间并使用稳定且唯一的排序键这样分页期间新增或更新的数据不会悄悄进入或移出当前批次例如以 created_at batch_cutoff 为边界再按 (created_at, id) 稳定排序。每条记录的处理结果区分成功、失败、合法跳过与待确认单条失败被隔离并记录原因不拖垮整批任务。整批结束后应对目标范围内每条记录的终态进行对账确保每条记录都能对应到成功、失败、合法跳过或待确认等明确状态只有满足预先定义的完成条件任务才能进入完成状态失败与待确认记录再进入补处理队列或人工清单。补处理同样要带上操作标识避免同一批记录被重复发送重复的副作用在通知类任务里尤其难以回收。通用模型与工作流编排平台通常能提供批量调用与失败重试能力但对账基线的确定、分页游标的持久化以及漏项补处理的对账规则仍需结合企业自身的数据接口与业务口径单独设计。在青山不语AI工作室的AI定制方案中任务执行前先登记目标范围及可用的对账基线取数游标与逐条处理状态分片持久化单条失败被隔离并留痕任务收尾时对登记的目标范围与各记录终态做完整对账确认成功、失败、合法跳过和待确认记录均有明确归属只有满足完成条件后才标记任务完成。这套机制能减少少做了却报完成的情况但它无法判断登记的总数或基线是否可靠范围应当怎么划定仍然要由业务侧确认。验收时可以让接口返回一个能被页大小整除的总数再让中间某一页超时观察任务是否只对成功、失败、合法跳过与待确认记录分别给出明确终态多出来的空页有没有被正确识别合法跳过是否未被误判为漏项、失败与待确认记录有没有进入补处理或人工清单还可以构造一个不返回可靠总数的接口观察系统是否改用目标清单或游标耗尽状态来确认本批范围而不是卡在缺失的 total 上。在我看来批量任务里更值得警惕的不是某一条失败而是系统对自己做了多少并不清楚。一个连范围都没数清就宣布完成的任务比一个明确报出失败的任务更难排查也更难向业务交代。