為什麼 Anthropic 需要做這個服務？
過去幾年，想跑 Claude 做長時間 agentic 任務的開發者，都要自己搭 harness——一個控制 Claude 呼叫、路由工具、管理 context 的執行環境。這個 harness 通常會根據模型當時的能力做出假設，一旦模型升版，假設就可能過期，harness 就需要修改。
Anthropic 把這件事稱為「harness 的假設會腐壞（go stale）」。舉例：他們發現 Claude Sonnet 4.5 在感覺到 context 快滿時會提早收工，所以在 harness 裡加了 context reset。升到 Opus 4.5 後，這個行為消失了，那個 reset 邏輯就變成累贅。
Managed Agents 的設計目標是：提供一個「假設比任何特定 harness 實作都活得長」的穩定介面——就算 Claude 內部行為改變，你的 agent 呼叫方式不需要跟著變。
換句話說，這是 Anthropic 把 agent 執行「作業系統化」的嘗試——就像 OS 把硬體虛擬化成 process/file 抽象層，讓應用程式不需要知道底下跑的是 1970 年代的磁碟還是現代 SSD。
三層解耦：Brain、Hands、Session
Managed Agents 把一個 agent 系統拆成三個可以各自替換的部分：
Claude + Harness
負責推理、呼叫 Claude API、把 Claude 的 tool call 路由到對應的基礎設施。Harness 崩潰時，只需用 wake(sessionId) 重啟，從 session log 恢復，不遺失任何狀態。
Sandbox（執行環境）
跑程式碼、讀寫檔案的隔離容器。Sandbox 故障時被當成 tool-call error 傳回給 Claude，Claude 決定是否重試——新的 sandbox 可以用 provision() 重建。這是「cattle，不是 pet」。
Event Log（持久化記錄）
獨立於 Claude context window 的 append-only 事件流。用 getEvents() 可以選擇性切片讀取，讓 long-horizon 任務的上下文不受 200K token 限制。
三層各自可以 fail、各自可以替換，互不影響。以前把所有東西塞進一個 container 的做法，讓 container 變成了「寵物」——一旦掛掉，整個 session 跟著消失，還得工程師手動進去除錯。現在每層都是「牲口」，可以隨時殺掉重建。
Credential 永遠不進 Sandbox
這是 Managed Agents 最值得關注的安全設計。過去把所有東西放在同一個 container 時，存在一個根本性的問題：Claude 產生的程式碼和 credential（如 API token）在同一個環境裡。一旦 prompt injection 成功，攻擊者只需要讓 Claude 讀自己的環境變數，就能拿到所有憑證。
Token 在 sandbox 初始化時 wire 進去
Git access token 在 sandbox 啟動時直接 wire 進 local git remote config。sandbox 裡的 git push/pull 可以正常運作，但 Claude 或 Claude 生成的程式碼從頭到尾都碰不到這個 token 本身。
Vault proxy 在 sandbox 外
自訂工具走 MCP，OAuth token 存在 sandbox 外的 secure vault。Claude 呼叫 MCP 工具時，請求經過 dedicated proxy，proxy 用 session token 從 vault 取得對應 credential 再呼叫外部服務。Harness 全程不知道 credential 內容。
Prompt injection 的影響範圍受限
就算攻擊者成功 prompt inject，Claude 生成的惡意程式碼在 sandbox 裡能拿到的只有被明確授權給那個 session 的資源，拿不到底層 credential。
結構性安全，不靠模型自律
Anthropic 明確說：靠限制 token 範圍來防止 Claude 「用受限 token 做壞事」，這本質上是在押注 Claude 的能力不會提升。結構性隔離才是正確做法。
Session Log 不等於 Context Window
Long-horizon 任務最常遇到的問題是：任務跑到一半，context window 快滿了，必須決定要丟掉哪些歷史。這個決定往往是不可逆的，而且很難在當下判斷未來的步驟會需要哪些資訊。
Managed Agents 用一個關鍵設計解決這個問題：session log 是獨立存在的 event stream，不是 Claude 的 context window。Claude 透過 getEvents() 介面選擇性地把 session 內容讀進 context：
# Session log 的三種讀取模式
# 1. 從上次讀到的地方繼續往後
getEvents(after=lastReadPosition)
# 2. 倒回某個動作前幾步，看前因
getEvents(before=specificAction, limit=5)
# 3. 在做重要決定前，重讀某段脈絡
getEvents(slice=[startIdx, endIdx])這讓 harness 在把事件傳進 Claude context 之前，可以做轉換（例如壓縮舊的 tool result）——而原始記錄保存在 session log 裡，需要時還可以再讀。不像直接做 compaction 把原始資訊不可逆地丟掉。
現在有什麼
什麼情況下用 Managed Agents
Managed Agents 最適合的場景是：你想讓 Claude 跑長時間自主任務，但不想維護自己的 harness 和 sandbox 基礎設施。它對以下情境特別有價值：
需要 managed infra 的企業
不想自建 agent 執行環境；需要 audit log、per-tool 授權、credential vault；Data 可以跑在 Anthropic infra 的場景。
Long-horizon / 多步驟任務
單一任務需要跑數小時以上；步驟數超過 context window 能記錄的量；需要跨 session 保持記憶。
Data 不能離開自己 infra
即使有 self-hosted sandbox 選項，Claude 的推理呼叫仍走 Anthropic API。如果完全 air-gapped 環境才可接受，需要另外評估。
需要高度客製化 harness 邏輯
Managed Agents 的介面刻意保持穩定（即「假設活得久」），如果你需要非常細粒度地控制 harness 行為，自建可能更靈活。
對於需要 self-hosted 的場景（公司資料不能進 Anthropic infra），Managed Agents 的 self-hosted sandbox 模式搭配自建的 MCP credential vault（如 cred-mcp）是合理的組合：Brain 走 Anthropic API，Hands 和 credential 都在自己手上。