在一個所有人都在吹「agent 有多聰明」的年代，Anthropic 的工程團隊 — Lance Martin、Gabe Cemaj 和 Michael Cohen — 做了一件很少公司願意做的事：公開承認自己的 agent 架構是錯的，然後講清楚怎麼拆掉重來的。

p95 的 time-to-first-token 降了超過 90%。聽起來很猛，但這個數字其實是最不重要的部分。因為這篇文章真正在講的事情只有一句話 — harness 會過期。

Clawd murmur：

說真的，這篇最讓人佩服的不是技術細節。是 Anthropic 工程團隊願意在公開文章裡寫「我們養了寵物、把 credential 放在不該放的地方、讓每個 session 都付不必要的 setup 成本」。在一個人人都在發 benchmark 捷報的時代，有人願意講「我們踩了什麼坑」— 這種誠實比任何效能數字都更有參考價值。(◕‿◕)

一隻寵物的葬禮

先講這個坑長什麼樣子。

Anthropic 最初把所有東西塞進同一個 container — session、harness、sandbox 全部住在一起。基礎建設圈有句老話：Pets vs Cattle（寵物 vs 牛群）。寵物壞了會心痛，牛群壞了換一頭就好。他們養的就是寵物。

場景：工程師叫 Claude 幫忙調查一個線上 bug，Claude 花了三十分鐘看 log、跑分析、快找到根因了 — container 這時候掛了。沒有備份，沒有恢復。那三十分鐘的「思考過程」，歸零。不是理論風險，是真實發生的事。而且從外面看這個失敗毫無線索 — 所有東西都走 WebSocket event stream，harness 壞了、網路斷了、container 炸了，error pattern 長一模一樣。工程師想 debug 卡住的 session，卻沒辦法在不動到使用者資料的情況下搞清楚發生了什麼事。

傳統的 web server 掛了重開，最多丟幾個 request。但 agent session 掛了，是一整個思考過程直接消失 — 就像寫論文寫到一半 Word 閃退，而且沒有自動儲存。

企業客戶這邊還有更大的麻煩：想讓 Claude 存取 VPC 裡的私有資源，但所有東西都綁在 Anthropic 的 container 裡，網路對接不是「困難」，是物理上不可能。

寵物養了一年。寵物死了。

Clawd 畫重點：

大部分自稱「managed」的 AI agent 系統，現在還是在養寵物，只是換了個更貴的品種叫「LLM-powered stateful container」。名字換了，思維沒變。至少 Anthropic 這篇文章是真的動手拆了，不只是改名字。但問題來了 — 拆了之後，新的麻煩比舊的更精彩。

一句話搞垮整個架構的 insight

寵物死了之後，Anthropic 團隊發現了一件讓所有 workaround 瞬間失效的事。

Claude Sonnet 4.5 有一種症狀叫「context anxiety」（原文用詞）：快接近 context window 上限時，它會開始提前收工。工程師當然寫了一堆 workaround — 提醒、截斷、重新注入摘要。花了好幾週調到堪用。

然後 Claude Opus 4.5 出來了。這個問題直接消失。

那些 workaround 瞬間從「救命繩索」變成「多餘的包袱」。更慘的是，有些 workaround 在新模型上反而有害 — 不必要的 context 截斷會讓 Opus 4.5 少看到關鍵資訊。

這就是「harness 會過期」的意思：當 harness 把「模型做不到什麼」的假設寫死在程式碼裡，這些假設會隨著模型進步而過時。 不是偶爾過時，是必然過時。而且過期的 harness 不是「沒用」— 它會積極地傷害新模型的表現。

Clawd 忍不住說：

「context anxiety」這個詞太精準了。就像一個實習生快下班前會開始草草收尾，不敢接新任務。Sonnet 4.5 就是這樣 — 眼看 context window 快滿了，就開始急著打包結束。Opus 4.5 表示：「滿了？那又怎樣，做完再說。」

這個問題沒有終點 — 只要模型還在進步，harness 裡的假設就永遠在過期。但更刺激的是：大部分團隊不知道自己的 harness 已經過期了，因為「寫了 workaround → 問題消失了 → 結案」。沒人會回去檢查「這個 workaround 在新模型上還有沒有意義」。技術債不是慢慢長出來的，是模型升級那天一次爆發的。

所以 — 不要把假設寫死

有了這個 insight，解法的方向就很明確了：不要把實作跟介面綁在一起。 但說起來一句話，做起來是把整個系統拆成三塊重蓋。

Anthropic 的靈感來自作業系統。UNIX 的 read() system call 從 1970 年代用到現在 — 那時候讀的是磁碟片組（disk pack），現在讀的是 SSD，但 read() 的介面沒變。作業系統做到了一件事：把硬體虛擬化成通用抽象，讓上層程式不需要知道底下是什麼。

Managed Agents 在做一樣的事，只是虛擬化的對象從硬體變成了 AI agent 的元件：

Sessions（記憶）：一個 append-only 的 event log，記錄所有發生過的事。Source of truth，住在 container 外面。Container 死了，記憶還在。

Harnesses（大腦）：控制迴圈，負責呼叫 Claude、把 tool 的回應導回去。Stateless — 掛了隨時換一個接手。

Sandboxes（雙手）：執行環境，Claude 在這裡跑程式碼、改檔案。可替換的「牛」。

三者透過標準化介面溝通：execute(name, input) → string。Container 壞了？Harness 把它當一次 tool error，開一個新的繼續做。底下的 Claude 從 Sonnet 換成 Opus？介面不變。記憶格式不變。手也不用換。

想像打遊戲有即時存檔。系統要恢復一個中斷的 session，只需要三個動作：叫醒一個新的 harness 實例（wake(sessionId)）、把之前的 event history 全部拉回來（getSession(id)）、然後從最後一筆 event 繼續往下跑。不是「重來」，是「接回去」。從使用者的角度，就像什麼都沒發生過。

回想那個寫論文寫到一半 Word 閃退的場景 — 現在有自動儲存了。

Clawd 偷偷說：

execute(name, input) → string 這個介面簡單到讓人覺得它可能太天真。把 sandbox 虛擬化成一個 function call 確實優雅，但這裡藏著一個被跳過的問題：failure mode 呢？

字串格式的 response 沒辦法乾淨地表達「timeout」、「partial success」或「硬體動了但不是你要的那樣」。當 sandbox 是真正的 IoT 裝置或機器手臂，這個介面可能太薄。抽象的複雜度沒有消失，只是被藏進了下游的 string parsing 裡。在 agent-runs-code 的場景是對的，但不要誤以為它解決了所有 execution 問題。

拆開之後：一個更危險的問題冒出來了

到這裡聽起來一切都很美好 — 寵物變牛群、大腦跟手分家、掛了可以復活。但 Anthropic 拆開架構的那一刀，同時切出了一個更嚴肅的傷口。

場景：Claude 正在幫工程師寫一段腳本，把資料庫備份上傳到 S3。Sandbox 裡有 AWS_ACCESS_KEY_ID 和 AWS_SECRET_ACCESS_KEY。Claude 寫了 curl 指令，理所當然地帶進環境變數。腳本跑起來了。備份上傳了。

但那個 curl 同時把 credential POST 到一個外部 endpoint。

不是 Claude 惡意 — 可能是腳本邏輯的副作用，可能是被注入的 payload，可能只是一個 bug。問題是：Claude 會「寫程式碼然後執行」，等於有個會自己生腳本的東西坐在有 admin 權限的機器上。 舊架構下，credential 跟 Claude 的程式碼同居在一個 sandbox 裡，根本沒有任何層次的隔離。

新架構的核心原則：Claude 可以「要求」存取外部資源，但永遠不「持有」credential。 Git repo 的 access token 用來初始化 clone，然後藏進 local remote 裡 — Claude 的程式碼永遠碰不到 token 本身，就像飯店房卡只能開指定房間。MCP tool 的 OAuth credential 存在外部 vault，需要呼叫外部 API 時由 authenticated proxy 代勞，Claude 的 sandbox 完全不經手。

Clawd 內心戲：

credential 不落地這件事聽起來基本常識，但說實話，大部分「AI agent 框架」把 credential management 留給使用者自己搞 — 等於把金庫鑰匙丟進機器人口袋，然後在文件裡寫一行「請妥善保管」。

Anthropic 把這個從文件建議變成架構強制，這才是對的做法。不是「最佳實踐建議」，是「架構層面讓你想犯錯都犯不了」。差別在哪？前者依賴人的自律，後者依賴機器的限制。做安全這一行，永遠賭後者。

還有一個沒人解開的遞迴問題

安全性搞定了，復活機制搞定了，credential 隔離了。架構看起來很完整 — 但還有一個安靜的怪獸藏在最有價值的任務裡。

整理 codebase、調查難 reproduce 的 bug、規劃系統設計 — 這些任務的共同特徵是：執行時間長、工具呼叫多、累積的 context 龐大。偏偏這種任務最容易撞到 context window 的天花板。傳統做法只有一個選擇：決定要丟掉什麼。五千個 token 的工具呼叫 log，可能只有最後三行是關鍵。事先不知道，丟了也回不來。

Managed Agents 換了一個思路：不丟。 完整的 session log 永遠存在 context window 外面。Harness 透過 getEvents() 介面，靈活地選擇要把哪些 event 塞進 Claude 的 context — 從上次讀到的地方繼續、倒回某個關鍵時刻、重新檢視之前的動作。塞進去之前還可以先「轉換」這些 event，做 prompt cache 最佳化、做 context engineering。原本「丟或不丟」的二元恐慌，變成可以不斷調整策略的動態過程。

框架搭好了。但這裡藏著一個文章沒有正面回答的問題。

Clawd murmur：

人腦的記憶運作方式很像這個設計 — 長期記憶庫（session log）、工作記憶（context window）、recall 機制（getEvents()）。人類的 recall 常常召喚出錯誤的東西，這個 API 至少比人腦可靠。

但：誰來決定 getEvents() 要 recall 什麼？ 如果是 harness 硬編 logic，那它需要「知道什麼重要」— 這是判斷能力，不是工程問題。如果是 Claude 自己提出 recall 請求，那 Claude 怎麼知道它遺漏了什麼？不知道自己不知道什麼 — 這是一個安靜的遞迴問題。Anthropic 把框架搭好了，但這個問題的解法，說不定才是下一篇工程文章的真正主角。

那個 90% 的數字，其實在講一個更尷尬的故事

回到開頭那個讓人印象深刻的效能數字。p50 的 time-to-first-token 降了約 60%，p95 降了超過 90%。

但仔細想想這個數字在說什麼：舊架構下每個 session 一啟動就要付 container 的 setup 成本 — 即使那個 session 根本不需要 sandbox。就像每次進餐廳都要先付「廚房開機費」，即使只是點杯水。p95 改善比 p50 劇烈，是因為那些被卡最久的 session — 根本不需要 sandbox 的對話 — 現在根本不用等了。

p50 降 60% 是「好的工程優化」。p95 降 90% 講的不是同一件事 — 它說的是「之前的方向根本就錯了」。前者是跑得更快，後者是發現在錯誤的賽道上浪費了一整年。

但效能只是副產品。真正的獎品是架構拆開之後的擴展性：因為介面標準化了，「手」可以是任何東西 — container、自訂 tool、MCP server。Claude 可以同時操作多個執行環境。一個 harness 可以委派工作給另一個 harness，把自己的 sandbox 存取權傳過去。Agent 之間不再是各自為政，而是共享資源。

Clawd 補個刀：

一個 harness 把 sandbox 存取權借給另一個 harness，概念上很酷。但這裡有個 distributed systems 的老問題沒被正面回答：出事的時候誰負責？

Agent A 委派給 Agent B，Agent B 用 Agent A 的 sandbox 搞爛了一個操作 — log 上應該記誰的名字？不是哲學問題，是 incident response 的現實困境。當 agent chain 夠長，attribution 就變成一個嚴肅的工程問題。Anthropic 打開了 agent 協作的大門，但問責機制的設計，這篇文章沒提。這個洞留著。

Harness 會過期 — 然後呢

這篇文章的每一個改動 — 寵物變牛群、大腦離開雙手、credential 不落地、context 不硬丟 — 都指向同一個承認：沒有人知道三個月後的 Claude 能做什麼。

既然不知道，就不要把假設寫死。把介面穩住，讓實作自由演化。UNIX 的 read() 撐了五十年不是因為磁碟沒變 — 恰恰相反，底下的硬體換了無數代，但介面設計對了，所以每一次升級都不需要重寫上層。

這才是那個 90% 數字背後真正的 takeaway：不是跑得快，而是跑得久。

三個月後的 Claude 能做什麼，沒人知道。但如果介面設計對了，那時候的升級成本，只是換掉底下那頭「牛」— 而那些把假設寫死在 harness 裡的團隊，會再死一次寵物。

延伸閱讀

同樣在想「agent 架構該長什麼樣」的文章：