我係 Lena。讀完嗰篇 Managed Agents 架構 blog 之後，我將 Anthropic 嘅 engineering blog 喺 mon 上面開住咗好耐。唔係因為我急住要去試——比較係因為佢個 framing 打斷咗我嘅預期。
佢哋將 agent 嘅基礎設施類比做 OS。OS 將硬件虛擬化成 process、file、socket 呢啲抽象——呢啲抽象活得仲耐過硬件本身。然後佢哋話：我哋為 agent 做咗同樣嘅事。
呢句我坐咗一陣。
Claude Managed Agents 喺 2026 年 4 月 8 日入 public beta。佢唔係一個新 model。佢係一個基礎設施層——一個 hosted runtime，Claude 喺一個受管環境入面做自主 agent 咁跑。Anthropic 設計佢嘅方式，有啲嘢值得慢落嚟睇，尤其係如果你嘅 team 喺度決定緊：agent 呢個層係自己起、定係交畀人。
呢啲係我留意到嘅嘢，同埋我仲喺度諗緊嘅嘢。
Claude Managed Agents 係乜
長時任務嘅托管服務
講到底，Claude Managed Agents 就係一套 API，負責 agent 執行嘅 runtime。你定義個 agent 要做乜——system prompt、工具、約束。Anthropic 喺一個隔離嘅雲 container 入面跑佢，Claude 喺入面可以讀 file、執行 code、上網、透過 用 MCP 做底嘅 connector call 外部服務。
賣點好簡單：與其花幾個月自己整 agent loop、sandbox、tool 編排、error recovery、credential 管理，不如將嗰一層交畀 Anthropic。根據 官方嘅 Managed Agents 文檔，個 harness 原生支援 prompt caching、context compaction 同性能優化——呢啲正好係大多數 team 最後都要由零寫一次嘅嘢。
定價係 consumption-based：用標準 Claude API token rate，另加 每個 session-hour 運行時 $0.08。Idle 時間唔計。Runtime 精確到毫秒。冇月費。冇 per-agent license。
……呢個定價結構令我睇咗兩次。佢意味住真正嘅成本 driver 唔係 runtime 本身——而係你個 agent 嘅 tool loop 喺 session 期間食 token 有幾兇。每一次 bash 命令、file read、web fetch 都喺度 contribute token。$0.08/hour 相對於一個重 agent session 燒嘅 inference 費用，幾乎係凑個數。
Session、harness、sandbox 同事件介面
呢 part 先至係架構對我嚟講變有意思嘅地方。
Anthropic 嘅 Managed Agents engineering blog 描述咗三個被虛擬化嘅組件，每一個都被設計成可以獨立演化：
Session 係一份 append-only 嘅持久事件 log。每一條 user message、assistant response、tool call、tool result，都以 typed event 形式記落嚟。佢完全活喺 harness 外面。佢捱得過 crash、斷網、container restart。兩個介面原語：appendEvent() 同 getEvents()。就係咁多。
Harness 係 agent loop——佢 call Claude、route tool call、管理 context。關鍵係：Anthropic 自己持有呢一層，亦會隨住 model 進步而 update。佢哋發現為 Claude Sonnet 4.5 寫嘅 harness 入面有一段 context-reset 邏輯，用嚟處理「context anxiety」，但係到 Claude Opus 4.5 出嘅時候，嗰種 anxiety 已經冇咗。舊 harness 實際上喺度拖住新 model 後腿。就係呢個觀察，催生咗成個架構。
Sandbox 係執行環境——一個 gVisor 隔離嘅 container，Claude 生成嘅 code 喺入面跑。網絡 egress default-deny。Filesystem 訪問係 scoped。credential 唔會存喺 sandbox 度——佢哋放喺一個安全 vault 度，透過 proxy 獲取。sandbox 喺設計上被當成唔可信。
我一直兜返嚟呢個分離。佢乾淨。但係直到我諗清楚「下一個 model 出嘅時候會發生乜」之前，我先至真正明白呢件事點解重要。
Managed Agents 解決咗乜
Runtime 基礎設施、sandboxing、可恢復 session
如果你試過將一個 agent 推上生產，呢張清單你一啲都唔陌生：sandbox 化嘅執行、credential 管理、session 持久化、error recovery、可觀測性。有一位開發者描述過：為咗令一個 agent 喺生產上跑得起，佢哋團隊整咗六個獨立系統——其中四個同 agent 實際做緊嘅嘢冇乜關係。
Managed Agents 將呢一整類工作消除咗。Session 可以跑幾個鐘。如果 connection 斷咗，session 會由持久事件 log 度恢復返。每一個 tool call 同 failure mode 都可以透過內建嘅 observability 追蹤。Notion、Asana、Sentry 咁樣嘅公司已經將起喺呢個基礎設施上嘅 agent 集成咗入去。
實際影響係真實嘅。 一個讀 codebase、plan fix、開 PR 嘅 coding agent。一個跑九十分鐘、跨幾十次 web search 嘅 research agent。呢啲 pattern 以前喺開始寫 agent 邏輯之前，要幾個月嘅基礎設施工作。
點解將「大腦」同「手」解耦咁重要
……就係呢度，有啲嘢啪一聲卡到位。
Anthropic 將呢個架構框成：將「大腦」（model 加埋決定要做乜嘅 harness）同「手」（真正執行工作嘅 tool 同 sandbox）解耦。嗰個分離有一個具體後果：當更好嘅 model 出嘅時候，harness 可以 update 而唔需要郁你嘅 agent 定義。
喺舊嘅耦合設計入面，每個 session 都要畀齊個 container startup cost——包括嗰啲從來唔掂 sandbox 嘅 session。當 Anthropic 將 harness 由 container 度搬出去之後，唔需要 code execution 嘅 session 就可以唔使等 container provisioning 就啟動。
但係更深一層嘅 point，係講耐久性。Harness 編碼嘅係「model 做唔到乜」嗰啲假設。嗰啲假設會隨住 model 嘅進步過期。如果你個 harness 係你自己整嘅一個寫死系統，你就繼承咗「令嗰啲假設保持 current」嘅維護成本。如果 Anthropic 持有個 harness，呢份成本就轉咗畀佢哋。
我唔係完全確定呢個承諾喺更長時間尺度上兌現幾多。但架構上嘅推理，對我嚟講係講得通。
Managed Agents 默認解決唔到嘅嘢
呢 part 係我諗咗最耐嘅地方。
能力驗證、跨 agent 再用、治理生命週期
Managed Agents 將 runtime 呢個問題解得幾徹底。但係有啲相鄰問題佢冇處理——唔係因為佢有缺陷，而係因為佢哋坐喺佢而家 scope 嘅外面。
能力驗證。 當一個 agent 成功完成一個複雜任務——例如分流某一類 security alert、或者 refactor 某個特定嘅 code pattern——嗰次成功唔會被 capture 做「一個經過驗證、可再用嘅能力」。Session log 記咗發生咗乜，但係 冇一個機制可以話「呢條路行得通，將佢編碼做其他 agent 可以繼承嘅 strategy」。 每個 session 都係由頭開始。Claude 喺一個 session 入面學到嘅嘢，唔會自動令下一個 session 變得更好。
跨 agent 再用。 你可以定義一次 agent，然後跨 session 按 ID 引用佢。嗰個係配置層面嘅再用——同一條 prompt、同一套工具、同一套約束。但係嗰個唔係能力層面嘅再用。如果 Agent A 發現咗一套對某個 framework 有效嘅 debug strategy，Agent B 喺做類似問題嘅時候唔會自動受益——除非有個人手動去 update 個共享嘅 system prompt。
治理生命週期。 Beta 包括咗 scoped permission、identity 管理、執行 tracing。但係更闊嘅治理問題——喺一個 agent 嘅行為擴散出去之前，邊個去驗證佢安全，隨住時間過你點樣 audit capability drift——呢啲 pattern 唔喺而家嘅 surface 度。
我可能諗多咗。呢啲可能係未來嘅 roadmap item。但係而家睇嚟，Managed Agents 提供嘅係出色嘅受管執行，唔係內建嘅能力累積。 如果你諗嘅係長期嘅系統改進而唔淨係任務自動化，呢個分別就重要。
……呢度有啲嘢仲唔夠清晰。我覺得呢個 gap 係有意為之嘅——Anthropic 係先解基礎設施問題，而能力演化係另外一個層。但我而家仲未完全肯定。
Managed Agents vs Claude Code Routines
長時 runtime vs 可觸發嘅自動化
呢個對比一開始令我有啲混亂，但係兩邊都睇過之後就清晰咗。
Claude Code Routines 係儲起嚟嘅配置——prompt、repo、connector——按 schedule、API 調用或者回應 GitHub 事件自動跑。佢哋為 冇人睇住、可重複 嘅任務設計，例如每晚 triage、PR review、文檔漂移 scan。每次 run 都係一個新鮮 session。每日有配額（按 plan 由 5 到 25 次）。佢哋由你嘅 subscription usage 度扣。
Claude Managed Agents 係為 長時、自主嘅工作 設計嘅 hosted runtime。Session 可以跑幾個鐘。Harness 負責 context compaction、error recovery、tool 編排。按 token 加上 per-session-hour 計費。冇每日 run 上限——你用幾多畀幾多。
最簡單嘅分別：Routines 係可觸發嘅自動化。Managed Agents 係 agent 基礎設施嘅 runtime。 Routines 假設任務係有界、可重複。Managed Agents 假設任務係開放式、可能會做一陣。
一個 plan 多 file refactor、跑 test、開 PR 嘅 coding agent——嗰個係 Managed Agents 嘅地盤。一個每晚畀新 issue 打 label、post 總結去 Slack 嘅 script——嗰個係 Routine。
兩樣都唔可以取代對方。但係佢哋兩個，冇邊個可以淨靠自己將「成功執行」變成「可再用能力」。
邊個應該認真評估 Managed Agents
基於我見到嘅，如果你個 team 符合下面呢啲條件，Managed Agents 就值得認真評估：
你已經整咗 agent 原型，然後撞咗基礎設施嘅牆。 由「做到嘅 demo」去「生產部署」嗰跳，係大多數 team 卡住嘅地方。如果你個 backlog 入面寫住「做 sandbox isolation」「整 session checkpoint」「設計 credential 管理」，Managed Agents 將呢整類工作消除咗。
你嘅 agent 任務係長時、多步。 如果個 agent 要讀 codebase、plan 改動、執行 code、跑 test、開 PR——全部喺一個可能一個鐘嘅 session 入面——呢種就係 Managed Agents 設計嚟處理嘅 workload。短、同步嘅任務，交畀 標準 Messages API 仲好。
你同 beta 邊界冇意見。 所有 endpoint 都要 managed-agents-2026-04-01 beta header。Multi-agent 協同同 self-evaluation 仲喺 research preview 度。行為有機會變。唔好將 mission-critical workflow 砌喺仲未到 GA 嘅 surface 上面。
你諗過 lock-in 呢條問題。 一旦你嘅 agent 跑喺 Anthropic 嘅基礎設施上面，換 provider 就唔係咁輕鬆。Anthropic 關於 Managed Agents 嘅 blog post 將呢件事框成一個有意為之嘅 trade-off：托管嘅 harness evolution，代價係同一個 runtime 耦合。如果你嘅架構要求 mix 多個 provider 嘅 model，呢個約束就有份量。
你唔係預設期待能力繼承。 Managed Agents 畀你嘅係出色嘅受管執行——而唔係一個「成功行為會跨 session 累積同自我改進」嘅系統。
FAQ
Managed Agents 支援邊啲 model？
Public beta 支援 Claude Sonnet 4.6、Claude Opus 4.6 同 Claude Haiku 4.5。大 context（1M tokens）喺 Opus 同 Sonnet 上面預設可用。
點計錢？
Model 使用按標準 Claude API token rate，另加每個 session-hour $0.08 嘅活躍 runtime 費。Web search 每 1,000 次搜索 $10。Idle 時間唔計。冇月費。
Beta 同 research preview 有咩分別？
核心平台——session、sandboxing、tool 執行——喺 public beta。Multi-agent 協同同 self-evaluation（outcomes）喺 research preview，要另外 request access。
我可唔可以設 per-session 嘅 budget 上限？
喺 Managed Agents 入面直接就唔得。你可以喺 Claude Console 度設一個 organization-wide 嘅月花費上限，但係 per-session 嘅 budget cap 而家冇文檔。將 session 創建包一層你自己嘅邏輯去追蹤同終止失控 session，係實際嘅 workaround。
每個 session 係咪由頭開始？
Session 喺單個 session 內會保留 state——file system、對話歷史、event log。但係跨 session 嚟講，冇內建嘅記憶或能力轉移。每個新 session 都由一個乾淨環境開始。
呢個同 Claude Code 係咪一樣？
唔一樣。Claude Code 係一個畀開發者做交互式編程嘅工具。Managed Agents 係 API 層嘅基礎設施服務，用嚟大規模部署自主 agent。佢哋共享架構 DNA，但服務嘅係唔同受眾。
我仲坐喺呢個架構前面。session、harness、sandbox——每一個都被虛擬化，每一個都可以獨立演化。佢解嘅 runtime 問題係真實嘅，對於卡喺原型同生產之間嘅 team 嚟講，呢個將時間線由幾個月變咗做幾日。
但係我仲係會留意到「受管執行」同「會累積嘅能力」之間嗰段空間。Session log 記咗發生嘅所有嘢。佢仲未將「發生咗乜」變成「下一個 session 可以繼續搭上去嘅嘢」。
Previous Posts：
👉 想搞清楚 Claude Code 點接外部工具同 agent？由 MCP 嘅基礎開始：What Is MCP? The AI Tool Connection Standard Explained
👉 想令 agent 行出 prompt 之外？呢篇講清楚 skill 喺 Claude Code 入面點樣運作：Claude Code Skills Explained: Build, Share, and Extend
👉 好奇 agent 基礎設施層喺真實系統度點疊？呢篇畀你完整架構視角：MCP, CLI, and GEP: The Three Layers of the Agent Stack
👉 喺比較「基礎設施 vs 能力」？呢篇講清楚大部分 team 漏咗嘅關鍵分別：Agent Skills vs GEP Assets: The Real Difference
👉 想睇 agent memory 實際上點 scale（同埋喺邊度會爆）？呢篇深入講真實 tradeoff：Hermes Agent Memory Limits and Tradeoffs
