除非重試預算明確，否則 API 逾時會將使用工具的代理變成重試債務
一個新鮮的 r/AgentixLabs 線程 使得生產版本的代理故障難以忽視。 API 超時並不是罕見的噪音。它們是正常操作條件。真正的錯誤是將每次超時視為暫時的不便，模型應該可以解決它。這就是為什麼片狀依賴性如何變成額外的模型呼叫、重複的工具嘗試以及事後無人能解釋的事件時間的原因。
超時是生產事實，而不是即時缺陷
當外部依賴停滯時，團隊通常首先責怪模型，因為模型是堆疊的可見部分。這就忽略了操作問題。逾時可能來自下游 API、身份驗證漂移、佇列壓力、租戶特定的速率限製或失敗前需要很長時間的錯誤請求形狀。如果線束無法區分這些情況，則代理人會將每次失敗視為另一個推理機會。
這就是為什麼超時工作流程感覺比紙上看起來更昂貴的原因。每次重試都可以在任務落地或終止之前觸發更多的規劃、更多的上下文重複使用、更多的工具敘述和更多的人工審查。故障始於依賴層，但帳單涉及整個運行過程。
沒有預算的重試邏輯變得昂貴
一個簡單的重試循環看起來是孤立的。當兩次嘗試之間沒有發生任何有意義的變化時，問題就會出現。相同的工具，相同的有效負載系列，相同的依賴關係，相同的阻塞狀態。從運行時的角度來看，另一種嘗試似乎是可行的。從操作員的角度來看，系統在客戶等待的同時，也慢慢排練同樣的故障。
修復方法不是零重試。修復方法是顯式重試策略。定義何時逾時需要再次嘗試、何時代理應正常降級、何時應暫停並稍後恢復運行以及何時應由人工接管。如果沒有這個邊界，工具超時就會悄悄地變成重試債務。
在認為工作流程可靠前要衡量什麼
按工具測量逾時率、每個成功結果的重試計數、重試增加的總延遲以及每次運行在失敗後採取的路徑：降級、升級或停止。也要記錄足夠的日誌以便稍後對事件進行分類：哪個工具超時、發生了多少次嘗試、有效負載是否發生變化以及是否存在冪等性防護。如果您只知道代理“運行”，那麼您不知道工作流程是否有效。
Token Robin Hood 適合該層。該產品不應承諾保證節省。它應該幫助團隊在任務獲得支出之前分析、發現和優化代幣使用擴展的地方。
下一步的實際行動
選擇一種具有真正外部依賴性的生產工作流程。為每個工具提供超時類別、重試預算和明確的後備操作。然後比較政策更改前後每項成功任務的成本。這將告訴你更多關於代理可靠性的信息，而不是關於模型是否“足夠好”的其他一般爭論。