Anthropic 在四月連續推出了兩個 agent 基礎建設: Managed Agents (4/8) 和 Advisor Strategy (4/9)，五月又加了 dreaming、outcomes、多代理編排等進階功能。

雖然因為供應商綁定(vendor lock-in)的關係，小編不太會推薦直接在 production 採用這些服務 — 但非常感恩 Anthropic 把開發過程中的架構決策都公開分享出來，特別是那篇工程部落格 Scaling Managed Agents: Decoupling the brain from the hands，讀起來就像一份高品質的分散式系統設計文件。

這篇就來整理這些功能背後的架構思路，看看有哪些設計決策值得自己做 agent 系統時參考。

Managed Agents: 託管式的 Agent Harness

先講清楚定位: Managed Agents 不是什麼新的模型能力，它是 harness 層的產品化。模型還是同一個 Claude，差別在於外面包的那層迴圈和基礎設施 — agent 迴圈、沙盒、工具執行、上下文管理、錯誤恢復 — 全部由 Anthropic 託管。你只要定義任務、工具和約束條件，就能在他們的基礎設施上跑長時間的自主 agent。

工程部落格裡用了一個很有意思的說法: meta-harness。意思是 Managed Agents 不是某一種特定的 harness，而是一個「可以跑各種 harness 的框架」。他們的原話是: 「不對 Claude 未來需要什麼樣的具體 harness 做假設，而是設計通用的介面，讓各種不同的 harness 都能在上面跑。」 例如 Claude Code 是一個優秀的 harness，針對特定領域的 agent 也可以有自己專屬的 harness — Managed Agents 可以容納所有這些，隨著模型的智慧提升而調整。

這個定位蠻關鍵的，因為 Anthropic 自己在過去的工程文章裡就反覆強調: harness 裡的假設會隨著模型進步而過時。例如 Sonnet 4.5 會因為感知到上下文快用完而提早結束任務，他們在 harness 裡加了上下文重置來應對; 但換成 Opus 4.5 之後這個行為消失了，重置反而變成多餘的負擔。meta-harness 的設計就是為了應對這種「今天有用、明天多餘」的問題 — 介面穩定，實作可以隨時換。

Lance Martin (Anthropic 員工) 在 X 上的貼文和架構部落格裡詳細解釋了設計演進。小編覺得最有價值的部分不是產品本身，而是他們怎麼一步步踩坑、然後解決問題的過程。

核心架構: 把大腦和雙手分開

這是整個 Managed Agents 最重要的架構決策。

第一版: 所有東西塞在同一個容器裡

一開始，Anthropic 把所有元件 — 對話紀錄、agent 迴圈、沙盒 — 都放在同一個容器裡。好處是簡單: 檔案操作就是系統呼叫，不需要設計服務邊界。

但這產生了一個經典的基礎設施問題: 他們養了一隻「寵物」。在「寵物 vs 牲畜」(pets vs cattle) 的比喻裡，寵物是你不能失去的、需要細心照料的個體; 牲畜則是可以隨時替換的。他們的容器就是那隻寵物 — 容器掛了，整個對話就沒了; 容器沒回應，只能想辦法搶救。

更糟的是，因為 agent 產生的不受信任程式碼跟憑證跑在同一個容器裡，一個成功的提示注入攻擊只需要說服模型讀取自己的環境變數，就能拿到所有權杖。

編按: Aparna Dhinakaran 在 X 上的整理把新舊架構的差異講得很簡潔 — 舊版: 一個容器，死了對話就沒了，憑證暴露給不受信任的程式碼。新版: 迴圈是無狀態的，沙盒是可丟棄的，推理立即啟動，憑證永遠碰不到。

第二版: 三個獨立介面

解法是把系統拆成三個獨立的元件，每個都可以獨立失敗或替換:

🔹 Session (對話紀錄) — 只附加的事件日誌，獨立於任何元件之外。迴圈透過 emitEvent() 寫入，透過 getEvents() 讀取。不管迴圈或沙盒怎麼掛，紀錄都還在。

🔹 Harness (迴圈/大腦) — 呼叫模型、路由工具呼叫的迴圈邏輯。完全無狀態 — 掛了就用 wake(sessionId) 重啟一個新的，從事件日誌裡撿回進度繼續跑。

🔹 Sandbox (沙盒/雙手) — 執行程式碼和編輯檔案的隔離環境。迴圈像呼叫任何其他工具一樣呼叫它: execute(name, input) → string。容器變成牲畜 — 掛了就重開一個，迴圈把失敗當作工具錯誤傳回模型，讓模型決定要不要重試。

小編覺得這個三層拆分的思路非常通用。工程部落格裡有一個很精彩的類比: 作業系統把硬體虛擬化成 process 和 file 這些抽象層，讓還不存在的程式也能在上面跑。read() 指令不在乎底下是 1970 年代的磁碟還是現代 SSD。抽象層比實作更持久。 Managed Agents 對 agent 元件做了同樣的事。

安全邊界: 憑證永遠不碰沙盒

這是小編覺得特別值得注意的設計。拆分之後，安全邊界變得很乾淨:

  • Git 存取: 用 token 在沙盒初始化時 clone repo，token 寫進 git remote 設定裡。沙盒裡可以 push/pull，但 agent 永遠碰不到 token 本身。
  • 外部工具: 透過 MCP 協定連接，OAuth token 存在安全保險庫裡。模型透過專用代理呼叫 MCP 工具，代理用 session token 去保險庫取憑證再發出請求。迴圈和沙盒都不知道憑證的存在。

在舊架構裡，你得靠限縮 token 的權限範圍來降低風險 — 但這是在假設模型不夠聰明來利用有限權杖。隨著模型越來越強，這個假設會越來越脆弱。結構性地讓憑證不可達，比任何權限限縮都更可靠。

Session 不等於上下文視窗

另一個精彩的設計決策: session (事件日誌) 和模型的上下文視窗是分開的東西。

長時間任務會超過上下文視窗的容量，傳統的處理方式 — 壓縮、摘要、裁剪 — 都涉及不可逆的取捨，很難預判未來哪些 token 會被需要。Managed Agents 的做法是: 完整的對話歷史永遠儲存在 session 日誌裡，迴圈可以透過 getEvents() 隨時回去查任何歷史片段。送進上下文視窗之前，迴圈可以對事件做任意轉換 — 排序、篩選、重新組織，怎麼做取決於當下的需求。

這樣分離的好處是: 可恢復的上下文儲存 (session 的責任) 和任意的上下文工程 (迴圈的責任) 被切開了。你不需要預測未來模型需要什麼樣的上下文管理策略 — 只要保證原始紀錄永遠在，策略可以隨時換。

多腦多手: 水平擴展

解耦之後帶來的直接好處是可以水平擴展。

多腦: 以前每個 session 都要開一個容器，推理要等容器啟動完才能開始。拆開之後，迴圈是無狀態的，不需要容器的 session 就不用等。官方數據顯示，p50 的首 token 回應時間降了約 60%，p95 降了超過 90%。

多手: 每個大腦可以連接多個沙盒，因為每隻手都只是一個工具介面。迴圈不在乎沙盒是容器、手機、還是 (官方原文) 一個寶可夢模擬器。而且因為手跟腦不綁定，大腦之間可以互相傳遞手的使用權。

進階功能: 只有外層迴圈才能做的事

Managed Agents 在五月加了幾個進階功能，小編覺得有趣的是: 這些功能都需要外層迴圈的基礎設施才能實現，不是模型本身能做到的。

Memory: 跨 Session 的持久記憶

Memory stores 讓 agent 在不同 session 之間保留資訊。技術上是把一組文字檔案掛載到沙盒的目錄裡，agent 用跟操作其他檔案一樣的工具來讀寫。

設計上有幾個值得注意的地方:

  • 支援 read_only 和 read_write 兩種存取模式 — 如果 agent 會處理不受信任的輸入，read_only 可以防止提示注入污染記憶庫
  • 每次修改都會產生不可變的版本紀錄，可以審計、追溯、還原
  • 最多掛載 8 個記憶庫，可以依使用者、專案、生命週期分開管理

Lance Martin 在 X 上分享了 memory 的設計思路，核心概念跟 Claude Code 的 CLAUDE.md 和 memory 檔案很像，但被結構化成了 API。

Dreaming: 讓 Agent 在 Session 之間自我改進

Dreaming 是一個排程程序，會回顧過去的 session，提取模式、整理記憶。它能發現單一 agent 看不到的東西 — 例如反覆出現的錯誤、團隊間共通的偏好、agent 收斂出來的工作流程。

你可以選擇讓 dreaming 自動更新記憶，或者由人類審閱後才寫入。Harvey (法律 AI 公司) 用了 dreaming 之後，agent 的任務完成率提升了約 6 倍。

Outcomes: 獨立評估者

Outcomes 讓你寫一份評分標準描述「成功長什麼樣」，然後由一個獨立的評估模型在自己的上下文視窗裡打分。關鍵在於: 評估者不會被 agent 的推理過程影響，因為它看的是輸出而不是思考過程。不及格的話，評估者會指出具體問題，agent 再修正。

這個「做事的人跟評估的人分開」的設計，在 AI 系統裡蠻重要的。官方數據顯示，outcomes 讓任務成功率比標準的提示迴圈高了最多 10 個百分點，文件生成品質也有顯著提升。

多代理編排

多代理編排讓主 agent 把工作拆分給多個專門的子 agent，每個子 agent 可以有自己的模型、提示和工具。它們在共享檔案系統上平行工作，主 agent 可以中途查看其他 agent 的進度。Netflix 的平台團隊用這個功能來平行分析數百個 build 的日誌。

編按: 以上這些進階功能 — dreaming、outcomes、多代理編排 — 都做在 Managed Agents 這個託管服務上，而不是開放成通用 API。這也合理，因為它們都需要外層迴圈 (session 日誌、排程、獨立的評估推理) 才能運作，不是單純的模型呼叫能搞定的。

Advisor Strategy: 小模型呼叫大模型

Advisor Strategy 是同期推出的另一個架構模式，概念相對簡單。

傳統多模型架構是大模型當編排者往下分派任務給小模型。Advisor strategy 反過來: Sonnet 自己跑完整流程，卡住了才往上問 Opus。Opus 看完完整對話上下文後回一段 400-700 token 的建議，然後 Sonnet 繼續跑。全程在同一個 API request 裡完成，不需要額外的來回。

Lance Martin 在 X 上用了一個比喻: 「資淺律師做 95% 的工作，資深合夥人只在關鍵決策點審閱。比資淺律師獨自硬啃便宜也更好，但只在需要時才請資深的出手。」

官方數據: Sonnet + Opus advisor 比 Sonnet 單獨高 2.7 個百分點 (SWE-bench)，成本反而低 11.9%。Haiku + Opus advisor 則是 Haiku 單獨分數的兩倍多，成本比 Sonnet 低 85%。

詳細的技術文件在這裡。

幾個實務觀察

不過 advisor strategy 在實際使用上有些值得留意的地方:

  • 誰決定何時求助? 執行者自己判斷什麼時候該問顧問。但開發者 Mejba Ahmed 觀察到，Sonnet 有時候會過度自信，該問的時候不問。他也碰過連續多次呼叫 advisor 卻越叫越沒方向的情況。
  • 省錢有前提: Vincent Schmalbach 的實測顯示，小任務用 advisor 反而比不用貴 53%。省錢的前提是任務夠長、夠複雜。官方文件也承認 advisor 對單輪問答和簡單任務沒幫助。
  • 成本控制不完善: max_tokens 只限制執行者的輸出，不限制顧問的 token 消耗。沒有對話層級的呼叫次數上限，需要自己在用戶端計數和清理。
  • 平台限制: 目前只能搭配 Claude 模型使用，而且只支援 Claude API 和 Claude Platform on AWS，Bedrock、Vertex AI、Foundry 都不支援。

架構設計的啟發

綜合 Managed Agents 和 Advisor Strategy，小編整理出幾個自己做 agent 系統時值得參考的架構原則:

1. 把推理、執行、紀錄拆開

這是最核心的教訓。推理迴圈 (大腦)、程式碼執行 (雙手)、對話歷史 (記憶) 應該是三個獨立的元件，各自可以失敗和替換。一旦拆開，你就能:

  • 迴圈掛了從紀錄恢復，不丟進度
  • 沙盒掛了重開一個，不影響推理
  • 水平擴展任何一層

2. 對話歷史要獨立於上下文視窗

不要把模型的上下文視窗當成唯一的紀錄來源。完整的事件日誌應該儲存在外部，上下文視窗裡放的是經過篩選和工程處理過的版本。這樣你可以隨時回溯、重放、用不同策略重新組織上下文，不怕壓縮或裁剪造成資訊永久遺失。

3. 憑證不碰執行環境

不要靠「限縮權限範圍」來保護憑證，而是讓執行環境根本碰不到憑證。透過代理層或初始化時注入的方式，讓 agent 可以「使用」服務但「看不到」密鑰。模型越聰明，權限限縮就越不可靠; 結構性隔離才是根本解法。

4. 小叫大，不一定大叫小

Advisor strategy 的啟發: 不一定要用最強模型當編排者。讓便宜模型跑大部分工作，只在關鍵節點呼叫強模型做決策，架構更簡單、成本更可控。但要注意「由誰決定何時升級」這個問題 — 執行者的自我評估能力是這個模式的瓶頸。

5. 評估和執行要分開

Outcomes 的設計揭示了一個重要原則: 做事的 agent 和評分的 agent 應該在不同的上下文裡運作。評估者不該被執行者的推理過程影響。這跟軟體工程裡「寫程式的人不該自己做最終 QA」是同一個道理。

6. 記憶需要主動整理

光是把資訊存下來不夠，還需要有機制定期回顧、提取模式、清理過時內容。Dreaming 做的就是這件事。在你自己的 agent 系統裡，可以用排程任務定期掃描歷史 session，整理出可複用的經驗。

現實面: 採用前要想清楚的事

架構設計再漂亮，產品要拿來用還是得面對幾個硬傷。社群裡最普遍的批評是供應商綁定(vendor lock-in) — 記憶、編排、評估全部跑在 Anthropic 的基礎設施上，想搬家不是換個 API key 就好，你得重建整個編排層。而且只能跑 Claude 模型，不支援 Bedrock、Vertex AI，對已經標準化在某個雲端平台的企業來說，這個服務等於不存在。

成本預測性也是問題。$0.08/session-hour 聽起來便宜，但 24 個 agent 各跑 8 小時就是 $15.36/天的 session 費用，還沒算 token。跟 OpenAI 純 token 計費或 Microsoft 容量制相比，預測性最差 — 偏偏這個定價結構懲罰的恰好是複雜的長時間任務，也就是你最需要 agent 的場景。

資料合規則是另一個硬傷。全託管 runtime 意味著所有資料都跑在你不擁有的基礎設施上，對需要證明資料落地(data residency)的企業是合規噩夢。Anthropic 企業方案有隱私承諾，但「承諾」跟「資料不離開自家機房」是兩回事。不過好消息是，Anthropic 在五月推出了 Claude Platform on AWS，讓企業透過 AWS 帳號存取完整的 Claude 平台功能 (包括 Managed Agents)，整合 IAM、CloudTrail 稽核和 AWS Marketplace 統一帳單，也支援用 inference_geo 參數指定推理的地理區域。對於需要更嚴格資料隔離的場景，還可以搭配 Amazon Bedrock 讓 AWS 作為唯一的資料處理者。這個方向算是在合規問題上踏出了重要的一步。

開源替代: LangChain Deep Agents

如果你對這套架構有興趣但不想被綁在 Anthropic 生態系裡，LangChain 的 Deep Agents 值得關注。Harrison Chase 在 Managed Agents 發布當天就推出了對應的開源版本 deepagents deploy，明確定位為 Claude Managed Agents 的開源替代。

Deep Agents 是一個 MIT 授權的 agent 框架，在架構上解決的問題跟 Managed Agents 很像，但核心差異在於不綁定任何模型供應商。LangChain 的工程部落格講得蠻直白:

「越來越多託管 agent 服務在方便的同時帶來供應商鎖定 — 綁定單一模型供應商、封閉的迴圈、隱藏在 API 背後的功能 (例如伺服器端壓縮產生的加密摘要，你在其他生態系裡用不了)。實際後果是團隊失去了對 agent 運作方式的可見性，也失去了修改它的能力。」

官方提供了一份對照表:

  Deep Agents Deploy Claude Managed Agents
模型支援 OpenAI、Anthropic、Google 等任意供應商 僅 Anthropic
迴圈 開源 (MIT) 封閉原始碼
沙盒 LangSmith、Daytona、Modal、Runloop 或自訂 內建
自行部署 支援 不支援
Agent 端點 MCP、A2A、Agent Protocol (開放協定) 專屬 API

架構上，Deep Agents 的設計思路跟 Managed Agents 有很多平行之處:

🔹 迴圈與沙盒分離: agent 可以跑在沙盒裡面 (跟 Claude Agent SDK 一樣)，也可以跑在長駐容器裡、透過網路遠端操控沙盒。沙盒掛了不影響 agent 迴圈。

🔹 持久化對話紀錄: 用 checkpointer 做短期記憶 (thread 層級)，production 環境用 PostgreSQL 儲存。迴圈和紀錄分開，迴圈無狀態、可以水平擴展。

🔹 跨 session 的長期記憶: 用 Store 做跨對話的持久化，支援語意搜尋 (pgvector)。可以設定 namespace 做使用者/專案隔離。記憶以檔案形式掛載到 agent 的虛擬檔案系統裡。

🔹 憑證隔離: 沙盒裡的 API 金鑰透過 auth proxy 管理，金鑰永遠不出現在沙盒的程式碼或日誌裡。

🔹 多代理編排: 透過子 agent 委派任務，每個子 agent 有獨立的上下文視窗。部署後的 agent 之間可以用 MCP 和 A2A 互相呼叫。

五月中 LangChain 又推出了 Managed Deep Agents，是 Deep Agents 的託管版本，跑在 LangSmith 上。有趣的是，即使是託管版本，底層迴圈仍然是開源的 — 你可以隨時切換回自建部署，不需要改程式碼。

部署方式也比較彈性: 全託管 (LangSmith Cloud)、混合式 (控制平面在雲端、資料平面在自家機房)、完全自建 (整套跑在自己的 Kubernetes 上) 都支援。

總結

小編覺得 Anthropic 這一系列的 agent 基礎建設，最有價值的不是產品本身 — 畢竟供應商綁定(vendor lock-in)對認真做架構的團隊來說是個硬傷。真正有價值的是他們把踩過的坑和設計決策都寫成了高品質的工程文件公開分享。

「把大腦和雙手分開」「session 不等於上下文視窗」「憑證永遠不碰沙盒」「做事跟評估分開」— 這些原則不管你用哪家的模型、用什麼框架，都適用。而 LangChain Deep Agents 也證明了這些架構 pattern 可以用開源、跨供應商的方式實現。

架構思路是跨平台的，產品不是。帶走 pattern，不必帶走產品。