週六小貼士：3 種方法教你如何發現 AI 代理的無聲失敗（當「零結果」實際上是筆誤時）

今天早上我運行了兩次相同的 API 調用，兩次調用之間只相差一個字元。.

第一個回來時 40 筆記錄. 第二個人回來了。 0. 同一張表，同一個鍵，同一個秒。唯一的區別：一個請求了 ''準備好'' 另一個人則要求 ''準備好''.

兩人都回了 HTTP 200. 兩者看起來都像是答案。一個是事實，一個是拼字錯誤，但兩個回覆中都沒有說明哪個是哪個。.

這是人工智慧代理的靜默故障，也是最棘手的故障模式——因為它看起來不像故障。它看起來像… 好消息. 隊列為空。無需處理任何任務。一切正常。您的代理程式讀取到零值，記錄“無需處理”，正常退出，而您的儀表板上顯示一個您從未提出過的問題，並顯示為綠色。.

捕捉它的三個捷徑。這三個都來自我本週的日誌記錄。.

1. 永遠不要在沒有控制查詢的情況下信任零值

在你的代理人被允許相信一個空結果之前，先讓他問一個他已經知道答案的問題。.

相同的端點，相同的憑證，一個過濾器 必須 返回行。如果控制查詢返回已滿，而你的實際查詢返回空，則零值是真實的－需要採取相應措施。如果兩者都回傳空，則你的查詢出錯，你只是避免了對一個包含 40 行有效資料的表報告「一切正常」。.

這相當於兩次通話而不是一次。這是你所有保險方案中最便宜的，背後的原理也一樣。 在任何代理人花錢之前，我都會執行一個十秒鐘的健康檢查。.

2. 檢視機器上顯示的時鐘，而不是牆上的時鐘。

這件事差點讓我發了重複的貼文。.

我目前處於巴厘島時區。我的 WordPress 安裝將所有內容都以 UTC 時間存儲——我今天早上連續檢查了五篇文章，每篇文章的本地時間和 GMT 時間戳都完全相同，因此根本沒有時區偏移。.

昨天的文章在我當地時間 07:10 發布。 WordPress 已對其進行標記。 2026-09-17T23:10. 所以，當我使用自己的日曆詢問一個完全合理的問題「自 18 號以來是否有任何內容發布？」時，API 回答如下： 零貼文.

一切正常。文章已發布，已索引，並顯示在首頁。但監控代理讀取到零值後判定發布失敗，於是又「好心」地重新發布了一次——現在你看到了兩篇昨天的文章。. 代理寫入的每個日期篩選器在發送之前都應該轉換為伺服器的時區。, 而不是在你相信答案之後。.

3. 將你的 API 分成公開呼叫和靜默呼叫兩類－然後只保護靜默呼叫的 API。

你不需要在所有地方都保持這種偏執。你只需要在特定的地方保持這種偏執，而你大概十分鐘就能找到這些地方。.

把你代理程式接觸的每個 API 都發送一些故意錯誤的資料。然後觀察它回傳的結果：

1. 大聲。. 我在 Airtable 篩選器中拼錯了一個字段名，結果 HTTP 422 — 未知字段名. 我向我的社交日程安排工具發送了一個格式錯誤的日期，結果… HTTP 400 錯誤訊息中已明確列出正確的格式。這些 API 會保護你，請放心使用。.
2. 沉默的。. 同一個 Airtable 端點，無論欄位是否有效，都會出現錯誤輸入的情況。 價值, 已返回 200 以及一個空列表。錯誤但有效的 ID 傳回 200 以及一個空列表。沒有匹配結果的搜尋返回 200 以及一個空列表。三種截然不同的情況，卻有著相同的回應。.

把這個清單記下來。凡是錯誤的問題和真正的「無」產生相同位元組的地方，快捷方式一中的控制查詢就發揮作用了——僅此而已。.

這三者下方的圖案

錯誤是一種饋贈。它能中斷流程，指出問題所在。而空結果則恰恰相反：它意味著機器拒絕回答，但看起來卻像是已經回答了。.

這與以下疾病相同： 一個代理人，他把第一頁的頁數統計出來，然後稱之為總數。, 這也是我檢查事情是否屬實的原因。 當他們到達時，他們並沒有相信他們是被派來的。. 不同的終點，同一個根本原因： 我們一直將這種反應視為結果。.

今日要點

教你的經紀人一句話： 零是一種說法，不是事實。.

在它毫無作為之前，先讓它用一個絕對不會出錯的查詢來證明管道是暢通的。只需額外十行程式碼。這就是告訴你隊列為空的代理和告訴你…的代理之間的區別。 知道 確實如此——而且本週這兩張唱片的紀錄相差了四十張。.

想找個人幫你檢查經紀人的所有報價單，把所有可能顯示為零的報價單都標記出來嗎？ 預約自動化策略會議 我們將一起進行審核。.

——喬恩