你的 AI Agent 昨晚半夜掛了，然後整個重來：ZenML 共同創辦人聊「耐久性」這個被忽略的大問題

TL;DR

• Agent 從筆電移到雲端叢集時，「耐久性」（durability）變成最大的工程挑戰，工具逾時、網路斷線、Pod 死掉都會讓幾萬次 tool call 白費
• Harness（讓模型大腦長出身體的程式）跟底層模型已經深度耦合，Cloud Code 跟 Opus 4.8 互相訓練出默契，你把 GPT 5.5 塞進去效果反而變差
• 開源 harness（Pi、OpenClaw、LangGraph）正在跟模型供應商搶地盤，誰贏還不知道，但開放陣營的機會因為 GLM 等開源模型追到 Opus 九成五而大增
• ZenML 的新產品 Kitaru 用 checkpoint + replay 機制，讓 agent 掛掉時不用從頭跑，還能把歷史紀錄拿來做模型替換實驗
• 長期願景是每個 agent 旁邊都跑一個「教練 agent」，自動分析瓶頸、跑實驗、持續最佳化

---

這集 Practical AI Podcast 在 2026 年七月九日播出。Practical AI 是由 Daniel Whitenack 和 Chris Benson 共同主持的 AI 應用導向節目，專門把前沿的 AI 技術拆成工程師和商業人士都能消化的實務觀點。Daniel 本身是 Prediction Guard 的 CEO，同時長期做 podcast 主持，視角偏實作派。這集的來賓是 Hamza Tahir，ZenML 的共同創辦人兼 CTO，人在德國，做了五年 MLOps 框架，最近帶團隊推出新產品 Kitaru，專攻 AI agent 的耐久執行問題。ZenML 是一套開源的 MLOps 框架，讓你的 ML pipeline 可以跑在不同的雲端後端上，某種程度上就是幫企業把 AI 工作流程工程化的基礎建設。

從 MLOps 到 Agent Ops：同一批問題換了衣服回來

Hamza 開場就講了一個很有既視感的觀察：2021 年 MLOps 那波工具爆炸，跟 2026 年 agent 工具爆炸，本質上是同一件事在重演。

核心問題從來沒變過。怎麼讓非確定性的程式碼在生產環境裡安全、可靠、可重試地跑起來。

以前是「載入資料 → 前處理 → 訓練模型 → 評估模型」這種有向無環圖（DAG，Directed Acyclic Graph，就是單方向、不會回頭的流程圖）。Agent 的世界把「無環」這個前提打破了，因為 agent 本質上就是迴圈。LLM 吐 token、執行 tool call、拿到結果、再吐 token，無限循環直到完成任務。

所以 ZenML 早在 2023 年就發現使用者開始「駭」他們的 pipeline 引擎來跑 agent，硬塞動態分支跟條件邏輯進去。與其讓使用者繼續 hack，不如正式支援。

Harness 是什麼？為什麼它突然變成兵家必爭之地

Hamza 給了一個我覺得很好的定義：

LLM 本身只是一台 token 產生器，它不會「做事」。Harness 就是那個讓大腦長出手腳的程式。它接收模型吐出的 token，解析成 tool call 的參數，執行對應的程式碼，把結果餵回去，然後重複。這個 while 迴圈加上周邊的記憶管理、上下文壓縮、索引，整包就是 harness。

之前在Hermes Agent：Nous Research 的「越用越聰明」AI 賭注裡也聊過類似的「大腦 vs 身體」比喻，Jeffrey 用的框架跟 Hamza 不謀而合。

有趣的是 harness 跟模型之間已經不只是「套在一起」的關係了。Hamza 說 Cloud Code 跟 Opus 4.8 透過持續的強化學習迴圈，已經深度耦合。Opus 4.8 知道自己跑在 Cloud Code 裡面，所以它呼叫 Edit File 之類的工具時，參數特別精準。你硬把 GPT 5.5 塞進 Cloud Code 的 harness，效果反而變差。

這就是模型供應商的策略：模型性能開始趨近天花板的時候，把 harness 做好就能繼續拉開差距。Harness 好 → 通用任務表現好 → 估值撐住。

但另一邊，開源陣營（Pi、LangGraph、Pydantic AI）認為 harness 不該被綁死在某家模型上。萬一美國政府哪天把某個模型禁了呢？（Hamza 人在舊金山，他說這句話的時候語氣半開玩笑半認真。）

我的觀察是兩邊會共存一段時間，但開源 harness 的機會正在因為開源模型追上來而急速放大。

當 Agent 離開你的筆電：耐久性問題全面爆發

這是整集最核心的段落。

大部分人想到 agent，腦中畫面還是筆電上跑 Cloud Code。但企業要的是 agent 跑在 Kubernetes 叢集裡、不依賴任何人的筆電、二十四小時運作。

一旦做了這個遷移，問題清單瞬間爆炸：

基礎建設層：你需要 API 入口 → 訊息佇列 → worker 池。Agent 不是毫秒級的 REST 請求，它是有狀態的長時間程序。Worker 會因為網路問題掛掉、Pod 被搶佔、sandbox 斷線。沒有訊息佇列做緩衝，一掛就全丟。

狀態管理：一個 coding agent 跑了兩萬次 tool call，快完成功能的時候掛了。檔案系統掛載在哪？怎麼恢復到那個狀態？

版本問題：一個任務跑三十天，第十五天你更新了程式碼。第三十一天該用新版還是舊版？

模型供應鏈風險：跑到一半，底層模型被下架了。然後呢？

更新恐懼：Hamza 坦承他至今「嚇到不行」每次要更新生產環境的 agent。光是在系統提示詞裡加一個字，都不知道會在那個高熵系統裡引發什麼連鎖反應。

老實說，聽到一個做了五年 MLOps 基建的人說他更新 agent 時會怕，我反而覺得安心。至少代表這不是我自己菜，是真的很難。

Kitaru 的解法：Checkpoint 一切，然後 Replay

ZenML 的新產品 Kitaru 就是針對上面這堆問題的回應。

核心邏輯很直覺：在 agent 執行過程中的關鍵節點存快照（checkpoint），存到外部資料庫或物件儲存。掛了就從最近的 checkpoint 復原，不用從頭跑。

具體做法：

1. Kitaru 對主流 harness（Anthropic Agents SDK、OpenAI Agents SDK）做了 adapter，你不用改 agent 的 SDK、prompt 或工具定義，把 Kitaru 當 runtime 墊在底下就好
2. 執行過程中自動在狀態轉換點做 checkpoint
3. 失敗時從 checkpoint replay，不需要重新跑整段
4. 可以在歷史 trace 中間換模型、mock tool call，做「如果當初用便宜模型會怎樣」的實驗

第四點特別有意思但也特別難。Hamza 自己承認：如果你在多輪對話的中間換模型，其實你永遠不確定用新模型從頭跑的話，agent 會不會走到同一個中間狀態。所以這個實驗本質上是「有瑕疵的」，但如果你的生產 trace 樣本夠大，統計上還是能看出哪些替換是值得的。

這讓我想到之前寫過的一個 string theorist 用五分鐘拿到 Sequoia 的支票那篇裡 Matan Grinberg 講的 token 資源分配問題。每個 token 花得值不值得，需要回頭看才知道。Kitaru 做的就是讓你有辦法回頭看。

終極願景：每個 Agent 旁邊都跑一個教練

Hamza 最後丟出一個很遠但很有想像力的方向：

我的終極目標是每次你啟動一個 agent，旁邊都有一個 companion agent，像教練一樣不斷觀察它哪裡做錯了，在背景跑實驗、replay 不同配置，持續幫主 agent 調優。

這還很遠。但如果 checkpoint + replay 的基建到位，加上成本持續下降，讓一個小模型當「監工」去分析大模型的 trace，邏輯上是通的。

工具爆炸的既視感

Hamza 對產業現狀的擔憂也值得記一下。他說走在 AI Engineers World's Fair 的展場裡，看到無數公司在解決同樣四五個問題的不同 take，跟 2021 年 MLOps 工具爆炸時一模一樣。Chip Huyen 當年寫過一篇文章記錄那個混亂期，現在 agent 基建圈正在重演。

但好消息是開源模型正在快速追上。他提到 GLM 已經達到 Opus 4.8 約九成五的效能，這個差距在兩週前還很遠。當企業發現可以用開源模型達到差不多的效果，他們就會更願意投資自建 agent 平台，而不是把一切綁在某一家模型供應商身上。

我自己的判斷是，「token 成本趨近電費、模型趨向商品化」這個大趨勢下，真正的競爭優勢會在 harness 跟 infra 這層。誰能讓 agent 跑得更穩、更便宜、更容易迭代，誰就贏。

---

這類 agent 基建的話題我會持續追蹤，畢竟這是決定 AI 能不能真正從 demo 走到生產的關鍵層。想看更多類似的拆解，可以訂閱 wilsonhuang.xyz，新文章出來就會收到通知。