AWS 物流团队：新增数据集只需一个 JSON 文件，AI Agent 自动发现无需重新部署

企业 AI Agent 需要访问数据湖时，最常见的做法是每个 Agent 各自嵌入 SQL 生成逻辑、表结构知识和连接处理。数据集一旦变化，每个 Agent 都要单独修补；权限散落在各处，没有统一的审计点；接入一张新表通常需要数天的定制开发。AWS 支持北美分拣中心（NASC）网络的工程团队在数千个数据集和多个团队各自构建 AI 助手的现实压力下，选择了另一条路：把数据访问能力集中到一个无状态的 MCP 服务器中，让 Agent 只负责推理和编排，不再关心底层数据如何接入。

这个服务器的核心设计决策是把工具层从 Agent 层中剥离出来。Agent 演化很快，但数据访问模式应该比任何单一 Agent 实现活得更久。具体做法是：每张表对应一个 JSON 元数据文件，记录数据库服务名、表名、业务描述、列级语义（包括类型、自然语言说明和样本值）、加载类型和刷新频率。这个文件被管道拾取后，用 Amazon Titan Text Embeddings 生成向量嵌入，索引到 Amazon Bedrock Knowledge Bases。一旦索引完成，所有已连接的 Agent 都能发现并查询这张表，不需要手动重建索引或重启服务器。

元数据文件里有一个容易忽略但实际关键的字段：business_description_for_the_table。它不只写表的业务含义，还携带引擎特定的查询提示。比如文中示例写道

In Athena SQL, always use date() to wrap string literals when comparing against timestamp columns.

这类提示直接减少了 SQL 生成后的校验失败次数。列级样本值同样重要——Agent 看到 warehouse_id 的样本值是 FC-EAST-07 而非East region facility，生成的 WHERE 子句就会用正确的格式。

架构分为四层，各自独立伸缩：客户端层处理认证和会话状态（Amazon Cognito 验证 JWT，DynamoDB 存储对话历史），MCP 服务器层做查询分析、工具选择和结果编排（FastMCP 框架，Amazon Bedrock 驱动），工具层对接 Athena 和 Redshift 执行 SQL、对接 Knowledge Bases 做语义检索，知识库刷新层负责元数据文件的发现和索引。Fargate 任务是无状态的，会话状态持久化在 DynamoDB 中，所以任务可以随时替换或扩缩而不丢失上下文。

团队还引入了一个可选的上下文映射机制：为特定应用指定它应该关注哪些表。当上下文限定了表范围，MCP 服务器在元数据目录中只搜索这些表，减少噪声、提高 SQL 生成准确率，同时把端到端延迟控制在他们自测的 15 到 20 秒范围内。没有指定上下文时，Agent 搜索所有已索引的表。

安全控制分层实施：MCP 服务器运行在私有子网，不直接暴露于互联网；只有客户端层通过带有 AWS WAF 的公网负载均衡器可以路由请求到它。Athena 查询工具在工具层面强制 SELECT-only，写操作在到达数据湖之前就被拒绝。所有工具调用以结构化 JSON 记录到 Amazon CloudWatch，给安全团队一个跨所有 Agent 和应用的统一审计点。

这套模式的可迁移认识是：当你的 Agent 数量和数据集数量同时增长时，把接入新数据从代码问题变成配置问题，能显著降低边际成本。但它的适用边界同样明确——整个实现深度绑定 AWS 服务栈（ECS Fargate、Athena、Bedrock、DynamoDB），元数据文件的准确性依赖人工维护，描述漂移或过期时的自动处理机制在文中被列为未来计划而非已实现，15 到 20 秒的延迟是团队自测结果而非独立基准。