引言
隨着人工智能技術的快速發展，特別是大語言模型（LLM）的廣泛應用，Agentic AI（智能體AI）正在成為下一個技術熱點。在 Agentic AI 的工作流程中，AI 智能體需要調用各種外部工具來擴展其能力邊界——從數據庫查詢到 API 調用，從文件操作到複雜的業務邏輯處理。
許多推理框架和Agentic AI框架提供了內置工具以供大語言模型使用，而為了標準化 AI 模型與外部工具之間的交互，Anthropic 在 2024 年 11 月推出了模型上下文協議（Model Context Protocol，簡稱 MCP）。MCP 就像是 AI 應用的”USB-C 接口”，提供了一種標準化的方式來連接 AI 模型與不同的數據源和工具。
然而，隨着 MCP 在實際應用中的推廣，一個重要的架構問題浮現出來：MCP 服務器應該部署在哪裏？本文將深入探討 MCP 協議，MCP 服務器本地部署和雲端部署的適用場景和參考架構，以及如何在亞馬遜雲科技雲平台上實現這一目標。
📢限時插播：無需管理基礎設施，利用亞馬遜技術與生態，快速集成與部署生成式AI模型能力。
✨ 精心設計，旨在引導您深入探索Amazon Bedrock的模型選擇與調用、模型自動化評估以及安全圍欄(Guardrail)等重要功能。
⏩快快點擊進入《多模一站通 —— Amazon Bedrock 上的基礎模型初體驗》實驗構建無限, 探索啓程！
第一部分：理解工具調用和 MCP 協議
從工具調用説起
工具調用（Tool use）指模型瞭解，選擇並調用外部工具的能力。例如用户希望檢索 Amazon EC2 的最新一代實例價格，而具體價格並沒有內置在大模型本身的知識中，僅靠大模型無法回答，或價目表已經陳舊不具備回答價值。但大模型擁有工具調用能力時，大語言模型會根據事先傳入的已安裝工具列表，選擇合適的工具，並生成對應工具的調用參數。但大語言模型自身無法直接運行工具，該執行過程是由推理框架或AI 智能體框架負責執行，再將執行結果返回給大語言模型。大語言模型根據執行結果進一步生成回覆。
許多 Agentic AI 框架內置了一些基礎工具供大模型調用。例如 Strands Agents SDK 提供了 30 種內置工具，包含計算器，HTTP 請求，文件系統操作等工具。在上述的實例價格查詢場景中，大模型根據自身知識，瞭解到可以使用 Strands Agents SDK 內置的HTTP 請求工具，調用 Amazon Pricing API 獲取價格。此時大模型就會生成工具調用請求， Strands Agent SDK 會根據請求中的 URL 和請求參數，調用 Amazon Pricing API，並將結果返回給大模型。
但 Agentic AI 框架內置的工具也有其侷限性。內置的工具主要為基礎工具，無法應對複雜的業務需求。有些業務甚至需要定製化的工具。且內置工具的版本更新和維護需要與框架的發佈週期同步，工具無法單獨頻繁迭代。應對這種場景，就需要外掛工具，將工具與Agentic AI框架解耦。而MCP協議就應運而生。
MCP 的架構設計
模型上下文協議（MCP）通過引入標準化的客户端-服務器架構和統一協議，試圖解決大模型的工具管理，集成和通訊的問題。MCP 客户端通常集成在 AI 應用中，如 Amazon Q Developer、Claude Desktop、Cursor 等工具。這些客户端負責與 MCP 服務器通信。而MCP 服務器則充當了 AI 應用和具體工具之間的轉換橋樑。MCP 服務器一般作為代理（Proxy）或邊車（Sidecar）服務存在，它將標準的 MCP 請求轉換為特定工具能理解的格式，執行相應操作後再將結果返回給客户端。
以 Claude 提供的示例 Git MCP Server 為例，客户端通過 MCP 協議向 MCP Server 發起操作 Git 存儲庫的請求，Git MCP Server 利用內置的 Git SDK 對存儲庫進行操作後，以 MCP 協議向客户端返回操作結果。這種設計實現了協議層面的解耦，使得工具的升級和變更不會直接影響到 AI 應用。
圖 1：MCP 客户端和服務器的關係
MCP 協議帶來的最大優勢是鬆耦合架構。AI 智能體只需要支持 MCP 協議，不需要關心工具的更新和變化，也不再需要學習和適配各種不同的 API 格式，所有的工具調用都通過統一的 MCP 協議進行，使用相同的數據格式和通信方式，這大大簡化了開發者使用多種工具的集成複雜度，讓大量工具的集成變得可行。而對工具提供方而言，每個工具的 MCP 服務器由相應的廠商或社區獨立開發和維護，而無需考慮與AI 智能體進行集成。這樣就實現了責任的清晰分工。
第二部分：部署方案的選擇
MCP 的部署模式
MCP 協議支持兩種主要的部署模式：本地部署和遠程部署。二者最明顯的區別是 MCP 服務器是否與客户端位於同一地。不同的部署模式適應不同場景，有各自的優缺點。下文中我們將會詳細比較這兩種部署模式。
本地部署
圖 2：本地環境運行Agent Tools
絕大多數 MCP 服務器默認提供本地部署方式。本地部署模式中，MCP 服務器作為本地進程或容器運行。用户需要配置啓動命令（如 npx ， uv 等包管理器，或 docker 等容器運行時）以及對應的啓動參數和環境變量。配置完成後，客户端通過系統調用創建子進程，啓動服務端程序，並建立與子進程的輸入輸出管道連接。客户端只要監測服務器進程，即可瞭解 MCP 服務器的運行狀況。這種基於進程生命週期的連接管理機制簡單有效，避免了複雜的網絡連接管理問題。
客户端與服務端通過標準輸入輸出流，採用 UTF-8 編碼的 JSON-RPC 2.0 規範進行通信。這種機制提供了原生的雙向通信。同時本地通信通過系統級別的管道傳輸，避免了網絡層的複雜性，保證了通信的可靠性和效率。
本地部署架構簡單，方便，適合在以下場景中使用：
- 在功能方面，一些需要本地數據訪問和工具集成的場景必須使用本地部署。例如在開發環境中，它可以讓AI助手直接訪問本地文件系統、執行構建腳本、運行測試用例，提供無縫的開發體驗。對於數據分析任務，本地部署的MCP服務可以直接訪問本地數據庫、處理本地文件，避免了數據傳輸的延遲和安全風險。
- 性能方面，本地部署避免了網絡開銷，具有更低的延遲和更高的吞吐量。對於需要頻繁交互的應用場景，如實時代碼分析、交互式數據探索等，這種性能優勢尤為明顯。
雖然本地部署在部署和操作層面比較方便，但在生產環境中面臨諸多挑戰：
- 版本管理困難：當後端工具升級時，其 API 可能發生變化，相應的 MCP 服務器就需要更新以適配新的 API。MCP 服務器 自身也在不斷迭代增加新功能和修補漏洞，這些因素導致 MCP 服務器更新非常頻繁。常用的 npm 和 uv 包管理器在緩存命中時，不會自動更新已安裝的包，用户必須主動檢查更新。本地部署模式下，這種更新完全依賴手動操作，在 MCP 服務器數量較多時，很難及時響應變化。
- 安全風險：雖然本地部署可以避免內容在網絡上傳輸導致的風險，但也帶來了更多權限泄露風險。本地 MCP 服務器默認情況下運行在與用户相同的命名空間下，權限與當前用户相同。理論上可以訪問當前用户能訪問的所有文件和資源。同時本地 MCP 服務器需要將所需的憑證（例如 API Key，用户名密碼等）存儲在本地，如配置不當，其他應用也可讀取並使用該憑證，造成橫向權限泄露。
- 資源和性能限制：每個 MCP 服務器都是獨立的進程，且都會隨着 MCP 客户端啓動。當需要啓動大量 MCP 服務器時，會顯著影響本地機器的性能。特別是在資源受限的開發環境中，這種影響會更加明顯。
遠程部署
遠程部署模式則將 MCP 服務器部署在其他的遠程服務器上，服務器暴露一個 HTTP 端點，客户端與服務器通過 Streamable HTTP 協議進行通信。Streamable HTTP 協議是 HTTP 協議的擴展，在標準 HTTP 1.1 的基礎上支持輕量級的 Server-sent Event（簡稱SSE，服務端發送消息）。MCP 客户端啓動時，會連接遠程 MCP 服務器的 HTTP 端點以初始化 Session。初始化完成後，客户端可通過 HTTP POST 方法發送請求，MCP 服務器在處理完成後，可以直接以 JSON 格式返回結果。如任務耗時較長，也可以將連接升級至 SSE，以流式形式逐步返回結果。
許多 MCP 服務器提供方已經開始支持遠程部署模式，例如 Remote GitHub MCP Server 和 Amazon Knowledge MCP Server 。這種模式雖然增加了網絡延遲，但在安全性、性能和可維護性方面具有顯著優勢。
圖 3：遠程環境運行Agent Tools
遠程部署在以下領域有獨到優勢：
- 版本更新更便捷：開發者可以通過持續集成部署（CI/CD）流水線，直接在單一可控的環境更新 MCP 服務器。用户無需進行操作，只需重新連接都能獲得最新版本的工具。這種自動化機制徹底解決了本地部署中手動維護和更新的痛點，大大降低了運維負擔，也減少了版本不一致所帶來的問題。
- 更加安全可靠：雲端部署在安全性方面提供了多層保護，而權限隔離是其中的核心優勢。MCP 服務器在受控的雲環境中運行，MCP 客户端在調用服務器時只發送具體的工具調用請求，不包含完整的對話上下文或敏感信息。這種設計大大降低了信息泄露的風險，即使 MCP 服務器被攻擊，攻擊者也無法獲取到完整的用户數據。同時，MCP 服務器可通過 OAuth 等標準協議進行身份認證鑑權。這使得無需將憑證分發至本地，也可以在通過身份認證後，利用遠程MCP 服務器的憑證進行一些需要高權限的操作，或訪問受訪問控制保護的知識庫。降低憑證泄露或被濫用的風險。
- 更優性能和性價比：資源優化是雲端部署的另一個顯著優勢。客户端只需要維護簡單的 HTTP 連接，而不用擔心本地資源消耗。對於一些有大量計算需求的場景，可以直接在雲端環境中滿足，無需在本地進行復雜的環境配置或消耗本地資源。按需計費的模式進一步降低了總體成本，特別是對於使用頻率不高的 MCP 服務器。
- 更好的可觀測和可維護性：現代 LLMOps 越來越重視可觀測性，雲端部署在這方面具有明顯優勢。統一監控系統可以提供請求量和響應時間的實時監控，詳細記錄資源使用情況，錯誤率等性能指標。而安全審計功能為企業級應用提供了必要的合規支持。系統可以記錄所有工具調用請求的完整日誌，實現可疑行為的自動檢測和告警，並生成詳細的合規性報告。這些功能在本地環境中很難實現，但在雲端環境中可以通過專業的監控和分析工具輕鬆提供。
考慮到這些優勢，遠程部署的 MCP 服務器特別適用於需要集中管理和共享資源的企業環境。在大型組織中，IT 團隊可以部署統一的 MCP 服務器集羣，為不同部門的 AI 應用提供標準化的工具和數據訪問接口。這種集中式架構不僅簡化了權限管理和審計追蹤，還能夠實現資源的統一監控和性能優化。
對於跨地域協作的團隊，遠程 MCP 服務器提供了理想的解決方案。團隊成員無論身處何地，都可以通過標準的 HTTP 協議訪問相同的服務器資源，確保了協作環境的一致性。這種部署方式還特別適用於需要高可用性的生產環境，管理員可以通過負載均衡、故障轉移等技術手段構建健壯的服務架構。
雲原生環境是遠程 MCP 服務器的另一個重要應用場景。在容器化和微服務架構中，MCP 服務器可以作為獨立的服務組件進行部署和擴展，與其他業務服務保持鬆耦合關係。這種架構模式支持按需擴容、滾動更新等現代運維實踐，為 AI 應用的規模化部署提供了技術基礎。
但遠程部署仍然有其侷限性：
- 網絡延遲和可靠性是影響遠程部署性能和穩定性的主要因素。特別是在需要頻繁交互的場景中，網絡往返時間可能會顯著影響用户體驗。相比本地部署的進程間通信，HTTP 傳輸必然會引入額外的網絡開銷，且網絡中斷或不穩定會直接影響服務的可用性。
- 在安全性方面，遠程部署需要將 HTTP 端點暴露到 Internet 或其他網絡環境，天生比本地部署擁有更大的攻擊面。數據需要通過網絡傳輸，增加了被截獲或篡改的風險。攻擊者也會通過暴露的 HTTP 端點試圖獲得工具的訪問權限。需要謹慎的安全設計和額外的安全投入（如認證鑑權，加密等）。
-
兼容性方面，Streamable HTTP 協議推出時間較晚，部分客户端對此支持較差。但可通過本地第三方工具，將其轉換為 stdio 模式，兼容更多客户端。
第三部分：在亞馬遜雲上構建和部署 MCP 服務器
根據您對基礎設施的選擇，亞馬遜雲科技提供了兩種主要的部署選項：
- 部署在 Amazon Bedrock AgentCore Runtime，由亞馬遜雲科技完全託管的 MCP 服務器運行時；
- 部署在亞馬遜雲科技計算服務，如 Amazon Lambda 或 Amazon ECS with Amazon Fargate，以獲得更多的基礎設施靈活性。
您可以根據您期望部署的區域選擇合適的部署模式。Bedrock AgentCore 目前處於公開預覽階段，僅在海外部分區域可用。在亞馬遜雲科技中國區域（含北京和寧夏區域），您可以在計算服務上部署 MCP 服務器。
1. 使用 Amazon Bedrock AgentCore Runtime 快速構建和部署 MCP 服務器
Amazon Bedrock AgentCore 是亞馬遜雲科技推出的一項全新服務，專門用於幫助開發者快速構建、部署和運行企業級的 Agentic AI應用，讓開發者能夠專注於創新，而不是底層的技術細節。它是為Agentic AI量身打造的開箱即用的”工具箱”，核心服務包括：
- Runtime（運行時）：提供會話完全隔離，安全的無服務器的運行環境，可用於Agent, MCP服務器託管部署；
- Gateway（網關）：幫助Agent安全地以MCP協議連接現有工具和API服務，簡化工具集成
- 以及Memory（記憶功能），Code Interpreter（代碼解釋器），Browser（瀏覽器工具），Identity（身份管理），Observability（可觀察性）等其他Agent 運行部署所需要的組件。
Amazon Bedrock AgentCore Runtime 是專門為 Agent 或 MCP 服務器構建的無服務器運行環境，提供會話級的安全隔離以及按量付費的計費模式。
圖 4：Bedrock AgentCore Runtime 部署MCP Server
Amazon Bedrock AgentCore Runtime 提供 MCP 服務器支持，您可以使用 bedrock-agentcore-starter-toolkit 快速將您的 MCP 服務器從源代碼部署到 Amazon Bedrock AgentCore Runtime，而無需管理任何基礎設施。
在準備好源代碼後，您僅需執行agentcore configure 和 agentcore launch 兩條命令，即可通過 CodeBuild 在亞馬遜雲科技託管環境構建容器鏡像，配置基於 Amazon Cognito 的身份認證機制，將構建完成的 MCP 服務器鏡像部署到 Amazon Bedrock AgentCore Runtime，並創建一個訪問端點。已認證的客户端可通過託管的端點，使用 Streamable HTTP 傳輸方式訪問 MCP 服務器。
我們提供基於 Jupyter Notebook 的快速使用指導，幫助您快速上手 Amazon Bedrock AgentCore Runtime。您可以從此處獲取此快速使用指導。
2. 利用 Amazon Lambda 部署無狀態 MCP 服務器
圖 5：Lambda 部署無狀態MCP Server
Amazon Lambda 特別適合處理無狀態的 MCP 服務器場景。這類場景通常包括網絡搜索、API 調用等無狀態操作，採用單次請求-響應模式，任務運行時間相對較短。Lambda 的事件驅動特性與這種使用模式高度契合。
Lambda 的優勢在於其獨特的計費模式和運行特性。毫秒級計費意味着只需為實際運行時間付費，對於間歇性使用的 MCP 服務器來説成本極低。強大的自動伸縮能力讓系統可以在10秒內啓動1000個實例，輕鬆應對突發流量。零服務器管理的特性讓開發者無需關心底層基礎設施的維護和升級。最重要的是，Lambda 提供的請求級隔離確保每個請求都運行在獨立的執行環境中，這對於安全性要求較高的企業應用非常重要。
技術實現方面，可以使用 Lambda Web Adapter 將基於 FastMCP 的 Web 應用部署到 Lambda。這個適配器作為一個層（Layer）集成到 Lambda 函數中，能夠將傳統的 Web 應用請求轉換為 Lambda 能夠處理的格式。使得您可以使用現有框架進行開發而無需進行代碼改動。
在 Lambda 上部署的服務器可通過 API Gateway 暴露給用户。API Gateway 是亞馬遜雲科技託管的 API 網關，可將部署到 Lambda 的 MCP 服務器安全的暴露到 Internet 或 VPC 內。API Gateway 支持基於 API Key 或 Lambda 的認證功能，您可以通過配置 API Key 或 Lambda 函數控制哪些用户可以訪問 MCP 服務器。API Gateway 與 WAF 的集成更能有效防止惡意流量訪問或嗅探 MCP 服務器，確保訪問安全。
我們提供了基於SAM（Serverless Application Model）的模板來幫助您快速開始在 Lambda 上開發無狀態的 MCP 服務器。該模板包含基於 FastMCP 框架的 Python 源代碼，用於部署的 SAM 模板，以及部署腳本。利用該模板，您可以快速部署運行在 Amazon Lambda 上的MCP 服務器， API Gateway，以及其他支持資源。具體部署參數可在 SAM 模板中定義，包括運行時環境、內存配置、環境變量等參數。您可以在此處獲取該模板。
3. 利用 Amazon ECS with Amazon Fargate 部署有狀態 MCP 服務器
圖 6：ECS Fargate 部署有狀態MCP Server
與無狀態的 Amazon Lambda 相比，容器環境無疑適合處理有狀態的 MCP 服務器場景。這類場景包括多輪對話場景（如 Playwright 自動化），需要保持狀態的長時間運行任務，以及處理時間較長，需要通過 Server-Sent Events (SSE) 不斷髮送進程或中間結果的應用。容器化部署更為靈活，對於複雜，或依賴外部組件的 MCP 服務器更為方便。您可以將依賴的組件和 MCP 服務器構建在同一個容器鏡像中，MCP 服務器和依賴項可通過跨進程調用或本地網絡進行交互，降低複雜度。
亞馬遜雲科技提供多種容器運行時選擇。您可以使用現有的容器基礎設施（如 Amazon ECS，Amazon EKS 等），在 Amazon EC2 上運行 MCP 服務器。如您不希望管理基礎設施，您可以使用 Amazon ECS 管理容器，並使用 Amazon Fargate 運行環境運行容器。Amazon ECS 是全託管，易上手的容器編排服務，您無需學習 Kubernetes 的複雜操作方式，即可將容器運行在亞馬遜雲科技託管的運行環境上。而 Amazon Fargate 作為全託管的運行環境，您無需管理操作系統，容器運行時等運行環境，有效減少了運維工作量。Amazon Fargate 按實際使用的 CPU 和內存進行計費，且支持基於 ECS Autoscaling 的指標跟蹤彈性伸縮，儘可能的節省成本。
我們需要使用 ALB 將啓用 Server-Side Event 的 MCP 服務器暴露到 Internet 或 VPC。在配置 ALB 時，需要啓用 Sticky Sessions 機制。該機制可以有效保持狀態，確保同一用户的多個請求能夠路由到同一個實例。
我們提供了基於 CloudFormation 模板來幫助您快速開始在 Amazon ECS 上開發有狀態的 MCP 服務器。該模板包含基於 FastMCP 框架的 Python 源代碼，用於部署的 CloudFormation 模板，以及部署腳本。利用該模板，您可以快速部署 ECS 集羣以及其他支持資源，構建容器鏡像，並將容器鏡像運行在 ECS Fargate 上。具體部署參數可在 CloudFormation 模板中定義，包括運行時環境、資源配置，VPC 配置 等參數。
第四部分：快速遷移現有的工具或 MCP 服務器至雲上
如果您已有現有的 Lambda 函數或 API， 利用 Amazon Bedrock AgentCore Gateway 可以快速的將現有工具以 MCP 協議暴露出來，以供客户端使用。如果您已經開發了基於 stdio 本地部署的 MCP 服務器，也可以利用亞馬遜雲科技解決方案，快速將MCP服務器部署到雲上。
使用 Amazon Bedrock AgentCore Gateway 轉換現有 API
圖 7：Bedrock AgentCore Gateway 架構
Amazon Bedrock AgentCore Gateway 是一項全託管的工具網關服務，其主要作用是作為一個統一的連接層，將各種不同的工具和資源轉換為 MCP 兼容的工具，使 Agent 能夠通過單一的端點訪問背後的多種工具。
Amazon Bedrock AgentCore Gateway 支持將 Lambda 函數、OpenAPI 規範 API、Smithy 模型 API 快速轉換為基於 Streamable HTTP 的 MCP 端點，並提供內置的認證鑑權。 例如，很多企業內部已經有現成的REST API，而 Amazon Bedrock AgentCore Gateway 就可以把這些現有 API 服務快速的轉換成一個MCP 服務器，供 AI Agent 使用。多個 API 可以掛載到同一個端點，以簡化客户端配置。
在某些真實業務場景下，Agent需要選擇的工具多達幾百甚至上千種。Amazon Bedrock AgentCore Gateway 支持語義檢索。語義檢索作為一個特殊的工具，可以根據Agent提出的需求，找出跟當前任務最相關的工具列表，再注入對應的工具描述給Agent進行選擇。該功能可以幫助 Agent 智能地發現和選擇最適合其任務的工具，大幅度減少輸入Token消耗，防止工具過多導致的延遲和效率問題。
我們提供基於 Jupyter Notebook 的快速使用指導，幫助您快速上手 Amazon Bedrock AgentCore Gateway。完整的示例代碼請參考 此處
在亞馬遜中國區域快速將現有 MCP 服務器部署至雲上
圖 8：mcp-proxy接口轉換
為了簡化現有 MCP 服務器到雲端的遷移過程，我們開發了一款自動化轉換解決方案。該解決方案將現有基於 stdio 交互模式的 MCP 服務器轉換至可在雲上部署的，基於 Streamable HTTP 的 MCP 服務器。該解決方案基於社區開源的 mcp-proxy項目，該項目本質上是一個 HTTP 服務器，將收到的請求轉發至 MCP 服務器進程中，以完成 Streamable HTTP 至 stdio 的轉換而無需修改源代碼。
利用該解決方案，您只需輸入 MCP 服務器的運行命令或 GitHub 倉庫地址，該解決方案會自動生成包含所有必要的運行時環境和依賴包的 Dockerfile，自動化構建容器鏡像。隨後使用 CloudFormation 模板將該容器鏡像部署至現有的 ECS 集羣中，並創建 ALB 將其暴露至 Internet。
這種自動化工具大大降低了從本地到雲端遷移的技術門檻。開發者只需要提供 MCP 服務器的運行命令，和基本的部署參數，工具就能自動完成整個部署流程。這對於那些有大量現有 MCP 服務器需要遷移的團隊來説特別有價值。您可以在 Github上獲取該解決方案。
結論
隨着 Agentic AI 技術的不斷髮展，MCP 協議正在成為連接 AI 智能體與外部工具的標準橋樑。雖然本地部署 MCP 服務器在開發階段具有便利性，但云端部署在生產環境中展現出了明顯的優勢。
通過將 MCP 服務器部署到亞馬遜雲科技雲平台，企業可以獲得自動化的版本管理、增強的安全性、更好的可擴展性和全面的可觀測性。特別是在版本管理方面，雲端部署徹底解決了本地部署中包管理器更新滯後的問題，確保用户始終能夠使用最新版本的 MCP 服務器。
在安全性方面，雲端部署通過物理隔離和精細化的權限控制，大大降低了權限泄露和惡意行為的風險。同時，統一的監控和日誌記錄也為企業提供了完整的安全審計能力。
成本方面，雲端部署的按需付費模式相比本地部署的固定成本投入更加經濟高效。特別是對於使用頻率不高的 MCP 服務器，雲端部署可以顯著降低總體擁有成本。
許多用户已經將 MCP 服務器部署到雲上，翰德在亞馬遜雲科技上海峯會上展示的簡歷分析 MCP 服務器是一個成功案例。他們在初期選擇了 ECS Fargate 平台部署有狀態服務，支持複雜的簡歷處理流程。隨着業務的發展和對成本優化的需求，團隊正在評估將部分功能遷移到 Lambda 平台，以進一步降低運營成本。從業務價值角度看，這個 MCP 服務器實現了簡歷篩選的自動化，大大提高了獵頭團隊的工作效率，減少了人工審核的工作量。
展望未來，隨着更多企業採用 Agentic AI 解決方案，MCP 服務器的雲端部署將成為主流選擇。自動化部署工具的發展也將進一步降低遷移門檻，讓現有的 MCP 服務器能夠更容易地遷移到雲端。
亞馬遜雲科技提供多種方式幫助您部署 MCP 服務器到雲端。您可以使用專門為Agentic AI工作負載提供無服務器運行環境的託管服務 Amazon Bedrock AgentCore Runtime，也可以使用多樣化的計算服務例如 Amazon Lambda 或 Amazon ECS with Amazon Fargate 應對各種複雜需求。對於正在考慮部署 MCP 服務器的開發者和企業來説，建議優先考慮雲端部署方案。這不僅能夠獲得更好的技術優勢，也能為未來的擴展和維護打下堅實的基礎。
本文提到的技術資料鏈接：
- 無服務器部署MCP服務器示例代碼庫：
https://github.com/aws-samples/sample-serverless-mcp-servers/tree/main - Amazon Bedrock AgentCore Runtime部署MCP示例代碼庫：
https://github.com/awslabs/amazon-bedrock-agentcore-samples/tree/main/01-tutorials/01-AgentCore-runtime/02-hosting-MCP-server - Amazon Bedrock AgentCore Gateway部署MCP示例代碼庫：
https://github.com/awslabs/amazon-bedrock-agentcore-samples/tree/main/01-tutorials/02-AgentCore-gateway
關於Agentic AI基礎設施的更多實踐經驗參考，歡迎點擊：
Agentic AI基礎設施實踐經驗系列（一）：Agent應用開發與落地實踐思考
Agentic AI基礎設施實踐經驗系列（二）：專用沙盒環境的必要性與實踐方案
Agentic AI基礎設施實踐經驗系列（三）：Agent記憶模塊的最佳實踐
Agentic AI基礎設施實踐經驗系列（四）：MCP服務器從本地到雲端的部署演進
Agentic AI基礎設施實踐經驗系列（五）：Agent應用系統中的身份認證與授權管理
Agentic AI基礎設施實踐經驗系列（六）：Agent質量評估
Agentic AI基礎設施實踐經驗系列（七）：可觀測性在Agent應用的挑戰與實踐
Agentic AI基礎設施實踐經驗系列（八）：Agent應用的隱私和安全
*前述特定亞馬遜雲科技生成式人工智能相關的服務目前在亞馬遜雲科技海外區域可用。亞馬遜雲科技中國區域相關雲服務由西雲數據和光環新網運營，具體信息以中國區域官網為準。
本篇作者
本期最新實驗《多模一站通 —— Amazon Bedrock 上的基礎模型初體驗》
✨ 精心設計，旨在引導您深入探索Amazon Bedrock的模型選擇與調用、模型自動化評估以及安全圍欄(Guardrail)等重要功能。無需管理基礎設施，利用亞馬遜技術與生態，快速集成與部署生成式AI模型能力。
⏩️[點擊進入實驗] 即刻開啓 AI 開發之旅
構建無限, 探索啓程！
