用 AtScale 和 Amazon Bedrock AgentCore 在 AWS 上为智能体 AI 构建语义层

在本系列第一篇文章中，我们使用 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）和 Model Context Protocol（MCP）。Strands 智能体与企业已经在使用的商业智能（BI）工具，都基于相同的定义获得相同的计算结果。

该模式其余部分沿用自之前的文章。Amazon Bedrock 上的基础模型（演练中使用 Anthropic Claude Sonnet 4.6）负责规划和编写查询。Amazon Bedrock AgentCore 托管 Strands 智能体，并管理智能体提交给 AtScale 的出站凭证。适用于调用方的联接、度量定义以及行级和列级过滤都保存在语义层内部，而不是提示词中。

我们假设你已熟悉本系列第一篇文章中的语义层架构：什么是语义层、语义层的用途，以及为什么模型要规划查询而不拥有联接。如果其中有任何新内容，第一篇文章已经涵盖。

读完本文后，你将了解：

如何使用语义建模语言（SML）对 C360 领域建模：数据集、维度和层次结构、事实、度量、计算度量以及透视图（perspective），并通过 Git 进行版本管理。
AtScale 如何针对 Amazon Redshift 规划维度查询，以及 AtScale 的自主聚合管理如何加速智能体生成的查询模式。
如何通过 AtScale MCP 服务器将模型暴露给由 AgentCore 托管的 Strands 智能体，以及如何将该 MCP 服务器注册到 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

前两篇文章中的客户 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）保持分析副本的实时更新。智能体查询的是单一的 AtScale 模型，该模型映射到 Amazon Redshift 表。

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。
模型（Model）– 顶层工件。一个模型引用数据集、维度、事实和指标，并通过 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 runtime（Amazon Bedrock AgentCore 的一项能力），后者承载智能体进程。智能体调用 Amazon Bedrock 上的 Claude Sonnet 4.6 来解释提示并规划查询。

出站。当智能体决定查询语义模型时，它会发起对 AtScale MCP 服务器的工具调用。AgentCore Gateway 充当出站代理：AtScale MCP 服务器被注册为 Gateway 上的一个 MCP 目标，因此工具调用经由 Gateway 路由，AgentCore Identity 在该跳注入凭据。AtScale 的 MCP 端点接受 bearer token（用于开发和单身份场景）或由 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 数据集。数据集声明物理连接、模式（schema）、表以及 AtScale 将呈现的列。数据集可以在 Design Center 中以可视化方式创建，也可以直接作为 YAML 编辑。两种方式都会将相同的 SML 文件写入 Git。

维度和层级。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 数据透视表的数值完全一致。我们将在“验证”部分确认这一匹配。

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 Queries 页面查看该记录，后续的治理章节也将以此为基础。

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

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 数据受到监管。部分用户（HR、欺诈调查）需要查看社会安全号码和卡号等个人身份信息。大多数用户（市场营销、分析）则不得查看。行级过滤器按地域限制分析师的访问，并且必须实现从人类浏览器到仓库的逐用户审计追踪。

AtScale 在语义层强制执行这些要求，在任何查询到达仓库之前。无论调用方是通过 MCP 的 Strands 智能体、通过 XMLA 使用 Excel 的分析师，还是通过 JDBC 的 notebook，执行方式都完全一致。SML 中的一个行级安全对象、一个视角、一组角色绑定，应用于模型的每个使用者。

从用户到 AtScale 的身份传播

这条链的形态与 Denodo 那篇文章中的一样，只是最后一跳落在 AtScale 引擎，而不是继续传到仓库。

人类用户针对企业 IdP 向应用进行身份验证，并收到一个 JWT。
应用通过 AgentCore Gateway 将 JWT 作为 bearer 令牌转发给 Strands 智能体，网关对其进行验证（签发者、受众、签名），并将请求路由到 AgentCore runtime。
当智能体调用 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、Amazon Redshift 实际看到的由 AtScale 转换后的下推 SQL、所应用的安全策略、该查询是否由聚合提供服务，以及返回的行数。由于该记录同时捕获了模型编写的查询和数仓执行的查询，审计人员可以从人类的问题追溯到产生该数字的 SQL。本系列的第一篇和第二篇文章都没有在同一条记录中同时捕获这两种形式的查询。

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

{
  "timestamp": "2026-08-31T10:34:56Z",
  "user_identity": "[email protected]",
  "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 版本中正式可用，并支持标准的 Model Context Protocol。任何兼容 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 的 Connecting with Claude 页面。AgentCore Gateway 代表智能体出示访问令牌，AtScale 引擎对照 Keycloak 验证该令牌，而下游策略评估则使用人类用户的身份。

将 AtScale MCP 服务器注册为 AgentCore Gateway 目标遵循标准的 Gateway MCP 目标流程。前面列出的工具对智能体而言就是普通工具，由 AgentCore Identity 在 Gateway 这一跳处理凭据。

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，单维度

列出我们在威斯康星州的客户及其所在城市。

智能体针对 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 为空的客户。与 dim_customer 在 cid 上的左联接保留了从未加入的客户，这些客户会以空的加入记录出现。智能体返回按终身消费额排名的前 20 名。AtScale 的规划器将联接解析为针对 Amazon Redshift 的原生 SQL 并返回排序列表。customer_lifetime_value 公式并非 LLM 需要自行发明的东西，它是在 customer_lifetime_value.yml 中定义一次并通过名称在查询中引用的计算度量。

治理复跑

我们以两个不同的调用者身份运行查询 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），并在 cid 上将连接添加到 dim_customer。
添加模型所需的任何新度量（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）脚手架，用于搭建一个包含 AtScale 所需组件的 EKS 集群：入口控制器、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）端点或一条允许 AtScale 命名空间出口流量访问 Amazon Redshift 的安全组规则连接 Amazon Redshift，而人类用户则通过入口负载均衡器访问该应用程序。

AtScale 提供自管理 EKS 之外的云端部署选项。请访问 AtScale 网站了解当前的 offerings 和 AWS 可用性。本文其余部分假设使用前文所述的自管理模式。

结论

对企业数据的智能体访问需要三项能力协同工作：一个能够规划并生成查询的基础模型，一个能够在实时数仓之上计算受治理的、有业务意义答案的语义层，以及一个托管智能体并管理身份流转的运行时。Amazon Bedrock、AtScale 和 Amazon Bedrock AgentCore 各自扮演其中一个角色。

智能体与语义层通信，而不是直接与数仓通信。维度、层次结构、度量、透视图和行级安全性都存放在 Git 中的 SML 里。当架构发生漂移或治理规则变更时，只需更新一个文件，每个消费者（智能体、Excel、Tableau、Power BI）都会在下一次查询时获取到更新。

从哪里开始

大多数成功落地的团队都从窄范围起步，再逐步扩展。

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