Agentic AI基础设施实践经验系列（四）：MCP服务器从本地到云端的部署演进

引言

随着人工智能技术的快速发展，特别是大语言模型（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 服务器本地部署和云端部署的适用场景和参考架构，以及如何实现云端部署目标。

第一部分：理解工具调用和 MCP 协议

从工具调用说起

工具调用（Tool use）指模型了解、选择并调用外部工具的能力。例如用户希望检索云服务提供商的最新实例价格，而具体价格并未内置在大模型知识中，或信息已陈旧不具备参考价值。此时拥有工具调用能力的大语言模型，会根据事先传入的已安装工具列表，选择合适工具并生成对应调用参数。但大语言模型自身无法直接运行工具，执行过程由推理框架或 AI 智能体框架负责，执行结果返回后，大模型再据此生成最终回复。

许多 Agentic AI 框架内置了基础工具供大模型调用。例如 Strands Agents SDK 提供了 30 种内置工具，包含计算器、HTTP 请求、文件系统操作等。在实例价格查询场景中，大模型可选择其内置的 HTTP 请求工具，调用云服务价格 API 获取数据，生成工具调用请求后，由 Strands Agent SDK 执行调用并返回结果。

但内置工具存在明显局限性：仅覆盖基础功能，无法满足复杂业务需求和定制化场景；版本更新与维护需同步框架发布周期，无法单独频繁迭代。应对这些问题，需要将工具与 Agentic AI 框架解耦，外挂工具的需求催生了 MCP 协议。

MCP 的架构设计

模型上下文协议（MCP）通过标准化的客户端 - 服务器架构和统一协议，解决大模型的工具管理、集成和通讯问题。MCP 客户端通常集成在 AI 应用中（如 Claude Desktop、Cursor 等），负责与 MCP 服务器通信；MCP 服务器则作为 AI 应用和具体工具之间的转换桥梁，一般以代理（Proxy）或边车（Sidecar）服务形式存在，将标准 MCP 请求转换为特定工具可理解的格式，执行操作后再返回结果。

以 Claude 提供的 Git MCP Server 为例，客户端通过 MCP 协议发起 Git 存储库操作请求，Git MCP Server 利用内置 Git SDK 执行操作后，以 MCP 协议返回结果。这种设计实现了协议层面的解耦，工具的升级和变更不会直接影响 AI 应用。

MCP 协议的核心优势是松耦合架构：AI 智能体只需支持 MCP 协议，无需关心工具更新变化，也无需适配不同 API 格式，所有工具调用通过统一协议、相同数据格式和通信方式完成，大幅降低多工具集成复杂度；工具提供方可独立开发和维护各自的 MCP 服务器，无需考虑与 AI 智能体的集成，实现责任清晰分工。

第二部分：部署方案的选择

MCP 的部署模式

MCP 协议支持两种主要部署模式：本地部署和远程部署，二者核心区别在于 MCP 服务器与客户端是否位于同一环境，适用于不同场景且各有优劣，以下进行详细分析。

本地部署

绝大多数 MCP 服务器默认支持本地部署，服务器以本地进程或容器形式运行。用户需配置启动命令（如 npx、uv 等包管理器，或 docker 等容器运行时）及对应的启动参数和环境变量。配置完成后，客户端通过系统调用创建子进程启动服务端程序，建立输入输出管道连接，通过监测服务器进程即可掌握运行状况，这种基于进程生命周期的连接管理机制简单有效，避免了复杂网络连接管理问题。

客户端与服务端通过标准输入输出流，采用 UTF-8 编码的 JSON-RPC 2.0 规范通信，提供原生双向通信能力。同时，本地通信通过系统级管道传输，规避网络层复杂性，保障通信可靠性和效率。

适用场景：

• 功能层面：需本地数据访问和工具集成的场景，如开发环境中 AI 助手访问本地文件系统、执行构建脚本、运行测试用例；数据分析任务中直接访问本地数据库、处理本地文件，避免数据传输延迟和安全风险。
• 性能层面：需要频繁交互的场景，如实时代码分析、交互式数据探索等，本地部署可避免网络开销，实现更低延迟和更高吞吐量。

局限性：

• 版本管理困难：后端工具升级可能导致 API 变化，MCP 服务器自身也需迭代更新，而 npm、uv 等包管理器在缓存命中时不会自动更新，本地部署需手动操作，服务器数量较多时难以及时响应变化。
• 安全风险：本地 MCP 服务器默认与用户运行在同一命名空间，权限等同于当前用户，理论上可访问用户能获取的所有文件和资源；同时需在本地存储 API Key、用户名密码等凭证，配置不当可能导致横向权限泄露。
• 资源和性能限制：每个 MCP 服务器都是独立进程，随客户端启动，大量服务器同时运行会显著占用本地机器资源，在资源受限的开发环境中影响更为明显。

远程部署

远程部署模式将 MCP 服务器部署在远程服务器上，服务器暴露 HTTP 端点，客户端通过 Streamable HTTP 协议通信。Streamable HTTP 是 HTTP 协议的扩展，在标准 HTTP 1.1 基础上支持轻量级的 Server-sent Event（SSE，服务端发送消息）。MCP 客户端启动时，连接远程 MCP 服务器的 HTTP 端点初始化 Session，之后可通过 HTTP POST 方法发送请求，服务器处理完成后可直接以 JSON 格式返回结果；若任务耗时较长，可将连接升级至 SSE，以流式形式逐步返回结果。

目前已有多个 MCP 服务器提供方支持远程部署模式，如 Remote GitHub MCP Server 等。该模式虽增加网络延迟，但在安全性、性能和可维护性方面优势显著。

核心优势：

• 版本更新更便捷：通过持续集成部署（CI/CD）流水线，可在单一可控环境中统一更新 MCP 服务器，用户无需手动操作，重新连接即可获取最新版本工具，彻底解决本地部署的手动维护痛点，降低运维负担，减少版本不一致问题。
• 安全可靠性更高：云端部署提供多层保护，权限隔离是核心优势 ——MCP 服务器运行在受控云环境中，客户端仅发送具体工具调用请求，不包含完整对话上下文或敏感信息，即使服务器被攻击，攻击者也无法获取完整用户数据；同时支持 OAuth 等标准协议进行身份认证鉴权，无需在本地分发凭证，即可通过身份认证后利用远程服务器凭证执行高权限操作或访问受保护知识库，降低凭证泄露或滥用风险。
• 性能和性价比更优：客户端仅需维护简单 HTTP 连接，无需担忧本地资源消耗；大量计算需求可直接在云端满足，无需本地复杂环境配置；按需计费模式降低总体成本，尤其适用于使用频率不高的 MCP 服务器。
• 可观测和可维护性更强：现代 LLMOps 重视可观测性，云端部署可通过统一监控系统提供请求量、响应时间、资源使用情况、错误率等实时性能指标；安全审计功能支持合规需求，可记录所有工具调用请求完整日志，实现可疑行为自动检测和告警，生成合规报告，这些功能在本地环境中难以实现。

适用场景：

• 企业环境：需要集中管理和共享资源的大型组织，IT 团队可部署统一 MCP 服务器集群，为不同部门 AI 应用提供标准化工具和数据访问接口，简化权限管理和审计追踪，实现资源统一监控和性能优化。
• 跨地域协作：团队成员无论身处何地，均可通过标准 HTTP 协议访问相同服务器资源，保障协作环境一致性。
• 生产环境：需要高可用性的场景，可通过负载均衡、故障转移等技术构建健壮服务架构。
• 云原生环境：容器化和微服务架构中，MCP 服务器可作为独立服务组件部署和扩展，与其他业务服务保持松耦合，支持按需扩容、滚动更新等现代运维实践，为 AI 应用规模化部署提供基础。

局限性：

• 网络依赖：网络延迟和可靠性影响性能和稳定性，频繁交互场景中网络往返时间可能显著降低用户体验；HTTP 传输引入额外网络开销，网络中断或不稳定会直接影响服务可用性。
• 安全风险：HTTP 端点暴露到互联网或其他网络环境，攻击面大于本地部署；数据通过网络传输时存在被截获或篡改的风险，攻击者可能通过暴露端点尝试获取工具访问权限，需额外投入安全设计（如认证鉴权、加密等）。
• 兼容性问题：Streamable HTTP 协议推出时间较晚，部分客户端支持较差，需通过本地第三方工具转换为 stdio 模式以兼容更多客户端。

第三部分：云端构建和部署 MCP 服务器

部署选项概述

根据基础设施选择，可提供两种主要部署选项：

1. 部署在托管的 MCP 服务器运行时，享受完全托管服务；
2. 部署在计算服务（如无服务器函数、容器服务等），获得更多基础设施灵活性。

可根据部署区域选择合适模式，托管运行时若处于公开预览阶段，仅在海外部分区域可用；在国内区域，可选择在计算服务上部署 MCP 服务器。

1. 利用托管运行时快速构建和部署 MCP 服务器

托管运行时是专门用于帮助开发者快速构建、部署和运行企业级 Agentic AI 应用的服务，让开发者专注于创新而非底层技术细节，是为 Agentic AI 量身打造的开箱即用 “工具箱”，核心服务包括：

• Runtime（运行时）：提供会话完全隔离、安全的无服务器运行环境，可用于 Agent、MCP 服务器托管部署；
• Gateway（网关）：帮助 Agent 安全地以 MCP 协议连接现有工具和 API 服务，简化工具集成；
• 其他组件：包括 Memory（记忆功能）、Code Interpreter（代码解释器）、Browser（浏览器工具）、Identity（身份管理）、Observability（可观察性）等 Agent 运行部署所需模块。

其中，托管运行时的 Runtime 组件是专门为 Agent 或 MCP 服务器构建的无服务器运行环境，提供会话级安全隔离和按量付费计费模式。

部署流程上，托管运行时提供 MCP 服务器支持，可使用专用工具包快速将 MCP 服务器从源代码部署到 Runtime，无需管理任何基础设施。准备好源代码后，仅需执行两条配置和启动命令，即可通过构建服务在托管环境构建容器镜像，配置基于身份认证服务的身份认证机制，将镜像部署到 Runtime 并创建访问端点。已认证的客户端可通过托管端点，使用 Streamable HTTP 传输方式访问 MCP 服务器。

同时，提供基于 Jupyter Notebook 的快速使用指导，帮助开发者快速上手托管运行时部署。

2. 利用无服务器函数部署无状态 MCP 服务器

无服务器函数特别适合处理无状态的 MCP 服务器场景，这类场景通常包括网络搜索、API 调用等无状态操作，采用单次请求 - 响应模式，任务运行时间相对较短，无服务器函数的事件驱动特性与之高度契合。

无服务器函数的核心优势：

• 计费模式：毫秒级计费，仅为实际运行时间付费，对于间歇性使用的 MCP 服务器成本极低；
• 伸缩能力：可在短时间内启动大量实例，轻松应对突发流量；
• 运维便捷：零服务器管理，开发者无需关心底层基础设施维护和升级；
• 安全隔离：提供请求级隔离，每个请求运行在独立执行环境中，满足企业应用高安全性要求。

技术实现上，可使用专用适配器将基于 FastMCP 的 Web 应用部署到无服务器函数。该适配器作为层（Layer）集成到函数中，能将传统 Web 应用请求转换为无服务器函数可处理的格式，支持使用现有框架开发而无需修改代码。

部署后的服务器可通过 API 网关暴露给用户。API 网关作为托管的 API 网关服务，可将无服务器函数上的 MCP 服务器安全暴露到互联网或私有网络内，支持基于 API Key 或函数自身的认证功能，控制访问权限；同时可与 Web 应用防火墙（WAF）集成，有效防止恶意流量访问或嗅探 MCP 服务器，保障访问安全。

此外，提供基于无服务器应用模型（SAM）的模板，帮助快速开发无状态 MCP 服务器，模板包含基于 FastMCP 框架的 Python 源代码、部署模板及部署脚本，可快速部署无服务器函数、API 网关及其他支持资源，部署参数（如运行时环境、内存配置、环境变量等）可在模板中定义。

3. 利用容器服务部署有状态 MCP 服务器

与无状态的无服务器函数相比，容器环境更适合处理有状态的 MCP 服务器场景，包括多轮对话场景（如 Playwright 自动化）、需要保持状态的长时间运行任务，以及处理时间较长、需通过 SSE 持续发送进程或中间结果的应用。容器化部署灵活性更高，对于复杂或依赖外部组件的 MCP 服务器更为便捷，可将依赖组件和 MCP 服务器构建在同一容器镜像中，通过跨进程调用或本地网络交互，降低集成复杂度。

容器服务提供多种运行时选择：可使用现有容器基础设施在虚拟机上运行 MCP 服务器；若无需管理基础设施，可使用容器编排服务管理容器，并采用无服务器容器运行环境运行容器。容器编排服务是全托管、易上手的容器编排服务，无需学习复杂的编排工具操作；无服务器容器运行环境作为全托管运行环境，无需管理操作系统、容器运行时等，有效减少运维工作量，按实际使用的 CPU 和内存计费，并支持基于指标跟踪的弹性伸缩，最大化节省成本。

部署时，需使用应用负载均衡器（ALB）将启用 SSE 的 MCP 服务器暴露到互联网或私有网络，配置 ALB 时需启用会话保持（Sticky Sessions）机制，确保同一用户的多个请求路由到同一个实例，维持服务状态。

同时，提供基于基础设施即代码（IaC）模板的快速部署方案，帮助在容器服务上开发有状态 MCP 服务器，模板包含基于 FastMCP 框架的 Python 源代码、部署模板及部署脚本，可快速部署容器集群及其他支持资源，构建容器镜像并运行在无服务器容器环境上，部署参数（如运行时环境、资源配置、网络配置等）可在模板中定义。

第四部分：快速迁移现有的工具或 MCP 服务器至云上

使用托管网关转换现有 API

托管网关是全托管的工具网关服务，核心作用是作为统一连接层，将各类工具和资源转换为 MCP 兼容工具，使 Agent 能通过单一端点访问多种工具。

托管网关支持将无服务器函数、OpenAPI 规范 API、Smithy 模型 API 快速转换为基于 Streamable HTTP 的 MCP 端点，并提供内置认证鉴权。例如，企业内部现有的 REST API 可通过该网关快速转换为 MCP 服务器，供 AI Agent 使用；多个 API 可挂载到同一端点，简化客户端配置。

针对工具数量庞大（数百甚至上千种）的业务场景，托管网关支持语义检索功能。语义检索作为特殊工具，可根据 Agent 需求匹配最相关的工具列表，再将对应的工具描述注入 Agent 供其选择，帮助 Agent 智能发现合适工具，大幅减少输入 Token 消耗，避免工具过多导致的延迟和效率问题。

提供基于 Jupyter Notebook 的快速使用指导，帮助开发者快速上手托管网关的 API 转换功能。

国内区域快速迁移现有 MCP 服务器至云上

为简化现有 MCP 服务器的云端迁移流程，开发了自动化转换解决方案，可将基于 stdio 交互模式的本地 MCP 服务器，转换为可云端部署的基于 Streamable HTTP 的 MCP 服务器。该方案基于社区开源的 mcp-proxy 项目，本质是一个 HTTP 服务器，能将收到的请求转发至 MCP 服务器进程，完成 Streamable HTTP 至 stdio 的转换，无需修改源代码。

使用该解决方案时，只需输入 MCP 服务器的运行命令或 GitHub 仓库地址，即可自动生成包含所有必要运行时环境和依赖包的 Dockerfile，自动化构建容器镜像；随后通过 IaC 模板将容器镜像部署至现有容器集群，并创建 ALB 暴露到互联网。

这种自动化工具大幅降低本地到云端的迁移技术门槛，开发者仅需提供 MCP 服务器运行命令和基本部署参数，即可自动完成整个部署流程，特别适合需要迁移大量现有 MCP 服务器的团队，该解决方案可在 GitHub 上获取。

结论

随着 Agentic AI 技术的不断发展，MCP 协议正在成为连接 AI 智能体与外部工具的标准桥梁。虽然本地部署 MCP 服务器在开发阶段具有便利性，但云端部署在生产环境中展现出明显优势。

通过将 MCP 服务器部署到云端，企业可获得自动化版本管理、增强安全性、更优可扩展性和全面可观测性。版本管理方面，云端部署彻底解决了本地部署中包管理器更新滞后的问题，确保用户始终使用最新版本；安全性方面，通过物理隔离和精细化权限控制，大幅降低权限泄露和恶意行为风险，统一监控和日志记录提供完整安全审计能力；成本方面，按需付费模式相比本地部署的固定成本投入更经济高效，尤其适用于使用频率不高的 MCP 服务器。

已有众多用户将 MCP 服务器部署到云上，例如某企业在技术峰会上展示的简历分析 MCP 服务器，初期选择容器服务的无服务器运行环境部署有状态服务，支持复杂简历处理流程；随着业务发展和成本优化需求，正评估将部分功能迁移到无服务器函数平台，进一步降低运营成本。该 MCP 服务器实现了简历筛选自动化，大幅提升猎头团队工作效率，减少人工审核工作量。

展望未来，随着更多企业采用 Agentic AI 解决方案，MCP 服务器的云端部署将成为主流选择。自动化部署工具的发展将进一步降低迁移门槛，让现有 MCP 服务器更容易迁移到云端。

提供多种方式帮助部署 MCP 服务器到云端：可使用专门为 Agentic AI 工作负载设计的托管无服务器运行环境，也可选择无服务器函数或容器服务等多样化计算服务应对复杂需求。对于正在考虑部署 MCP 服务器的开发者和企业，建议优先考虑云端部署方案，不仅能获得更优技术优势，也能为未来的扩展和维护奠定坚实基础。