跨雲 AI Agent 託管平台選型完整指南：Anthropic、Bedrock、Vertex、Foundry 四大平台五維度決策與六條合約紅線

先說結論：2026 年下半年，AI Agent 不再用「自己組框架 + 自己部署」的方式跑——四大雲廠商已經把整套 Agent 託管平台端上桌，你只要丟業務邏輯、不用煩惱 runtime、context、orchestration、tracing 這些事。問題只剩一個：四家平台選哪家、選錯會被綁多久。

Gartner 2026 年 Q1 的 Hype Cycle for Generative AI 把 Managed Agent Platform 從「Innovation Trigger」推到「Peak of Inflated Expectations」，企業採購預算搶得兇。但實際投產 6 個月以上的案例不到 10%，多數還卡在「PoC 燒到一半才發現平台選錯、整套重做」。

這篇給「準備發包做 AI Agent 系統」或「已經有 PoC 想 scale 到 production」的決策者看。我們把四大平台拆成「五維度決策框架」+「採購合約六條紅線」+「90 天 PoC 路線圖」，目標是讓你看完知道：我這個案子該選哪家、為什麼選、合約要釘哪些條款。框架邏輯延伸自 AI Agent 系統採購完整框架 跟 AI Agent 框架選型完整指南。

四大平台一張表看完：誰擅長什麼、誰怕什麼

先給全景視角。這四家在 2026 年第二季都已 GA（General Availability），但定位差異比表面看起來大。

一個常被忽略的點：這四家是「Agent runtime」而不是「framework」。框架（LangGraph、CrewAI）是你寫 code 用的，runtime 是 code 跑哪。一個 LangGraph 寫好的 Agent，理論上四家都可以跑——但實際上要不要重寫，看你 tool calling、context persistence、tracing 怎麼接。後面會逐一拆解。

Anthropic Managed Agents：Claude 原生派的精準打擊

Anthropic 2026 年 5 月把 Managed Agents 正式 GA，定位很清楚——「最會用 Claude 的地方就是 Anthropic 自己」。賣點是「原生 context engineering」：自動把對話歷史壓縮、長期記憶（dreaming）、tool calling 都整合好，開發者不用煩惱 prompt cache、context window 管理。

實際用起來最有感的差異是 Claude Dreaming（memory governance）。Agent 跑完一段時間會自動「做夢」整理記憶，把無關的對話 drop、把關鍵的事實 promote 成長期 memory——不需要你自己接 vector DB。對於需要長對話、多輪推理的場景（法律審查、財務分析、客服處理複雜申訴），這是其他三家做不到的。

適合場景

（1）對話品質敏感、需要 Opus 級推理（複雜法律、醫療、金融）；（2）需要長期記憶但又不想自己維運 vector DB；（3）強治理需求——Anthropic 在 Usage Policy 上比另外三家保守，金融、醫療客戶會偏好；（4）公司本來就在用 Claude API、做模型路由的，省事。

最大的坑

鎖定 Claude 一家。如果你想跑 GPT 或 Gemini 來省成本（Haiku 之外），Anthropic Managed Agents 不會給你選——這是平台定位。混搭模型的場景請看下面 Bedrock 或 Foundry。

AWS Bedrock AgentCore：多模型混搭的工程師最愛

如果你已經住在 AWS、用 IAM、用 CloudWatch、用 S3，Bedrock AgentCore 幾乎是預設選項。AWS 2026 年初 GA 之後把整套 Agent 編排、tool 註冊、guardrail、tracing 都做進來，最大優勢是「模型不綁」——同一個 Agent 流程可以混用 Claude（推理）、Llama（成本敏感）、Cohere（embedding），靠 routing 決定哪個 task 用哪個 model。

但便利的代價是 lock-in 更深。Bedrock 的 tool calling 用的是 AWS 自己的格式（不是 OpenAI function 標準），把 Agent 搬離 AWS 等於整套重寫。多數企業是「先 PoC 用 Bedrock 跑得很快，9 個月後想換省成本，發現走不掉」——這個情境跟 SaaS 退場成本完整解析 講的 vendor lock-in 一模一樣，只是換到 Agent 層。

適合場景

（1）已重度使用 AWS（80% 以上 infra 在 AWS）；（2）需要多模型混搭 + 動態 routing；（3）企業內 compliance 已綁 AWS Artifact / Config（HIPAA、SOC2）；（4）願意接受 vendor lock-in 換取整合便利。

最大的坑

Bedrock 跨區域 latency 偏高（美東 → 台灣 800ms+），台灣中小企業如果做面向終端用戶的 Agent，要做好 cache + edge 設計，或考慮 GCP / Azure 的台灣 region。

Google Vertex AI Agent Builder：搜尋與多模態整合派

Vertex AI Agent Builder 的最大差異化是兩件事：Gemini 2M context（一次吞整本財報、整套合約沒問題）跟「原生 Google 工具整合」——Google Search、Maps、YouTube、Workspace 用 connector 接，幾乎無痛。如果你的 Agent 需要做即時資訊查詢、地理位置、企業內 Google Drive 文件，Vertex 是最順的選擇。

延伸閱讀：Gemini 3.1 Ultra 完整解析 講的就是 2M context 對企業採購的衝擊。Vertex Agent Builder 把 Gemini 的長 context 優勢進一步包成現成 Agent。

適合場景

（1）需要長 context（一次處理大量文件）；（2）需要原生整合 Google 服務；（3）做面向終端用戶的搜尋、推薦、地圖場景；（4）已用 Google Workspace + BigQuery 做數據分析的公司，整合最省事。

最大的坑

Vertex 的 governance UI 跟 Anthropic / Azure 比仍偏「工程師導向」，非技術人員上手難。第二個問題是：Gemini 在繁體中文的指令遵循（instruction following）2026 年 5 月還是稍弱於 Claude，台灣本土客戶做 Agent 要花更多時間調 prompt。

Azure AI Foundry Agents：M365 與 Entra ID 治理派

Foundry Agents 在 2026 年 4 月跟著 Microsoft Agent 365 完整解析 一起 GA。最大優勢是「跟微軟生態圈無痛整合」——Entra ID 做身份治理、Purview 做資料治理、Application Insights 做 tracing，跟 Teams / Outlook / SharePoint 的 connector 都現成。

如果你的公司已經是 M365 / Dynamics 365 的重度使用者（多數中型以上台灣企業），Foundry 是默認選擇。它的隱藏優勢是 Entra ID 的 fine-grained permission——你可以做到「這個 Agent 只能讀 A 部門的 SharePoint，不能讀 B 部門」這種公司治理需求，其他三家要自己接 RBAC 才能做到。

適合場景

（1）已重度用 M365 + Entra ID 的中型以上企業；（2）強合規治理需求（Purview 做資料分類 + DLP）；（3）需要做 Copilot Studio 跟自己 Agent 並存的環境；（4）想用 GPT-5.5 + Claude 並選的客戶（Foundry 兩家都有）。

最大的坑

Foundry 的學習曲線最陡。整套設定包含 Entra ID app registration、Purview label、Foundry workspace、AI Foundry hub、Foundry project，5 個概念混在一起。台灣中小企業沒有專任 Azure 工程師通常做不起來，導入 6 週起跳，建議搭配外包顧問。

五維度決策框架：替你算出該選哪家

把上面四家攤開放在一張決策圖上，五個維度逐一評分。每個維度 1-5 分，總分高的就是該選的那家。

維度 1：開發成本（你要寫多少 code、訓多久工程師）

Foundry 4 分、Bedrock 4 分（已在生態圈內最快）；Anthropic 3 分（API 設計簡潔但整合連接器少）；Vertex 2 分（治理 UI 弱、需要工程師多）。

維度 2：營運成本（同樣流量誰最便宜）

看你的場景。需要 Opus 級推理 → Anthropic 跟 Bedrock 一樣（都跑 Claude）；想用 Haiku / Mistral 7B 跑高量任務 → Bedrock 5 分（routing 最靈活）；單純用 Gemini Flash → Vertex 4 分。Foundry 因 Azure overhead 通常貴 10-15%。

維度 3：治理與合規（你的客戶或內部審計會問的）

Foundry 5 分（Purview + Entra 最強）；Anthropic 4 分（Usage Policy 保守）；Bedrock 3 分；Vertex 3 分。金融、醫療客戶務必選 Foundry 或 Anthropic。

維度 4：鎖定深度（5 年後想換廠商有多難）

Anthropic 3 分（雖綁 Claude 但 API 簡潔）；Vertex 1 分、Bedrock 1 分、Foundry 1 分（全綁雲基礎設施）。風險意識高的客戶建議走 Anthropic + 自建 orchestration 的混合架構。

維度 5：未來性（這家平台 18 個月後還會領先嗎）

四家都是雲端巨頭的核心戰略，短期內都不會消失。但「投資強度」上：Anthropic 跟 OpenAI 的差距最關鍵，Bedrock 的多模型策略最 hedge，Vertex 的 Gemini 進展速度，Foundry 跟 OpenAI 深綁是最大變數。

採購合約六條紅線：簽之前釘死

Managed Agent Platform 屬於「持續燒錢」型 SaaS，不像買套軟體一次性。合約沒釘好 18 個月後一定會痛。這六條是必加：

紅線 1：context / memory 資料的所有權

Agent 跑的對話記錄、長期記憶、向量化的 embeddings——所有權歸客戶。合約寫明：終止合約 30 天內，廠商必須提供完整匯出（原始對話 + embedding + metadata），不收費。多數平台預設只給你「最近 90 天」，要爭取「全量」。

紅線 2：模型輸出不得用於 train 廠商或其他客戶 model

這是 Samsung ChatGPT 洩密復盤 之後所有企業都該抓的紅線。四家平台預設都不會拿你的資料 train，但「不得用於 train」要寫進合約附件，未來廠商改 policy 才有依據。

紅線 3：費用結構透明 + 預警機制

Managed Agent 的單價是「per request × tokens × model」三層計費，月帳單暴漲很常見。合約要求廠商提供：（1）每日 / 每週 budget alert（超過 80% 自動寄信）；（2）每月 anomaly report；（3）模型升級不可自動漲價（必須 30 天前書面通知）。

紅線 4：Tracing 資料保存 ≥ 12 個月

Agent 出 bug 時 tracing 是唯一證據。預設保存期通常 90 天，這對台灣金管會、衛福部要求的 1 年以上稽核保留期不夠。合約寫明 trace log 保存 ≥ 12 個月，且可匯出。

紅線 5：SLA 與責任歸屬

Agent 講錯話、傳錯文件、做錯決策——廠商賠不賠？多數標準 SLA 只賠 service credit（停機補償），不賠「AI 錯誤造成的業務損失」。合約要爭取：因 model bug 造成的可量化損失，廠商賠償至少 3 個月服務費。

紅線 6：模型版本鎖定權

Anthropic 可能 9 個月就把 Sonnet 4.6 deprecate 換 Sonnet 5.0，行為可能變化。合約要寫：客戶可請求「鎖定特定 model snapshot」至少 12 個月，廠商不得單方面切換。Bedrock 在這方面相對好（model 版本顯式選擇）。

90 天 PoC 路線圖：從評估到驗收

即使你已經很確定要哪家，正式採購前先跑 90 天 PoC——這是 找外包做 AI 系統的 7 個坑 提到的鐵律。Managed Agent 平台特別重要，因為「設想中的整合便利」跟「實際接你既有系統」往往落差大。

真實踩雷案例：三個 6 個月後才浮現的痛

案例 1：選錯平台，第二年想換要花 800 萬

一家 B2B SaaS 2025 年用 Bedrock 跑通客服 Agent，第二年發現整套 routing 邏輯只能跑在 Bedrock，想搬到 Vertex 省 30% token 費，估算 migration 800 萬（重寫 Agent flow + 重訓員工 + 三個月並行成本）。最後沒搬，繼續 Bedrock。教訓：PoC 階段就要做 vendor migration 思想實驗。

案例 2：context 記憶資料拿不回來

一家金融客戶用 Anthropic Managed Agents 跑 6 個月，想匯出「Claude 學到的長期記憶」做內部分析，發現 Anthropic 只提供對話 raw log，dreaming 階段整理出的記憶是 black box。教訓：簽約時把「memory artifact 可匯出」寫進合約。

案例 3：模型升級導致 prompt 失效

某電商用 Vertex 跑商品分類 Agent，Gemini 2.5 升 3.0 後分類結果跟過去 3 個月歷史不一致，導致 dashboard 數據斷層。教訓：合約鎖定 model version、做 A/B 驗證再升級。

常見問題（FAQ）

結語：Managed Agent 是工程便利，不是策略放棄

選 Managed Platform 不代表「我不需要懂 Agent 是什麼」。相反，平台越成熟，業務邏輯、prompt 設計、context engineering 的差異越決定成敗——這些事情平台不會幫你做。

我們在 恆遠的 AI 系統開發服務 幫過幾家中型企業選平台 + PoC 並行 + 採購合約把關。如果你正在 90 天 PoC 階段，可以從這篇的「五維度決策框架 + 六條合約紅線」開始檢核自己的供應商提案——大部分 RFP 缺的不是技術 spec，是這 11 個檢核點。

延伸閱讀：

· AI Agent 系統採購完整框架

· Anthropic Claude Dreaming 完整解析

· Microsoft Agent 365 GA 完整解析