失敗後能不能恢復，才是 agent 拉開差距的地方
我做 SRE 有幾年了，看過太多系統在 happy path 上跑得很漂亮，一遇到 timeout 就整個卡死。AI agent 也一樣，現在大家底下用的模型不是 Claude 就是 GPT，差的其實是系統層有沒有真的把錯誤路徑處理好。
OpenClaw 這次的 release notes 給了我一個蠻具體的視角來思考這件事。
失敗路徑才是真正的分水嶺
這次改動集中在幾個地方：interrupted tool call recovery、stale session binding 修復、以及 provider/plugin timeout 的全面綁定。
以 interrupted tool call 來說（#88129, #88136, #88141, #88162 這幾個 issue），情境是 agent 跑到一半的時候 tool call 中斷了，session 可能也跑掉了。以前大概是整個重跑，或者留下一個爛掉的狀態等人去清。現在修的是讓 agent 恢復的時候能接回原本的 transcript，orphan tool state 也會清掉，media completion delivery 會重試。
聽起來是細節，但在實際環境裡很要命。我自己跑過一個比較長的 agent 任務，中間因為網路抖動 tool call 斷了，然後 session binding 還停在舊的狀態。要注意的是，stale session binding 不只是「任務要重跑」這麼簡單，如果 binding 沒清乾淨，下一次 run 可能撿到上一次的殘留狀態，然後做出完全不對的決定。這種 bug 最難追，因為表面上 agent 還在跑，只是行為怪怪的。等你發現，可能已經錯了好幾步。
Timeout 不是 nice-to-have
另一塊讓我注意的是 timeout 的全面綁定。release notes 的說法是把 OAuth/device-code lifetimes、media downloads、local service probes、generated-content polling paths 全部都 bound 住，不讓任何一條能 hang 住整個 run。
這段話對 SRE 來說很有共鳴。沒有 timeout 的系統，穩不穩定靠的是運氣。每一個 external call 沒有被 bound 住，就是一個潛在的 hang 點。以前 AI agent 工具這塊比較粗糙，很多地方是 best-effort 的，設計上沒有把「超時」當成一級公民處理。
另外也有改 GitHub Copilot OAuth request timeout，「cap GitHub Copilot OAuth request timeouts before creating abort signals」。看起來小，但 OAuth 超時是我見過最多的「為什麼 agent 不動了」原因之一。有時候就卡在 auth 那邊，沒有任何錯誤訊息，整個 run 就掛著。
Workboard 的意義
最後聊一下 Workboard 加的 orchestration primitives。multi-agent 系統現在蠻流行，但很多人忽略的一件事是：多個 agent 在跑的時候，你怎麼知道哪個 agent 跑到哪裡了？哪個 task 被哪個 agent 鎖定？失敗的時候怎麼重新分配？
這些問題沒有答案，multi-agent 架構就只是好看。Workboard 這次加了 task-backed board runs 和 agent coordination tools，方向是給 multi-agent run 一個可以追蹤的 boundary。對 SRE 來說，有 observability 的系統才是可以 operate 的系統，agent 也一樣。
三件事加在一起，interrupted tool call recovery、timeout binding、multi-agent run tracking，其實指向同一個問題：你的 agent 架構在非理想狀況下會怎麼死，以及死了之後能不能爬起來。模型夠聰明只是入門，這些地方處理得好不好才是分水嶺。
補充一下，這波版本是 [email protected]，release notes 裡有 25+ 個相關 issue number，想追細節可以去對。另外要注意的是，這些 fix 有些影響的是 CLI-backed runtimes 的行為，如果是跑 embedded 或 channel turns，建議確認一下使用情境有沒有對上。
作者：承翰