週六小貼士：3 種方法幫你了解失敗的 AI 代理運行已經做了什麼（在重試之前）

昨晚我的一個代理運行了四十分鐘，留下了一個 320 位元組的日誌檔案。只有六行：一個頭部資訊、一個流程 ID，除此之外什麼都沒有。沒有退出程式碼，沒有結果行，也沒有錯誤訊息。.

根據我擁有的所有自動檢查工具顯示，該運行根本沒有任何作用。.

它實際上已經完成了所有工作——向一家線上供應商發送了五封陌生開發郵件，更新了五行資料庫記錄，清理了七項重複任務，並產生了自己的完成報告。這一切都是真實的，都是永久性的，但卻不可見。.

然後我的監控程式發現了缺少的結果行，判定運行失敗，並觸發了重試。這次重試會推送五次。 更多的 每天最多只能發送五封電子郵件。但並沒有達到這個限制——原因我並不引以為豪，稍後我會解釋。.

規則：失敗的運行不等於未運行的運行

退出程式碼表示進程已停止，但它不會告訴你進程停止的具體位置。在此之前，你的代理人所做的一切仍然保留在系統中——可能在其他人的資料庫中，也可能在其他人的收件匣裡。.

所以在重試失敗的AI代理運行之前，你只有一項任務：弄清楚它已經做了什麼。這裡有三個捷徑，都是昨晚就有的。.

1. 詢問目的地，而不是日誌

日誌是已終止進程留下的唯一遺留物。它是 至少 可靠的查找地點。相較之下，您的代理寫入的每個系統都保留了自己的時間戳，而這些系統從未處於危險之中。.

我的日程安排器記錄了昨晚的日程：

18:05:15 正在分發 link-outreach-conductor（超時時間為 2400 秒） 18:45:15 錯誤 — 逾時時間為 2400 秒，正在終止進程樹

四十分鐘後，銷售人員終止了銷售。現在從外部聯絡服務商的角度來看，同樣的時間視窗顯示，他們今天早上直接從 API 讀取了五個潛在客戶資訊：

10:30:12Z caroline@legaltechnology.com 10:30:13Z info@getresponse.com 10:30:14Z hello@getzendo.io 10:30:17Z zoe.sagalow@financial-planning.com 10:30:17Z zoe.sagalow@financial-planning.com 10:30:19990:1999.

那是我這邊的18:30——擊殺發生前15分鐘，正好在死亡窗口期內。日誌裡完全沒記錄下這7秒鐘的操作。我還檢查了自己的資料庫：所有五行資料都已讀取。 已聯繫.

把供應商的時間戳記當作黑盒子記錄器。日誌隨著飛機一起燒毀了。.

2. 查看您的經紀人將自己的文件存放在哪裡

這件事讓我很惱火。我的特務們完成任務後會向我的任務經理提交一份運行報告。這是昨晚的報告，今天早上我取得了這份報告：

建立時間：2026-09-25T10:45:02.199Z 完成時間：2026-09-25T10:45:02.528Z 名稱："✅ 外聯負責人 — 5 條推送，0 條回复…"

該進程於世界協調時 10:45:15 終止。此次運行已自行產生成功報告。 十三秒 在拍攝之前。.

再讀一遍，因為這才是真正的教訓：運行完成通知一直存在，它存在於一個我的故障檢測機制根本無法讀取的系統中。我的監控程式只根據一個字串進行分類—— 技能結果： — 在同一文件中。另一個系統中顯示「已完成，已推送 5 個」的報告對該系統不可見。.

列出你的特工留下的所有痕跡。在相信所謂的「沉默」之前，務必逐一檢查。這與……的原則相同。 永遠不要在沒有控制查詢的情況下信任零值 差別在於，上週該機構撒謊說什麼都沒報告，而昨晚它撒謊說… 說 沒有什麼。.

3. 永遠不要讓「沒有結果」意味著「放棄」一項需要投入時間的技能。

對於只讀技能，一次錯誤的重試只會浪費一些 API 呼叫。而對於發送電子郵件、信用卡扣款或發佈內容的技能，則會浪費雙倍的資源。.

我以為這裡有個守衛。重試只會選擇標記為「已標記」的線索。 尚未開始, 所以它肯定無法再次聯繫任何人。沒錯，而且毫無用處： 成功的 運行會將這些行翻轉為 已聯繫, 因此，過濾器會跳過這些重複項，重試程式會愉快地選擇五個全新的線索。我的重複防護機制阻止了重複項的出現，而這些重複項原本根本不存在風險。.

解決辦法並非更聰明的篩選，而是向目的地詢問預算：統計當天在該地產生的支出，從預算上限中減去該金額，然後將剩餘部分上報。這與第一種捷徑的原理相同——供應商掌握著真相。.

還有實話實說。之所以沒有發生雙重發送，是因為第一次重試在啟動時崩潰了：

身份驗證失敗：OAuth 會話已過期且無法刷新。

這本身就是個虛驚——憑證沒問題。我的調度程序不會將身份驗證令牌重新暴露給它生成的進程，而我的視訊管道會這樣做，因為同樣的漏洞在七月份導致整個叢集的視訊服務癱瘓。所以這次運行在造成損害之前就停止了。. 第二個漏洞並非安全機制。. 我之前寫過關於 在採取行動之前，先審核警報。; 這是誤報反而救了你的版本，更糟的是，這種幸運你只會注意到一次。.

作為對比：昨天這個容器上的一個憑證確實失效了。我的 Google 刷新令牌已恢復。 無效授權 連續兩天早上，Search Console 和 Analytics 仍然無法訪問，因為 任何代理人都無法在同意畫面上點選「允許」。. 一張無效的憑證，一張偽造的憑證，都在24小時內完成。其中只有一張需要人工審核。.

重點

敘述是你的代理人所做的最廉價的事情，也是它最先失去的東西。一個被終止的程序會丟棄它的日誌、摘要和註解——但會保留它已經產生的每一個副作用。昨晚遺失的只是敘述，沒有失去任何工作成果。.

因此，你的重試邏輯應該基於這樣的假設：一次失敗的運行很可能確實發生了。 某物, 然後去查清楚。和…是同一家人 確保你可以撤銷你的代理人所做的任何操作。 ——只不過在這裡，你不是在撤銷，你只是拒絕做兩次。.

今天花十分鐘：選擇一個負責向外發送訊息的代理任務，並回答一個問題。如果任務送到一半失敗，重試會傳送什麼內容？如果目標系統無法回答，你沒有重試策略──只能靠拋硬幣決定。.

就是這樣 無人值守運行代理 實際上，關鍵不在於更聰明的提示，而在於準確了解半死不活的跑圖會留下什麼。如果你不想用我的方式學習，, 預約策略諮詢 我們將繪製出堆疊中的支出路徑，以防其中一個路徑被觸發兩次。.

——喬恩