基于 AWS 的无服务器 MCP 架构：Lambda 与 Fargate 在 Agentic AI 负载下的选择

摘要

Agentic AI 的效能不仅依赖于提示工程，更需要一个安全、结构化的方式来访问企业内部数据与系统。模型上下文协议（Model Context Protocol, MCP）正是为此而生，它在 AI 代理与组织系统之间架起了一座可扩展且受治理的桥梁。本文旨在深入探讨如何在 AWS 上构建生产级的远程 MCP 服务器，并对三种主流的无服务器架构方案——Lambda + Web Adapter、原生 Lambda 实现以及 Fargate ECS——进行全方位的对比分析。本文已根据 MCP v2025.03.26 的最新进展进行修订，将 Streamable HTTP Transport 协议带来的原生 Lambda 流式支持作为关键背景，重新评估各方案的优缺点与适用场景，帮助为 Agentic AI 工作负载部署在Serverless架构选择最合适的部署方案。

1. 引言

1.1 MCP 服务器的必要性

模型上下文协议（MCP）使 AI 代理能够安全、有效地与组织的内部数据和系统进行交互，超越了简单的提示词交互，从而交付更具意义、感知上下文的成果。无论是读取只读的资源 (resources)、与工具 (tools) 交互，还是生成提示 (prompts)，MCP 服务器都极大地扩展了 Agentic AI 的能力边界，使其能与您的应用程序和数据深度融合。

1.2 架构选型的重要性

在 AWS 上构建 MCP 解决方案之前，明确用户需求至关重要。以下问题将直接影响您的架构决策：

• 您的应用场景是否需要持续的数据流？
• 您的主要用户是进行探索式编程（“vibe coding”）的开发者，还是自主执行任务的 AI 代理？
• 您的服务对象是内部开发者，还是遍布全球的付费客户？

这些问题的答案将引导您走向不同的架构选择。最终决策取决于您的具体需求、预期使用模式、性能与可扩展性要求、成本考量、开发者体验、可观测性以及安全性等多方面因素。

2. 关键技术更新：MCP v2025.03.26 与原生 Lambda 流式支持

Streamable HTTP 是 MCP 中 SSE 的升级替代品，通过单一端点、双向通信和增强的连接恢复机制解决了 SSE 的单向性和复杂性问题。SSE 作为遗留传输机制已被弃用，但在过渡期间仍通过向后兼容性支持现有实现。开发者应优先采用 Streamable HTTP，同时为旧客户端保留 SSE 支持，以确保无缝集成和未来兼容性。SSE 已被 MCP 规范标记为已弃用（自 2024-11-05 版本起），Streamable HTTP 成为推荐的远程传输机制。

在深入探讨具体架构方案之前，必须了解一个技术更新。Anthropic 于2025年3月发布的 MCP v2025.03.26 版本，引入了 Streamable HTTP Transport，这是一个专为无服务器（Serverless）环境设计的、完全无状态的传输协议。它取代了之前依赖服务器发送事件（SSE）的协议。

这一变化的核心影响在于，它能够完美结合 AWS Lambda Response Streaming（响应流）功能。这意味着，过去 Lambda 因其“非服务器”特性而难以支持 MCP 流式传输的根本性障碍已被扫除。现在，Lambda 可以原生、高效地支持 MCP 的流式交互，不再需要额外的适配层或复杂的变通方案。

在我的GitHub上开源的项目AI_MCP，我已经应用了Streamable HTTP Transport将MCP Server部署在了AWS Lambda函数上，大家可以参考。

这个背景是理解后续架构分析的关键。它并没有让原有的讨论失效，而是让我们能以一个全新的、更精准的视角来审视每种方案的真正价值和权衡。

3. 方案一：AWS Lambda + Web Adapter & MCP SDK

AWS Lambda Web Adapter 是一个能让在 Lambda 上运行传统服务器应用的开源项目，它在 Lambda 和应用之间充当了适配层。

架构流程:

在此方案中，我们利用 Web Adapter 来启动一个基于 FastMCP SDK 的 MCP 服务器。Web Adapter 负责将 API Gateway 的事件格式转换为传统服务器应用所期望的套接字（socket）负载格式。

现状评估:

在 MCP 新协议发布之前，这是在 Lambda 上运行基于 SDK 的 MCP 服务器的唯一可行方式。然而，在 Lambda 已原生支持流式响应的今天，此方案的定位发生了根本性变化：

• 变为遗留或过渡方案：对于新的 MCP 项目，已无理由选择此方案。它的存在更多是为那些已采用此模式的项目提供维护路径，或作为将其他非 MCP 服务器应用“平移”到 Lambda 的一种方式。
• 复杂性凸显：与当前更简洁的原生流式方案相比，Web Adapter 引入的额外配置（Shell脚本、环境变量）、更长的调用链以及显著增加的冷启动时间（1-3秒）等缺点变得更加突出。

3.1 性能分析

冷启动延迟是其最大性能瓶颈。虽然它现在可以支持流式传输，但其性能表现劣于更直接的 Lambda 原生流式方案。

3.2 开发者体验

开发者需要处理多个技术层，调试因多层日志而变得困难。与更简洁的方案相比，其开发者体验较差。

3.3 适用场景

• 维护已采用此架构的遗留项目。
• 将其他需要模拟服务器环境的非 MCP 应用迁移至 Lambda。

4. 方案二：“原生” AWS Lambda MCP 服务器 (自研解析器)

架构流程:

此方案摒弃了所有外部适配器，核心在于自行编写一个 MCP 解析器 作为 Lambda Handler 的入口，手动处理请求的解析、路由和响应构建。MCP解析器负责MCP的生命周期

现状评估:

此方案的核心权衡——“完全的控制权 vs. 巨大的维护成本”——依然存在，但在新的技术背景下，天平更加倾向于后者。

• 自研吸引力下降：既然官方的 MCP SDK（如 FastMCP）已经可以完美地在 Lambda 上以原生流式方式运行，从零开始构建和维护一个与官方协议同步的解析器，其必要性已大大降低。
• 定位更趋利基：此方案的价值现在更局限于那些有极端需求的场景，例如需要对 MCP 协议进行深度定制或构建安全中间件，需要在协议层面进行拦截和修改。

4.1 开发者体验

开发者体验依然是最佳的，因为可以完全掌控代码，统一日志和追踪。但这一优势需要用高昂的开发和维护成本来换取。

4.2 适用场景

• 需要对 MCP 协议进行深度定制或拦截的安全网关类产品。
• 对开发者体验和代码控制有极致要求，且愿意投入巨大资源维护协议解析器的团队。

5. 方案三：AWS Fargate ECS MCP 服务器

此方案代表了传统的、基于容器的服务器模型，在无服务器化的 Fargate 平台上运行。

架构流程:

我们将 MCP 服务器打包成一个 Docker 镜像，并将其部署在 Fargate ECS 集群上。通过应用负载均衡器（ALB）对外提供服务。

现状评估:

随着 Lambda 获得原生流式能力，Fargate 的定位变得更加清晰和聚焦。它不再是支持流式传输的唯一选择，其核心优势在于：

1. 零冷启动：对于延迟极其敏感、完全无法容忍任何冷启动抖动的应用，Fargate 是无可替代的选择。
2. 支持超长任务：Fargate 没有 Lambda 的15分钟运行时限。如果 MCP 调用的某个工具本身需要运行数小时，Fargate 是唯一的平台。

5.1 性能分析

无冷启动问题是其相较于 Lambda 的最大性能优势。对于需要持续稳定低延迟的场景，Fargate 表现出色。

5.2 成本考量

由于服务器是24/7运行，基础成本较高。但对于流量稳定且持续高并发的场景，其总成本可能低于同等容量下启用了预置并发的 Lambda。

5.3 适用场景

• 对延迟极其敏感，要求零冷启动的生产级应用。
• 拥有非常稳定、可预测且持续高并发流量的场景。
• 当 MCP 工具本身需要超过15分钟的超长执行时间时。

6. 总结与建议

MCP v2025.03.26 的发布，确立了 “标准 Lambda + 官方 SDK” 作为部署 MCP 服务器的新基线。原有的几种方案也因此有了更清晰的定位。

最终选择建议：

1. 默认选择标准 Lambda 方案：对于绝大多数新的 MCP 服务器部署，直接使用官方 SDK（如 FastMCP）并部署在标准的、启用响应流的 Lambda 函数上。这是当前兼具成本、性能、开发体验和可维护性的最佳实践。

2. 在特定情况下选择 AWS Fargate：当您的业务对延迟有“零容忍”的严格要求，或者您的流量模型是高度持续且平稳，以至于 Fargate 的定价模型更优时，Fargate 依然是您的最佳选择。此外，对于需要突破15分钟执行上限的极少数工具，Fargate 是唯一的选择。

3. 谨慎评估其他方案：Lambda + Web Adapter 应仅用于维护遗留项目。自研解析器的原生 Lambda 方案则应仅在有明确的、不可替代的协议定制需求时才予以考虑。