Your Agent Didn't Fail. Your Harness Did. — Vinoth Govindarajan, OpenAI
三句話摘要
AI Agent 系統的失敗大多源於架構問題而非模型問題，需要從狀態所有權、操作順序、生命週期管理、授權控制和證據保留五個維度重新設計系統架構。 生產 AI Agent 的核心挑戰不在模型有多聰明，而在系統架構能否通過清晰的狀態所有權、有序的操作提交、完整的生命週期管理、嚴格的授權控制和鏈式的證據追蹤，把「模型的提議」轉化為「系統確實執行並且用戶真的看到了」。 系統可靠性的三層差異：用戶可見的成功（交付）、系統內部記錄（持久化狀態）、下一輪可重播（可驗證性）這三層可能不同步。沈默的成功比崩潰更危險，因為用戶和操作者都看不出問題，但模型會基於不完整的歷史給出看似自信的回答。
重點整理
重點- 1
系統可靠性的三層差異：用戶可見的成功（交付）、系統內部記錄（持久化狀態）、下一輪可重播（可驗證性）這三層可能不同步。沈默的成功比崩潰更危險，因為用戶和操作者都看不出問題，但模型會基於不完整的歷史給出看似自信的回答。
- 2
狀態所有權必須單一且可回溯：每個事實都需要明確的擁有者（如日曆事件屬於日曆系統、對話輪次屬於會話記錄）。所有權不是人員，而是能重構現實的持久化記錄系統。如果沒有系統能回放某個事實，就表示系統沒有可靠地記住它。
- 3
操作必須有序且單一提交路徑：多個寫入者各自正確但同時執行時會導致先後更新被無聲覆蓋。需要明確的提交順序機制（隊列、互斥鎖、事務），保守地在提交時應用，而非整個系統層級，因為用戶會把順序感知為個性和行為。
- 4
外部邊界必須有明確終態和證據鏈：工具調用、消息傳送、文件修改等操作在未完成時會讓系統卡住。每項工作需要截止時間、超時、取消機制和完整的收據記錄，追蹤完整的調用鏈（提議 → 授權 → 執行 → 用戶側確認）。
實用技巧與重點
乾貨- 五個生產失敗模式（with receipt 會捕捉什麼）：
- State hole：用戶看到傳送成功，但狀態或會話記錄遺漏了該變更
- Overlapping writers：兩個寫入者各載入同一舊狀態，各改不同記錄，第二個儲存無聲覆蓋第一個
- Dangling tool call：會話包含工具調用但沒有對應結果，系統卡住等待永不到達的事件
- Approval drift：過期的授權仍被當作有效的狀態使用，導致舊權限仍可執行
- Missing edge proof：工具報告成功，但用戶界面未顯示結果（內部成功 ≠ 外部成功）
- Harness 藍圖五層：
- Event（事件源：聊天、webhook、計時器、工具結果）
- Session key（會話映射確保單一寫入者）
- Control plane（模型+工具）
- Tools with approvals & policies（執行前置條件）
- Audit trail / Receipt（完整證據記錄）
- 審計五問框架（應用於每個生產路徑）：
- 什麼觸發了這個運行？（身份來源：用戶消息、webhook、計時器等）
- 繼承了什麼狀態？（會話記錄、內存快照、策略版本、工具定義）
- 用了什麼授權？（記錄：行動者、會話、工具、運行 ID、參數、作用域、有效期）
- 什麼被執行了？（不是意圖摘要，而是實際 API 調用、重試次數、冪等鍵、外部結果）
- 什麼證據留存了？（票據更新了嗎、消息渲染了嗎、文件改了嗎、日曆事件建立了嗎）
- 關鍵概念：
- 生產合同：Model proposes → Harness commits → Receipt proves
- 車的比喻：模型是引擎（能力），系統架構是方向盤、剎車、交通規則、儀表、黑盒（控制）
- 收據(Receipt)vs 記錄單(Transcript)：記錄單記的是 Agent 說什麼，收據記的是系統實際允許、嘗試、執行了什麼以及用戶端確認了什麼
- 批准(Approval)物件必填字段：誰批准、哪個會話、哪個運行、哪個工具、哪些參數、有效期、結果
結論
結論“生產 AI Agent 的核心挑戰不在模型有多聰明，而在系統架構能否通過清晰的狀態所有權、有序的操作提交、完整的生命週期管理、嚴格的授權控制和鏈式的證據追蹤，把「模型的提議」轉化為「系統確實執行並且用戶真的看到了」。”
完整解析
詳細演講開場用一個真實生產事故揭開序幕：用戶要求 Agent 記錄一筆退款，系統回應說已記錄，用戶看到的界面看起來正常，但下一輪對話時 Agent 完全沒有這筆記錄。這不是幻覺、不是崩潰、不是胡言亂語，而是一種隱蔽失敗——用戶可見邊界看起來成功，但持久化記錄卻有空洞。講者 Vinod 強調這類問題的危險性在於，系統依然可以流暢地生成下一個回答，只是基於一份破碎的歷史。這就是為什麼 Agent 可靠性不能只停留在模型質量層面。
Vinod 在 OpenAI 從事 code、data 與 AI 基礎設施工程，此前在蘋果和優步做分布式系統。他用 OpenClaw（OpenAI 的一個 Agent 系統）作為公開案例研究，因為其代碼、問題追蹤、文檔使得系統架構異常透明。演講的核心論述是一份「生產合同」：模型提議行動，系統確認並執行，收據證明了什麼實際發生。如果只記一個比喻，就是買車——沒人會只看馬力選車，你也在乎方向盤、剎車、道路規則、儀表和黑盒記錄器，因為模型提供能力，架構才提供控制。一台有強力引擎卻沒有剎車的車不是自動駕駛，那是有加速度的責任。
系統架構藍圖包含五層：事件從聊天、webhook、計時器、其他系統進入；控制平面根據會話鍵映射事件，確保每個可變狀態只有一個主動寫入者；運行時調用模型和工具；工具通過批准和策略執行；審計線索記錄完整收據。關鍵洞察是 Agent 運行時是無狀態的，它為每一輪重新組裝工作集（會話記錄、狀態、內存、策略、工具定義），模型只看見架構提供的信息。如果某個輸入遺漏或過時，答案仍可能聽起來連貫——連貫性不等於工作集完整。
講者列舉五個生產失敗模式，每個都打破了不同的邊界。狀態空洞：用戶看見回應，源系統卻無法重播那個改變，交付成功但持久化失敗。重疊寫入者：兩個調用者載入同樣的舊狀態，各改不同記錄，第二次儲存無聲覆蓋了第一次，用戶可能看見遭駁回的確認重新浮現。懸空工具調用：運行等待永不到達的事件（進程死亡、連接中斷、超時未記錄），系統卡住，新消息在後面排隊等待。授權漂移：過期批准仍被當作有效的持久化狀態提供，卡住了後續工作。缺失邊界證明：工具報告成功，但消息未在用戶界面渲染——內部路徑接受了請求，不等於用戶看見了結果。
對應的架構修復指向同樣的五個維度。狀態所有權：每個事實需要明確擁有者，能夠重構現實。操作順序：明確的提交路徑（隊列、互斥鎖、事務），保守地在提交時應用，因為用戶會把順序感知為行為特性。生命週期：每項工作需要截止時間、超時、取消、最大重試次數，收據記錄終端結果，下一步不用猜測。授權控制：批准物件必須綁定具體行動、包含有效期，不能當作模糊的「用戶可能在系統附近」。邊界證明：收據追蹤完整鏈條——模型提議、策略允許/拒絕、執行嘗試、用戶側確認/失敗。
演講最後提出一份審計框架，應用於每個實際生產路徑：什麼觸發了它（身份來源）、繼承了什麼狀態、用了什麼授權、實際執行了什麼、什麼證據存活下來。這五個問題能把流暢對話轉化為可檢驗的生產運行。它們曝露因果關係，讓團隊可以追蹤狀態所有權破裂在何處、操作順序跳過了什麼、授權過期了卻仍被使用、執行與用戶感受之間的鴻溝。
關鍵時刻
Pipeline v2帶時間戳的重點，會在逐字稿層級分析上線後產生。目前請先透過原始影片觀看。
事實查核
Pipeline v2說法查證是下一次管線升級的一部分。KeyFrame 只會顯示它真正能驗證的內容。
