如何在 AWS 上用 Strategy Mosaic 和 Amazon Bedrock AgentCore 构建智能体 AI 语义层

本文由 Strategy 首席产品经理 Zhili Cheng、AI 工程总监 George Earle 和销售工程师 Kyler K 共同撰写。

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

Stardog 的语义层以本体为基础：概念和关系以 RDF 建模，IRI 是联邦查询的单位，SPARQL 是查询语言。Denodo 采用数据虚拟化：基础视图和衍生视图通过 VQL 组合。Mosaic 采用维度模型：属性、层次结构、事实和指标通过 Strategy 的指标表达式语法组合，链接模型是联邦查询的单位。该模型通过一个定义提供四种原生协议：供 AI 智能体使用的模型上下文协议 (MCP)、通过 Trino 为 SQL 客户端提供的 JDBC/ODBC、供 Power BI 和 Excel 使用的 XMLA，以及供自定义应用程序使用的 REST。这些协议背后是一长串经过认证的数据源。支持的系统包括 Snowflake 和 Databricks 等云数据仓库。运营数据库包括 Amazon Relational Database Service (Amazon RDS)、Oracle 和 SQL Server。分析引擎包括 Amazon Athena、Trino 和 SAP HANA，软件即服务 (SaaS) 数据源则包括 Salesforce。链接模型模式的适用范围不限于本演示采用的 Amazon Redshift 和 Amazon Aurora 组合。在本演示中，托管在 AgentCore 运行时上的 Strands 智能体（AgentCore 是 Amazon Bedrock AgentCore 的一项功能）通过 MCP 端点访问 Mosaic。联接、指标定义以及针对每个调用方的行和列筛选器都位于 Mosaic 内，而非智能体提示中。

我们假设你已熟悉本系列第一篇文章中的语义层架构。如果其中有任何内容对你来说是新的，Stardog 文章介绍了相关基础知识。

读完本文后，你将了解：

• 如何使用两个链接模型，在 Amazon Redshift 和 Amazon Aurora 之间对 Strategy Mosaic 中的 C360 领域建模，无需 ETL。
• Mosaic 的指标语法（基础指标、带命名筛选器对象的高级指标、级别限定符和复合指标）如何表达智能体必须据以推理的业务定义。
• 如何通过 Mosaic MCP 服务器向托管在 AgentCore 上的 Strands 智能体公开模型，以及用户身份如何传递，从而确保行级安全 (RLS) 和对象级安全 (OLS) 在端到端流程中得到落实。
• 如何为智能体流量选择实时下推执行还是内存执行。
• 如何将相同的受治理定义发布到 Power BI、Tableau、笔记本和自定义应用程序，以及如何将其导出为 Apache Ossie 格式，以供 Mosaic 之外的工具使用。

本演示的事实来源是 Strategy One (2026 年 3 月)；在该版本中，默认启用了通过 MCP 服务器访问 Mosaic。

本文使用的 Strategy Mosaic 术语

在开始介绍模型之前，先简要了解相关术语。

• Mosaic Schema 和 Mosaic Models。 一个通用语义层中的两条建模路径。Mosaic Schema 是集中治理的企业模型。Mosaic Models 是 Mosaic Studio 中自助式、AI 辅助的建模路径。模型可映射到 Schema 属性，并继承维度、对象 ACL 和 RLS。本演练使用 Mosaic Models。
• 模型。 任一建模路径中的顶层构件。它在物理表之上发布属性、指标、层级结构和安全规则。本演练使用两个 Mosaic Models，一个基于 Amazon Redshift，另一个基于 Aurora，并将二者关联起来。
• 属性。 一种业务实体，例如 Customer。它包含多种形式：用于连接的 ID 形式和用于读取的显示形式。Mosaic 使用这些形式，将“Carolyn Inworth”这样的名称解析为底层的 cid。
• 层级结构。 属性之间的父子关系。Category 通过 parent 汇总到 Department。Address 汇总到 City，再汇总到 State。
• 事实和指标。 事实是数值列。指标对其进行聚合。Purchase Amount = price * quantity 是一个基础指标。指标也可以是高级指标（由命名条件限定的聚合）或复合指标（基于其他指标的公式）。
• 筛选器对象。 在尖括号中由指标引用的命名条件。[Large Orders] 是一个筛选器，其限定条件为 Purchase Amount > 500。指标引用 <[Large Orders]>，而不将谓词内联。
• 层级限定符。 用于固定聚合粒度的指标表达式语法。{~+, !Customer+} 将粒度设为 Customer，不受查询切片方式影响。
• 模型关联。 通过共享属性（Customer、Time）跨模型组合。Mosaic 将聚合操作下推到各个数据源，并根据关联属性连接中间结果。
• 认证模型。 只有认证模型才能通过 MCP 服务器访问。
• 实时或内存中。 每个模型有两种执行模式：实时将查询下推到数据源，或从驻留在 Mosaic 中的立方体获取答案。本文后续将详细介绍。

示例：跨 Amazon Redshift 和 Amazon Aurora 的 Customer 360

前两篇文章中的 C360 模式保持不变。该架构改编自 Stardog 的 C360 Knowledge Kit，因此跟读本系列的读者会看到相同的实体、键，以及由不同语义层解答的核心问题。某零售企业的运营系统中存有客户记录、地址、信用卡和奖励计划注册信息，而数据仓库中则存有订单、产品和产品类别。业务用户希望获得跨越这两类数据的答案，而无需了解每项事实存在哪个系统中。

本文的不同之处在于 Mosaic 如何访问这两个数据源。Mosaic 不会在查询时跨引擎联合行数据。它会为每个数据源规划一个查询，将原生 SQL 下推，并在 Mosaic 引擎中根据通过模型关联声明的共享属性连接中间结果集。C360 演练将分析侧建模为基于 Amazon Redshift 的 Purchase 模型，将运营侧建模为基于 Amazon Aurora PostgreSQL-compatible edition 的 Customer 模型。

两个数据库中的架构：

Amazon Aurora PostgreSQL-compatible（运营）

Amazon Redshift（分析型）

共享 ID 为 cid，这是一个整数，在 Aurora 的 customer 中作为主键出现，在 Amazon Redshift 的 purchase 中则是普通列。它们之间没有 SQL 约束，也不可能有，因为它们运行在不同的引擎中。每个将客户与其订单关联起来的问题，都必须在某处处理这个整数。Mosaic 通过模型链接来处理它，而不是通过物化跨引擎联接。

一个能体现整个模型的典型问题是：按生命周期总消费额排名前 20 的客户中，哪些还没有加入奖励计划？这就是 Denodo 帖子中的自动注册问题。它需要从 Aurora 获取客户资料、从 Amazon Redshift 获取汇总消费额，并从 Aurora 获取注册状态，然后依据语义层中的定义进行排名和筛选。

参考架构

图 1 展示了端到端运行时。入站身份验证路径从客户端经由 AgentCore Gateway（Amazon Bedrock AgentCore 的一项功能）到达运行时。出站查询路径则从 Strands 代理经由 Mosaic MCP 端点到达 Amazon Redshift 和 Amazon Aurora。

图 1：参考架构。客户端、Amazon Bedrock AgentCore 组件、Strategy Mosaic MCP 端点、Mosaic 引擎，以及 Amazon Redshift 和 Amazon Aurora 之间的入站身份验证路径和出站查询路径。

运行时分为入站路径和出站路径。

入站。客户端通过 Amazon Bedrock AgentCore Gateway 发送用户的问题。Gateway 会针对企业身份提供商（IdP）验证用于标识人类用户的 JSON Web Token (JWT)。随后，它将请求路由到托管 Strands 代理的 Amazon Bedrock AgentCore runtime。该代理调用 Amazon Bedrock 上的 Anthropic Claude Sonnet 4.6，以理解提示并规划查询。

出站。当代理决定查询语义模型时，其 MCP 工具会通过 HTTPS 直接连接到 https://<env-domain>/collaboration/mcp/mosaic 处的 Mosaic MCP 端点。代理会在 Authorization: Bearer 标头中提供 OAuth 2.0 访问令牌。Mosaic 会通过其内置的 OAuth 授权服务器验证该令牌，并将调用方解析为 Strategy 用户。随后，它会应用 Use MCP Server 权限和认证模型门禁，为该用户评估行级和列级安全性，并规划跨已链接的 Purchase 和 Customer 模型的查询。Amazon Redshift 和 Amazon Aurora 会针对 Mosaic 引擎按各数据源生成的原生 SQL 作出响应。

有两个特性对后续内容很重要。跨数据源联接之所以能够进行，是因为建模者声明了链接，而不是因为两个数据源恰好都可访问。代理只能遍历模型中已有的链接。到达 Mosaic 的令牌代表人类用户，而非服务账户，因此行级安全（RLS）和列级安全（OLS）会端到端地依据调用方身份进行评估。AWS Secrets Manager 会在调用之间保存调用方的刷新令牌，而“受管控的访问”一节将介绍完整的身份链。

构建语义层

该演示使用两个 Mosaic 模型，即 Mosaic Studio 中的自助式 AI 辅助建模路径，并通过共享属性将二者关联起来。Mosaic Studio 是创作套件，本文中的截图来自其 Design Center 建模工作区。分三个步骤：分别配置两侧的数据集和连接，配置属性和层级结构，然后配置承载业务逻辑的指标。拥有现有集中治理 Mosaic Schema 的团队，可以将模型的属性映射到该 Schema，并从企业级 Schema 继承维度、对象 ACL 和 RLS，无需进行并行的安全审查。如果数据架构师已经维护了受治理的 Schema，应尽早完成此操作。

两个关联模型

每个 Mosaic 模型连接一个实时数据源。模型关联会将二者组合起来。

• Purchase：基于 Amazon Redshift 实时运行。事实数据位于 purchase 表（price * quantity）中，维度位于 product、category、vendor 和购买日期中。
• Customer：基于 Amazon Aurora PostgreSQL-compatible 实时运行。维度位于 customer、address、credit_card、rewards_account。

在每个模型中，都会针对源 Schema 一次性声明物理连接。Purchase 模型解析 purchase.pid = product.id、product.dept = category.id 和 product.brand = vendor.id，并针对 category.parent = category.id 配置一个用于部门汇总的自引用。Customer 模型解析 customer.location = address.id、customer.cid = credit_card.cid 和 customer.cid = rewards_account.cid。这些关系是 Mosaic 用于规划下推至源端的原生 SQL 的依据。Purchase 和 Customer 之间不会发生任何物理层面的跨模型传递。

两个模型通过 Customer 和 Time 关联。当问题需要同时使用二者时（例如，威斯康星州消费最高的客户会从 address 获取州，从 purchase 获取消费金额），Mosaic 会将适当的聚合下推到各个数据源，并依据关联属性合并结果。无需 ETL，也无需第三份副本。

领域所有权遵循模型边界。CRM 团队负责 Customer，数据系统团队负责 Purchase。双方都不会交出各自的数据源。双方只需就关联属性达成一致，安全性就会从底层模型自动传播。Amazon Redshift 与 Amazon Aurora 之间不存在物化的跨引擎连接，也不存在共享的物理 Schema。连接的基础就是对关联属性达成一致。

属性和层级结构

属性可以包含多种形式。Customer 使用 cid 作为 ID 形式，使用 first_name + last_name 作为显示形式，因此客服人员可以询问“Carolyn Inworth”，Mosaic 会将其解析为关联两侧的正确键。图 2 展示了在 Mosaic Studio 中创作的 Customer 属性，其中 cid 是 ID 形式，Full Name、First Name 和 Last Name 是显示形式。

图 2：Design Center 中的 Customer 属性定义。cid 是用于基于底层键进行连接的 ID 形式。Full Name、First Name 和 Last Name 是显示形式。

C360 需要关注两个层级结构：

• Category 层级通过 parent 向上汇总到 Department。 category.parent 自引用意味着部门级问题能够保持一致地进行聚合。
• Address 层级以相同模式通过 City 向上汇总到 State。 这样，State = 'WI' 就是一个单独的属性限定条件，而不是需要由代理构造的连接。

图 3 展示了在 Design Center 中创作的地理层级结构，该结构将 State 通过 City 和 ZIP Code 逐级连接到 Customer。

图 3：Customer 模型在 Design Center 中的地理层级结构。State 通过 City 和 ZIP Code 向上汇总到 Location，Location 再与 Customer 关联。

代理请求的是 State = 'WI'，而不是 address.state。物理列名不会离开模型。语义层的每个使用者都能看到属性形式及其显示形式，而层级结构会自动承载汇总关系。

指标：基础指标、高级指标、复合指标、时间智能指标

基础指标对事实数据应用聚合函数。Purchase Amount 是 purchase 表中的 Sum(price * quantity)。

图 4 展示了在 Mosaic Studio 中创建的 Purchase Amount 基础指标：公式为 Price * Quantity，描述字段向代理说明了该指标在业务层面的含义。

图 4：在 Design Center 中创建的 Purchase Amount 指标。该公式将价格乘以数量，描述则向代理说明了该指标在业务层面的含义。

有趣的 C360 概念是高级指标：由命名条件限定的聚合。在 Strategy 中，条件是尖括号中的筛选器对象引用，而不是内联谓词。筛选器对象是具有自身名称、描述和权限的模型对象，因此可以在共享同一定义的指标之间复用，并且可进行审计。

只需定义一次筛选器：

每个筛选器对象都包含名称、描述、限定条件和访问权限。建模者为 [Large Orders] 创建或导出的结构如下：

name:          [Large Orders]
description:   Purchases whose net line amount exceeds $500.
               Referenced by Large Order Spend and any metric that
               scopes to high-value transactions.
qualification: Purchase Amount > 500
permissions:   read:   Everyone
               modify: Data Modelers

然后在指标表达式中引用这些筛选器。以下每个都是高级指标：由命名筛选器限定的基础聚合。

Large Order Spend    Sum([Purchase Amount]) {~+} <[Large Orders]>
Sports Spend         Sum([Purchase Amount]) {~+} <[Sports Category]>
Rewards Spend        Sum([Purchase Amount]) {~+} <[Rewards Members]>

图 5 展示了 Design Center 中应用筛选条件的高级指标视图。它使用了与前一个 Large Order Spend 相同的创建模式。

图 5：在 Design Center 中创建高级指标，展示基础公式以及从 Large Orders 筛选器对象中引用的筛选条件。

Customer Lifetime Spend 还需要层级限定符，因为 lifetime 表示完整历史记录，无论当前问题如何切分：

Customer Lifetime Spend    Sum([Purchase Amount]) {~+, !Customer+}

! 前面的 Customer 将分组设置为 none，因此该指标会在每一行返回每位客户的完整总额，而不是折叠为每位客户一行。完整语法请参阅 Strategy 指标层级符号。

注意，筛选器表中的 [Big Spender] 限定的是指标表达式，而不是属性谓词。筛选器对象可以基于其中任一种条件进行限制。钱包份额是一个由其他指标构建的复合指标：

Sports Share of Wallet    [Sports Spend] / [Customer Lifetime Spend]

层级和条件会从组件中原样传递。钱包份额是一个比率，因此不会进行求和或平均。AWS Region 中的份额并不是每位客户份额的平均值，指标描述会向代理说明这一点。请参阅 Strategy 条件指标。

除了基础指标、高级指标和复合指标之外，Mosaic 还将受治理的时间智能指标作为一等表达式提供。Previous Year、Previous Quarter、Year-to-Date 和 Quarter-to-Date 在模型上声明一次，并在切片过程中保留，因此诸如 今年 Sports 的支出与去年相比如何 这样的问题，会转化为属性选择和两个指标引用，而不是手写 SQL 日期筛选器。自定义日历在模型级别关联，因此同一个同比表达式既适用于九月结束的财年，也适用于十二月结束的日历年。请参阅 Mosaic 中受治理的时间智能指标。

只需编辑一次筛选器对象，Power BI 仪表板、SQL 提取和代理就会同步变化。这就是命名且受治理的模型工件能够提供、而内联 SQL 谓词无法提供的价值。

Mosaic 如何规划和执行查询

Mosaic 引擎会将每个 MCP query 调用解析为 Trino 方言 SQL，将维度引用解析为底层的 Purchase 和 Customer 模型，应用调用者所受的 RLS 或 OLS，并为每个数据源规划物理 SQL。该方言与 Strategy 为 MCP 查询工具发布的方言一致，因此，代理生成的 SQL 可在连接到同一认证模型的 MCP 客户端之间移植。

对于自动注册问题，查询规划过程如下：

1. 下推至 Amazon Aurora：将 customer 与 rewards_account 按 cid 连接，投影个人资料和 rewards_account.create_date，并筛选注册信息为空的记录。返回每位未注册客户一行。
2. 下推至 Amazon Redshift：按 cid 对 SUM(price * quantity) 分组。返回每位客户的总消费额。
3. 在 Mosaic 内合并：按 cid（链接属性）连接两个中间结果集，按终身消费额排序，并返回前 20 条。

Aurora 执行事务型个人资料连接。Amazon Redshift 执行事实表聚合。Mosaic 在一个小型中间数据集上处理跨引擎连接（每位客户一行，而不是每笔订单一行）。手写管道可以近似实现同样的结构，但之后必须一直保持同步。

有一个 SQL 细节很重要。指标是受治理的值，但 Trino 会将其视为所选列，因此查询使用 GROUP BY 时，指标需要使用 SUM(metric_name) 这样的聚合包装器。指标的定义、条件和连接路径仍由 Mosaic 解析。外层聚合由调用者负责。因此，钱包份额这类不可加总的比率需要在其描述中明确说明。

实时下推或内存中

每个 Mosaic 模型都以两种模式之一运行。

两种模式都执行相同的安全规则。RLS 和 OLS 在模型上设置一次，无论答案来自何处，都会进行评估。两者的选择关乎性能和成本。

代理流量具有重复性且呈突发状。代理将威斯康星州消费额最高的客户拆解为多个探索性后续问题时，会针对同一近期时间段触发许多小型查询。通过内存提供这些查询结果，可将每次查询带来的可变数仓开销转为固定的 Mosaic 容量，而且通常速度更快。对于有界时间窗口内的交互式代理工作负载，内存模式往往既更快也更省钱。将模型切换为内存模式之前，请先配置 Mosaic 端的授权，并在验证数据的同一轮测试中验证这些授权。

一个定义，四种接口

上一节中构建的指标、属性、层级和安全规则，通过原生协议提供给每类使用者。无需连接器转换、无需重新实现指标，也不会产生偏差。

本演练中 Strands agent 使用的同一认证 Mosaic 模型，也为在 Amazon Quick 中工作的业务分析师提供服务；Amazon Quick 将 Mosaic MCP 注册为经过 OAuth 身份验证的连接器。无需进行第二次集成。

受治理的访问：身份传播与运行时执行

Mosaic 在语义层实施访问控制，查询到达 Amazon Redshift 或 Aurora 之前就会进行检查。HR 和欺诈分析角色可以查看 ssn 和 card_num 等个人身份信息 (PII) 字段。营销和分析角色则不能查看。无论调用方是通过 MCP 使用 Strands agent、通过 XMLA 使用 Excel 的分析师，还是通过 JDBC 使用笔记本，执行方式都完全相同。一套 RLS 和 OLS 对象、一道认证模型关卡、一次权限检查。标记为敏感的属性和指标也会提供给 Mosaic Sentinel Risk Management，后者会针对触及标记对象的查询发出警报，并检测行为异常，作为 OLS 旁边的纵深防御层。

图 6 展示了跨两个通道的身份传播链：每位用户执行一次的前端 OAuth 握手，以及每次 agent 工具调用都会执行的逐请求路径。每个通道都端到端传递用户身份，因此 Mosaic 可以针对调用方而非服务账户执行 RLS 和 OLS。

图 6：身份传播链。前端 OAuth 握手对每位用户执行一次，或在刷新令牌续期时执行（步骤 1-4）。逐请求路径在每次 agent 工具调用时执行（步骤 5-10）。链路中的任何环节都不会切换到服务账户。Mosaic 会根据调用方的 Strategy 用户身份执行治理。

该链路包含两个通道。

前端 OAuth 握手（每位用户执行一次）。人类用户通过企业 IdP 进行身份验证。应用程序针对 /collaboration/authorize 中的 Strategy Library 发起 OAuth 2.0 Authorization Code 流程，使用的范围为 offline_access。Strategy Library 通过 SAML 或 OIDC 与同一 IdP 联合后，会在 /collaboration/token 返回一对刷新令牌和访问令牌。应用程序将刷新令牌保存到 AWS Secrets Manager，并以用户的 IdP sub 声明作为键。

逐请求路径（每次 agent 工具调用）。AgentCore Gateway 验证 IdP JWT 并路由到 AgentCore runtime；该 runtime 承载 Strands agent，由其在 Amazon Bedrock 上调用 Claude Sonnet 4.6。Agent 的 MCP 工具从 Secrets Manager 获取用户的刷新令牌，将其兑换为新的访问令牌，并将 Authorization: Bearer <access_token> 提交给 /collaboration/mcp/mosaic。Mosaic 将令牌解析为 Strategy 用户，执行 Use MCP Server 权限、认证模型关卡以及 RLS 和 OLS，然后针对 Purchase 和 Customer 制定并执行查询。营销分析师看不到 ssn 或 card_num。欺诈分析师则可以看到。

链路中的任何环节都不会切换到服务账户。治理会从 IdP 到 Mosaic 引擎始终基于调用方的身份进行评估。

通过 Mosaic MCP 服务器开放此层

Strategy Library 开放了两个 MCP 端点：

两者均可独立工作。本演练使用 Mosaic MCP。将语义层直接置于 Strands agent 前面，可以跳过一个推理环节。

工具链

四种工具，从项目到模型、语义，再到查询依次串联。

代理会自动串联这些调用。get_projects 和 get_models 会根据描述缩小范围，找到合适的模型，然后代理才会读取列名。get_semantics 会返回受治理的定义，代理随后据此使用真实对象名称编写 SQL：Sports Share of Wallet 是复合指标，Customer Lifetime Spend 的范围限定为 Customer、Category 层级，以及每个指标的公式。

Mosaic 特有的两项 SQL 约定很重要。列标识符遵循 <form>__<name> 模式，必须用双引号括起来（"customer__customer name"）。时间属性既以基础列形式公开，也以预先分桶的时间间隔列形式公开（(day interval)、(month interval)）；文档明确指出，按时间分组聚合时应使用时间间隔列，而不是 date_trunc。

元数据是准确性的关键

get_semantics 会返回定义，但代理仍必须选择正确的指标。没有说明时，Total Spend 和 Customer Lifetime Spend 看起来可以互换，但事实并非如此。四项属性起到了主要作用：对象说明（指标的含义和不应使用它的情况，包括非可加指标的聚合行为）、语义定义（复合指标的组成方式）、关系（哪些属性适合作为切片维度），以及治理上下文（让代理能够说明它无法查看哪些内容，而不是把经过筛选的数字说成完整结果）。模型说明是 get_models 返回的第一项内容，也是代理选择正确模型的依据。Mosaic 可以从上游目录导入元数据，因此已经维护的列说明会直接流入，无需重新录入。

部署代理

Strands 是一个用于构建代理的轻量框架。一个简短的 Python 入口程序将 Amazon Bedrock 上的 Claude Sonnet 4.6 连接到作为工具来源的 Mosaic MCP 端点。AgentCore 运行时负责托管该进程。AgentCore Gateway 负责终止入站请求，并转发人类用户的 JWT。

系统提示词很重要。明确指示代理在编写 SQL 前遵循三步调用模式：先调用 get_projects，再调用 get_models，最后对目标模型调用 get_semantics。要求它只引用 get_semantics 返回的属性名和指标名。再加入一小段，说明目标模型中的业务术语（Customer Lifetime Spend 是客户在其整个历史期间的总值，不受当前切片影响。Sports Share of Wallet 是一个比率。依此类推）。这类提示词工程最能提升准确性。

为重复使用的系统提示词部分启用 Amazon Bedrock 提示词缓存。get_semantics 负载有几千个令牌，并且在同一模型版本内不会变化，因此缓存可以降低重复调用时每次调用的输入令牌成本。针对稳定语义层的代理流量，正是最能从缓存中受益的重复、突发型流量模式。

MCP 路径上的两种效果会叠加。首先，get_semantics 返回经过压缩的业务上下文（指标定义、层级结构、属性形式），而非原始架构 DDL，因此模型可以基于规模更小、信号更强的负载进行推理。Strategy 的已发布基准测试衡量了提供语义上下文而非原始架构对输入令牌和每次查询成本的影响。其次，Bedrock 提示词缓存会让已经压缩的负载在多次调用间保持热缓存。对于重复的代理流量，这两种效果都会作用于每次调用：模型基于压缩后的上下文进行推理，重复调用则命中缓存。

验证

为确认语义层、代理和身份流程按预期工作，我们让代理处理了三类查询，然后以另一种角色重新运行其中一类查询进行治理验证。

查询 1，仅查询 Aurora。 列出我们在威斯康星州的客户及其所在城市。

代理会针对 Customer 模型生成查询，提取 Customer 和 City 的显示形式，并将州筛选为 WI：

SELECT "customer__customer name", "city__city name"
FROM   "Customer"
WHERE  "state__state name" = 'WI'
ORDER BY "customer__customer name"

Mosaic 向 Aurora 推送单个查询并返回数据行。Amazon Redshift 不会被访问。

查询 2，仅查询 Amazon Redshift。 按销量列出我们的前 10 种产品。

SELECT "product__product name", SUM("Units Sold") AS "total_units"
FROM   "Purchase"
GROUP BY "product__product name"
ORDER BY "total_units" DESC
LIMIT 10

整个查询都推送到 Amazon Redshift。Aurora 不会被访问。

查询 3，跨模型查询。 在终身消费额最高的前 20 位客户中，哪些人尚未加入奖励计划？

SELECT "customer__customer name",
       "state__state name",
       SUM("Customer Lifetime Spend") AS "lifetime_spend"
FROM   "Customer"
WHERE  "rewards_account__account_id" IS NULL
GROUP BY "customer__customer name", "state__state name"
ORDER BY "lifetime_spend" DESC
LIMIT 20

Mosaic 会跨两个模型进行规划。客户资料和注册状态来自 Aurora，消费额汇总来自 Amazon Redshift，并在 Mosaic 引擎内通过 Customer 链接属性进行联接，然后筛选并取前 N 条结果。 代理无需定义 Customer Lifetime Spend。它按名称引用该指标，Mosaic 会解析其公式、级别限定符和链接路径。

治理重新运行。我们以两种调用者身份运行查询 1，并将 ssn 添加到投影中。作为欺诈分析师，get_semantics 返回了 SSN 属性，查询也返回了相应值。作为营销分析师，get_semantics 返回了一个不含 ssn 的 Customer 属性，因此代理没有可供投影的属性。相同请求、相同查询文本，基于同一项定义得出两个正确答案。

跨界面验证。我们通过 Mosaic XMLA 端点在 Excel 中打开同一个已认证的 Customer 模型，并将 State 和 Customer Lifetime Spend 拖到数据透视表中。各州级别的汇总与代理给出的数字完全一致。

运行初期，代理对客户的 wallet 占比取了平均值，这是典型的不可加指标错误。在指标描述中加上一句话（“比率指标。不要跨客户取平均值，应根据组成部分重新计算”）后，问题就解决了。这就是为什么应在第一个冲刺中，而不是最后一个冲刺中编写指标描述。

扩展到多个数据源

同样的链接机制也可扩展到第三个数据源：通过 Amazon Athena 查询 Amazon Simple Storage Service (Amazon S3) 中的点击流事件、Amazon S3 这一功能提供的 Amazon S3 Tables 中的 Apache Iceberg 表，或 CRM 等 SaaS 数据源。在 Mosaic 中为数据源建模，并按 Customer 和 Time 建立链接后，浏览到购买相关的问题就能组合成同一个客户视图，无需构建第三条数据管道。添加数据源不会改变已有的指标定义。代理只能沿着建模人员声明的路径查询。AWS Lake Formation 管理对底层数据湖表的访问。Mosaic 的 RLS 和 OLS 则在此基础上应用。

同样的实时数据源模式适用于 Strategy 支持的数据源目录中的所有系统，涵盖 PostgreSQL 和 MySQL 等本地部署数据库，以及本文前面提到的数据仓库和引擎。

与 Apache Ossie 的互操作性

有些工具不会依赖单一语义层。Apache Ossie（孵化中）是为填补这一空白而推出的开放规范，最初于 2025 年 9 月 23 日以 Open Semantic Interchange 的名称发布，目前已进入 Apache 孵化器，名为 Apache Ossie（孵化中）。它定义了一种与供应商无关的格式，用于表示指标、维度、关系和业务概念，让定义可以在工具之间流转，无需重新录入。Strategy 与 Snowflake、Dremio、dbt Labs、Salesforce 等共同参与其中。

Mosaic 支持导出和导入 Ossie 工件。基于 Amazon Redshift 建模的指标和维度定义可以发布为 Ossie YAML，供支持 Ossie 的工具使用，无需 Mosaic 连接器。其他地方编写的定义（例如在 dbt 中维护的指标，或在目录中标准化的维度）也可以流入 Mosaic，而不必重新实现。这些工件是纯文本，因此可以存放在 Git 中，并像其他代码一样在各个环境中逐步部署。

Apache Ossie 目前尚处早期阶段。在最需要可移植性、对保真度要求最低的场景中使用它，例如公式、维度、描述和所有权元数据；治理策略、执行策略和安全配置则继续使用 Mosaic 原生功能。

部署：Strategy Cloud

Mosaic 作为托管服务运行在 Strategy Cloud 上。Strategy 负责运维应用程序。与 Amazon Redshift 和 Amazon Aurora 的连接通过网络从 Strategy Cloud 出站。你需要在源安全组中将 Strategy Cloud 的 CIDR 范围加入允许列表。

可观测性

两个可观测性平面覆盖从提问到获得答案的整个过程。

Sentinel 和 Platform Analytics 覆盖查询侧。Sentinel 会近乎实时地捕获查询时长、慢查询，以及按用户、工具和模型划分的使用情况。

AgentCore Observability（Amazon Bedrock AgentCore 的一项功能）覆盖智能体侧：规划步骤、工具调用、每轮延迟。Sentinel 和 Platform Analytics 显示请求到达 Mosaic 后发生了什么。AgentCore Observability 则显示智能体在请求到达之前的活动。

结论

可靠的智能体分析结合了强大的推理能力、可信的业务上下文和安全的执行。Amazon Bedrock 提供模型，Strategy Mosaic 提供基于实时数据的受管控语义层，Amazon Bedrock AgentCore 则托管智能体并终止身份验证。智能体与语义层交互，而不是直接访问 Amazon Redshift 或 Aurora。架构会不断演进，语义模型吸收这些变化，同一套定义可供 Power BI、Tableau、笔记本、Strands 智能体和 Amazon Quick 使用。通过 Apache Ossie，这些定义也能被不连接 Mosaic 的工具使用。

从哪里开始

• 选取一个目前存在争议的指标（NRR、贡献毛利、活跃客户是常见选择）。选择一个当前存在多个定义的指标。
• 围绕它编写三到五个业务问题。这些问题将成为验收测试。
• 在 Mosaic 中对主要数据源建模，并确保该指标能够返回一个有据可依的数值。
• 逐步添加其他数据源，每次添加一个，并针对模型中已有的属性进行关联。
• 为智能体会接触到的每个指标和属性撰写说明。这是最能提升准确性的环节。
• 通过 Mosaic MCP 连接 Strands 智能体，并运行验收问题。
• 观察几周真实的查询模式，然后将热门数据移至内存中。
• 将稳定的定义导出为 Apache Ossie，并纳入版本控制。

延伸阅读

• Strategy Mosaic – 通用语义层
• 使用 MCP 服务器与智能体、Mosaic 模型和多维数据集交互
• Strategy 高级指标：报表数据和计算
• Strategy 条件指标
• Strategy 指标级别符号
• Strategy 复合指标
• Amazon Bedrock AgentCore 开发者指南
• Amazon Bedrock 提示词缓存
• Apache Ossie（孵化中）
• 使用 Stardog 和 Amazon Bedrock AgentCore 在 AWS 上为智能体 AI 构建语义层
• 使用 Denodo 和 Amazon Bedrock AgentCore 在 AWS 上为智能体 AI 构建语义层

作者简介

Zhili Cheng

Zhili 是 Strategy 的首席产品经理，负责领导 Mosaic——Strategy 的通用语义层；其工程和产品领域从业经验超过 17 年。

George Earle

George 是 Strategy 的 AI 工程总监，负责领导公司的 AI 工程工作。

Kyle K

Kyle 是一名经验丰富的企业软件销售工程师，专注于售前、解决方案架构和概念验证项目。他拥有 Eastern Washington University 的计算机科学学士学位。

JP Boreddy

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

Sahil Thapar

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