某企業(yè)的運營團隊月初要用智能體給一百二十多家合作門店推送對賬提醒。任務跑完后系統(tǒng)提示處理完成運營同事?lián)苏J為通知已經(jīng)發(fā)出。到了月中陸續(xù)有門店反饋沒有收到提醒人工核對才發(fā)現(xiàn)實際只發(fā)出去二十來條正好是接口返回的頭一頁剩下的條目從頭到尾都沒有被取出來過。團隊起初懷疑是接口偶發(fā)異常給每個調(diào)用都加上了重試重新跑了一遍結果仍只多發(fā)出零星幾條。排查之后問題不在發(fā)送環(huán)節(jié)而在取數(shù)環(huán)節(jié)剩下的那些門店記錄從來沒有進入過處理范圍重試再多也只是把同一批已經(jīng)處理過的記錄又走了一遍。接口按頁返回數(shù)據(jù)是最常見的取數(shù)方式每調(diào)用一次只給出一頁需要帶著游標繼續(xù)往后取直到?jīng)]有更多為止。智能體如果只調(diào)一次就認為拿到了全部等于把這一頁取完了誤讀成數(shù)據(jù)取完了。這類偏差在小批量場景里不易暴露一旦目標對象超過一頁后面的記錄就整批消失而表面上任務依然走完了全部流程。接口的頁大小有時由服務端默認值決定并不完全受調(diào)用方控制調(diào)用方如果把它寫死在判斷邏輯里頁大小一變推斷就會跟著失準。完成判定本身也容易出問題。有的流程靠本頁返回的條數(shù)是否小于頁大小來推斷是否結束。當總量正好是頁大小的整數(shù)倍時用這種寫法會多發(fā)出一次取數(shù)請求最后一頁為空這是一次多余的往返并不會因此漏掉數(shù)據(jù)。真正的隱患在另一處若接口因超時或截斷偶爾返回不足一頁卻并非末頁按條數(shù)判斷就會提前收尾丟掉后面的記錄。此外也有接口在返回體里帶了是否有下一頁的標記只是這個字段沒有被讀取系統(tǒng)轉而依賴并不穩(wěn)妥的條數(shù)推斷。與其從條數(shù)上反復推敲不如顯式依賴接口給出的結束標記或下一頁游標。更隱蔽的是缺失條目沒有對賬。任務的進度記錄往往只寫已處理多少條卻沒有先登記本批的目標范圍或對賬基線。沒有范圍基線少做了多少就無從發(fā)現(xiàn)完成狀態(tài)與真實業(yè)務結果之間的差額被悄悄抹平。進度寫成了成功對賬卻對不上業(yè)務側只能等外部反饋來暴露問題。對賬也不該只在任務結束時做一次異步返回或延遲落庫的結果可能在任務收尾之后才回來需要一次周期性的核對把它們重新納入統(tǒng)計。數(shù)據(jù)枚舉結束、業(yè)務動作處理結束與最終對賬通過是不同階段不應共用同一個“完成”狀態(tài)。page exhausted ≠ enumeration complete ≠ processing complete ≠ reconciliation passed把其中任意一步當成終點都會讓系統(tǒng)早于真實業(yè)務結果宣布成功。一種可行的做法是先登記本批的目標范圍與可用的對賬基線再按游標分批取數(shù)并在每批處理后把游標位置與逐條狀態(tài)分片落庫中途中斷也能從記錄的位置續(xù)跑。如果數(shù)據(jù)源提供與本次查詢范圍一致且可作為權威基線的總數(shù)可以將其登記用于對賬如果沒有可靠總數(shù)則應通過目標清單、穩(wěn)定快照、游標耗盡狀態(tài)或其他可核對機制確認本批枚舉范圍。長批次還應固定本批的數(shù)據(jù)邊界例如記錄快照版本、截止水位或查詢截止時間并使用穩(wěn)定且唯一的排序鍵這樣分頁期間新增或更新的數(shù)據(jù)不會悄悄進入或移出當前批次例如以 created_at batch_cutoff 為邊界再按 (created_at, id) 穩(wěn)定排序。每條記錄的處理結果區(qū)分成功、失敗、合法跳過與待確認單條失敗被隔離并記錄原因不拖垮整批任務。整批結束后應對目標范圍內(nèi)每條記錄的終態(tài)進行對賬確保每條記錄都能對應到成功、失敗、合法跳過或待確認等明確狀態(tài)只有滿足預先定義的完成條件任務才能進入完成狀態(tài)失敗與待確認記錄再進入補處理隊列或人工清單。補處理同樣要帶上操作標識避免同一批記錄被重復發(fā)送重復的副作用在通知類任務里尤其難以回收。通用模型與工作流編排平臺通常能提供批量調(diào)用與失敗重試能力但對賬基線的確定、分頁游標的持久化以及漏項補處理的對賬規(guī)則仍需結合企業(yè)自身的數(shù)據(jù)接口與業(yè)務口徑單獨設計。在青山不語AI工作室的AI定制方案中任務執(zhí)行前先登記目標范圍及可用的對賬基線取數(shù)游標與逐條處理狀態(tài)分片持久化單條失敗被隔離并留痕任務收尾時對登記的目標范圍與各記錄終態(tài)做完整對賬確認成功、失敗、合法跳過和待確認記錄均有明確歸屬只有滿足完成條件后才標記任務完成。這套機制能減少少做了卻報完成的情況但它無法判斷登記的總數(shù)或基線是否可靠范圍應當怎么劃定仍然要由業(yè)務側確認。驗收時可以讓接口返回一個能被頁大小整除的總數(shù)再讓中間某一頁超時觀察任務是否只對成功、失敗、合法跳過與待確認記錄分別給出明確終態(tài)多出來的空頁有沒有被正確識別合法跳過是否未被誤判為漏項、失敗與待確認記錄有沒有進入補處理或人工清單還可以構造一個不返回可靠總數(shù)的接口觀察系統(tǒng)是否改用目標清單或游標耗盡狀態(tài)來確認本批范圍而不是卡在缺失的 total 上。在我看來批量任務里更值得警惕的不是某一條失敗而是系統(tǒng)對自己做了多少并不清楚。一個連范圍都沒數(shù)清就宣布完成的任務比一個明確報出失敗的任務更難排查也更難向業(yè)務交代。