AWS 上为 Agentic AI 构建数据基础：从湖仓到 MCP

构建一个为智能体 AI 做好准备的数据基础，正成为部署 AWS 的组织的一项优先事项。这一基础依赖于统一的湖仓以及像模型上下文协议（MCP）这样的互操作性协议。你可以从原型走向生产。然而，许多团队仍然难以知道从哪里开始。

根据Gartner的说法，到 2027 年，超过 40% 的智能体 AI 项目将因未能交付预期价值而被取消。虽然 Gartner 指出了若干促成因素，但我们认为根本原因归结为两点：缺乏治理和数据不一致。

如果你正在为 AI 智能体构建数据平台，你可能已经认识到四个障碍。你的数据分散在各个孤岛中。你的非结构化数据虽然可用，但难以使用。你的智能体和你的系统缺乏一种共同的通信方式。质量和治理方面的缺口削弱了信任并导致幻觉。

每个障碍都会阻碍智能体 AI。要消除这些障碍，需要从整体上重新思考你的数据基础，而不是一次修复一条管道。

在本文中，我们将带你了解在 AWS 上构建一个为智能体 AI 做好准备的数据基础的四大支柱。

支柱 1：使用零 ETL 构建统一的湖仓

基础始于你的数据存放在哪里以及你如何查询它。

超越数据湖和数据仓库：湖仓作为你的基础

每个数据平台都介于两种方法之间。数据湖提供灵活的存储、开放格式，以及以低成本保存在 Amazon Simple Storage Service（Amazon S3） 上的原始数据，这适合数据科学和 AI 工作负载。然而，这种灵活性往往伴随着薄弱的治理。数据仓库提供原生 ACID 事务、高性能 SQL 和强大的治理，但在处理不断增长的数据量或非结构化数据时变得僵化。

Amazon SageMaker Lakehouse 结合了这两种方法，而无需进行完整迁移。你的运营、分析和 AI 数据都存放在同一个地方。Amazon S3 Tables 是 Amazon S3 的一项能力，提供原生的、开源的 Apache Iceberg 支持。你可以从 Spark、Amazon Athena、Amazon EMR 或 Amazon Redshift 进行读写。

智能体 AI 所需的三大湖仓能力

为智能体构建的湖仓需要三项能力。零 ETL 摄取消除了管理管道的需要。联合目录为你提供跨 S3、Amazon Redshift、Snowflake 或 Databricks 的表的统一视图。借助查询联合，你可以在不复制数据的情况下查询多个数据源。

SELECT customer_id, sentiment_score FROM s3tables.sales_db.orders WHERE order_date > '2024-01-01';

为湖仓提供数据的原生零 ETL 集成

AWS Glue 连接器引入运营数据源，如 Amazon Aurora、Amazon DynamoDB 和 Amazon Relational Database Service（Amazon RDS）。它们还支持 SaaS 数据源，包括 Salesforce、ServiceNow 和 SAP。流式数据源包括 Amazon Managed Streaming for Apache Kafka（Amazon MSK）和 Amazon Kinesis。原始数据和向量嵌入都落在同一受治理的基础中，为下一个支柱做好准备：上下文工程。

图 1：Amazon SageMaker Lakehouse 通过零 ETL 摄取和联合目录统一数据

支柱 2：为高性能 AI 智能体进行上下文工程

湖仓使数据可访问，但智能体还需要经过整理的相关上下文才能有效地对其采取行动。大语言模型（LLM）仍然是无状态的，具有有限的上下文窗口。向智能体输入过多数据往往会适得其反。关于长上下文模型的研究发现了一种“迷失在中间”效应，即放置在远离提示开头或结尾位置的信息实际上会被忽略（Liu 等，2023）。上下文工程通过一个基于三个组件构建的上下文管理器来应对这一挑战：知识库、会话状态与历史，以及数据工具。

图 2：基于知识库、会话状态与历史，以及数据工具构建的上下文管理器

对于知识库，AWS 提供多种向量存储选项，包括 Amazon OpenSearch、Amazon Aurora PostgreSQL 和 Amazon Neptune。Amazon S3 Vectors 是 Amazon S3 的一项能力，它之所以突出，是因为原始数据和索引嵌入都位于同一受治理的湖仓基础中。这意味着智能体和商业智能工具消费相同的可信来源，而无需复制数据或管理单独的系统。

以下片段是说明该流程的示例伪代码。请查阅 Amazon Bedrock Knowledge Bases API 参考以获取确切的参数名称和模型标识符。

# Illustrative pseudocode: parameter names are simplified
bedrock_agent.create_knowledge_base(
    name="customer-context-kb",
    vector_store_configuration={
        "s3VectorsConfiguration": {
            "vectorBucketArn": "arn:aws:s3vectors:::my-vector-bucket"
        }
    },
    embedding_model_arn="arn:aws:bedrock:::foundation-model/amazon.titan-embed-text-v2"
)

静态知识只解决了一半的问题。智能体记忆通过两个层级跨会话保留动态上下文。短期记忆保存原始会话历史。长期记忆存储向量化记录。

Amazon Bedrock AgentCore 记忆是 Amazon Bedrock AgentCore 的一项能力，它通过提取模块自动化这一过程。该模块在原始事件中识别关键术语，例如客户名称或项目，并将它们写入长期存储以供重用。其结果包括个性化、对话连续性以及更少的幻觉。

数据工具补全了上下文管理器。智能体不是接收提示中的所有内容，而是调用工具仅获取它所需的经过整理的数据，例如 SQL 查询的结果。这些能力在智能体开始相互通信以及与你的系统通信之前就做好了准备。MCP 是我们下一个支柱的主题，它规范了这种工具访问。

图 3：Amazon Bedrock AgentCore 记忆从原始事件中提取关键术语到短期和长期记忆

支柱 3：使用 MCP 和开放协议实现多智能体互操作性

在智能体能够检索到正确的上下文之后，下一个挑战是协作，既包括智能体之间的协作，也包括与现有系统的协作。多智能体辩论技术，即让模型相互审查并纠正彼此的输出，与单一模型相比有助于提高可靠性（Du 等，2023）。有两种开放协议可满足这一需求。Agent2Agent（A2A）负责智能体之间的通信。Model Context Protocol（MCP）将智能体连接到你的系统。

使用开放协议进行智能体之间的通信

借助 A2A，智能体通过标准 HTTP 和 JSON 进行协作，无需共享内存或建立直接连接。它支持长时间运行的任务。一个负责处理耗时视频处理作业的智能体可以在处理过程中报告进度，而编排器则决定是等待还是重新分配该任务。每个智能体都会发布一张智能体卡片，描述其能力、输入和输出。流行的开源智能体编排框架可以在委派工作之前查询这张卡片。

使用 MCP 将智能体世界连接到你的系统

MCP 通过三个组件标准化了智能体访问你的数据和工具的方式。资源（Resources）暴露只读数据。工具（Tools）执行诸如 SQL 查询之类的操作。提示（Prompts）提供可复用的指令。

Amazon Bedrock AgentCore Gateway是 Amazon Bedrock AgentCore 的一项能力，它集中管理这种访问。它可以连接到 AWS Lambda 函数、API，或像 Salesforce 这样的 SaaS 集成。它还在同一处强制执行身份验证和审计日志记录。

语义搜索与工具发现

随着你的网关不断扩展，智能体可能会被可用工具所淹没。AgentCore Gateway 通过语义搜索解决了这一问题：智能体以自然语言进行查询，网关则根据 AWS Identity and Access Management（IAM）策略，仅返回相关的、权限范围内的工具。

支柱 4：用于信任与合规的数据和 AI 治理

智能体现在通过 MCP 进行通信和操作，因此它们所依赖的数据必须值得信赖。治理已成为你真正的差异化优势。基础模型（FM）已广泛可用，因此你的数据以及你管理数据的方式才是让你的智能体脱颖而出的关键。Amazon SageMaker Data Catalog 通过三项能力满足这一需求：发现、治理和协作。

大多数企业数据仍是非结构化的，且元数据不完整。该目录会为每个数据集自动生成摘要、词汇表、数据血缘和质量指标。这让用户在将智能体连接到数据之前对数据充满信心。

治理遵循发布-订阅模式。生产者发布数据集，消费者按其需求范围订阅访问权限，可通过完全访问、行级过滤或列级过滤实现。

这些工作流通过 IAM 运行并暴露 API，因此团队可以自动化审批流程，而无需手动管理访问请求。

Amazon SageMaker Unified Studio将生产者、分析师和数据科学家带入一个共享环境。内置的生成式 AI 助手可将自然语言请求转换为 SQL、Python 或可视化单元格，队友可以立即运行。这将数据探索转变为共享、可审计的笔记本，而不是彼此割裂的脚本。

这四大支柱（湖仓、上下文工程、互操作性和治理）共同构成了一个可在企业规模上构建的基础。你可以在 AWS Summit Paris 的录播会议视频中找到完整的技术讲解。

图 4：湖仓、上下文工程、互操作性和治理作为智能体 AI 数据基础的四大支柱

结论

在本文中，我们概述了一个在 AWS 上构建 AI 就绪数据基础的四支柱框架，其设计围绕互联的能力，而非零散修补的各个管道。Amazon SageMaker Lakehouse 解决了碎片化和数据孤岛障碍。它通过 S3 Tables 和原生 Apache Iceberg 支持，将运营数据、分析数据和 AI 数据整合到一个受治理的基础中。使用 Amazon S3 Vectors 和 Amazon Bedrock AgentCore 内存进行上下文工程，可应对第二个障碍：技术上可访问但无法使用的非结构化数据。它将你统一的数据转化为智能体可以据以行动的知识和持久记忆，而不是使上下文窗口过载。

在智能体获得正确的上下文之后，MCP 和 Amazon Bedrock AgentCore Gateway 可应对互操作性障碍。它们为智能体提供了一种安全、集中的方式来访问你的工具和系统。随着网关不断扩展，语义搜索使工具发现保持可控。最后，Amazon SageMaker Data Catalog 弥合了侵蚀信任并可能引入幻觉的治理缺口。其发现、发布-订阅式访问和血缘能力为你提供了智能体 AI 投入生产运行所需的可追溯性。

如果你要踏上这段旅程，顺序很重要。首先要正确搭建你的湖仓和零 ETL 摄取，因为每一个下游支柱都依赖于拥有单一、受治理的事实来源。然后在扩展到多智能体编排之前投入上下文工程。会产生幻觉或丢失会话上下文的智能体，在开始通过 A2A 或 MCP 相互通信后只会使错误不断累积。

从第一天起就将治理作为一条并行轨道，而不是最后的检查点。列级和行级访问控制在早期构建比后期改造要容易得多。

这些支柱同样适用于媒体个性化、客户服务自动化和欺诈检测管道等工作负载。在每一种场景中，多个智能体都需要共享一致、可信的企业数据视图。

如需深入了解，请观看 AWS Summit Paris 的录播会议视频 以获取完整的技术讲解。你还可以查阅 Amazon SageMaker Lakehouse 文档和 Amazon Bedrock AgentCore 文档 以了解实施细节。