基于 Amazon ECS Fargate 的无服务器 MCP 服务器：让 AI Agent 访问数据湖
构建人工智能（AI）应用的组织面临一个反复出现的挑战：如何让大语言模型（LLM）代理访问企业数据湖，同时不必在每个代理和应用中重复实现集成逻辑。多数团队一开始会把代理直接连到数据库和 API，中间没有类似模型上下文协议（MCP）服务器这样的共享网关。每新增一个数据集就要写一套自定义代码，每个代理也各自实现访问控制。随着数据集或代理数量增长，权限执行逐渐走样，接入一个新数据源往往要花好几天工程时间。我们团队支持 Amazon 北美分拣中心（NASC）网络，那里的规划团队依赖运营数据来管理产能、劳动力和包裹流转。为了让这些团队能用对话方式查询数据，我们在 Amazon Elastic Container Service（Amazon ECS）上配合 AWS Fargate 构建了一个无服务器的模型上下文协议（MCP）服务器，专门解决 NASC 规划团队的这个问题。这个服务器充当 AI 代理与企业数据湖之间的集中式网关，不绑定特定代理。要开放一个新数据集，只需提供一个 JSON 元数据文件，服务器会在下一次流水线同步时自动发现它。本文将介绍整体架构，说明这种元数据驱动的做法如何省去为每个数据集单独写集成代码，并解释这套无服务器基础设施如何在多租户环境中支撑多个代理和应用。
问题与设计目标
设计这套系统时，有两个相互关联的挑战决定了我们的思路：数据访问方式碎片化，以及难以为继的接入模式。
规模化带来的集成难题
我们的数据湖包含数千个数据集，覆盖运营指标、业务分析和领域专属数据。多个团队都想要能对话式查询这些数据的 AI 助手，但每个团队都从零开始搭建自己的集成。每个代理都内嵌了自己的 SQL 生成逻辑、模式知识和连接处理，因此一旦模式发生变化，就得逐个修补所有代理。访问控制也是分散的，数据访问决策没有统一的审计点。
接入一个新数据集，需要编写定制工具代码、做查询校验、再重新部署，每张表通常要花好几天。
设计目标
我们定下四项要求：
- 配置驱动的数据湖访问。新增数据集只需一个元数据文件，不用写代码。
- 与 Agent 无关的工具接口。任何兼容 MCP 的客户端都能调用同一套工具。
- 集中式权限管控。访问控制统一在 MCP 服务器层强制执行。
- 弹性基础设施。系统能随 AI 负载的突发波动伸缩。
方案总览
架构把职责拆成四层：客户端、MCP 服务器、工具、知识库刷新。每层都能独立伸缩、独立部署。工具层之下是一份元数据目录，存放 schema 描述、列级语义和表间关系，AI Agent 生成 SQL 时会参考这些内容。因为 Agent 在查询时从目录里取 schema 知识，所以不用把表结构硬编码，schema 变了也不用重新部署。知识库刷新层负责让目录保持最新，新数据集的元数据一到就建立索引。下面逐层展开。
架构详解
下图展示了从用户查询到数据层、贯穿全部四层的请求流程。
用户在客户端应用（网页聊天、Slack、IDE 插件或外部 Agent）里提交查询。请求先经 Amazon Route 53 做 DNS 解析，到达公有子网中的应用负载均衡器，该负载均衡器配置了 HTTPS 和 AWS WAF。负载均衡器把请求交给 Amazon Cognito，由它验证用户身份并补充请求信息。通过认证的流量随后进入私有子网，客户端层运行在 Amazon ECS Fargate 上。这一层用 Amazon DynamoDB 保存会话状态，再通过内部应用负载均衡器把请求转发到 MCP 服务器层——同样跑在 Amazon ECS Fargate 上。
在 MCP 服务器层，由 Amazon Bedrock 驱动的 AI Agent 负责编排工具，这些工具用 FastMCP（一个构建 MCP 服务器的 Python 框架）编写。每次模型交互都会套用 Amazon Bedrock Guardrails。
右侧的数据层承载工具后端。Amazon Athena 和 Amazon Redshift 对数据湖执行 SQL 查询，Amazon Bedrock Knowledge Bases（全托管的检索增强生成 RAG 能力）负责语义搜索。数据写入 Amazon S3 和知识库的过程由 AWS Lambda 处理。下面各节会逐一展开每一层的细节。图 1：请求经过无服务器 MCP 服务器的流转路径，从客户端应用一直到数据层
MCP 客户端层：认证与会话管理
请求从客户端应用出发，先经 Amazon Route 53 做 DNS 解析，再到达配置了 HTTPS 和 AWS WAF 的应用负载均衡器（Application Load Balancer）。负载均衡器把流量转发给 Amazon ECS Fargate 上的客户端服务。该服务集成 Amazon Cognito 做 JWT（JSON Web Token）认证，并用 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 server 会把元数据目录的搜索范围收窄到这些表，从而减少干扰、提高 SQL 生成的准确率。要新增一个业务领域，只需在这份映射里加一条记录。
MCP server 层：无状态执行，会话状态外置
MCP server 运行在自己独立的 ECS Fargate 集群上，与客户端层隔离。请求经由 Amazon Route 53 和位于私有子网的内部 Application Load Balancer（应用负载均衡器）到达这里。服务器负责完整的编排流程，包括查询分析、工具选择、执行和响应生成。通过 MCP 协议端点（/mcp）——一个由 FastMCP 驱动的 JSON-RPC 接口——外部兼容 MCP 的客户端（例如 Amazon Q Developer 或各类 IDE 扩展）可以直接发现并调用工具。
Fargate 任务本身是无状态的，会话状态保存在 DynamoDB 中，因此任务可以被替换或扩缩容而不会丢数据。请求到来时，agent 会取出会话历史，用 Amazon Bedrock 分析用户意图，发现并调用合适的工具，再把结果流式返回给用户。
工具层：由元数据驱动的数据湖访问
每个工具都用 FastMCP 注册，运行时即可被发现：
| 序号 | 工具 | 后端 | 用途 |
|---|---|---|---|
| 1 | SQL 查询工具 | Amazon Athena、Amazon Redshift | 对数据湖中任意已配置的数据集以及 Redshift 执行 SQL 查询 |
| 2 | 文档与元数据搜索 | Amazon Bedrock Knowledge Bases | 对内部文档、表元数据和团队 wiki 做语义搜索 |
| 3 | 策略搜索 | Amazon Bedrock Knowledge Bases | 检索运维策略和标准流程 |
Athena 查询工具是与数据湖交互的主要入口。agent 先查询元数据目录，弄清有哪些可用的 schema，再通过 Amazon Bedrock 生成优化后的 SQL 查询，校验并按 Athena 的兼容性要求自动纠错，然后执行。结果回到负责编排的 agent，由它组织成自然语言回答。
负责任的 AI 管控
所有与大语言模型（LLM）的交互都会经过 Amazon Bedrock Guardrails，用于过滤有害内容、执行事实依据校验（grounding check），并帮助拦截提示词注入攻击。
这些防护栏在 MCP 服务器层作为生产环境的控制手段运行，因此无论智能体以何种方式连接，都能受益于同一套内容安全策略。Athena 查询工具强制仅允许 SELECT 查询，写操作在工具层就被拦截，根本到不了数据湖。
知识库刷新层：一个 JSON 文件即可接入数据集
整个系统围绕配置驱动的扩展能力构建。新增数据集只需一个描述表的元数据 JSON 文件，外加一条可选的上下文映射条目。该文件记录表结构、业务上下文和列级语义，是 AI 智能体理解和查询数据集的唯一事实来源：
"database_service_name": "athena",
"database_name": "analytics_db",
"table_name": "regional_order_summary",
"business_description_for_the_table": "区域订单历史，包含配送状态和履约表现。只记录已完成订单及其配送数据。每日刷新。在 Athena SQL 中比较时间戳列时，务必用 date() 包住字符串字面量。",
"column_details": {
"order_id [varchar]": {
"description": "结账时分配的唯一订单标识。",
"sample_values": ["ORD-20250115-001234", "ORD-20250116-005678"]
},
"order_date [timestamp(3)]": {
"description": "下单的日期和时间。按时间范围筛选时用这一列。",
"sample_values": ["2025-01-15 08:00:00.000", "2025-01-16 12:30:00.000"]
},
"warehouse_id [varchar]": {
"description": "处理该订单的履约中心。",
"sample_values": ["FC-EAST-07", "FC-WEST-03", "FC-SOUTH-12"]
}
},
"load_type": "增量加载（刷新最近 7 天数据）",
"refresh_frequency": "每天 UTC 6:00",
"table_size": "约 21 亿行",
"creation_time": "2024-03-15",
"last_refresh_time": "2025-05-20T06:00:00Z"
`business_description_for_the_table` 字段存放特定引擎的查询提示，例如“始终用 date() 包裹字符串字面量”，用来减少 SQL 校验失败。`column_details` 字段把每个“列名 [类型]”与自然语言描述和示例值配对，让智能体既能理解表结构，也能读懂业务含义。`sample_values` 字段对生成准确的 WHERE 条件很关键，因为智能体能从示例值里学到真实的数据模式——比如 `warehouse_id` 存的是 `FC-EAST-07` 这类编码，而不是“East region facility”这种展开的名称。流水线会读取元数据文件，用 Amazon Titan Text Embeddings 生成向量嵌入，再索引到 Amazon Bedrock Knowledge Bases。索引完成后，所有接入的智能体都能发现这张表，无需手动重建索引或重启服务器。如果某个应用需要更高准确率，工程师还可以选择把数据集关联到业务上下文。这样搜索范围会收窄，智能体就能优先命中正确的表。下面是一个上下文映射的示例：
```json
{
"delivery_metrics": {
"description": "Delivery accuracy and defect attribution data",
"tables": ["analytics_db.customer_orders_summary"],
"sources": {"wiki": [], "quip": []}
}
}
不指定上下文时，智能体会搜索所有已索引的表。上下文映射通过限制搜索空间来降低延迟、提升 SQL 准确率。这个范围限定是可选的，随时可以添加，不需要改动元数据文件本身。
串起来看：一次实际查询
用户问：“上个月金额最高的 10 笔订单是哪些？”客户端会给请求附加业务上下文，缩小搜索范围。智能体先把问题转成向量嵌入，在元数据目录中搜索匹配的 schema，再通过一次轻量的大模型调用选出最相关的表。拿到选中的 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 上执行。Agent 把结果整理成自然语言回复，流式返回给用户。在我们的测试中，整个端到端流程 15–20 秒内完成。
同一套编排机制远不止用于 SQL。文档搜索同样注册为这台服务器上的一个工具，因此 agent 能在单轮对话中回答同时涉及结构化与非结构化数据的问题，例如“我们 Q4 的退货率是多少，产品团队对根本原因的分析又是怎么说的？”针对这个请求，agent 会跑一次 Athena 查询拿退货率数据，再到 Knowledge Bases 里做一次文档搜索拿分析内容，最后把两者合并成一个回答。
安全与多租户访问
这种单轮编排之所以能成立，关键在于每次工具调用都要经过同一个受控网关。架构采用分层防护，而不是只设一个关卡。
MCP 服务器跑在私有子网中，前面是内部 Application Load Balancer，公网访问不到。只有客户端层能向它转发请求，而客户端层位于带 AWS WAF 的公网 Application Load Balancer 之后。Amazon Cognito 在客户端层校验用户身份，只有带 token 且通过认证的请求才会向下游转发。
在工具层面，Athena 查询工具强制只允许 SELECT 查询，写操作在到达数据湖之前就会被拒绝。所有工具调用都会以结构化 JSON 记录到 Amazon CloudWatch，安全团队由此获得一个统一审计点，覆盖每个 agent、每个应用的数据访问。
该架构已在提供 Amazon Bedrock 和 Amazon Bedrock Knowledge Bases 的 AWS 区域上线。
这种集中式设计也让服务器具备多租户能力。标准化的 /mcp 端点接受任何兼容 MCP 的客户端，不管它用的是哪种 LLM 或编排框架，因此多个 agent 可以共享同一套工具和同一套访问控制。
新增一个 agent 只需要把它的地址指向服务器端点，因此接入新团队只是扩展系统，既不会削弱现有安全模型，也不会重复搭建一套。
无服务器架构与弹性伸缩
每一层都按照自身的工作负载特点独立伸缩：
| 层级 | 伸缩机制 | 触发条件 |
|---|---|---|
| 客户端（ECS Fargate） | ECS 服务自动伸缩 | CPU 利用率（50% 阈值） |
| MCP 服务器（ECS Fargate） | ECS 服务自动伸缩 | CPU/内存利用率 |
| Athena Serverless | 自动伸缩 | 查询并发数 |
| Amazon Bedrock | 托管服务自动伸缩 | 推理请求量 |
Amazon ECS Fargate 提供无服务器计算，不需要管理任何 EC2 实例。下游的 Athena 和 Bedrock 都会自动伸缩，因此不管是单条查询还是几百条并发查询，系统都能处理，无需改动任何配置。
使用场景与扩展方向
除了基础问答，这套架构还能支撑多种用法。
企业知识助手可以把数据湖查询和文档检索结合起来，回答同时涉及结构化数据和非结构化知识的复杂问题。比如：“我们 Q4 的退货率是多少？产品团队对根本原因的分析怎么说？”
内部数据分析副驾驶让业务人员用对话方式查询数据湖，不用写 SQL。agent 依靠元数据描述和查询提示，找到准确且高效的查询方式。
标准化的 /mcp 端点还支持多 agent 协作。数据分析、文档检索、运维告警等各司其职的 agent 可以共用同一个 MCP 服务器，通过统一协议访问完整的工具集。
新团队接入数据也遵循同样的配置驱动模式：添加一个元数据 JSON 文件，一个流水线同步周期之内，他们数据集就能被所有已连接的 agent 和应用发现。
结语
在 Amazon ECS Fargate 上部署一个集中式 MCP 服务器，相当于在 AI agent 和企业数据湖之间架起一个可扩展、安全可靠的网关。
这种元数据驱动的做法省掉了为每个数据集单独编写集成代码的工作，而 Model Context Protocol 标准意味着任何兼容 MCP 的客户端都能直接接入，不需要定制适配器。架构上的关键决策，是把工具层和智能体层分开。智能体迭代很快，但数据访问方式应该比任何单个智能体的实现活得更久。把可扩展性当成配置问题、而不是代码问题，能大大加快接入速度。更多内容可参阅 Amazon ECS on AWS Fargate、Amazon Bedrock、Amazon Bedrock Knowledge Bases 用户指南、Amazon Athena 以及 Model Context Protocol 规范。
后续计划
我们正从两个方向扩展这套架构。
第一，更细粒度的访问控制。表的所有者可以把敏感列标记为对某个权限组受限，智能体在生成 SQL 时会自动排除这些列，无需改动提示词。
第二，打通反馈闭环。当查询失败或返回低置信度结果时，系统会记录失败模式，并给出有针对性的改进建议，比如改进列描述、补充查询提示。
关于作者
Aishwarya Pawar
Aishwarya 是 Amazon 的资深数据工程师，工作处在生成式 AI 与企业数据的交汇点。她专注于把大语言模型（LLM）引入数据工作流，打造能自动完成复杂分析的智能系统，让团队用自然语言就能和自己的数据对话。她的目标是让强大的 AI 能力变得易用、可靠，让洞察不再只属于会写代码的人。她所倡导的未来是：数据开放、直观，能随时为组织中的每个人提供决策支撑。
Sairam Vangapally
Sairam 是 Amazon 的资深数据工程师，在构建支撑北美关键物流业务的实时大规模数据平台方面经验丰富。他曾主导端到端数据管道的设计与部署，实现大规模的高吞吐数据摄取、转换与分析。
他热衷于构建有韧性的数据基础设施，并推动跨团队协作，交付能加快运营洞察、带来业务价值的解决方案。
Nitin Goyal
Nitin 在亚马逊分拣中心（Sort Center）组织担任数据工程经理，负责牵头优化北美各站点的运营效率。他在亚马逊任职超过 10 年，先后服务于多个团队，专长是设计高性能数据系统，尤其侧重实时流式管道、人工智能和低延迟方案。凭借这些专长，他推动了复杂运营工作流的开发，提升了分拣中心的生产效率与运营效果。
本文将介绍如何在 Amazon ECS 上结合 AWS Fargate 构建无服务器的模型上下文协议（Model Context Protocol，MCP）服务器，让 AI 智能体以安全、元数据驱动的方式访问企业数据湖。接入新的数据集时，只需提供一个 JSON 文件，无需为每个数据集单独编写集成代码。