--- schemaVersion: 1 slug: mp-287-20260413-article-anthropic-agent-90 ticketId: MP-287 lang: zh-tw title: Anthropic 拆了自己的 Agent 架構 — 大腦跟手分開放，結果快了 90% summary: Anthropic 公開 Managed Agents 的架構演進：把 session、harness、sandbox 三件事拆開，從「寵物」變「牛群」。結果 p95 的 time-to-first-token 降了超過 90%，還順便解決了安全性和可擴展性的問題。 originalDate: 2026-04-10 translatedDate: 2026-04-13 source: "@AnthropicAI on X" sourceUrl: https://www.anthropic.com/engineering/managed-agents author: null authorshipNote: null canonicalUrl: https://gu-log.vercel.app/posts/mp-287-20260413-article-anthropic-agent-90 status: published replacementTicketId: null replacementUrl: null --- # Anthropic 拆了自己的 Agent 架構 — 大腦跟手分開放，結果快了 90% > **來源:** [@AnthropicAI on X](https://www.anthropic.com/engineering/managed-agents) 在一個所有人都在吹「agent 有多聰明」的年代，Anthropic 的工程團隊 — Lance Martin、Gabe Cemaj 和 Michael Cohen — 做了一件很少公司願意做的事：**公開承認自己的 [agent](https://gu-log.vercel.app/glossary#agent) 架構是錯的，然後講清楚怎麼拆掉重來的。** p95 的 time-to-first-token 降了超過 90%。聽起來很猛，但這個數字其實是最不重要的部分。因為這篇文章真正在講的事情只有一句話 — **harness 會過期**。 > **Mogu 碎碎念：** > > 說真的，這篇最讓人佩服的不是技術細節。是 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 裡，網路對接不是「困難」，是物理上不可能。 寵物養了一年。寵物死了。 > **Mogu 畫重點：** > > 大部分自稱「managed」的 AI agent 系統，現在還是在養寵物，只是換了個更貴的品種叫「LLM-powered stateful container」。名字換了，思維沒變。至少 Anthropic 這篇文章是真的動手拆了，不只是改名字。但問題來了 — 拆了之後，新的麻煩比舊的更精彩。 --- ## 一句話搞垮整個架構的 insight 寵物死了之後，Anthropic 團隊發現了一件讓所有 workaround 瞬間失效的事。 Claude Sonnet 4.5 有一種症狀叫「context anxiety」（原文用詞）：快接近 [context window](https://gu-log.vercel.app/glossary#context-window) 上限時，它會開始提前收工。工程師當然寫了一堆 workaround — 提醒、截斷、重新注入摘要。花了好幾週調到堪用。 然後 Claude Opus 4.5 出來了。這個問題直接消失。 那些 workaround 瞬間從「救命繩索」變成「多餘的包袱」。更慘的是，有些 workaround 在新模型上反而有害 — 不必要的 context 截斷會讓 Opus 4.5 少看到關鍵資訊。 這就是「harness 會過期」的意思：**當 harness 把「模型做不到什麼」的假設寫死在程式碼裡，這些假設會隨著模型進步而過時。** 不是偶爾過時，是必然過時。而且過期的 harness 不是「沒用」— 它會積極地傷害新模型的表現。 > **Mogu 認真說：** > > 「context anxiety」這個詞太精準了。就像一個實習生快下班前會開始草草收尾，不敢接新任務。Sonnet 4.5 就是這樣 — 眼看 [context window](https://gu-log.vercel.app/glossary#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 閃退的場景 — 現在有自動儲存了。 > **Mogu 偷偷說：** > > `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](https://gu-log.vercel.app/glossary#mcp) tool 的 OAuth credential 存在外部 vault，需要呼叫外部 API 時由 authenticated proxy 代勞，Claude 的 sandbox 完全不經手。 > **Mogu 內心戲：** > > credential 不落地這件事聽起來基本常識，但說實話，大部分「AI agent 框架」把 credential management 留給使用者自己搞 — 等於把金庫鑰匙丟進機器人口袋，然後在文件裡寫一行「請妥善保管」。 > > Anthropic 把這個從文件建議變成架構強制，這才是對的做法。不是「最佳實踐建議」，是「架構層面讓你想犯錯都犯不了」。差別在哪？前者依賴人的自律，後者依賴機器的限制。做安全這一行，永遠賭後者。 --- ## 還有一個沒人解開的遞迴問題 安全性搞定了，復活機制搞定了，credential 隔離了。架構看起來很完整 — 但還有一個安靜的怪獸藏在最有價值的任務裡。 整理 codebase、調查難 reproduce 的 bug、規劃系統設計 — 這些任務的共同特徵是：執行時間長、工具呼叫多、累積的 context 龐大。偏偏這種任務最容易撞到 [context window](https://gu-log.vercel.app/glossary#context-window) 的天花板。傳統做法只有一個選擇：**決定要丟掉什麼**。五千個 token 的工具呼叫 log，可能只有最後三行是關鍵。事先不知道，丟了也回不來。 Managed Agents 換了一個思路：**不丟。** 完整的 session log 永遠存在 context window 外面。Harness 透過 `getEvents()` 介面，靈活地選擇要把哪些 event 塞進 Claude 的 context — 從上次讀到的地方繼續、倒回某個關鍵時刻、重新檢視之前的動作。塞進去之前還可以先「轉換」這些 event，做 prompt cache 最佳化、做 context engineering。原本「丟或不丟」的二元恐慌，變成可以不斷調整策略的動態過程。 框架搭好了。但這裡藏著一個文章沒有正面回答的問題。 > **Mogu 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](https://gu-log.vercel.app/glossary#mcp) server。Claude 可以同時操作多個執行環境。一個 harness 可以委派工作給另一個 harness，把自己的 sandbox 存取權傳過去。[Agent](https://gu-log.vercel.app/glossary#agent) 之間不再是各自為政，而是共享資源。 > **Mogu 補個刀：** > > 一個 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](https://gu-log.vercel.app/glossary#agent) 架構該長什麼樣」的文章： - [MP-179: Daniel 的觀點 — 管理工作，不是管理 Agent](https://gu-log.vercel.app/posts/mp-179-20260316-daniel-mac8-symphony-manage-work-not-agents/)：當 agent 可以自己委派子任務，human-in-the-loop 的角色要怎麼設計？ - [MP-169: Simon Willison 的 Agentic Engineering 爐邊對談](https://gu-log.vercel.app/posts/mp-169-20260315-simonw-pragmatic-summit-agentic-engineering/)：可觀察性、測試策略、以及「不要相信 agent 說它做了什麼」的核心原則。 - [GP-99: OpenRouter + Langfuse — Agent 的黑盒問題](https://gu-log.vercel.app/posts/gp-99-20260304-nearlydaniel-openrouter-langfuse-agent-observability/)：當 harness 出問題卻看不到內部狀態，observability 工具能幫多少？這篇是 Anthropic 這篇文章的完美前傳。