AI Agent的联邦数据访问：打破企业数据孤岛

当今企业数据分散在专用系统中，每个系统都有自己的工具和专业知识。查询数据库需要 SQL。访问 Amazon Simple Storage Service (Amazon S3) 上的批量数据需要 Amazon Athena 和 Trino 等计算引擎。消费来自 Amazon Kinesis 的实时流需要流处理专业知识。每个软件即服务 (SaaS) 应用都有自己的 API、认证模型和查询语言。如今，只有数据工程师才能驾驭这种环境，而业务用户则提交工单、等待报告，或依赖回答昨天问题的仪表板。当领导者需要跨多个系统的一次性答案时，他们又回到了工单队列。

考虑一家流媒体公司：客户档案、内容目录和广告活动效果作为批量数据存储在 Amazon S3 上。观看遥测数据（如设备类型、流质量、观看时长和缓冲事件）通过 Amazon Kinesis 实时流入。订阅者管理和支持工单存储在关系型客户关系管理 (CRM) 数据库中。领导者经常提出如下问题：

• 上个季度哪些内容推动了最多的订阅增长？
• 营销支出与观看完成率如何关联？
• 未参与新内容的用户中流失率是否在激增？

回答这些问题面临两个挑战：

数据孤岛问题。 数据存储在多个位置，包括 S3 上的批量存储、Kinesis 中的实时流，以及在线事务处理 (OLTP) 数据库，每个都有其各自的访问模式、查询语言和认证模型。组织传统上通过构建数据湖或采用数据网格来解决这个问题，但两者都需要大量的数据工程投资和持续的维护。

访问差距。 驾驭企业系统的专业知识集中在少数数据工程师手中，造成了瓶颈，任何仪表板或商业智能 (BI) 工具都无法完全解决。每一个新的一次性需求都意味着更多的工程工作，而且这不是自助式的。

一种根本不同的方法正在出现：不是将所有数据移动到一个地方，或为每个源构建定制集成，而是让 AI 代理直接与数据所在的系统对话。模型上下文协议 (MCP) 使这成为可能，这是一种开放协议，标准化了 AI 应用连接到外部数据源和工具的方式。MCP 服务器将多样化的系统封装在统一的接口后面，以便于工具发现、调用和响应处理。任何用户都可以用自然语言提问，代理无需知道哪个系统持有数据、使用什么 API 或需要什么查询语言，就能到达正确的数据。

在这篇博文中，我们提出了使用 MCP 和 Amazon Bedrock AgentCore 访问存储在不同系统和数据存储中的数据的参考架构。这些模式适用于具有混合数据源的企业，但我们以上述流媒体公司示例为基础来具体说明问题。

解决方案概述

我们的解决方案是流媒体公司的联邦数据基础。它使用 MCP 服务器和 Amazon Bedrock AgentCore 支持实时和批量分析，并使分析在整个组织中可访问。以下参考架构显示了从数据摄取到治理和计算层，再到生成式 AI 层（代理在此层跨 MCP 服务器编排）的完整视图。演示使用合成数据：批量数据集由 Python 脚本生成，流式遥测由 AWS Lambda 产生。完整的源代码可在随附的 GitHub 仓库中获得，因此您可以自行部署和试用。

图 1：跨批处理、流式和关系型源的联邦数据访问参考架构

演练

本节涵盖前提条件，然后逐步介绍用户请求如何端到端地流经参考架构。

前提条件

• 具有 Amazon Bedrock AgentCore 和其他 AWS 服务访问权限的 AWS 账户。有关更多信息，请参阅 AgentCore Runtime 的权限 文档。
• 已配置 AWS 命令行界面 (AWS CLI)
• 已安装 Python 3.10 或更高版本。
• 已安装 Docker 或 Finch。

请求流程

1. 用户请求： 用户通过由 Amazon CloudFront 提供服务的 React 应用提交自然语言问题，静态资产存储在 Amazon S3 上。
2. 身份验证： Amazon Cognito 对用户进行身份验证，并颁发身份令牌，该令牌随请求一起发送到代理层。
3. 代理编排： 请求到达运行在 AgentCore 运行时（Amazon Bedrock AgentCore 的一项功能）上的 Strands 代理。该代理对问题进行推理，并确定要查询哪些数据源。
4. 网关路由： Amazon Bedrock AgentCore Gateway（Amazon Bedrock AgentCore 的一项功能）将三个 MCP 服务器聚合在单个端点后面，处理工具发现、身份验证和路由。
5. MCP 服务器执行： 代理将查询路由到适当的 MCP 服务器，每个服务器都运行在 Amazon Bedrock AgentCore 运行时上，并在 Amazon Bedrock AgentCore Gateway 之后。数据处理 MCP 服务器查询 AWS Glue Data Catalog 和 Amazon Athena 以获取 S3 上的批处理和流式数据，Amazon Aurora MCP 服务器将工具调用转换为针对 Amazon Aurora MySQL CRM 数据库的 SQL，而 AWS 文档 MCP 服务器提供 AWS 服务上下文。
6. 数据源： 该架构特意跨多个存储系统，以反映企业数据通常如何跨团队和技术分散。批处理数据（客户档案、内容标题和广告活动）由 AWS Lambda 在 Amazon EventBridge计划并以 Parquet 文件的形式存放在 Amazon S3 上。流媒体观看遥测数据（用户观看内容、暂停时间、退出位置）通过 Amazon Kinesis Data Streams 和 Amazon Data Firehose 流入 S3。CRM 记录（订阅方案、支持工单、账户状态）存储在 Amazon Aurora MySQL 数据库中。AWS Glue Data Catalog将基于 S3 的数据源注册到统一的元数据层，AWS Lake Formation 在目录中强制执行细粒度的访问策略。批处理、流式和关系型数据源的混合使得联合访问至关重要。没有任何单个查询引擎能够原生访问所有数据集。
7. 响应：结果通过 Amazon Bedrock AgentCore Gateway 返回给代理，代理生成自然语言回答，并通过前端将其传递给用户。

要部署我们的参考架构，请按照代码仓库中的说明进行操作。

联合数据访问的设计模式

在我们的架构中，我们提出了三种联合数据访问的设计模式，每种模式在集中治理和直接访问灵活性之间取得平衡。

模式 1：目录优先访问

AWS Glue Data Catalog 将所有 S3 数据源注册到统一的元数据层：包括模式、业务上下文、数据质量指标和血缘关系。托管在 Amazon Bedrock AgentCore 运行时上的 AWS Data Processing MCP 服务器，将 AWS Glue Catalog 元数据和 Amazon Athena 查询功能封装为标准 MCP 工具调用。因此，当用户询问“上个季度哪些广告活动带来了最多的订阅者激活？”时，代理通过目录工具发现表，并从列元数据中解析业务术语。然后，它通过 Athena 执行连接操作，而无需直接调用任何 Glue API。

下图追踪了单个用户请求如何流经联合数据访问架构：从代理，通过 MCP 服务器，最终到达 Amazon S3 中的数据。

图 2：目录优先访问模式的请求流

在内部，使用 Strands Agent 框架构建的代理有三个组件：系统提示、大型语言模型（LLM）和一组 MCP 工具。我们使用由 Amazon Bedrock 提供支持的 Claude Haiku 4.5 作为基础 LLM，并通过 Amazon Bedrock AgentCore Gateway 发现工具。系统提示教会代理如何使用这些工具，不是通过列出每个表中的每列，而是通过提供基于意图的路由规则和强制性的模式发现工作流程。以下是系统提示的摘录：

TOOL DISCOVERY & ROUTING:

You access tools via the MCP Gateway. Use x_amz_bedrock_agentcore_search
to find the right tool by keyword when unsure.

Routing by intent:
- Telemetry/streaming/viewing data → Glue catalog tools, then Athena query tools
- CRM/support tickets/ratings → MySQL tools (run_query, get_table_schema)
- AWS service questions → documentation search tools

SCHEMA DISCOVERY (MANDATORY before writing SQL):

Before writing any Athena query, retrieve the table schema:
→ Use manage_aws_glue_tables with operation='get-table',
database_name='acme_telemetry', table_name='<table>'

This returns all columns, data types, partition keys, and storage details.

为了看到实际效果，考虑当用户询问“2026 年 2 月按事件类型划分的流式事件有多少？”时会发生什么：

1. 代理的路由规则将“流式事件”匹配到 AWS Glue Catalog 和 Athena 查询路径。如果不确定使用哪个工具，Gateway 的语义搜索通过关键词来发现工具，而无需精确的名称。
2. 代理调用由 Data Processing MCP 服务器公开的manage_aws_glue_tables来检索完整的模式：列名和类型、分区键（年、月、日、小时）以及存储格式。
3. 有了模式信息后，代理编写带有分区过滤器的 Presto/Trino SQL（WHERE year='2026' AND month='02'）。
4. 代理执行查询，检索结果，并生成自然语言回答。用户永远不会看到 SQL、Glue API 或分区策略。

这种先发现后查询的工作流程使该模式具有自助服务性。Amazon Bedrock AgentCore Gateway 提供统一的工具发现，当新的 MCP 服务器出现时无需更新路由逻辑。AWS Glue Data Catalog 提供实时元数据层，使新表和列立即可见。

这种模式并非 AWS 独有。其他平台也采用相同的模式。例如，Databricks 为 Unity Catalog 提供托管的 MCP 服务器，让代理能够发现并查询在 Unity Catalog 中注册的受治理数据集、AI 模型和函数。它们共同的权衡是：所有数据必须先编目，代理才能访问，这可能在快速变化的环境中成为瓶颈。

图 3：使用 AWS Glue Data Catalog 和 Amazon Athena 的目录优先访问

模式 2：直接源访问

代理通过专用的 MCP 服务器直接访问源系统（无中间目录）。托管在 Amazon Bedrock AgentCore 运行时上的 Aurora MCP 服务器直接查询 Amazon Aurora CRM 数据库。因此，像“高级订阅者有多少未解决的支持工单？”这样的问题会路由到 MCP 服务器，它将工具调用转换为针对 Aurora 的 SQL。代理从不构建数据库连接或管理凭据。MCP 服务器通过AWS Secrets Manager处理身份验证，并且只公开两个工具：run_query用于 SQL 执行和get_table_schema用于模式检查。

图 4：直接访问 Amazon Aurora CRM 数据库

在内部，与模式 1 相同的代理架构适用：系统提示、LLM 和一组 MCP 工具。我们使用由 Amazon Bedrock 提供支持的 Claude Haiku 4.5 作为基础 LLM，并通过 Amazon Bedrock AgentCore Gateway 发现工具。没有需要首先查询的目录层。系统提示提供轻量级的模式提示：表名和 WHERE 子句所需的关键枚举值，以便代理能够正确路由并编写有效的过滤器，而无需往返：

MYSQL CRM DATA (Aurora MySQL via RDS Data API):

Database: acme_crm

Tables:
- support_tickets: status (open|in_progress|resolved|closed),
  priority (low|medium|high|critical),
  category (billing|technical|content|account)
- content_ratings: rating (1-5), review_text

Use get_table_schema to verify full column details before complex queries.
Use run_query(sql='SELECT...') to execute. Default to read-only SELECT.
Use standard MySQL syntax (not Presto/Trino).

对于简单的查询，代理直接根据这些提示编写 SQL。对于复杂查询（如多表连接或不熟悉的列），代理调用get_table_schema，首先验证完整模式，镜像模式1中的“先发现后查询”纪律，但针对源数据库而非目录。要看到实际效果，考虑“按类别显示我打开的关键支持工单”：

1. 代理的路由规则将“支持工单”匹配到MySQL CRM路径，并调用run_query，使用SELECT针对support_tickets表，筛选条件为status='open'和和priority='critical'
2. Aurora MCP服务器通过RDS Data API将其转换为对Amazon Aurora的查询。
3. 结果通过AgentCore Gateway返回，代理组成格式化答案，包含工单数量、类别等。

直接访问模式以目录治理换取简单性。没有元数据注册步骤。MCP服务器按原样查询数据库，这意味着Aurora中的模式更改立即可见。这使其非常适合模式稳定且易于理解的操作数据库，以及为每张表编目会增加开销而不增加价值的情况。

今年早些时候，AWS MCP Server正式可用。它是Agent Toolkit for AWS的一部分，该工具套件包括MCP服务器、技能和插件，帮助编码代理在AWS上更有效、更高效地构建。该服务器不是公开一组固定的按服务工具，而是提供通用的AWS API访问：aws___run_script在沙盒环境中执行Python，具有AWS API的凭据访问权限，使用SigV4进行身份验证，并由您现有的AWS身份和访问管理（IAM）策略授权。因为这达到了大多数AWS API，您可以通过RDS Data API将代理连接到Aurora中的关系数据，或通过Kinesis Data Streams中的实时流数据，使用boto3调用，例如GetShardIterator和GetRecords。

模式3：混合访问

在实践中，大多数组织不会只选择一种模式，因为数据环境过于多样化。我们的流媒体公司正是如此：S3上的批处理和流式数据受益于目录优先治理（模式1），而Aurora CRM数据库更适合直接访问（模式2）。我们的参考架构在单个编排代理下结合了两种模式。受治理的源通过目录路由。操作源直接访问，两种路径在同一代理之后共存。关键见解：两种路径使用相同的协议。Amazon Bedrock AgentCore运行时托管MCP服务器，AgentCore Gateway处理工具发现、身份验证和路由。组织可以以适合其当前数据成熟度的任何模式开始，并在接入更多源时发展为统一访问。

验证部署

从堆栈输出访问CloudFront URL，使用测试用户凭据登录，并尝试以下查询：

查询1 – 客户分析可视化：

“按订阅类型构建客户分布图？”

代理查询Athena中的customers表，并生成柱状图和饼图，显示跨订阅层的分布。

图5：客户跨订阅层的分布

查询2 – CRM运营明细：

“按类别和优先级显示支持工单的明细。”

这完全路由到MySQL MCP服务器，查询Aurora CRM数据库中的工单分布，不会触及S3或Athena。

图6：支持工单按类别和优先级的明细

查询3 – 联邦跨源查询：

“评分最高的前五个标题是什么，它们有多少流媒体小时数？”

这需要代理查询Aurora中的content_ratings以获取评分，然后与Athena中的streaming_events和titles关联。

图7：评分最高的前五个标题及其流媒体小时数

注意事项

将上述架构模式部署到生产环境时，请考虑以下附加因素：

• 应用程序安全性：我们的架构模式使用Amazon Cognito进行身份访问和控制。但是，您应仔细审查代理与后端系统交互所使用的身份。
• 数据沿袭和访问控制：考虑使用AWS Lake Formation对代理AI应用程序中的数据资产进行数据治理、身份验证和授权。
• 代理的语义层：通过为代理提供正确的业务上下文并构建独立的语义层，可以提高代理响应质量。AWS最近宣布支持业务上下文和语义搜索。这可以帮助代理通过语义含义发现和理解数据，提高响应质量并避免幻觉和其他许多问题。

清理

为避免持续费用，请销毁两个AWS Cloud Development Kit (AWS CDK)堆栈（先代理堆栈，然后数据堆栈），并删除任何孤立资源，如Kinesis流和Amazon CloudWatch日志组。有关详细清理说明，请访问存储库的README。

结论

企业数据仍锁定在孤岛和访问鸿沟之后。每个一次性问题都要经过少数数据工程师之手，而洞察结果却过时了。MCP翻转了模型。不是集中数据或编写定制集成，而是部署MCP服务器，将每个源包装在标准化协议之后，让AI代理代表用户查询它们。无论您选择目录优先访问、直接访问，还是统一在单个代理之后的两种方式，代理都能处理复杂性，用户无需应对。添加新数据源意味着部署新的MCP服务器，而不是重新设计管道。

仍然存在开放问题，例如，跨代理组合输出的数据沿袭、当代理是主要数据消费者时的身份和授权问题，以及不仅捕获什么 代理访问了但为什么。这个领域正在快速发展：AWS Labs MCP 服务器，AWS MCP 文档，以及MCP 网关注册表。

部署参考架构，试验这些模式，并分享你所学到的经验。

致谢

我们感谢 Yadgiri Pottabathini 在测试该存储库方面所做的努力。