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

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

AtScale 的形态与前两者不同。其语义模型是维度式的（维度、层级和度量），而不是三元组图或一组视图。AtScale 使用语义建模语言编写模型，这是一种开放的、基于 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（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 模式保持不变。一家零售企业的客户记录、订单、产品和奖励注册信息分散在多个系统中，业务用户希望在不了解哪个系统持有哪项事实的情况下提出跨领域问题。我们在本系列第一篇文章中改编的 Stardog C360 Knowledge Kit 用 Customer、Order、Product 和 Address 实体对此场景建模，这些实体通过一个整数 cid 连接，该整数在客户表中作为主键出现，在购买表中作为普通列出现。

本文与前两篇的不同之处在于数据的物理位置。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 会观察各使用方的查询模式，当某种模式的开销足够大、值得为其物化汇总表时，就在仓库中物化汇总表。之后匹配该模式的查询会透明地路由到该聚合表。
设计中心 – AtScale 的创作界面。建模人员可以通过可视化画布或文本编辑器编辑 SML。无论哪种方式，磁盘上的产物都是 Git 中的 SML YAML。
AtScale MCP 服务器 – 位于 <atscale-host>/mcp 的产品内 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 端点接受两种凭证：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 的层级原语是对产品到类别关系的简洁表达。针对该模型的查询无需递归 SQL 公共表表达式即可导航 product → category → parent category，大语言模型（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 工具和 notebook）、XMLA（用于 Excel 和 Power BI）以及 MCP（用于 agent）访问。total_revenue 计算返回给 Claude Sonnet 4.6 的数字，与返回给指向同一 XMLA 端点的 Excel 数据透视表的数字相同。我们在 Verification 中确认了这一匹配。

AtScale 如何规划并下推查询

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

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

在物理规划阶段会发生两件事，使 AtScale 区别于手写管道。第一，join 作为原生 SQL join 下推到 Amazon Redshift，而不是在语义层中物化。Amazon Redshift 优化器看到的是带有过滤和聚合的单条 SQL 语句，并据此执行。第二，AtScale 的聚合管理器在其注册表中检查是否存在与查询模式匹配的预构建聚合。如果存在按正确粒度按客户对购买进行分组的汇总表，AtScale 会重写查询以命中该聚合，而不是扫描 fact_purchase。查询返回的时间仅为针对原始事实表所需时间的一小部分，而 agent 或建模人员无需进行任何手动路由工作。

图 4：agent 的维度查询进入 AtScale 规划器。规划器检查其聚合注册表，找到与查询模式匹配的聚合，重写查询以命中 Amazon Redshift 中的汇总表，并返回结果。下方路径展示了同一查询在没有匹配聚合的情况下直接命中 fact_purchase

聚合管理器是使 agent 驱动的工作负载在经济上可行的关键。LLM 驱动的分析触发的查询比人类分析师更多，而像告诉我一些关于我们销售的有趣事情这样的开放式提示可能会产生十几个查询。AtScale 观察查询模式，在仓库本身（而非单独的缓存）中物化聚合，并透明地路由匹配的查询。聚合创建是根据跨消费者观察到的流量按需定义的，而不仅仅是 agent。

查询的审计记录同时捕获了 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 数据受到监管。部分用户（人力资源、反欺诈）需要查看社会安全号码和卡号等个人可识别信息。大多数用户（市场营销、分析）则不得查看。行级过滤器按地域限制分析师，并且逐用户审计轨迹必须从用户浏览器一直保留到仓库。

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

从用户到 AtScale 的身份传播

该链路与 Denodo 文章中的形态相同，只是最后一跳落在 AtScale 引擎，而不是继续传到仓库。

用户针对企业 IdP 完成应用身份验证，并获得一个 JWT。
应用将 JWT 作为持有者令牌通过 AgentCore Gateway 转发给 Strands 智能体，后者对其进行验证（颁发者、受众、签名）并将请求路由到 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、Amazon Redshift 所看到的经 AtScale 转换的下推 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 版本中正式可用，并使用标准的 Model Context Protocol。任何兼容 MCP 的客户端（AgentCore 运行时中的 Strands 代理、Claude、ChatGPT、Cursor、VS Code）都可以连接到同一端点，针对同一已部署模型进行操作。

该服务器暴露了一组限定于查询语义模型的工具。AtScale 文档按版本发布工具参考。对于代理驱动的工作负载而言，重要的工具包括：

list_models：枚举调用方可以看到的模型，以及描述维度如何映射到事实的列组。
describe_model：返回所选模型的维度、层级、度量、计算和业务描述。这是 agent 的系统提示词在开始编写查询之前所加载的载荷。
search_columns：对模型的列进行关键词搜索。当完整的 describe_model 载荷会占用过多 LLM 上下文窗口时很有用。
validate_query：检查维度 SQL 语句是否与模型兼容，而不对仓库执行它。这让 agent 可以在触发任何 Amazon Redshift 计费操作之前低成本地迭代查询。
run_query：对模型执行维度 SQL 语句并返回行。
run_queries：批量运行多条语句，适用于开放式提示词，agent 会并行触发多个探索性查询。
get_version：报告 MCP 服务器版本，以便客户端决定是否缓存模型 schema。

AtScale MCP 端点接受两种认证模式。bearer-token 路径使用从 Design Center 铸造的 API 令牌。每个请求都以令牌所有者的身份运行，该路径适用于概念验证或单一身份服务。OAuth 2.0 路径使用 AtScale 捆绑的 Keycloak，其预置客户端的 ID 恰好为 atscale-mcp，记录在 AtScale 的 Connecting with Claude 页面上。AgentCore Gateway 代表 agent 出示访问令牌，AtScale 引擎针对 Keycloak 验证该令牌，下游策略评估使用人类用户的身份。

将 AtScale MCP 服务器注册为 AgentCore Gateway 目标遵循标准的 Gateway MCP 目标流程。前面列出的工具对 agent 来说就是普通工具，由 AgentCore Identity 在 Gateway 跳转处处理凭据。

侧栏：用 AI 辅助建模扩展模型

AtScale MCP 服务器暴露的工具范围限于查询，而 AtScale 一直在扩展 MCP 接口，加入作者侧工具，让 agent 能够内省仓库 schema、从源元数据生成候选 SML 模型、按规范验证 SML，并将结果提交到 Git。这种模式——agent 塑造语义模型而不仅仅是读取它——天然适合 Claude Code 和 Cursor 工作流。在这些工作流中，数据工程师与 LLM 协作，在新数据集上引导构建模型。

AtScale 将这一方向归为三项能力。Semantic Discovery Engine 扫描仓库 schema、查询历史和血缘，以推断候选连接、层级和指标定义。Model Recommendation System 根据观察到的查询模式建议维度、度量和关系。Governed Feedback Loop 在 SML-and-Git 工作流中保留对 AI 建议的人工审核，因此变更是有版本且可审计的。

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

部署并运行 agent

Strands Agents 是一个用于构建智能体的小型框架。一个简短的 Python 入口点将 Amazon Bedrock 上的 Claude Sonnet 4.6 连接到作为工具来源的 AtScale MCP 服务器。AgentCore 运行时托管该进程。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 为 null 的客户。对 dim_customer 按 cid 的左连接保留了从未注册的客户，这些客户会以 null 注册记录出现。智能体返回按生命周期消费额排名前 20 的客户。AtScale 的规划器将连接解析为针对 Amazon Redshift 的原生 SQL，并返回排名列表。customer_lifetime_value 公式并非 LLM 必须发明的内容。它是在 customer_lifetime_value.yml 中定义一次并在查询中按名称引用的计算度量。

治理重跑

我们运行了 Query 1 的一个变体，以两个不同的调用者身份，在投影中加入了 ssn（Show me our customers in Wisconsin, with their SSN）。作为 hr_user，describe_model 返回完整的 C360 模型，agent 据此组合查询，结果集中包含 SSN 值。作为 marketing_user，describe_model 返回 Marketing 视角，该视角不暴露 ssn。agent 没有可投影的属性，因此返回的答案不含 SSN。两次运行之间除了调用者身份外没有任何变化。查询文本、agent 代码、MCP 服务器、AtScale 引擎和 Amazon Redshift 均未改动。

跨消费者确认

我们通过 AtScale XMLA 端点，在 Excel 中打开同一个 C360 模型，并将 Customer.State 和 Total Revenue 拖到数据透视表上。州级汇总数据与 agent 对等价问题返回的结果完全一致，数字分毫不差。

扩展到其他数据源

向 C360 模型添加新数据源是一项建模工作，而非集成工作。假设客户支持团队要求模型包含工单数量，以便 agent 能够回答 Which of our top spenders opened a support ticket in the last 30 days? 步骤如下：

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

agent 代码或 AgentCore 配置无需任何改动。下次 agent 调用 describe_model 时，它会看到新的维度和度量，并能够针对它们组合问题。同样的模式适用于不同的数据仓库。如果数据源落地到 Snowflake 或 Databricks 而非 Amazon Redshift，则连接是一个带有 Snowflake 或 Databricks 连接的新 SML 数据集，查询将按照先前的多源说明在该引擎中解析。

部署：Amazon EKS 上的 AtScale

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

EKS 上的 AtScale 部署运行在一小组 Kubernetes pod 上。atscale-engine 是核心查询规划器和执行器。atscale-mcp-server 是 agent 与之通信的 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）以及 ingress（atscale-ingress，通常由 AWS Network Load Balancer 前端）。

C360 应用程序（一个聊天 UI 或调用 agent 的客户端库）可以在同一 EKS 集群中以其自己的命名空间运行。它使用 IAM role for service account (IRSA) 来访问 Bedrock 和 AWS Secrets Manager，而无需嵌入凭证。

网络配置是标准做法：AtScale 通过虚拟私有云（VPC）端点或允许 AtScale 命名空间出站访问 Amazon Redshift 的安全组规则来访问 Amazon Redshift，而人类用户则通过入口负载均衡器访问应用程序。

AtScale 提供除自管理 EKS 之外的云部署选项。请查看 AtScale 网站了解当前提供的方案和 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 智能体。

关于作者

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，帮助企业设计生产级解决方案。