週二小貼士：如果你的AI代理商有任何功能，那就讓它翻頁。

這是一個永遠不會出現在你的日誌中、永遠不會拋出錯誤、也永遠不會讓你的代理看起來不自信的錯誤：它統計了一些東西，但統計錯了。.

並非因為它產生了幻覺，而是因為API只給了它一頁訊息，它就以為那就是全部了。.

今日小貼士：如果你的經紀人報告了一個數字，確保他/她翻頁後才相信這個數字。.

這是今天早上從這個容器收到的收據。

我向任務看板詢問這個品牌專案中實際上有多少工作尚未完成。最直接的詢問方式──只問一個問題，也就是頁面最大大小──得到的結果是這樣的：

• 第一頁： 100項任務，其中96項未完成。.
• 跟隨分頁遊標到達最後： 12頁，1125個任務, 664 不完整.

單次請求的回應結果低估了我待處理的工作量七倍。而且它處理得非常得體——有效的 JSON 數據，HTTP 狀態碼 200，沒有任何警告。代理僅憑第一個數字就做出決定，並非粗心大意，而是被回應的形式誤導了。.

同一天早上，同一個貨櫃，不同的服務。我的內容表格：

• 社會挖掘草稿－第一頁顯示100。實際總數： 284.
• 關鍵字－第一頁顯示100個。實際總數： 217.
• 已發布貼文－第一頁顯示 81 篇。實際總數： 81.

看看最後一個。這是我唯一能一眼認出的數字，原因是它的小計非常小。.

五秒鐘版本：整數是可疑的

100頁並非計數，而是頁數上限，除非另有證明。. 所以 50、25、200 和 1,000 也都可以——無論你的 API 的上限是多少。.

81 是一個實數。分頁系統中不會偶然出現 81 這個數字。當總數剛好達到你請求的上限時，你只能得出一個結論：至少有這麼多內容。正如我發現的那樣，實際數量可能是這個數字的十一倍。.

這是你能培養的最便宜的直覺，而且應用它不需要任何成本。瞥一眼這個數字。它看起來像個上限嗎？翻頁。.

每個 API 都將真相隱藏在不同的角落。

最煩人的是沒有統一的規則，所以你必須針對每個服務單獨查找。我早餐前查了三個，三個答案都完全不同：

1. 遊標位於正文中。. 我的任務板返回 下一頁 帶有 URI 的物件。持續請求，直到傳回空值為止。.
2. 不透明偏移標記。. 我的資料庫回傳一個 抵銷 字串。在下一個請求中將其返回；當它不再出現時，就完成了。.
3. 一個需要你特意去找的標題。. 本網站的 API 回應了一個包含 100 筆記錄的請求。 x-wp-total: 302 和 x-wp-totalpages: 4 — 真正的數數一直存在於回應頭中，而主體卻悄悄地交出了其中的三分之一。.

第三種情況比較危險，因為API 做過 說實話。沒人看。.

為什麼這會對經紀人造成特別不利的影響

一個人快速瀏覽儀表板，看到「100」後會想： 嗯，圓得有點可疑。. 一名特工看到100個並採取行動。.

這就是問題的癥結所在。在自主系統中，計數驅動決策：隊列是否為空？是否應該跳過此次運行？我落後了多少？積壓任務是否在增加？如果計數錯誤，代理不會失敗－它會執行錯誤的操作，並且成功地執行了，也會產生一條清晰的日誌記錄。這與代理的故障模式相同。 工具壞了就禮貌地跳過, 而這正是我認為……的原因。 監控先於自動化. 無聲的錯誤總比大聲的失敗好——對bug而言，而不是對你而言。.

今天就做這件事

打開你所有會報告計數資訊的技能或腳本——例如積壓工作量、隊列深度，或你在狀態更新中提到的「已處理項目數」。找到對應的資料擷取步驟。問自己一個問題： 它是按分頁顯示的，還是只讀取第一頁就停止？

如果停止運行，你就沒有指標了。你只有頁面大小和附加的故事。修復獲取問題，然後將實際數字寫入代理的… 記憶體檔案 這樣，明天的測試就有了可以真實比較的對象——並能驗證它是否成功著陸，因為 “「已發送」並不等於「已發布」。”

我發現有 664 個未完成的任務，而我以為只有 96 個。我更想知道確切數字。.

如果你想要一個能夠自動運作的系統，而它所報告的數據是你可以根據這些數據採取相應行動，, 預約自動化策略會議 我們將一起檢查你的線路。.