基于 Amazon ECS Fargate 的无服务器 MCP server，为 AI 智能体提供数据湖访问

构建由人工智能（AI）驱动的应用的组织面临一个反复出现的挑战：让大型语言模型（LLM）智能体访问企业数据湖，而无需在每个智能体和应用之间重复集成逻辑。大多数团队一开始会将智能体直接连接到数据库和 API，中间没有诸如模型上下文协议（MCP）服务器这样的共享网关。每新增一个数据集都需要定制代码，每个智能体都要重新实现自己的访问控制。随着数据集或智能体数量的增长，权限执行逐渐出现偏差，接入一个新数据源需要耗费数天的工程工作。

我们的团队支持亚马逊北美分拣中心（NASC）网络，该网络中的规划团队依赖运营数据来管理产能、劳动力和包裹流转。为了让这些团队能够以对话方式访问这些数据，我们在 Amazon Elastic Container Service（Amazon ECS） 上使用 AWS Fargate 构建了一个无服务器 模型上下文协议（MCP） 服务器，为 NASC 的规划团队解决这一问题。该服务器充当 AI 智能体与企业数据湖之间的集中式、与智能体无关的网关。暴露一个新数据集只需一个 JSON 元数据文件，服务器会在下一次管道同步时自动发现它。

在本文中，我们介绍该架构，展示元数据驱动的方法如何消除对每个数据集单独集成代码的需求，并解释无服务器基础设施如何在多租户环境中支持多个智能体和应用。

问题陈述与设计目标

两个相互关联的挑战塑造了我们设计该系统的方式：碎片化的数据访问模式和不可持续的接入模式。

规模化下的集成挑战

我们的数据湖包含数千个数据集，涵盖运营指标、业务分析和领域特定数据。多个团队希望拥有能够以对话方式查询这些数据的 AI 助手，但每个团队都从头构建了自己的集成。每个智能体都嵌入了自己的 SQL 生成逻辑、模式知识和连接处理，因此模式变更意味着要逐个修补每个智能体。访问控制是碎片化的，没有单一的数据访问决策审计点。接入一个新数据集需要定制的工具代码、查询验证和重新部署，通常每张表需要耗费数天的工作。

设计目标

我们确立了四项要求：

• 配置驱动的数据湖访问。添加数据集只需一个元数据文件，而非代码。
• 与智能体无关的工具接口。任何兼容 MCP 的客户端都可以调用相同的工具。
• 集中式权限执行。访问控制在 MCP 服务器层强制执行。
• 弹性基础设施。系统能够随突发性的 AI 工作负载模式进行扩展。

解决方案概述

该架构将关注点分离为四层（客户端、MCP 服务器、工具和知识库刷新），每一层都可独立扩展和部署。元数据目录支撑着工具层，存储模式描述、列级语义和表关系，AI 智能体在生成 SQL 时会引用这些内容。由于智能体在查询时从目录中获取模式知识，因此无需硬编码表结构，也无需在模式变更时重新部署。知识库刷新层使该目录保持最新，在新增数据集元数据到达时对其进行索引。以下各节将详细描述每一层。

架构详解

下图展示了从用户查询到数据层、跨越全部四个层的请求流程。用户从客户端应用（Web 聊天、Slack、IDE 插件或外部代理）提交查询。请求通过 Amazon Route 53 进行 DNS 解析，并到达公有子网中配置了 HTTPS 和 AWS WAF 的 Application Load Balancer。负载均衡器将请求路由到 Amazon Cognito，由其对用户进行身份验证并丰富请求内容。经过身份验证的流量随后进入私有子网，客户端层运行在 Amazon ECS Fargate 上。该层在 Amazon DynamoDB 中处理会话状态，并通过内部 Application Load Balancer 将请求转发到同样运行在 Amazon ECS Fargate 上的 MCP 服务器层。在 MCP 服务器层中，由 Amazon Bedrock 驱动的 AI 代理编排使用 FastMCP（用于构建 MCP 服务器的 Python 框架）构建的工具。Amazon Bedrock Guardrails 应用于每一次模型交互。在右侧，数据层承载工具后端。Amazon Athena 和 Amazon Redshift 对数据湖运行 SQL 查询，而 Amazon Bedrock Knowledge Bases 这一全托管的检索增强生成（RAG）能力则负责语义搜索。向 Amazon Simple Storage Service（Amazon S3）和知识库的数据摄取由 AWS Lambda 处理。后续各节将详细描述每一层。

图 1：通过无服务器 MCP 服务器的请求流程，从客户端应用到数据层

MCP 客户端层：身份验证与会话管理

请求从客户端应用出发，经 Amazon Route 53 进行 DNS 解析，到达配置了 HTTPS 和 AWS WAF 的 Application Load Balancer。负载均衡器将流量转发到 Amazon ECS Fargate 客户端服务，该服务集成 Amazon Cognito 进行 JSON Web Token（JWT）身份验证，并集成 Amazon DynamoDB 进行会话存储。

上下文映射配置驱动这一丰富过程，将每个查询限定为仅涉及相关表。在我们的测试中，这种限定使端到端交互延迟保持在 15–20 秒范围内。以下示例展示了一个上下文映射配置：

{
  "package_data": {
    "description": "Package tracking and delivery information",
    "tables": ["analytics_db.regional_order_summary", "operations_gold.load_summary"],
    "sources": {"wiki": [], "quip": []}
  },
  "labor_planning": {
    "description": "Workforce management and capacity planning",
    "tables": ["workforce.capacity_details"],
    "sources": {"wiki": [], "quip": []}
  }
}

当上下文指定了表时，MCP 服务器会将元数据目录的搜索范围缩小到这些表，从而减少噪声并提高 SQL 生成的准确性。添加新的业务领域只需向此映射添加一个条目。

MCP 服务器层：无状态执行与会话状态

MCP 服务器运行在独立的 ECS Fargate 集群上，与客户端层隔离。请求通过 Amazon Route 53 和私有子网中的内部 Application Load Balancer 到达它。服务器处理完整的编排，包括查询分析、工具选择、执行和响应生成。通过 MCP 协议端点（/mcp）——一个由 FastMCP 驱动的 JSON-RPC 接口——外部兼容 MCP 的客户端（如 Amazon Q Developer 或 IDE 扩展）可以直接发现并调用工具。

Fargate 任务是无状态的，会话状态持久化在 DynamoDB 中，因此任务可以在不丢失数据的情况下被替换或扩缩容。当请求到达时，代理检索会话历史，使用 Amazon Bedrock 分析用户意图，发现并调用适当的工具，并将结果流式返回给用户。

工具层与元数据驱动的数据湖访问

每个工具都注册到 FastMCP 并可在运行时被发现：

Athena 查询工具是访问数据湖的主要接口。智能体首先查询元数据目录以了解可用的 schema，通过 Amazon Bedrock 生成优化的 SQL 查询，验证并自动修正 SQL 以兼容 Athena，然后执行它。结果返回给编排智能体进行自然语言综合。

负责任 AI 控制

Amazon Bedrock Guardrails 应用于所有 LLM 交互，旨在过滤有害内容、执行接地检查，并帮助阻止提示注入尝试。这些护栏作为 MCP 服务器层的生产控制运行，因此每个连接的智能体无论以何种方式连接，都能受益于相同的内容安全策略。Athena 查询工具强制仅执行 SELECT 查询，在工具层就拒绝写操作，使其无法到达数据湖。

知识库刷新层：通过单个 JSON 文件完成数据集接入

整个系统围绕配置驱动的可扩展性构建。添加新数据集需要一个描述表的元数据 JSON 文件和一个可选的上下文映射条目。该文件捕获表的 schema、业务上下文和列级语义。它作为单一事实来源，供 AI 智能体理解和查询数据集：

{
  "database_service_name": "athena",
  "database_name": "analytics_db",
  "table_name": "regional_order_summary",
  "business_description_for_the_table": "Regional order history with shipping status and delivery performance. Contains completed orders with delivery data. Refreshes daily. In Athena SQL, always use date() to wrap string literals when comparing against timestamp columns.",
  "column_details": {
    "order_id [varchar]": {
      "description": "Unique order identifier assigned at checkout.",
      "sample_values": ["ORD-20250115-001234", "ORD-20250116-005678"]
    },
    "order_date [timestamp(3)]": {
      "description": "Date and time the order was placed. Use this column for time-range filtering.",
      "sample_values": ["2025-01-15 08:00:00.000", "2025-01-16 12:30:00.000"]
    },
    "warehouse_id [varchar]": {
      "description": "Fulfillment center that processed the order.",
      "sample_values": ["FC-EAST-07", "FC-WEST-03", "FC-SOUTH-12"]
    }
  },
  "load_type": "Incremental (refreshes last 7 days)",
  "refresh_frequency": "Daily at 6:00 AM UTC",
  "table_size": "~2.1B rows",
  "creation_time": "2024-03-15",
  "last_refresh_time": "2025-05-20T06:00:00Z"
}

business_description_for_the_table 字段携带引擎特定的查询提示，例如“始终使用 date() 包裹字符串字面量”，以减少 SQL 验证失败。column_details 字段将每个 column_name [type] 与自然语言描述和示例值配对，使智能体同时具备 schema 感知和业务语义。sample_values 字段对于准确生成 WHERE 子句很重要，因为智能体会学习真实的数据模式，例如 warehouse_id 保存的是像 FC-EAST-07 这样的代码，而不是“East region facility”这样的完整名称。

该管道会拾取元数据文件，使用 Amazon Titan Text Embeddings 生成向量嵌入，并将它们索引到 Amazon Bedrock Knowledge Bases。一旦建立索引，该表就可被所有连接的智能体发现，无需手动重新索引或重启服务器。

为了提高特定应用的准确性，工程师可以选择将数据集与业务上下文关联。这会缩小搜索范围，使智能体优先选择正确的表。以下示例展示了一个上下文映射条目：

{
  "delivery_metrics": {
    "description": "Delivery accuracy and defect attribution data",
    "tables": ["analytics_db.customer_orders_summary"],
    "sources": {"wiki": [], "quip": []}
  }
}

如果未指定上下文，智能体会搜索所有已索引的表。上下文映射通过限制搜索空间来降低延迟并提高 SQL 准确性。此范围限定是可选的，可以随时添加，而无需修改元数据文件本身。

综合运用：实际执行一次查询

当用户问“我们上个月价值最高的 10 个订单是什么？”时，客户端会用业务上下文丰富请求以缩小范围。智能体将问题转换为向量嵌入，在元数据目录中搜索匹配的 schema，并通过一次轻量级 LLM 调用选择最相关的表。

利用选定的 schema、列描述和引擎特定的查询提示，智能体生成如下 SQL 语句：

SELECT order_id, customer_id, total_amount, order_date
FROM analytics_db.regional_order_summary
WHERE order_date >= date_add('month', -1, current_date)
ORDER BY total_amount DESC
LIMIT 10

SQL 会经过验证，并针对引擎兼容性进行自动纠正，然后在 Amazon Athena 上执行。智能体将结果格式化为自然语言响应，并流式返回给用户。在我们的测试中，这一端到端流程可在 15–20 秒内完成。

同样的编排能力不仅限于纯 SQL。由于文档搜索作为同一服务器上的另一个工具注册，智能体可以在单轮对话中回答同时涉及结构化和非结构化来源的问题，例如“我们第四季度的退货率是多少，产品团队的分析对根本原因是怎么说的？”对于该请求，智能体会运行 Athena 查询获取退货率数据，并通过 Knowledge Bases 文档搜索获取分析内容，然后将两者合并为一个响应。

安全与多租户访问

这种单轮编排之所以可行，是因为每次工具调用都经过同一个受控网关。该架构采用分层安全，而非单一执行点。MCP 服务器运行在内部 Application Load Balancer 之后的私有子网中，无法从互联网访问。只有位于面向公网的 Application Load Balancer（带 AWS WAF）之后的客户端层才能将请求路由到它。Amazon Cognito 在客户端层验证用户身份，只有经过身份验证、携带令牌的请求才会被转发到下游。在工具层面，Athena 查询工具强制仅执行 SELECT 查询，在写操作到达数据湖之前就将其拒绝。所有工具调用都会以结构化 JSON 记录到 Amazon CloudWatch，这为安全团队提供了一个跨所有智能体和应用的数据访问单一审计点。该架构可在提供 Amazon Bedrock 和 Amazon Bedrock Knowledge Bases 的 AWS 区域中使用。

这种集中式设计也正是该服务器支持多租户的原因。由于标准化的 /mcp 端点接受任何兼容 MCP 的客户端，无论其使用哪种 LLM 或编排框架，多个智能体可以共享相同的工具和相同的访问控制。添加新智能体只需将其指向服务器端点，因此接入另一个团队可以扩展系统，而不会削弱或重复安全模型。

无服务器基础设施与扩展

每一层都通过适合其工作负载模式的机制进行扩展：

Amazon ECS Fargate 提供无服务器计算，无需管理 EC2 实例。下游服务（Athena、Bedrock）自动扩展，因此系统无需更改配置即可处理单个查询或数百个并发查询。

用例与扩展

该架构支持除基础问答之外的多种模式。企业知识助手可以将数据湖查询与文档搜索相结合，回答同时涉及结构化数据和非结构化知识的复杂问题，例如“我们第四季度的退货率是多少，产品团队的分析对根本原因有何说法？”内部数据分析副驾驶让业务用户无需编写 SQL 即可通过对话方式查询数据湖，依靠元数据描述和查询提示引导智能体采用准确、高效的查询模式。

标准化的 /mcp 端点还支持多智能体工作流。用于数据分析、文档检索和运营告警的多个专用智能体可以共享同一个 MCP 服务器，每个智能体都通过通用协议访问完整的工具套件。新团队的数据接入遵循同样的配置驱动模式。他们添加一个元数据 JSON 文件，在一个管道同步周期内，其数据集即可被所有连接的智能体和应用程序发现。

结论

在 Amazon ECS Fargate 上部署的集中式 MCP 服务器为 AI 智能体与企业数据湖之间提供了可扩展且安全的网关。元数据驱动的方法消除了为每个数据集编写集成代码的需要，而 Model Context Protocol 标准意味着任何兼容 MCP 的客户端都可以连接，无需自定义适配器。

关键的架构决策是将工具层与智能体层分离。智能体快速演进，但数据访问模式应当比任何单一智能体实现更长久。将可扩展性视为配置问题而非代码问题，可以加速接入过程。

要了解更多信息，请参阅 AWS Fargate 上的 Amazon ECS、Amazon Bedrock、Amazon Bedrock Knowledge Bases 用户指南、Amazon Athena 以及 Model Context Protocol 规范。

后续步骤

我们正在两个方向上扩展该架构。第一，更细粒度的访问控制：表所有者可以将敏感列标记为按权限组限制，智能体会自动从生成的 SQL 中排除这些列，无需在提示层面做任何更改。

第二，闭合反馈回路：当查询失败或产生低置信度结果时，系统会捕获失败模式，并给出有针对性的建议，以改进列描述、添加查询提示。

关于作者

Aishwarya Pawar

Aishwarya 是 Amazon 的高级数据工程师，工作于生成式 AI 与企业数据的交汇处。她专注于将大型语言模型引入数据工作流，构建智能系统以自动化复杂分析，并让团队能够用自然语言与数据交互。她的工作重点是让强大的 AI 能力变得平易近人且可靠，使洞察不再局限于会写代码的人。她倡导这样一个未来：数据开放、直观，并随时为组织中的每个人驱动决策。

Sairam Vangapally

Sairam 是 Amazon 的高级数据工程师，在架构支撑北美关键物流运营的实时、大规模数据平台方面拥有丰富经验。他主导了端到端数据管道的设计与部署，实现了大规模的高吞吐数据摄取、转换与分析。他热衷于构建具备韧性的数据基础设施，并推动跨职能协作，以交付加速运营洞察与业务影响的解决方案。

Nitin Goyal

Nitin 担任 Amazon 分拣中心组织的数据工程经理，负责领导优化北美各设施运营效率的相关举措。他在 Amazon 拥有超过 10 年的任职经历，先后服务于多个团队，专长于架构高性能数据系统，尤其侧重于实时流式管道、人工智能和低延迟解决方案。他的专业能力推动了复杂运营工作流的开发，从而提升分拣中心的生产力与效能。