Claude Managed Agents 是什麼？代管代理怎麼計費、何時該用

Claude Managed Agents 是 Anthropic 於 2026 年 4 月 8 日展開公開測試的代管代理平台：代理迴圈與執行環境由官方一手包辦，你定義一份 Agent 設定檔，啟動 Session，Claude 就在 Anthropic 管理的沙盒容器裡跑指令、讀寫檔案、執行程式碼，過程以事件流回報，中途還能下指導棋。計費只有兩本帳：模型 token 依牌價計算，外加 session 運行時間每小時 0.08 美元，而且只有 session 實際處於 running 狀態時才跳表。產品目前仍是 beta（API 代號 managed-agents-2026-04-01），所有 Claude API 帳號預設可用，不必排隊申請。這些定位、狀態與計費口徑出自官方的 Managed Agents 總覽文件與官方定價頁，查證時間為 2026 年 10 月上旬；beta 產品改版快，動手前請以官方頁面當天內容為準。

它鎖定的是自建代理最磨人的那一層。用 Messages API 自己組代理迴圈的人都知道，模型呼叫本身不難，難的是迴圈要自己轉、上下文爆了要自己壓縮、沙盒要自己供、憑證要自己藏、斷線要自己恢復；這些工程跟代理要做什麼毫無關係，卻決定它能不能上生產環境。Managed Agents 把這一層整包收走：官方給它的定位是「跑在代管基礎設施上的預建代理 harness」，最適合長時間執行與非同步工作；需要自訂迴圈與精細控制的場景，官方仍然指向 Messages API。

閱讀路線可以按角色調整。技術主管與開發者重點看概念地圖、路線分工與導入判斷幾段，那是做架構決策需要的部位。在評估代理自動化的行銷與營運工作者，工具整合與計費拆解兩段會給你具體的數字感。還不確定 AI Agent 與一般聊天式 AI 差別的讀者，建議先讀代理式 AI 與生成式 AI 的差異解析再回來，後面的內容會順很多。

查證基礎先交代。文中的事實以官方文件、官方定價頁與 API 參考為本，查證時間為 2026 年 10 月上旬；行為描述出自官方文件的記載，不是本站的實機測試紀錄。Managed Agents 從 4 月上線至今已改版數輪，引用任何早期資料前，請先對照現行文件。

重點先看

• 定位：把代理迴圈與執行環境一起代管，Agent 定義一次、Session 反覆執行，適合長時間、非同步、多工具的任務。
• 時間軸：2026 年 4 月進入公開測試，API beta 代號 managed-agents-2026-04-01；10 月查證時仍為 beta，所有 API 帳號預設可用。
• 計費兩本帳：token 依模型牌價（快取乘數照用、批次折扣不適用），session 運行時間每小時 0.08 美元且只計 running 狀態；網頁搜尋每千次 10 美元。
• 環境二選一：Anthropic 代管的雲端沙盒，或把工具執行搬進自家基礎設施的自架沙盒，後者為資料落地與合規需求而設。
• 資料邊界：session 的對話歷史、沙盒狀態與產出存在 Anthropic 端，官方文件明載目前不適用零資料保留（ZDR）與 HIPAA 的 BAA。
• 現在就能做：一把 API 金鑰加 beta 表頭即可起手，Console 有圖形介面與快速上手範本。

Managed Agents 在解決什麼問題：把代理迴圈和執行環境一起收走

自建派最想問的問題是：代管到底代管了哪些事？把官方文件攤開，答案比多數人想像的多。代理迴圈本身（模型呼叫、工具調度、重試）由 Anthropic 的編排層執行；工具動作（bash 指令、檔案操作、程式碼執行）發生在每個 session 獨立的容器裡；沙盒供應、容器生命週期與工作排程由平台處理。上下文管理也在清單上：接近上限時自動壓縮 session 歷史，重複的歷史 token 走提示快取。這串清單就是自建時你要自己寫、自己測、自己顧的部分，現在變成服務的一部分。

官方給的產品對照只有兩欄，直接中文化如下。Messages API 是直接的模型存取，Managed Agents 是跑在代管基礎設施上的預建 harness，兩者鎖定的情境從一開始就分開了。

責任邊界的另一種講法是大腦與手的分工：推理在 Anthropic 的編排層，動作在 session 的容器裡。這個拆法對除錯很有用，輸出有問題先看事件流裡的模型決策，環境有問題先看容器與資源設定，兩者混在一起看只會更糊。模型升級時底層架構不用重建，因為你的程式從頭到尾只跟 Agent 設定與事件流打交道。

官方文件列了六個適用訊號，可以直接當需求檢核表用：長時間執行（跑幾分鐘到幾小時、多次工具呼叫）、雲端基礎設施（要預裝套件與網路存取的安全沙盒）、自架執行（為合規或資料落地把沙盒放自家）、最少基礎建設（不想自建迴圈、沙盒與工具執行層）、有狀態 session（跨多次互動保存檔案系統與對話歷史）、排程執行（用 cron 定時跑）。拿自己的需求對這六列打勾，命中越多，代管的投報越清楚；一列都不沾的任務，走 Messages API 通常更划算。

還有一個常被低估的部分：有狀態本身。session 中斷後可回復、事件歷史可回放、輸出存在服務端可事後取回，這些對長任務是剛需，自建時等於要自己設計一套檢查點系統。Managed Agents 把它變成預設行為，這也是它敢收 session 運行費的底氣：你付的是整套執行層的錢，模型費只是其中一本帳。保存期限要看清楚：官方文件載明沙盒狀態自沙盒建立起保留 30 天為上限，後續活動不會延長它，期滿後續跑的 session 會拿到全新的沙盒，該帶走的檔案要及時經輸出目錄取回。

四個核心概念，與一個 session 的生命週期

官方文件把產品收斂成四個概念。Agent 是保存下來的設定物件，模型、系統提示、工具、MCP 伺服器與 Skills 都定義在這裡。Environment 是容器供應的設定模板，決定 session 跑在哪種環境。Session 是引用某個 Agent 的執行實例，承接任務並產出事件。Events 是你的程式與代理之間的往來訊息，包含使用者訊息、工具結果與狀態更新。

流程是固定的：Agent 建一次，Session 每次跑，session 帶的是指向 Agent（或它的某個版本）的引用。常規做法是把 model、system、tools 都定義在 Agent 上做版本化管理；要在單一 session 換模型、清掉系統提示或調整工具，API 也提供 session 層的覆寫形式，覆寫只影響該次 session、不回寫 Agent，工具與 MCP 設定甚至能在 session 閒置時更新。版本化仍然是核心設計：每次更新 Agent 都產生新的不可變版本，session 建立時可以把版本釘在某個指定號碼上，改提示詞不會炸掉進行中的工作，出事時把新 session 釘回舊版本，也能讓兩個版本各跑一輪對照。實務上這等於把代理設定當程式碼管理，差別在版本號由平台保管。

session 的生命週期有四個狀態：idle、running、rescheduling、terminated。收到新事件從 idle 轉 running，工作做完回到 idle 等下一個輸入；rescheduling 是暫時性錯誤後的自動重試；terminated 代表 session 已終結，原因是不可恢復的錯誤或已被封存，官方文件特別澄清正常完成不會走到 terminated。建立 session 時若帶了 initial_events，會直接以 running 開始；不帶就以 idle 開始，沙盒在建立當下就開始供應，第一個工具呼叫不必等它。文件也提醒 idle 不等於成功：stop_reason 會告訴你它在等輸入、等工具確認，還是撞上了預算上限，回合完成也不保證每個工具都成功，輸出仍要檢查。

訊息的送進時機比想像中寬鬆：session 在 running 或 idle 都能收事件，訊息會排隊並照順序處理，不必等上一則回完再送下一則。跑到一半要改方向也有專用手段，送使用者訊息可以在它工作中導正，中斷事件可以把進行中的回合停下來，這兩個動作構成「交辦之後仍保有操控權」的體驗基礎。少數狀態例外：卡在等人回覆或撞預算上限時，只收得下結算類事件，新任務會被拒收。

開發期的觀察工具是現成的：每個 session 在 Console 有即時檢視頁，工具呼叫與訊息逐條流出來；事件流斷線時，用事件列表去重補播就行，不必重跑任務。代理跑長任務時，這個頁面比任何 log 檔都好讀。

和自己架代理差在哪：harness 誰管、機器誰管

「代管還是自建」其實是兩個獨立的問題：代理迴圈（harness）誰供應，部署（機器與執行環境）誰供應。把選項攤開，Claude 生態有四條路，各自把不同程度的責任交給你。

前兩條把機器留給你，第三條是唯一迴圈與部署都交給官方的路線，第四條把驅動 Claude Code 的同一套代理迴圈、工具與上下文管理裝進你的程式，但主機仍是你的。想深入這種工程視角的讀者，可以讀harness engineering 這個代理工程新領域的解析；Claude Code 本身的安裝、操作與交辦實務，站內也有從問答案到敢交辦的完整教學。

Claude Code 與 Managed Agents 的關係值得單獨講清楚，兩者名字裡都有 Claude，定位卻不同：前者是開發者手中的互動工具，跑在你自己的終端機與檔案系統上；後者是把代理放上生產環境的部署平台，跑在雲端容器裡。兩者可以搭配使用，在 Claude Code 裡把工作流打磨成形，再把穩定的任務交給 Managed Agents 排程執行，是合理的演進路線。

四條路線之間也不是單行道。自建迴圈起家的團隊，把成熟穩定的任務搬上代管平台換取運維減量，是常見的方向；反方向也成立，代管上線後發現需要更細的核准流程或特殊執行環境，把該任務收回 Agent SDK 自建，兩邊共用同一套模型與工具設計。因為 Agent 設定本質上是一份宣告式文件（模型、提示、工具、MCP），搬移的成本主要在整合層，業務邏輯可以原樣帶走。選路線時與其糾結一次到位，不如把「將來會換路線」當成設計輸入，整合層保持薄，依賴收斂在 Agent 設定與事件流兩個介面上。

beta 滿半年，功能地圖已經和四月不同

Managed Agents 在 2026 年 4 月 8 日以公開測試之姿上線，日期與各功能的轉正時間在官方 release notes 都查得到，這條時間線值得攤開：記憶庫在 4 月 23 日轉入公開測試，多代理協調與成果評估迴圈在 5 月 6 日跟上，自架沙盒 5 月 19 日開放，排程部署 6 月 9 日上線，session 預算與推論地區釘選 8 月 7 日加入。換句話說，上線當時還拿不到的能力，現在都已收進 beta 主體：多代理 session 讓一個協調者代理在同一個容器裡派工給多個代理執行緒，記憶庫以檔案系統的形式跨 session 保存所學，排程部署用 cron 讓代理在固定時間自己跑，成果評估迴圈讓代理對著評分標準反覆迭代直到過關。研究預覽的名單換成了 MCP tunnels（連進私有網路裡的 MCP 伺服器）與 dreaming（讀記憶庫與過往 session 逐字稿、重組出新的記憶庫）兩項，要透過官方申請表單另外爭取。

同一批變化裡還有兩件事值得記下。Managed Agents 可以在 Claude Platform on AWS 上使用，與第一方版本有些功能與行為差異，計費換算成 AWS 市集的 CCU 單位；自架沙盒也從早期藍圖變成現役功能，細節在後文安全段展開。這對讀者的實際影響是：任何寫於 4 月到 7 月之間的教學與比較文，功能邊界都可能與現況不同，引用前先對照現行文件；常見的團隊工具整合問題，答案也從「看公告」變成「MCP 伺服器加 vault 憑證」的標準做法，下一段展開。

工具與整合：八件內建工具、MCP 伺服器與自訂工具

內建工具一次給八件，以版本化的工具集 agent_toolset_20260401 打包：bash 在沙盒裡跑指令，read、write、edit、glob、grep 處理檔案，web_search 與 web_fetch 負責查網路。工具可以逐件開關，兩個網路工具支援網域白名單與黑名單（每份清單最多 64 個網域，兩者不能同時用）。這兩個工具跑在 Anthropic 的伺服器上，但環境網路設定的影響要看模式：limited 環境的 allowed_hosts 白名單同樣會約束它們，清單空白時等於全啞；unrestricted 環境與自架沙盒則不受環境網路限制，要收緊就靠工具自己的網域清單。web_fetch 另有一個 2026 年 10 月上旬加入的限制：它只抓已出現在 session 上下文裡的 URL，只出現在代理自己輸出、系統提示或附件裡的網址會回 url_not_in_prior_context 錯誤，把要抓的網址寫進使用者訊息就不會踩到。起手建議把兩個網路工具預設停用，任務真的需要時再開，並搭配白名單把可及範圍縮到已知站點。

MCP 伺服器是接外部能力的標準路徑，官方 MCP 連接文件以 GitHub 為例走過整條設定路徑，每個 Agent 最多宣告 20 台，全部以 URL 連線。宣告只寫類型、名稱與 URL，不帶任何認證；認證屬於 vault，在 session 建立時以 vault_ids 附上，平台依 URL 自動配對。Notion 這類團隊工具的接法是 MCP 端點加 vault 憑證；vault 的 MCP 憑證分 mcp_oauth 與 static_bearer 兩型、以伺服器 URL 對應，而 Notion 整合權杖那類 REST API 金鑰走的是 environment_variable 型憑證、由沙盒端程式直接呼叫 API 時使用，兩套認證系統不能互相頂替。MCP 工具集的權限預設 always_ask，每次呼叫都要你核准，要放寬得明確設定。超過十萬字元的工具輸出會自動落成沙盒裡的檔案，代理拿到截斷預覽與檔案路徑，必要時再讀全文，上下文不會被單次巨量輸出灌爆。對 MCP 協定本身不熟的讀者，可以先看MCP 讓 AI 串接外部工具與資料的機制解析。

自訂工具把剩下的路留給你：代理發出 agent.custom_tool_use 事件後 session 轉 idle（stop_reason 標為 requires_action），你的程式執行完把結果以 user.custom_tool_result 事件送回，session 恢復 running。這條路讓內部系統不必開放給沙盒就能進入代理的工作流，權限也完全在你手上，因為執行者就是你自己的程式。Skills 把領域知識與操作範本以漸進揭露的方式餵給代理，文件也支援直接從掛載程式庫的 .claude/skills 目錄載入，不必逐一上傳設定。

MCP 的失敗處理值得先知道：建立 session 時不會預先驗證連線與憑證，伺服器連不上或拒絕認證時，session 照樣建得起來、互動照樣可行，差別是事件流裡會出現帶伺服器名稱的 session.error 事件，連線會在下一次狀態轉換時重試。設計上你可以選擇擋住後續互動等修復、觸發憑證輪替，或讓代理在缺少那台伺服器工具的情況下繼續。知道這個行為，第一次在事件流裡看到連線錯誤時不會誤以為整個任務掛了。

資料進出有一條雙向橋：輸入檔案經 Files API 上傳後掛進 /mnt/session/uploads，GitHub 儲存庫可以整庫掛載（掛載資源是雲端沙盒的功能，自架沙盒的 session 資源目前僅支援記憶庫）；代理的產出寫到 /mnt/session/outputs，事後以 session 範圍的檔案列表下載回來。掛載的檔案是唯讀的，代理要改就寫出新檔，這個設計保證輸入素材不會被意外改寫。官方文件自己就拿 Notion 當 vault 憑證的設定範例，真實世界的整合需求也多半是同一個形狀：任務明確、工具邊界清楚，正是 MCP 加沙盒這個組合的甜蜜點。

進階功能：多代理、記憶庫、排程部署與成果迴圈

多代理 session 解決的是「一個迴圈讀到爆」的問題。當任務會拆出多個獨立子題，例如查十個來源或審幾十份文件，單一執行緒的上下文會被閱讀灌滿，協調者的記憶體浪費在資料搬運上。Managed Agents 的做法是在 Agent 設定裡掛一張派工名單（multiagent roster），協調者拿到派工工具後自己決定何時分派：名單最簡單的起手式只放 self，讓它能把自己的複製品叫出來各接一個子題；要壓成本，就把閱讀密集的工作交給名單上另一個用便宜模型的代理。所有代理共用同一個容器與檔案系統，但各自跑在獨立的執行緒裡，有自己的對話歷史、模型與工具；執行緒是持久的，協調者事後還能回頭追問先前派出去的代理。你要寫的編排程式碼是零，成本按各執行緒自己的模型費率計。2026 年 10 月加入的動態工作流再往前一步：協調者直接寫出一份多代理的工作流程式，交給平台在背景執行、收回合併後的結果，連派工時機都不必自己盯。

記憶庫（memory stores）補上跨 session 的延續性。session 預設用完即棄，代理學到的東西跟著消失；記憶庫是一個 workspace 層級的小文件集合，掛進 session 時以檔案系統目錄的形式出現在容器裡，代理用一般的檔案工具讀寫。每一次修改都產生不可變的版本快照，等於自帶稽核軌跡，可以回滾到任一時間點，也能對單一版本做刪改。憑證千萬別寫進記憶庫：任何掛載這個儲存庫的 session 都讀得到它的內容，把金鑰寫進去等於抄錄到所有未來的對話裡，認證該放的地方是 vault。

排程部署（scheduled deployments）把代理變成常駐的自動化工作者。一個部署物件綁好 Agent、Environment、資源與起始事件，加上 cron 表達式與時區（最細到分鐘），每次觸發就自主建一個 session 跑一輪，逐次留下執行紀錄，可以暫停與恢復。夜間巡檢、每週合規掃描、每小時的監看任務，都落在這個模式裡；部署也能掛預算，逐次複製到觸發的 session 上。這是交辦一次、定期回收成果的形態，和即時互動的 session 是兩種使用節奏。

成果迴圈（outcomes）處理的是另一個老問題：怎麼定義做完且做好。一般的代理任務以對話收尾，成品好壞要人看；成果迴圈讓你在開場就定義完成條件：描述預期產出，附上一份評分標準，設定迭代上限（預設 3 次、最多 20 次）。一個在獨立上下文裡跑的評分者逐項打分，把沒達標的條目回饋給代理修改，直到過關或用完迭代。把「做到好為止」從一句口號變成可檢查的規格，對報告產生、資料清理這類有明確驗收條件的任務特別有用。

計費拆解：token 照牌價，加上每小時 0.08 美元的運行費

計費的數字最容易過期，先把結構定住再看費率。官方定價頁給 Managed Agents 的專節寫得明白：帳單由兩個維度組成，token 與 session 運行時間。token 帳完全照模型牌價，提示快取的乘數照用；運行帳以 session 處於 running 狀態的時間計費，每小時 0.08 美元，量測精細到毫秒，idle、rescheduling 與 terminated 都不計。容器不另外收錢：session 運行費取代了舊的容器計時模式，不會再疊一層容器帳。

模型價差就是第一個成本槓桿：同樣的 token 量，Fable 5.1 的輸入單價是 Haiku 4.5 的十倍，Opus 5.5 與 Sonnet 5.5 差一倍。表列是本文試算與選型常用的四個型號，官方定價頁另有更便宜的 Haiku 5.5，提示在 10 萬 token 內每百萬輸入 0.10 美元、輸出 0.50 美元（超過門檻的長提示另計），閱讀型子代理可以再往下一階。各模型的規格與切換時機，站內有Claude Opus 5.5 的價格與切換時機解析可以對照。

工具費只有一條：session 裡觸發的網頁搜尋每千次 10 美元，web_fetch 不收工具費，抓回的內容照 token 計。兩項 Messages API 的折扣在這裡不適用：批次折價被明確排除，因為 session 有狀態且互動，沒有批次模式；Bedrock 與 Vertex 這類合作雲也不提供這項服務。要走 AWS 採購的團隊，Claude Platform on AWS 可以用，帳單換算成 CCU 單位進 AWS 帳單。把推論釘在美國（inference_geo 設 us）時 token 帳乘以 1.1，代理模型設成 fast 時照 fast mode 的加價費率。

官方給了一個試算例，直接引用：一小時的編碼 session 用 Opus 5，消耗 5 萬輸入與 1.5 萬輸出 token，輸入 0.25 美元、輸出 0.375 美元、運行 0.08 美元，合計 0.705 美元；若其中 4 萬輸入是快取讀取，總數降到 0.525 美元。這個例子的重點在結構：模型費是主帳，運行費只有在代理真的在跑時才累積。反過來換算，就算一個 session 全月無休都在 running，運行費上限約 57.6 美元（0.08 乘 24 乘 30），閒置不計費的設計讓常駐代理的底薪相當低，真正的變數永遠是模型費。

成本治理的平台工具是 session 預算：建立 session 時可設一個以美元計的硬上限，平台持續以牌價計算這個 session 的消耗（模型 token、每千次 10 美元的搜尋、每小時 0.08 美元的運行都算在內），到頂就暫停為 idle，stop_reason 標為 budget_reached，歷史與沙盒都保留，改上限或移除後工作自動續跑。預算只能在建立時給，之後改或移除，不能事後補加；卡在上限時只收結算類事件（核准、工具結果、中斷），新任務一律拒收。注意預算以牌價計算，有合約折扣的團隊實付通常低於這個數字，把預算當新工作的煞車用，別當對帳單看。

估算的單位也要選對：算任務的總帳，別只看單次請求。完成一個任務可能包含多次模型呼叫，每一次的輸入還會隨對話歷史與工具結果累積，重試與多代理派工都要算進去。開一字排開的估價表之前，先量四個變數：單一任務平均幾次呼叫、每次的輸入輸出規模、有沒有開網路工具、session 實際跑多久。這四個數字用試點任務實測一次，乘上費率表就是可信的單位成本，比憑感覺抓預算穩得多。

壓成本的三個槓桿：模型分層、快取與預算

實際壓成本有三個槓桿。模型分層：多代理架構讓貴模型做規劃與驗收，讀料與抽取交給便宜模型，各執行緒照各自模型的費率計費，成本結構立刻不同；閱讀型子代理用 Haiku 級模型就夠，Haiku 5.5 在短提示下每百萬輸入 0.10 美元、Haiku 4.5 每百萬 1 美元，跟旗艦模型的差距是一到兩個數量級。快取：session 內重複的歷史與設定自動走提示快取，Opus 5.5 的快取讀取是原價的百分之五，長任務多輪往來時這是最大的一筆節省。預算：對探索型任務與初次上線的自動化，先設小額上限跑一輪，把單位成本量出來再放量，比任何估算都可靠。

安全與治理：權限政策、憑證保險庫與資料邊界

治理有三層可以調：工具權限、憑證與網路、資料邊界。更深層的代理治理框架（提示注入防護、人類核可設計、失敗隔離）站內AI Agent 穩定落地的實戰指南有完整討論，這裡聚焦 Managed Agents 平台自身提供的控制點。

工具權限有三種政策。always_allow 直接執行，是內建工具集的預設；always_ask 每次暫停等人核准，是 MCP 工具集的預設；auto 交給伺服器逐一評估每次呼叫，結果有三種：判定安全就放行、判定高風險就拒絕（代理收到錯誤結果繼續跑，你的程式無法推翻）、拿不準就暫停問人。每次工具呼叫事件都帶 evaluated_permission 欄位與評估詳情，等於自帶稽核軌跡。文件對 auto 有一句重要警告：它不是人工檢查點，被判安全的呼叫在任何人事前都看不到的情況下就執行了，後果可能不可逆；真的需要人看的眼光，就退回 always_ask。

資源生命週期有一個容易踩的坑：封存是不可逆的。Agent 沒有刪除操作，終局手段只有封存，封存後變成唯讀，進行中的 session 可以跑完，但新的 session 不能再引用它，而且沒有解除封存的選項；Environment 與記憶庫則有真正的刪除（Environment 要在沒有 session 引用時才刪得掉），也提供封存這條路。把封存當日常清理用途，等於把生產線上的代理設定永久下架，穩妥的做法是任何封存動作前先跟負責人確認。session 本身也有真正的刪除，會連事件歷史與沙盒一起清掉（跑著的 session 要先中斷、等到 idle 才能刪），任務結束就刪是成本與清理的正確姿勢。

憑證走 vault，設計原則是密鑰不進沙盒。MCP 的 OAuth 憑證存在 vault 裡由平台代管刷新，代理連上 MCP 伺服器時才自動注入；environment_variable 型的憑證在流量離開沙盒的當下替換，沙盒裡的程式碼（包括代理自己寫的）只看得到佔位符。掛載的 GitHub 儲存庫是另一組搭配：agent 宣告的 GitHub MCP 伺服器同樣只帶 URL、認證放 vault，儲存庫掛載資源則自帶 authorization_token 欄位，API 回應裡不會回顯它。這條邊界擋的是提示注入場景：就算代理被文件內容誘導想讀密鑰，也讀不到。網路層的 limited 模式預設全擋，以 allowed_hosts 白名單放行特定主機，套件管理器與 MCP 端點要各自開啟，對外連線管得比多數自建環境都緊。

資料邊界是最需要法務過的一關。session 有狀態是產品設計：對話歷史、沙盒狀態與產出存在 Anthropic 端，官方文件明載 Managed Agents 目前不適用零資料保留（ZDR）與 HIPAA 的 BAA；你保有刪除權，session 與上傳的檔案都能隨時透過 API 刪掉。兩個折衷存在：inference_geo 可以把推論釘在美國，token 加價一成，多代理全體要一致；自架沙盒把工具執行搬進你的基礎設施，檔案內容與對外連線留在你家，連線方向只有你家往外的單向長輪詢。但要理解工具的輸入輸出仍會流經 Anthropic 控制面，兩個網路工具也照舊跑在 Anthropic 伺服器上，自架並沒有把所有路徑都收回自家。真正零資料保留的剛需，現階段的誠實答案是走 Messages API 自建。

導入判斷：五個問題決定代管還是自建

功能、計費與治理都清楚了，決策收斂成五個問題。

第一問，任務形態對不對。官方定位給的訊號是長時間執行、非同步、多工具、要保留進度。一問一答、單次摘要、固定流水線，用 Messages API 加個迴圈多半夠了，掛上代管平台只是平白多付運行費。判斷的試金石：這個任務會跑幾十分鐘嗎？中斷後要續跑嗎？要碰檔案系統或跑程式嗎？三個都是否，先別上。

第二問，資料邊界能不能過。ZDR 與 BAA 的排除是硬限制，個資法、產業法規與合約面的零保留條款都要逐條對照。實務上比較好走的流程是先做資料分級：可以公開的資料（公開報價、公開文件、網路內容）直接上雲端沙盒；內部等級的資料走自訂工具，處理留在自家，只把結論回傳給代理；敏感等級的資料連結論都不該出國，這類任務留在自建路線。分級做完，哪部分能代管、哪部分要自建自然浮現，比一開始就全有全無的爭論有效率得多。這一問沒有模糊空間，過不了就停，後面的成本比較都不用做了。

第三問，控制權要不要留。把迴圈交給平台，換到的是不用養基礎設施，付出的是對執行細節的直接控制。需要自訂核准流程、把狀態寫進自家資料庫、對執行環境有特殊合規要求的團隊，Agent SDK 或手動迴圈仍是正解。折衷也存在：外部任務與公開資料交給 Managed Agents，敏感邏輯留在自家服務，以自訂工具當橋，兩邊各取所需。

第四問，成本治理怎麼做。代理成本的特性是變異大：同一個任務，模型選擇、思考深度、重試次數都會讓帳單浮動。務實路徑是三步：設小額預算跑試點，從 usage 欄位（token 計數、搜尋次數、list_cost、active_seconds）量出單位成本，再按任務定型放量。牌價與合約價的差異也要記在試算表裡，預算上限是以牌價計的。

第五問，beta 風險能不能吞。介面會動是 beta 的本質：官方明講行為會在版本間調整，研究預覽功能隨時變動，把關鍵路徑押上去等於把穩定性外包給別人的實驗。穩健的做法是把對平台的依賴收斂在薄薄的整合層，業務邏輯與資料留在自己手裡，關鍵流程等穩定版再上。

導入代理平台從來就不是純 API 工程，工具設計、資料準備與流程重塑都要人承接，相關職務的工作樣貌可以參考FDE 前線部署工程師的職責解析。OpenAI 陣營也有同型選擇，OpenAI Agents API 的計費與導入評估用了同樣結構的五問與帳務拆解，兩篇對照著讀，跨陣營的決策會更具體。

上手路徑：從 API 金鑰到第一個 session

起手的三件事：一把 Claude API 金鑰、在請求帶 managed-agents-2026-04-01 beta 表頭（官方 SDK 自動處理）、確認帳號已啟用（所有 API 帳號預設開啟）。偏好圖形介面的人從 Console 的快速上手範本起步；同樣的流程也有命令列路線，把 Agent 與 Environment 寫成版控檔案，以 ant apply 指令同步，控制面交給檔案，資料面（建 session、收事件）交給你的程式。

第一個 session 的標準流程：建 Environment（雲端或自架）、建 Agent（模型、提示、工具）、建 Session 引用兩者、送出第一個 user.message、開事件流看它跑。判定跑通的訊號是事件流裡出現工具呼叫與狀態轉換，Console 的 session 頁能逐條回放整個過程。

帳務與用量的觀測不需要自建儀表板。session 物件上的 usage 欄位累計了 token 計數、伺服器工具用量（例如網頁搜尋次數）、以牌價計算的 list_cost，以及 active_seconds（有執行緒在跑的時間，多執行緒重疊只算一次，正好對應運行費的計費口徑）。把這幾個數字按任務歸檔，單位成本曲線幾輪就會浮出來，異常的任務一眼就能挑出來；需要事件級通知而非輪詢的場景，webhook 可以在 session 狀態變化時收到簽章過的 HTTP 通知。

收尾養成兩個習慣：把 session ID 存進自己的對話狀態，追問與稽核都靠它；任務結束就刪 session，要留的產出先從輸出目錄取回，刪除會連事件歷史、容器與檢查點一起清掉。之後的擴充順序建議：先停用兩個網路工具觀察成本，再掛一台 MCP 伺服器接內部資料，然後試 session 預算與多代理名單，每一輪都對照 usage 欄位把單位成本記下來。這樣走完一圈，回頭看導入判斷那五個問題，答案會具體得多。

常見問題