嗨，我係 Lena。睇完 Anthropic 嘅發佈公告之後，我將嗰個標籤頁開咗好耐。唔係因為有咩睇唔明——其實嗰份文檔寫得異常清晰——而係因為我想坐低慢慢消化佢哋劃出嘅嗰條界線。呢個唔係一個新模型。呢點我即刻就明白咗。但多讀咗幾次之後，我先開始搞清楚佢究竟係咩，同埋更有價值嘅部分——佢唔打算成為咩。
以下係我整理出嚟嘅內容。
Claude Managed Agents 到底係咩
沙箱運行時，唔係新模型
首先要講清楚嘅一件事：Claude Managed Agents 係一個基礎設施層，唔係模型升級。 呢個係 Anthropic 託管嘅 agent 運行時——一個介於你嘅代碼同你已經喺度用嘅 Claude 模型之間嘅託管環境。
Claude Managed Agents 提供咗將 Claude 作為自主 agent 運行所需嘅框架同基礎設施。你唔再需要自己搭建 agent 循環、工具執行同運行時，而係得到一個完全託管嘅環境，Claude 可以喺入面安全噉讀取檔案、執行命令、瀏覽網頁同運行代碼。
我嘅理解方式係咁嘅：你定義 agent 做咩，Anthropic 負責令佢跑起嚟所需嘅一切。沙箱容器、會話管理、工具執行、錯誤恢復、上下文處理——呢啲就係搭建生產級 agent 嘅「第二份工」，嗰個同智能完全冇關、但令大多數團隊花三到六個月先做得啱嘅部分。Managed Agents 幫你搞掂咗呢件事。
Sessions、Environments 同 Agent Harness
有四個概念值得一開始就搞清楚。Agent 係模型、系統提示、工具、MCP Server 同技能嘅組合——定義一次，通過 ID 引用。Environment 係預裝軟件包同網絡訪問規則嘅雲端容器。Session 係引用你嘅 agent 同 environment 嘅運行時實例。而 Harness 就係 Anthropic 所講嘅協調呢一切嘅管理層。
Anthropic 嘅工程團隊將佢描述為一個「meta-harness」——一項圍繞接口構建嘅託管服務，呢啲接口嘅設計壽命要超過任何具體嘅實現。Harness 編碼咗關於 Claude 邊啲嘢做唔到嘅假設，而呢啲假設會隨住模型進步而變得過時。
呢種設計哲學令我覺得幾有意思。佢哋唔只係喺度解決今日嘅基礎設施問題。佢哋嘗試構建一個夠穩定嘅抽象層，令你嘅 agent 代碼唔會喺 Anthropic 每次發佈新模型時崩咗。好似 session log 就充當咗一個喺 Claude 嘅 context window（上下文窗口）之外嘅持久上下文對象——令長時間運行嘅任務擁有恢復點，而唔係脆弱嘅記憶體狀態。
Managed Agents 解決咗啲咩
沙箱隔離同安全嘅工具執行
呢一點係實實在在嘅，而且非常重要。每個 session 都運行喺隔離嘅 Linux 容器入面。Agent 可以讀取檔案、執行 bash 命令、運行代碼——配置可控嘅網絡訪問規則，而且冇逃出沙箱嘅風險。自己試過搭呢套嘢嘅團隊都知道，呢個需要幾大嘅工程量。喺生產環境入面做錯咗，後果係真的嚴重。
Agent 運行喺安全嘅沙箱環境入面。認證、工具執行同密鑰管理由 Anthropic 嘅基礎設施處理。你唔需要自行配置伺服器或者編寫執行隔離代碼。
帶檢查點嘅長時間運行 Session
Session 能夠喺網絡斷開之後繼續存活。一個多步驟嘅研究任務唔會因為連接喺第 34 步中斷或者觸發速率限制而從頭嚟過。進度同中間輸出保存喺 session 事件日誌入面。對於嗰啲運行幾分鐘或者幾個鐘嘅任務——嗰啲冇專用基礎設施幾乎冇可能可靠構建嘅工作——Managed Agents 直接解決嘅就係呢類問題。
作用域權限同執行追蹤
每一次工具呼叫、每一個決策、每一個輸出都可以喺 Claude Console 入面追蹤。 作用域權限令你精確定義 agent 可以觸達邊啲工具同數據源。對於喺受監管行業構建 agent、或者處理涉及敏感系統嘅企業工作流嘅人嚟講，呢個係承重級功能——唔係錦上添花。
Multi-Agent 協調（Research Preview——我要特別標明呢一點）
呢一點需要謹慎措辭。Multi-agent 協調——即一個 agent 啟動並指揮其他 agent 嚟並行處理複雜工作——作為功能被列出咗。但截至 2026 年 4 月 8 日公測發佈時，包括 outcomes、multiagent 同 memory 在內嘅某啲功能處於 research preview 階段，需要單獨申請訪問權限。
呢個唔係一個細嘅附加說明。我見到好幾篇文章將 multi-agent 協調描述為已上線功能。佢唔係。如果你嘅架構依賴 agent 自主生成其他 agent，今日唔好喺呢個假設上面構建生產系統。 申請 research preview 訪問權限，喺功能成熟之前將佢視為唔穩定嘅能力。
Managed Agents 冇解決啲咩
呢一節係我諗得最耐先諗清楚嘅。因為呢個產品喺佢所做嘅嘢上面確實好好——而恰恰因為咁，人哋好容易期望佢去做嗰啲佢從未被設計嚟做嘅嘢。
跨 Session 嘅能力持久化——運行結束，學習都結束
當一個 Managed Agents session 完成嗰陣，環境係臨時嘅（ephemeral）。容器關閉。Agent 喺嗰次運行中學到嘅、改進嘅或者諗出嚟嘅嘢，唔會延續到下一次。 下一個 session 仍然從相同嘅初始 agent 定義開始。
冇機制令 agent 喺 session A 中成功嘅策略自動喺 session B 中可用。如果 Claude 用一種特別優雅嘅方式解決咗一個棘手嘅多步調試問題，嗰個解法存在於 session log 入面——可以查閱，但唔會作為可複用嘅能力向前傳播。你可以重新閱讀佢。你可以手動提取佢。但冇原生嘅繼承路徑。
呢個就係基礎設施做緊基礎設施該做嘅嘢：可靠噉運行 session，然後關閉佢。 佢冇聲稱自己係進化層。呢個唔係批評——係一個值得清楚理解嘅設計邊界。
跨 Agent 繼承——冇共享可複用資產嘅機制
同 session 持久化分開嚟睇：Managed Agents 冇機制令一個 agent 經過驗證嘅能力可以畀系統入面嘅其他 agent 使用。Agent 之間默認唔共享任何嘢。每個 agent 定義都係隔離嘅。如果你嘅團隊有三個 agent 都能從某個通用調試策略中受益，嗰個策略就存在三份——定義三次、維護三次、改進三次。
我仲喺度試緊搞清楚呢個對規模化團隊意味住咩。感覺唔似係隨機嘅。感覺好似係一個可以解決嘅問題。但 Managed Agents 冇處理佢，而我仲未完全諗清楚正確嘅邊界喺邊度。
進化生命週期——冇驗證、晉升或治理層
Managed Agents 有執行層面嘅治理：作用域權限、執行追蹤、沙箱隔離。佢冇嘅係能力進化層面嘅治理：冇「呢個策略成功咗 40 次應該被晉升」嘅驗證機制，冇從「喺 session 中測試過」到「成為 agent 定義嘅一部分」嘅晉升路徑，冇能力點樣隨時間發展嘅血統追蹤。
呢個係同一個大問題嘅兩個唔同層面。基礎設施治理嘅係 agent 喺一次運行中做咗咩。進化治理嘅係 agent 能力點樣隨時間變化同改進。Managed Agents 正在刻意噉將第一層做好。第二層仍然係開放嘅。
託管執行 vs 能力進化
同一個問題嘅兩個唔同層面
我試下精確噉表述呢一點，因為我覺得框架嘅定義比任何單一功能都重要。
Managed Agents 係執行基礎設施。佢嘅工作係確保 agent 運行安全、可觀測、可恢復、可擴展。佢喺呢方面做得好好。Anthropic 嘅工程文章將設計圍繞穩定嘅接口展開——呢啲接口被構建為能夠比特定實現存活更耐，以適應未來嘅 harness 同模型改進。
能力進化係另一個層面：agent 點樣喺跨運行、跨團隊、跨部署嘅過程中積累、驗證、共享同繼承成功嘅行為。呢個層面唔喺託管運行時入面。佢亦都唔可能喺——佢哋喺唔同嘅時間尺度上解決唔同嘅問題。
點解解決咗基礎設施唔等於解決咗進化差距
我反覆留意到嘅差距係：一旦 session 結束，某啲嘢運行得好好，佢去咗邊？佢喺 session log 入面。可以恢復。但佢唔會自動出現喺下一次運行中。唔會同其他 agent 共享。唔會根據某個適應度標準被驗證同晉升。
呢個唔係託管基礎設施嘅失敗。呢個係技術棧唔同層面嘅差距——一個 Managed Agents 從未被設計嚟填補嘅差距。呢個區分好重要，因為嗰啲使用 Managed Agents 並期望佢解決能力複用問題嘅團隊會撞到呢面牆，而且唔會即刻明白點解。運行時工作得好完美。問題在於佢上面缺少一個進化層。
邊個應該用 Managed Agents
最佳匹配：需要生產級 Agent 運行時但唔想自己搭嘅團隊
如果你嘅瓶頸係基礎設施——如果你喺 agent 上線之前就要花幾個月搭沙箱、會話管理、重試邏輯同執行追蹤——咁 Managed Agents 就係喺度解決正確嘅問題。Claude Managed Agents 按兩個維度計費：token 同 session 運行時長，每 session 小時 $0.08，精確到毫秒。空閒時間唔計入運行時長。對於長時間運行嘅工作負載，相比自己搭嘅替代方案，呢個成本結構係合理嘅。
包括 Notion、Rakuten、Asana 同 Sentry 在內嘅早期採用者已經上線咗生產用例。據報道 Rakuten 喺一個星期之內就部署咗每個專業 agent。呢個就係基礎設施運作良好嘅信號。
如果能力複用先係瓶頸，咁就唔太啱
如果你嘅問題係 agent 不斷重複發現同樣嘅解決方案，成功嘅策略冇辦法喺運行之間或者團隊成員之間傳遞，你冇方法驗證同晉升有效嘅嘢——Managed Agents 唔會解決呢啲。運行時會可靠噉運行，而進化差距仲係會喺度。
限制同取捨
Beta 狀態係真嘅。 所有請求都需要 managed-agents-2026-04-01 beta header，行為可能會喺版本之間調整以改進輸出。Anthropic 保留更改 harness 工作方式嘅權利。構建嗰陣請為應對變更做好計劃。
數據流經 Anthropic 嘅基礎設施。 對於敏感工作負載——法律文件、財務記錄、專有代碼——每一次工具呼叫同決策都運行喺 Anthropic 嘅雲入面。佢哋嘅企業版有數據隱私承諾。呢個係咪可以接受取決於你嘅具體合規要求。
Lock-in 值得正視。 Managed Agents 係 Claude 專屬嘅。如果你嘅架構需要供應商靈活性或者多模型路由，Claude Agent SDK 或者直接使用 Messages API 會畀你更多控制權。
常見問題
Claude Managed Agents 係咩？
一個於 2026 年 4 月 8 日公測發佈嘅託管基礎設施層。佢提供一個預構建、可配置嘅 agent harness，運行喺 Anthropic 嘅雲入面——處理沙箱執行、session 持久化、工具編排同執行追蹤。佢唔係新模型。
Claude Managed Agents 收費幾多？
模型推理適用標準嘅 Claude API token 費率，另外每 session 小時收取 10。做決策之前請去 Anthropic 嘅官方定價頁面確認最新價格——呢啲數字可能會變。
Claude Managed Agents 能唔能記住跨 session 學到嘅嘢？
唔能。Session 係隔離嘅。Agent 定義持久存在並通過 ID 引用，但運行時環境係臨時嘅。Session 中發展出嘅能力同策略唔會自動延續到下一個 session。跨 session 嘅 memory 作為 research preview 功能列出，需要單獨申請訪問——默認唔可用。
Claude Managed Agents 同 Claude Code 有咩分別？
唔同嘅產品解決唔同嘅問題。Claude Managed Agents 係用嚟大規模部署生產 agent 嘅託管 API 運行時。Claude Code 係本地編碼工作流工具。Anthropic 嘅文檔明確警告合作夥伴唔好將 Managed Agents 品牌標注為 Claude Code 或者任何其他第一方 Anthropic 產品。
Claude Managed Agents 支唔支持 multi-agent 工作流？
截至 2026 年 4 月發佈，Multi-agent 協調處於 research preview 階段，需要單獨申請訪問權限。佢唔喺通用公測入面。喺你確認獲得訪問權限且功能成熟之前，唔好圍繞呢個能力嘅穩定性或者可用性嚟設計生產系統。
我大概會繼續關注 research preview 功能嘅發展。「multi-agent 協調存在」同「multi-agent 協調已就緒」之間嘅差距係有意義嘅，而 memory 功能尤其值得密切關注——關注佢對跨 session 能力持久化意味住咩（或者唔意味住咩）。呢個部分仲未完全塵埃落定。
