功能變多大家都會講，出錯後回不回得來才麻煩
我看 2026.6.8 release notes，第一眼其實不是看新模型，也不是看 Telegram 表格終於比較正常這種表面功能。我反而先把幾個 recovery 相關的修正圈起來，因為這種東西平常不顯眼，真的出事的時候才知道差很多。
補充一下，我自己的習慣是看 agent 類產品更新時，會先找三種字眼：fallback、abort、resume。因為功能多一點，通常只是多一個入口；但 recovery path 少補一個洞，可能就是整段流程卡死，還不一定第一時間看得出來。
這版裡我最有感的是那串「More reliable agent runs」。裡面不是只有籠統地寫穩定性提升，而是很具體地把幾個容易壞的地方補上了：generated media completions 要能走回正確路徑，reset archive fallback reads 要恢復，restart shutdown aborts 跟 yielded subagent pauses 也要處理，另外還把 session identity prompts 補進去。這幾個名字單看很碎，可是放在一起就很清楚，團隊在補的是同一件事，就是系統偏離預期之後，能不能自己找到回來的路。
很多人看 release note 會比較容易被 richer channel delivery 吸走注意力，像 Telegram 保留 intentional line breaks、tables、expandable blockquotes，WhatsApp 也比較不 brittle。這些當然重要，因為使用體驗真的會好很多。我不是說這些不值得看，而是如果底下的狀態機不穩，畫面再漂亮也只是把錯誤包裝得比較順。thinking 面板、rich reply、漂亮表格，這些都比較像表層；真正撐住日常使用的是你昨天那個跑到一半中斷的 session，今天還能不能接得回去。
另外一個我會特別記的是 memory/state 那段。有寫到 oversized OpenAI embedding batches split before 431s，也有 SQLite avoids WAL on NFS volumes。這兩條看起來很 infra，但其實就是典型的「沒踩過的人不會主動做，踩過一次就忘不了」。前者是在請求太大時先拆批，避免直接撞 431；後者是在某些儲存環境下少掉 WAL 帶來的副作用。這不是那種拿來宣傳會很好看的功能，可是如果你真的每天在跑資料、跑索引、跑 workflow，這種修正的價值通常比多一個新開關還直接。
我之前整理 internal automation 的時候也有類似經驗。最常讓人誤判的不是明顯報錯，而是流程看起來有在跑，實際上已經偏掉了。訊息發出去了，但送錯 channel。任務重新啟了，但讀不到前一段 archive。subagent 表面上 pause 了，實際上 terminal 那邊早就 abort。這些問題單一看都像小 bug，可是累積起來，使用者對系統的信任會掉很快，因為你不知道下次壞掉會壞在哪。
所以我現在看 agent 產品更新，反而會先用一個很無聊的標準判斷：它有沒有把失敗當成主要場景在設計。如果 release notes 裡開始大量出現 fallback reads、abort handling、state recovery、identity prompt 這類字眼，我通常會覺得是好事。表示團隊已經不只是在想「能不能做更多」，而是在想「做壞了怎麼辦」。
這類修正不 flashy，但最接近信任基建。功能大家都會加，真正麻煩的是出錯之後，系統還認不認得自己，還找不找得到原本那條路。這件事如果有補齊，版本號不用很大，我也會比較願意更新。
作者：承翰