AtScale 与 Amazon Bedrock AgentCore 如何在 AWS 上构建智能体语义层

在本系列的第一篇文章中，我们使用 Stardog 的知识图谱，在 Amazon Aurora 和 Amazon Redshift 之上构建了 AWS 语义层。我们在 Amazon Bedrock AgentCore 上运行了一个 Strands 智能体，让它基于该语义层执行操作。第二篇文章沿用了相同的客户 360 (C360) 模式，改用 Denodo 的数据虚拟化平台，并将数据源扩展到包括一个本地 PostgreSQL 集群。本文再次采用相同的 C360 模式，并使用 AtScale 作为语义层。

AtScale 的实现方式与前两种不同。它的语义模型是维度模型（维度、层级和度量），而不是三元组图或视图集合。AtScale 使用语义建模语言（Semantic Modeling Language）编写模型。这是一种基于 YAML 的开放规范，并在 Git 中进行版本控制；它还能通过三种协议同时公开单个已部署模型：SQL、XML for Analysis (XMLA) 和模型上下文协议 (MCP)。Strands 智能体和企业现有的商业智能 (BI) 工具，都能根据相同定义获得相同的计算结果。

该模式的其余部分沿用前几篇文章的做法。Amazon Bedrock 上的基础模型（本示例采用 Anthropic Claude Sonnet 4.6）负责规划并编写查询。Amazon Bedrock AgentCore 托管 Strands 智能体，并管理智能体向 AtScale 提供的出站凭证。适用于调用方的联接、指标定义以及行和列筛选器都位于语义层中，而非提示词中。

我们假设你已了解本系列第一篇文章介绍的语义层架构：什么是语义层、它的用途，以及为什么模型会规划查询而不负责管理联接。如果这些内容对你来说是新的，第一篇文章会对此进行介绍。

读完本文后，你将了解：

如何使用语义建模语言 (SML) 对 C360 领域建模：数据集、维度和层级、事实、度量、计算度量和视角，并在 Git 中进行版本控制。
AtScale 如何针对 Amazon Redshift 规划维度查询，以及 AtScale 的自动聚合管理如何加速智能体生成的查询模式。
如何通过 AtScale MCP 服务器向托管在 AgentCore 上的 Strands 智能体公开模型，以及如何将该 MCP 服务器注册到 AgentCore Gateway。AgentCore Gateway 是 Amazon Bedrock AgentCore 的一项功能。
用户身份如何从企业身份提供商，经由 AgentCore Identity，（Amazon Bedrock AgentCore 的一项功能）传递到 AtScale；以及 AtScale 如何在查询时实施基于角色的访问控制 (RBAC)、行级安全和视角。
如何使用 AtScale Helm chart 和 AtScale K8S Blueprints 存储库，在 Amazon Elastic Kubernetes Service (Amazon EKS) 上部署 AtScale。

本示例的事实依据是 AtScale C2026.7 版本。如涉及具体工具名称或端点，我们会引用 AtScale 文档。

示例：基于 Amazon Redshift 的客户 360

前两篇文章中的 customer 360 模式保持不变。零售企业的客户记录、订单、产品和奖励计划注册信息分散在各个系统中，而业务用户希望提出跨领域问题，无需了解每条信息存储在哪个系统中。我们为系列首篇文章改编的 Stardog C360 Knowledge Kit 通过 Customer、Order、Product 和 Address 实体对这一场景进行建模，这些实体通过整数 cid 关联；该整数在 customer 表中是主键，在 purchase 表中则是普通列。

本文与前两篇文章的不同之处在于数据实际存放的位置。Stardog 和 Denodo 会在查询时跨两个引擎进行联合查询。AtScale 会将维度查询规划为原生数据仓库 SQL，并针对每个查询将其下推至一个引擎，因此跨引擎数据会在上游进行整合。在本演示中，所有分析用 C360 数据都存放在 Amazon Redshift Serverless 中。Amazon Aurora PostgreSQL 仍是运营系统的事实来源，并通过复制路径（AWS Database Migration Service 或 Amazon Aurora zero-ETL to Amazon Redshift）保持分析副本为最新状态。代理会查询一个映射到 Amazon Redshift 表的 AtScale 模型。

Amazon Redshift 中的架构：

表	关键列
customer	cid (PK), first_name, last_name, email, ssn, phone, location
address	id (PK), city, state, zip, street_name
credit_card	id (PK), cid, card_num, card_type
rewards_account	id (PK), cid, account_id, create_date
purchase	id (PK), pid, purchase_date, quantity, price, cid, card
product	id (PK), name, brand, price, dept
category	id (PK), dept_name, parent
vendor	id (PK), vendor_name, industry

八个表中有九个值得关注的列。cid 将客户记录与购买记录关联起来。pid 将购买记录与产品关联起来。dept 将产品与类别关联起来。所有分析数据都位于 Amazon Redshift 中，因此联接会下推为原生 SQL，而不是在语义层或提取、转换和加载 (ETL) 管道中进行解析。

一个能够检验整个模型的典型问题是：按终身消费额排名前 20 的客户中，哪些人尚未注册奖励计划？这是 Denodo 文章中的自动注册问题，本文沿用这一问题，让跟随本系列阅读的读者看到同一个请求如何由不同的语义层作答。它涉及客户资料、地址、购买历史和注册状态：跨四个逻辑实体，为每位客户返回一行。

本文使用的 AtScale 术语

AtScale 在数据仓库之上以维度模型的形式实现语义层。AtScale 文档和 SML 规范使用了一组特定的基本概念，本文会反复提到。进入演示之前，先简要介绍这些概念会有所帮助。

语义建模语言 (SML) – 一种基于 YAML 的开放规范，用于描述语义模型。每个 SML 对象（模型、数据集、维度、层级、度量、计算、视角、行级安全）都是一个 YAML 文件。该规范位于 github.com/semanticdatalayer/SML。
模型 – 顶层构件。模型引用数据集、维度、事实和度量，并通过 AtScale 查询引擎将它们开放出来。
维度和层级 – 维度将相关属性（客户、产品、日期）分组。维度中的层级将这些属性组织成不同级别（产品 → 类别 → 部门，或年 → 季度 → 月 → 日）。
事实和度量 – 事实是一个数据集，其中包含可度量事件，并通过键列与维度关联。度量是从事实列聚合得出的数量，例如用于表示收入的 SUM(price * quantity)。
计算 – 以其他度量为基础，通过公式表示的派生度量。
视角 – 向特定角色或群组公开的、可发布的模型子集。AtScale 通过视角控制调用方可以查看哪些维度和度量。
行级安全 – 一种模型对象，可根据调用方的身份或属性筛选返回给调用方的行。
自主聚合管理 – AtScale 会监控各使用方的查询模式，并在某种模式的开销高到足以证明创建汇总表合理时，在数据仓库中具体化该表。后续匹配该模式的查询会透明地路由到聚合表。
Design Center – AtScale 的创作界面。建模人员可通过可视化画布或文本编辑器编辑 SML。无论采用哪种方式，磁盘上的构件都是 Git 中的 SML YAML。
AtScale MCP 服务器 – 产品内的 MCP 端点，位于 <atscale-host>/mcp，可向任何 MCP 客户端公开语义模型。

如需了解更多详情，请参阅AtScale 文档和SML 规范，它们是权威参考资料。

参考架构

运行时分为入站路径和出站路径，其结构与 Stardog 和 Denodo 相关博文中的架构相同。

入站。客户端通过 AgentCore Gateway 将用户的问题发送给 Strands 代理。Gateway 会向企业身份提供商（IdP）验证用于标识人类用户的 JSON Web Token（JWT），然后将请求路由到AgentCore 运行时（Amazon Bedrock AgentCore 的一项功能），由其承载代理进程。代理调用 Amazon Bedrock 上的 Claude Sonnet 4.6，以解读提示并规划查询。

出站。代理决定查询语义模型时，会向 AtScale MCP 服务器发起工具调用。AgentCore Gateway 充当出站代理：AtScale MCP 服务器在 Gateway 上注册为 MCP 目标，因此工具调用会经由 Gateway 路由，AgentCore Identity 会在该跳注入凭证。AtScale 的 MCP 端点接受承载令牌（适用于开发和单一身份场景），或由 AtScale 捆绑的 Keycloak 实例签发的 OAuth 2.0 访问令牌（生产环境路径）。AtScale 引擎会验证令牌，将调用方解析为一个 AtScale 角色，并根据已部署的 C360 模型规划查询。

查询请求沿 AtScale 引擎向下传递，结果则向上传回。没有用于预先具体化跨数据库联接的 ETL 作业。Amazon Redshift 中的分析副本是语义模型的真实数据源，并通过上游复制路径与 Aurora 保持同步。

图 1：客户端、Amazon Bedrock AgentCore 组件、AtScale MCP 服务器、AtScale 引擎和 Amazon Redshift Serverless 之间的入站身份验证路径和出站查询路径

该架构在身份验证方面有意采用明确的设计。Gateway 和 Identity 在运行时边缘保存令牌。智能体看不到这些令牌，只负责协调对话和工具调用。

构建语义层

AtScale 的语义模型由一组 SML 对象（数据集、维度、事实、度量、计算、视角、行级安全）构成，并在 Git 中进行版本管理。工作模型的结构是数据工程师熟悉的星型模式，但每个对象都以 YAML 而非数据定义语言（DDL）表示，且每个对象都是一个独立文件。构建 C360 模型分为三个阶段：基于 Amazon Redshift 表创建数据集；创建维度和层次结构，并定义它们之间的联接；创建表达业务逻辑的度量和计算。

数据集。每个 Amazon Redshift 表都会成为一个 SML 数据集。数据集声明 AtScale 将展示的物理连接、架构、表和列。数据集可以在 Design Center 中以可视化方式创建，也可以直接编辑 YAML。无论使用哪种方式，写入 Git 的都是同一个 SML 文件。

维度和层次结构。C360 模型包含七个维度。dim_customer保存客户资料属性，并通过位置键与dim_address联接，通过cid与dim_rewards联接。dim_product保存产品属性，并通过dim_category将它们组织成层次结构。dim_date支持基于日期的分析。dim_vendor按供应商对产品分组。dim_rewards为每位已注册客户保存一行，其中包含account_id和create_date；它以雪花模式扩展自dim_customer，因此从未注册的客户在注册属性中会显示为 null。

AtScale 的层次结构原语简洁地表达了产品与类别之间的关系。针对该模型的查询可以遍历product → category → parent category，无需使用递归 SQL 公用表表达式；大型语言模型（LLM）看到的是一条维度路径，而不是联接图。

产品层次结构的代表性 SML 片段：

# dim_product.yml
unique_name: dim_product
object_type: dimension
label: Product
hierarchies:
  - unique_name: product_category
    label: Product Category
    levels:
      - unique_name: department
        dataset: category
        key_columns: [dept_name]
      - unique_name: category
        dataset: category
        key_columns: [id]
      - unique_name: product
        dataset: product
        key_columns: [id]
secondary_attributes:
  - unique_name: brand
  - unique_name: product_name
    key_column: name

事实和度量。C360 的事实表是fact_purchase，映射到 Amazon Redshift 购买表。它通过cid与dim_customer联接，通过pid与dim_product联接，并通过purchase_date与dim_date联接。度量基于事实表定义：total_revenue作为SUM(price * quantity)，order_count作为COUNT(id)，units_sold作为SUM(quantity)。

计算度量。业务逻辑保存在模型中，而不是查询中。customer_lifetime_value是total_revenue，在客户粒度上计算；同一公式也适用于事实表中粒度更粗的切片。像big_spender和spend_tier这样的细分属于带有条件表达式的计算度量：

# big_spender.yml
unique_name: big_spender
object_type: metric
expression: |
  CASE WHEN SUM(price * quantity) > 10000
  THEN 'Yes' ELSE 'No' END

该表达式在查询时计算。列只能在某个粒度上保存一个结果；表达式则会根据查询所请求的切片重新计算，无论是按客户、按客户和年份，还是按地区。当定义发生变化（阈值从 $10,000 调整为 $15,000）时，只需更新一个 YAML 文件，经由拉取请求审核后，通过 AtScale CI 钩子部署。每个使用方都会在下一次查询时获取新定义，无论使用方是智能体、通过 XMLA 访问的 Excel，还是通过多维表达式（MDX）访问的 Tableau。

图 2：AtScale Design Center 中的 C360 模型。dim_customer、dim_address、dim_rewards、包含产品到类别层次结构的 dim_product、dim_date、dim_vendor，以及由橙色连线连接的 fact_purchase；橙色连线表示维度与事实之间的关系以及雪花关系。计算度量（customer_lifetime_value、big_spender、spend_tier）显示为独立节点，并从事实表引用

图 3：同一模型以 SML YAML 并列呈现，每个维度、度量和计算各对应一个文件，并在 Git 仓库中进行版本管理

图 3 右侧的产物不是模型的描述。它就是模型。Design Center 的可视化画布和 YAML 编辑器是同一文件的两种视图，而 Git diff 则是每项更改的权威记录。这些文件符合开源 SML 规范，因此无需借助引擎即可读取仓库。

部署后，可同时通过 SQL（供基于 JDBC 的 BI 工具和笔记本使用）、XMLA（供 Excel 和 Power BI 使用）以及 MCP（供智能体使用）访问该模型。total_revenue 计算返回给 Claude Sonnet 4.6 的数值，与指向同一 XMLA 端点的 Excel PivotTable 返回的数值相同。我们会在 Verification 中确认两者匹配。

AtScale 如何规划并下推查询

当智能体针对语义模型提出问题时，由 AtScale 的 AI Computation Engine（ACE）负责规划。无论是来自 MCP run_query 工具的维度 SQL 请求，还是来自 Excel 的 XMLA 请求，查询经历的步骤都相同。只有最前端的解析器不同。

以自动注册问题为例：按终身消费额排名前 20 的客户中，哪些尚未注册奖励计划？智能体根据 describe_model 返回的模型上下文提示，针对 C360 模型编写维度 SQL 查询。ACE 将该查询解析为逻辑计划，把维度引用解析为底层的 fact_purchase、dim_customer、dim_address 和 dim_rewards 数据集，应用调用方所受的任何行级安全策略，然后针对 Amazon Redshift 规划物理查询。

在物理规划阶段，有两件事让 AtScale 有别于手写管道。首先，连接操作会作为原生 SQL 连接下推到 Amazon Redshift，而不是在语义层中实体化。Amazon Redshift 优化器会看到一条带有筛选和聚合操作的 SQL 语句，并据此执行。其次，AtScale 的聚合管理器会检查其注册表，查找与查询模式匹配的预建聚合。如果存在一张按适当粒度对客户购买情况进行分组的汇总表，AtScale 就会重写查询，使其命中该聚合，而不是扫描 fact_purchase。查询返回所需的时间仅为直接查询原始事实表所需时间的一小部分，无需智能体或建模人员手动进行路由。

图 4：智能体的维度查询进入 AtScale 规划器。规划器检查其聚合注册表，找到与查询模式匹配的聚合，将查询重写为命中 Amazon Redshift 中的汇总表，然后返回结果。下方路径展示了在没有匹配聚合时，相同的查询直接命中 fact_purchase

聚合管理器让智能体驱动的工作负载在经济上可行。LLM 驱动的分析发起的查询数量超过人工分析师，而诸如 告诉我一些关于我们销售情况的有趣发现 这样的开放式提示可能会触发十多个查询。AtScale 会监控查询模式，在数据仓库本身中（而非单独的缓存中）实体化聚合，并透明地路由匹配的查询。聚合的创建由所有使用方的实际流量决定，而不仅仅是智能体。

查询审计记录会同时捕获 LLM 编写的维度 SQL 和 AtScale 将其改写成的数仓原生 SQL，以及是否有聚合数据为该查询提供服务。操作员可以通过 Design Center 中的 AtScale 查询页面查看该记录；后续的治理部分将以此为基础。

关于多源与互操作性的说明

AtScale 通过 JDBC 连接数仓。C360 演示以 Amazon Redshift Serverless 为目标。同一个 SML 模型也适用于 Snowflake、Databricks 和 Google BigQuery，AtScale 为每种数仓都记录了连接方式。更换连接时，变化的是 AtScale 输出的 SQL 方言，而不是 Git 中的 SML。

有一项架构特性值得明确说明，因为它与本系列前两篇文章不同。单个 AtScale 查询会在一个数仓引擎中解析。如果 C360 模型跨越两个数仓（例如，维度位于 Snowflake，事实数据位于 Amazon Redshift），那么同时涉及两者的查询必须通过以下两种方式之一进行协调。第一种是在上游通过复制流程，将分析数据副本整合到一个数仓中。第二种是由数仓自身处理，利用引擎级联邦查询，例如使用 Amazon Redshift Spectrum 查询 Amazon Simple Storage Service (Amazon S3)，或使用两个引擎都能读取的 Apache Iceberg 表。AtScale 会规划维度查询，并将其推送到一个引擎。跨引擎的处理则位于更底层。

这种选择有利有弊。它无法实现 Stardog 和 Denodo 在查询时执行的实时跨引擎联邦查询，但能让 AtScale 的规划器和聚合管理器基于单引擎执行模型运行，这正是聚合能力能够在大规模场景中发挥关键作用的原因。已经采用以数仓为中心的分析架构、并通过变更数据捕获 (CDC) 管道连接运营系统的企业，可以复用现有架构。需要跨引擎实时联邦查询才能获得答案的企业，则更适合使用前两篇文章介绍的语义层。

受治理的访问：身份传递与运行时强制执行

Customer 360 数据受到监管。部分用户（人力资源、欺诈管理）需要查看社会安全号码、卡号等个人身份信息。大多数用户（营销、分析）则不得查看。行级筛选器会按地理区域限制分析人员的访问，并且必须保留从用户浏览器一直到数仓的逐用户审计记录。

AtScale 会在语义层强制执行这些要求，确保查询尚未到达数仓时就已生效。无论调用方是通过 MCP 访问 Strands agent、通过 XMLA 使用 Excel 的分析人员，还是通过 JDBC 使用笔记本，执行方式都完全一致。SML 中的一个行级安全对象、一个视角和一组角色绑定，会应用于每个模型使用方。

从用户到 AtScale 的身份传递

这一链路与 Denodo 文章中的链路结构相同，只是最后一跳到达 AtScale 引擎，而不是继续到数仓。

用户通过企业 IdP 向应用进行身份验证，并获得 JWT。
应用将 JWT 作为承载令牌，通过 AgentCore Gateway 转发给 Strands agent；AgentCore Gateway 会验证令牌（颁发者、受众、签名），并将请求路由到 AgentCore 运行时。
当智能体调用 AtScale MCP 服务器的工具时，AgentCore Identity 会提供由 AtScale 随附的 Keycloak 签发、映射到人类用户身份的 OAuth 2.0 访问令牌。AtScale 凭证不会进入智能体代码。
AtScale MCP 服务器接受 OAuth 令牌。AtScale 引擎会通过 Keycloak 验证令牌，将调用方解析为 AtScale 角色，并在应用调用方的行级安全约束和透视绑定后规划查询。数据仓库使用来自 AWS Secrets Manager 的 AtScale 连接身份进行访问。

图 5：从人类用户到 AgentCore Gateway、AgentCore 运行时、AgentCore Identity、AtScale MCP 服务器和 AtScale 引擎的身份链，最终到达语义层强制执行点。数据仓库这一步使用带有 AtScale 凭证的服务账户连接

RBAC、行级安全和透视

AtScale 将访问控制表达为三种可组合的基本机制。RBAC 根据 Keycloak 声明为调用方分配角色。行级安全是一种模型对象，会根据调用方的身份或属性筛选返回给调用方的行。透视是可发布的模型子集，面向特定角色或组开放。

在 C360 演示中，我们定义两个角色。

hr_user：可以查看完整的 C360 模型，包括 ssn 和 card_num。
marketing_user：可以查看 Marketing 透视；该透视在模型层隐藏 ssn 和 card_num。

当 marketing_user 提出引用 ssn 的问题时，智能体的 describe_model 调用会返回 Marketing 透视，而该透视不包含 ssn。智能体没有可供投影的属性。行级筛选也以相同方式组合：一个按州限定客户范围的 SML 行级安全对象，会将调用方限制在特定的一组行内，而无需对智能体的提示进行任何更改。

审计可追溯性

通过 AtScale 引擎执行的查询会记录调用方身份、模型、LLM 生成的维度 SQL、AtScale 转换后的下推 SQL（Amazon Redshift 实际接收的 SQL）、应用的安全策略、是否由聚合结果提供查询，以及返回的行数。由于记录同时包含模型编写的查询和数据仓库执行的查询，审计人员可以从人工提出的问题一路追溯到生成结果的 SQL。本系列的第一篇和第二篇文章都没有在同一条记录中同时捕获这两种查询形式。

受治理查询的审计记录如下所示：

{
  "timestamp": "2026-08-31T10:34:56Z",
  "user_identity": "mary_major@example.com",
  "user_role": "marketing_user",
  "semantic_model": "Customer_360",
  "question": "Top 10 customers by revenue in California",
  "generated_sql": "SELECT full_name, total_revenue FROM ...",
  "translated_pushdown_sql": "SELECT ... FROM redshift ...",
  "security_policies_applied": ["regional_row_security"],
  "served_from": "aggregate",
  "execution_time_ms": 850,
  "rows_returned": 10
}

generated_sql 和 translated_pushdown_sql 字段使审计链条完整：审计人员可以同时看到 LLM 针对语义模型编写的查询，以及数据仓库实际运行的查询。

通过 AtScale MCP 服务器公开该层

AtScale MCP 服务器是 AtScale 发行版的一个组件，公开于 <atscale-host>/mcp。它已在 AtScale C2026.7 版本中正式推出，并使用标准的模型上下文协议。任何兼容 MCP 的客户端（AgentCore 运行时中的 Strands 智能体、Claude、ChatGPT、Cursor、VS Code）都可以连接到同一端点，并访问同一个已部署模型。

该服务器提供一组用于查询语义模型的工具。AtScale 文档会按版本发布工具参考。对于智能体驱动的工作负载，重要的工具包括：

list_models：列出调用方可见的模型，以及用于说明维度如何映射到事实的列组。
describe_model：返回所选模型的维度、层级、度量、计算和业务描述。这是智能体开始编写查询前加载到系统提示中的负载。
search_columns：对模型的列进行关键词搜索。当完整的 describe_model 负载会占用过多 LLM 上下文窗口时，这种方式很有用。
validate_query：检查维度 SQL 语句是否与模型兼容，而不在数据仓库中执行。这样智能体可以低成本地反复调整查询，再执行任何会产生 Amazon Redshift 费用的操作。
run_query：针对模型执行维度 SQL 语句并返回行。
run_queries：批量运行多条语句，适用于开放式提示；此时智能体会并行执行多条探索性查询。
get_version：报告 MCP 服务器版本，以便客户端决定是否缓存模型架构。

AtScale MCP 端点支持两种身份验证模式。Bearer 令牌方式使用从 Design Center 生成的 API 令牌。每个请求都以令牌所有者的身份运行，适用于概念验证或单一身份服务。OAuth 2.0方式使用 AtScale 捆绑的 Keycloak，以及一个预先配置的客户端，其 ID 恰好为 atscale-mcp，相关文档见 AtScale 的使用 Claude 进行连接页面。AgentCore Gateway 代表智能体提供访问令牌，AtScale 引擎通过 Keycloak 验证该令牌，下游策略评估则使用人类用户的身份。

将 AtScale MCP 服务器注册为 AgentCore Gateway 目标，遵循标准的 Gateway MCP 目标流程。前文列出的工具会作为普通工具呈现给智能体，凭证则由 AgentCore Identity 在 Gateway 跳转环节处理。

侧边栏：通过 AI 辅助建模扩展模型

AtScale MCP 服务器提供的工具专注于查询；AtScale 还在扩展 MCP 接口，加入面向模型作者的工具，使智能体能够检查数据仓库架构、根据源元数据生成候选 SML 模型、依据规范验证 SML，并将结果提交到 Git。这种由智能体塑造语义模型而不只是读取模型的模式，非常适合 Claude Code 和 Cursor 工作流。在这些工作流中，数据工程师与 LLM 协作，为新数据集快速搭建模型。

AtScale 将这一方向归纳为三项能力。语义发现引擎会扫描数据仓库架构、查询历史记录和数据血缘，以推断候选联接、层级和指标定义。模型推荐系统会根据观察到的查询模式，建议维度、度量和关系。受治理的反馈循环会在 SML-and-Git 工作流中保留对 AI 建议的人工审核，因此变更都有版本记录且可审计。

发布时可用的具体工具记录在 AtScale MCP 工具参考中。请查看最新发布说明，了解哪些功能已正式发布，哪些仍处于预览阶段。本文其余部分介绍使用者路径，即智能体查询已部署模型；这是当前生产级 C360 工作流所依赖的方式。

部署并运行智能体

Strands Agents 是一个用于构建智能体的小型框架。简短的 Python 入口点将 Amazon Bedrock 上的 Claude Sonnet 4.6 连接到 AtScale MCP 服务器，将其作为工具源。AgentCore runtime 承载该进程。AgentCore Gateway 终止入站请求，并通过 AgentCore Identity 保存出站 AtScale 凭证。Amazon Bedrock 上的基础模型可用性因 AWS 区域而异。当前列表请参阅按模型划分的区域可用性。

系统提示至关重要。AtScale 文档和 AtScale 语料库中的参考演示始终建议智能体采用三步调用模式：先调用 list_models 查看可用内容，然后针对目标模型调用 describe_model，将维度和度量加载到上下文中，最后才调用 run_query（如果查询需要大量迭代，也可以先调用 validate_query）。其理由是，LLM 不应捏造列名或指标名称，而应仅引用 describe_model 返回的内容。系统提示应明确说明这一点，并简要介绍目标模型中的业务术语（total_revenue 指销售额，而非数量），以便智能体将用户的问题映射到正确的度量。

为系统提示中重复使用的部分启用 Amazon Bedrock 提示缓存。describe_model 负载有数千个 token，并且在同一模型版本内不会变化，因此启用缓存后，重复调用的每次查询输入 token 成本都会降低。缓存点配置是 BedrockModel 对象上的一个请求参数。当前参数名称请参阅 Strands 文档。

验证

为了确认语义层、智能体和身份流程按预期工作，我们通过智能体运行了三个查询，然后在不同角色下对其中一个查询进行了治理重跑。正常部署中应能复现以下行为。

查询 1，单一维度

列出我们在 Wisconsin 的客户及其所在城市。

智能体会针对 C360 模型生成维度 SQL 查询，从 dim_customer 和 dim_address 中选择 first_name、last_name 和 city，条件为 state = 'WI'。AtScale 的规划器会将维度路径解析到 Amazon Redshift 中的 customer 和 address 表，向下推送一条 SQL 语句，并返回相应行。

查询 2，带聚合命中的聚合查询

按售出数量列出我们的前 10 款产品。

智能体按产品汇总 units_sold 并按降序排列。AtScale 的聚合管理器会找到匹配的按需定义的聚合，并重写查询，使其命中 Amazon Redshift 中的汇总表，而不是扫描 fact_purchase。Queries 页面会并排显示 LLM 生成的维度 SQL 和路由到聚合的数仓 SQL。

查询 3，跨域查询

按生命周期消费金额排名前 20 的客户中，哪些人尚未加入奖励计划？

智能体会生成一个连接 dim_customer、dim_address、dim_rewards 和 fact_purchase 的查询，并按客户汇总 customer_lifetime_value。查询会筛选 dim_rewards.account_id 为空的客户。通过在 cid 上左连接 dim_customer，可以保留从未加入奖励计划的客户；这些客户会显示为空的加入记录。智能体会返回生命周期消费金额最高的前 20 位客户。AtScale 的规划器会将这些连接解析为针对 Amazon Redshift 的原生 SQL，并返回排名列表。LLM 无需自行编造 customer_lifetime_value 公式。该公式是在 customer_lifetime_value.yml 中定义一次的计算度量，并在查询中按名称引用。

治理重跑

我们以两个不同的调用方身份运行 Query 1 的一个变体，并在投影中添加 ssn（显示我们在威斯康星州的客户及其 SSN）。作为 hr_user，describe_model 会返回完整的 C360 模型，智能体据此编写查询，结果集包含 SSN 值。作为 marketing_user，describe_model 会返回 Marketing 视角，其中不公开 ssn。智能体没有可供投影的属性，因此返回的答案不包含 SSN。两次运行之间唯一的变化是调用方的身份。查询文本、智能体代码、MCP 服务器、AtScale 引擎和 Amazon Redshift 均未发生变化。

跨使用方验证

我们通过 AtScale XMLA 端点在 Excel 中打开同一个 C360 模型，并将 Customer.State 和 Total Revenue 拖到数据透视表中。各州的汇总值与智能体针对等效问题返回的结果完全一致，精确到个位数。

跨数据源扩展

向 C360 模型添加新数据源是建模工作，而非集成工作。假设客户支持团队要求将工单量纳入模型，以便智能体回答过去 30 天内，我们的哪些高消费客户提交过支持工单？步骤如下：

按照与运营表相同的复制模式，将支持工单数据载入 Amazon Redshift，与其他 C360 表放在一起。
添加一个 SML 数据集，将新表映射到逻辑对象。
添加或扩展一个维度（dim_ticket），并添加与 dim_customer 的连接，连接条件为 cid。
添加模型所需的任何新度量（open_ticket_count、avg_resolution_time）。
提交 SML 更改，通过拉取请求进行审核，并通过 AtScale CI 钩子部署。

智能体代码和 AgentCore 配置均无需更改。智能体下次调用 describe_model 时，就会看到新的维度和度量，并能据此编写查询。相同的模式也适用于其他数据仓库。如果数据源载入的是 Snowflake 或 Databricks，而非 Amazon Redshift，那么只需添加一个连接到 Snowflake 或 Databricks 的 SML 数据集；查询会在相应引擎中解析，如前文的多数据源说明所述。

部署：在 Amazon EKS 上运行 AtScale

AtScale 运行于 Kubernetes 上，AWS 上的参考部署平台是 Amazon EKS。AtScale 在 oci://docker.io/atscaleinc/atscale 提供官方 Helm 图表，而 AtScale K8S Blueprints 存储库提供基础设施即代码（IaC）脚手架，用于搭建 EKS 集群及 AtScale 所需的组件：入口控制器、用于 AtScale 元数据库的持久化存储、用于查询缓存的 Redis 实例，以及配置为支持身份联合的 AtScale Keycloak 实例。

AtScale 在 EKS 上的部署由一组规模不大的 Kubernetes Pod 组成。atscale-engine 是核心查询规划器和执行器。atscale-mcp-server 是智能体调用的 MCP 端点。atscale-keycloak 是内置身份提供方，可与 Amazon Cognito、Okta、Azure Active Directory 及其他符合 OpenID Connect（OIDC）标准的 IdP 建立身份联合。支持性 Pod 负责处理 SML API 和 Design Center UI（atscale-sml-api、atscale-sml-web）、PostgreSQL 元数据存储（atscale-db）、查询缓存（atscale-redis）和入口流量（atscale-ingress，通常由 AWS Network Load Balancer 提供前置服务）。

C360 应用（聊天 UI 或调用智能体的客户端库）可以在同一个 EKS 集群的独立命名空间中运行。它使用服务账户的 IAM 角色（IRSA）访问 Bedrock，并使用 AWS Secrets Manager，无需嵌入凭证。

网络连接是标准配置：AtScale 通过虚拟私有云 (VPC) 端点或安全组规则连接 Amazon Redshift，该规则允许 AtScale 命名空间向 Amazon Redshift 发起出站流量；人类用户则通过入口负载均衡器访问应用程序。

除了自行管理的 EKS，AtScale 还提供其他云部署选项。请查看 AtScale 网站，了解当前产品和 AWS 可用情况。本文其余部分假设采用前文所述的自行管理模式。

结论

要实现对企业数据的代理式访问，需要三项功能协同工作：能够规划并生成查询的基础模型、能够基于实时数据仓库计算受治理且具有业务意义的答案的语义层，以及用于托管代理并管理身份流的运行时。Amazon Bedrock、AtScale 和 Amazon Bedrock AgentCore 分别承担其中一项职责。

代理与语义层交互，而不直接访问数据仓库。维度、层级、度量、视角和行级安全规则都保存在 Git 中的 SML 内。当架构发生变化或治理规则变更时，只需更新一个文件，各个使用方（代理、Excel、Tableau、Power BI）便会在下次查询时获取更新。

从何开始

大多数成功实现这一方案的团队，都是从小范围着手，再逐步扩展。

选择一个涉及两个或三个数据源、且目前回答起来耗时过长的工作流程。
编写 3–5 个该工作流程需要回答的问题。这些就是语义层从第一天起必须支持的查询。
使用 AWS Database Migration Service 或 Amazon Aurora 零 ETL，将运营数据整合到 Amazon Redshift（或你选择的数据仓库）中。
在 Design Center 中根据数据仓库架构引导生成 SML，然后根据能力问题进行完善。
使用 AtScale Helm chart 和 AtScale K8S Blueprints 在 Amazon EKS 上部署 AtScale，将 AtScale MCP 服务器注册为 AgentCore Gateway 目标，并通过它接入 Strands 代理。

作者简介

Frank Lapolito

Frank 是 AtScale 的解决方案工程师，帮助组织简化数据架构，并将技术复杂性转化为业务价值。

JP Boreddy

JP 是 AWS 的高级解决方案架构师，与企业客户合作，提供云架构、数据和 AI 工作负载方面的支持。

Sindhu Jambunathan

Sindhu 是 AWS 的高级解决方案架构师，拥有 13 年以上经验，帮助 ISV 客户构建可扩展、安全且经济高效的数据和生成式 AI 解决方案。加入 AWS 之前，她曾任 Microsoft 高级软件工程师，并拥有佛罗里达大学计算机工程硕士学位。

Sahil Thapar

Sahil 是 AWS 的首席解决方案架构师，负责与 ISV 客户合作，在 AWS 云上构建高可用、可扩展且具有弹性的应用程序。他专注于容器、机器学习和生成式 AI，帮助企业设计生产级解决方案。