Your Agent Failed in Prod. Good Luck Reproducing It. - Tisha Chawla & Susheem Koul, Microsoft

生產環境中的 AI Agent 故障往往具有不可複現的特性——工程師拉取遙測日誌中的提示詞，用相同模型本地運行卻完美工作，多次重試仍無問題，但那一次失敗的運行已造成實際損害。講者以一個股票交易 Agent 為例：使用者要求「賣 $1,000 的 ACME 股票」，但 Agent 誤將金額數字 1,000 理解為股票數量，執行了賣出 1,000 股的操作。以每股 $190 計算，原本 $1,000 的交易變成了 $190,000 的災難。更糟的是，API 返回乾淨的 HTTP 200 回應，沒有任何例外或警報，所有監控儀表板仍然完全綠燈。

面對這類問題，工程師的直覺反應是將模型溫度設為零，期望貪心解碼能帶來確定性行為。但這完全是誤解。溫度為零只是保證每次都選擇機率最高的 token，卻根本無法修復破碎的推理路徑。更致命的是，位元確定性在硬體層級本來就不存在。浮點運算不滿足結合律，矩陣運算的時序改變會影響最終邏輯進而改變獲勝 token；更重要的是批處理變異性——同一請求會與其他在該毫秒內到達伺服器的請求分組，是否通過某個子網路完全取決於當時批入的流量。混合專家模型（MoE）的路由也面臨相同的容量限制問題。

因此，追求精確的文本輸出重現是一場必然失敗的戰爭。講者提出了根本性的轉變：不追求位元確定性（相同輸入必然相同輸出），而追求可重放性（能夠重建已發生過的運行以進行調試）。位元確定性是可控性（controllability），而可重放性是可觀測性（observability）。我們不需要模型完全確定性，只需要記錄它做了什麼、捕捉狀態快照。

為此，講者介紹了 Chronicle 框架。其核心概念是「邊界」（Boundary），一個包圍 Agent 工作流中任何節點的邊界框，無論是工具呼叫、LLM 呼叫或 RAG 檢索。只要是方法就可用 Boundary 註解標記，確保進入和離開該方法的所有內容都被記錄。同時可定義模型版本、程式碼版本等參數，使整個 Agent 運行的完整狀態被凍結並儲存為追蹤。

在實際應用中，Chronicle 不僅記錄失敗場景，還將這些記錄用作測試用例。一旦在工具層面添加了護欄修復邏輯，就可以用之前記錄的追蹤執行測試，在其他節點打樁而僅讓修改過的節點實際運行。這使得測試變得確定性、免費且可重複。講者強調了兩種測試方式的區別：確定性測試用於護欄和工具呼叫等決定性節點，行為測試則用 LLM as Judge 來評估 Agent 的語氣和決策軌跡。