用 Strategy Mosaic 与 Amazon Bedrock AgentCore 在 AWS 上为智能体 AI 构建语义层

本文与 Strategy 首席产品经理 Zhili Cheng、AI 工程总监 George Earle 以及销售工程师 Kyler K 联合撰写。

在本系列第一篇文章中，我们在 AWS 上基于 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）、面向 SQL 客户端的基于 Trino 的 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 runtime（Amazon Bedrock AgentCore 的一项能力）上的 Strands 智能体通过 MCP 端点访问 Mosaic。连接、指标定义以及按调用者的行级和列级过滤都位于 Mosaic 内部，而不是在智能体提示中。

我们假设您已熟悉本系列第一篇文章中的语义层架构。如果其中有任何内容对您来说比较陌生，Stardog 那篇文章已覆盖相关内容。

读完本文，您将了解：

• 如何使用两个链接模型在 Strategy Mosaic 中跨 Amazon Redshift 和 Amazon Aurora 对 C360 领域建模，且无需任何 ETL。
• Mosaic 的指标语法（基础指标、带命名过滤对象的高级指标、级别限定符和复合指标）如何捕捉智能体必须理解其推理的业务定义。
• 如何通过 Mosaic MCP 服务器将模型暴露给托管在 AgentCore 上的 Strands 智能体，以及用户身份如何传递，从而使按用户的行级安全性（RLS）和对象级安全性（OLS）端到端生效。
• 如何针对智能体流量在实时下推和内存执行之间做出选择。
• 如何将同一套受治理的定义发布到 Power BI、Tableau、notebook 和自定义应用，以及如何将其导出为 Apache Ossie 格式以供 Mosaic 之外的工具使用。

本演练的事实来源是 Strategy One（2026 年 3 月），这是 Mosaic 通过 MCP 服务器访问正式默认可用的版本。

本文使用的 Strategy Mosaic 术语

在进入模型之前，先做一个简短的术语参考。

• Mosaic Schema 与 Mosaic Models。同一个通用语义层内的两种建模路径。Mosaic Schema 是集中治理的企业模型。Mosaic Models 是 Mosaic Studio 中自助式、AI 辅助的建模路径。模型可以映射到 Schema 属性，并继承维度、对象 ACL 和 RLS。本演练使用 Mosaic Models。
• 模型（Model）。任一建模路径中的顶层工件。它在物理表之上发布属性、指标、层次结构和安全规则。本演练使用两个 Mosaic Model，一个建在 Amazon Redshift 上，一个建在 Aurora 上，二者相互关联。
• 属性（Attribute）。诸如 Customer 之类的业务实体。它带有多种形式：用于连接的 ID 形式和用于读取的显示形式。Mosaic 使用形式将诸如“Carolyn Inworth”之类的名称解析为底层的 cid。
• 层次结构（Hierarchy）。属性之间的父子关系。Category 通过父级上卷到 Department。Address 上卷到 City 再到 State。
• 事实与度量。事实是一个数值列。度量对它进行聚合。Purchase Amount = price * quantity 是一个基础度量。度量还可以是高级的（由命名条件限定的聚合）或复合的（基于其他度量的公式）。
• 筛选对象（Filter object）。从度量中以尖括号引用的命名条件。[Large Orders] 是一个筛选器，其限定条件为 Purchase Amount > 500。度量引用 <[Large Orders]> 而无需内联谓词。
• 级别限定符（Level qualifier）。用于固定聚合粒度的度量表达式语法。{~+, !Customer+} 将粒度固定为 Customer，无论查询如何切分。
• 模型链接（Model linking）。跨模型在共享属性（Customer、Time）上进行组合。Mosaic 将聚合下推到每个数据源，并在通过模型链接声明的共享属性上连接中间结果。
• 认证模型（Certified model）。只有经过认证的模型才能通过 MCP 服务器访问。
• 实时或内存中。两种针对每个模型的执行模式：实时下推到数据源，或从 Mosaic 驻留的 cube 中获取答案。详情请见本文后续内容。

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

前两篇文章中的 C360 模式保持不变。该 schema 改编自 Stardog 的 C360 Knowledge Kit，因此跟随本系列的读者会看到由不同的语义层回答的相同实体、键和锚定问题。一家零售组织的客户记录、地址、信用卡和奖励注册信息位于运营侧，而订单、产品和产品类别位于数仓中。业务用户希望获得跨越两者的答案，而无需知道哪个系统保存着哪个事实。

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

跨两个数据库的 schema：

Amazon Aurora PostgreSQL 兼容版（运营）

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，可以将模型的属性映射到该架构上，并继承企业架构中的维度、对象 ACL 和 RLS，无需另行安全评审。如果您的数据架构师已经在维护受治理的架构，建议尽早执行此操作。

两个相互关联的模型

每个 Mosaic 模型连接到一个实时数据源。模型关联将它们组合起来。

• Purchase（购买）：实时连接 Amazon Redshift。事实数据位于 purchase 表（price * quantity），维度位于 product、category、vendor 和购买日期。
• Customer（客户）：实时连接 Amazon Aurora PostgreSQL 兼容版。维度位于 customer、address、credit_card、rewards_account。

在每个模型内部，物理联接只针对源架构声明一次。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 之间没有物化的跨引擎联接，也没有共享的物理架构。联接就是关联属性的约定。

属性和层级

属性承载多种形式。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 层级通过父级上卷到 Department。category.parent 上的自引用意味着部门级的问题能够一致地聚合。
• Address 以同样的模式通过 City 上卷到 State。这使得 State = 'WI' 成为单一的属性限定，而不是智能体必须自行构造的联接。

图 3 展示了在 Design Center 中创建的地理层级，将 State 经由 City 和 ZIP Code 一路链接到 Customer。

图 3：Design Center 中 Customer 模型的地理层级。State 经由 City 和 ZIP Code 上卷到 Location，Location 再链接到 Customer。

智能体请求的是 State = 'WI'，而不是 address.state。物理列名不会离开模型。语义层的每个使用者看到的都是属性形式及其显示形式，层级会自动承载上卷逻辑。

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

基础指标是对事实表应用一个分组函数。Purchase Amount 是 Sum(price * quantity) 表上的 purchase。

图 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 还需要一个层级限定符，因为“生命周期”意味着整个历史记录，而不受当前问题切片方式的影响：

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

Customer 之前的 ! 将分组设置为无，因此该指标在每一行都返回每位客户的完整总额，而不是折叠为每位客户一行。完整语法请参阅 Strategy Metric Level Symbols。

注意，筛选表中的 [Big Spender] 限定的是指标表达式而非属性谓词。筛选对象可以对二者进行限定。Share of wallet（钱包份额）是一个复合指标，由其他指标构建而成：

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

层级和条件会从组件中原样传递。Share of wallet 是一个比率，因此不做求和或求平均。一个 AWS Region 的份额并不是每位客户份额的平均值，指标描述中已告知智能体这一点。请参阅 Strategy Conditional Metrics。

除了基础、高级和复合指标之外，Mosaic 还将受治理的时间智能指标作为一等表达式提供。Previous Year、Previous Quarter、Year-to-Date 和 Quarter-to-Date 只需在模型上声明一次，并且在切片时保持不变，因此像 今年 Sports 的支出与去年相比如何 这样的问题，只需选取一个属性并引用两个指标，而无需手写 SQL 日期筛选。自定义日历附加在模型层级，因此同一个同比表达式既适用于 9 月结束的财年，也适用于 12 月结束的自然年。请参阅 Governed Time-Intelligence Metrics in 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 上的连接，投影 profile 和 rewards_account.create_date，并过滤 enrollment 为 null 的记录。每个未注册客户返回一行。
2. 下推到 Amazon Redshift：SUM(price * quantity) 按 cid 分组。每个有总消费额的客户返回一行。
3. 在 Mosaic 内部合并：在 cid（关联属性）上连接两个中间结果集，按终身消费额排名，并返回前 20 名。

Aurora 运行事务性的 profile 连接。Amazon Redshift 运行事实聚合。Mosaic 处理小中间集上的跨引擎连接（每个客户一行，而不是每个订单一行）。手写管道可以近似实现同样的结构，但之后必须永远保持同步。

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

实时下推或内存

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

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

智能体流量是重复且突发性的。一个将 威斯康星州最高消费者 分解为多个探索性后续查询的智能体，会在同一近期数据片上发起许多小查询。从内存中提供服务可将多变的逐查询仓库开销转化为固定的 Mosaic 容量，而且通常更快。对于有界窗口上的交互式智能体工作负载，内存模式通常既更快又更便宜。在将模型切换到内存模式之前，先配置 Mosaic 侧的权限，并在用于验证数字的同一测试流程中验证这些权限。

一个定义，四个接口

上一节构建的指标、属性、层级和安全规则通过原生协议触达每一个消费者。无需连接器转换，无需指标重复实现，不会产生偏差。

通过本演练中 Strands 智能体调用的同一经过认证的 Mosaic 模型，也可供在 Amazon Quick 中工作的业务分析师使用，Amazon Quick 将 Mosaic MCP 注册为经 OAuth 认证的连接器。无需进行第二次集成。

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

Mosaic 在语义层强制执行访问控制，即查询到达 Amazon Redshift 或 Aurora 之前。HR 和反欺诈角色可以看到诸如 ssn 和 card_num 之类的个人身份信息（PII）字段。市场营销和分析角色则看不到。无论调用方是通过 MCP 使用 Strands 智能体、通过 XMLA 使用 Excel 的分析师，还是通过 JDBC 使用笔记本，强制执行方式完全相同。一套 RLS 和 OLS 对象、一道认证模型关卡、一次权限检查。被标记为敏感的属性和指标还会输入到 Mosaic Sentinel Risk Management，该功能会针对触及被标记对象的查询发出警报，并检测行为异常，作为 OLS 旁边的纵深防御层。

图 6 展示了两条通道上的身份传播链：每用户仅运行一次的前门 OAuth 握手，以及每次智能体工具调用时运行的按请求路径。每条通道都将用户身份端到端传递，因此 Mosaic 可以基于调用方而非服务账户来强制执行 RLS 和 OLS。

图 6：身份传播链。前门 OAuth 握手每用户运行一次，或在刷新令牌续期时运行（步骤 1-4）。按请求路径在每次智能体工具调用时运行（步骤 5-10）。链中任何环节都不会重新限定为服务账户。Mosaic 基于调用方的 Strategy 用户身份评估治理。

这条链遵循两条通道。

前门 OAuth 握手（每用户一次）。人类用户向企业 IdP 进行身份验证。应用程序以 offline_access 为作用域，在 /collaboration/authorize 处对 Strategy Library 启动 OAuth 2.0 授权码流程。Strategy Library 通过 SAML 或 OIDC 与同一 IdP 联合，在 /collaboration/token 处返回刷新令牌和访问令牌对。应用程序将刷新令牌持久化到 AWS Secrets Manager，以用户的 IdP sub 声明作为键。

按请求路径（每次智能体工具调用）。AgentCore Gateway 验证 IdP JWT 并路由到 AgentCore runtime，后者托管调用 Amazon Bedrock 上 Claude Sonnet 4.6 的 Strands 智能体。智能体的 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 智能体之前，可省去一次推理跳转。

工具链

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

智能体会自动串联这些调用。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 负载长达数千 token，且在同一模型版本内不会变化，因此缓存可以降低重复调用时每次调用的输入 token 成本。面向稳定语义层的智能体流量正是最能从中受益的重复性、突发性模式。

MCP 路径上有两个效应叠加。首先，get_semantics 返回压缩后的业务上下文（指标定义、层级、属性形式）而非原始 schema DDL，因此模型在更小、信号密度更高的负载上进行推理。Strategy 的 公开基准测试衡量了提供语义上下文相对于原始 schema 在输入 token 和每查询成本上的影响。其次，Bedrock 提示词缓存让这段已经压缩的负载在多次调用间保持热缓存。对于重复性的智能体流量，两个效应在每次调用都生效：模型在压缩后的上下文上进行推理，而重复调用命中缓存。

验证

为了验证语义层、智能体和身份流程按预期工作，我们通过智能体运行了三类查询，然后以不同角色对其中的一个进行了治理重跑。

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

智能体针对 Customer 模型生成一个查询，投影 Customer 和 City 的显示形式，并将 state 过滤为 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 返回的 Customer 属性完全不含 ssn，因此智能体没有可投影的属性。相同的请求、相同的查询文本，一份定义得出两个正确的答案。

跨界面确认。 我们通过 Mosaic XMLA 端点在 Excel 中打开同一个经过认证的 Customer 模型，将 State 和 Customer Lifetime Spend 拖入数据透视表。州级总计与智能体得出的数字完全一致。

在运行早期，智能体对各个客户的钱包份额取了平均值，这是典型的不可加性错误。在指标描述中加入一行（“比率指标。不要跨客户取平均值，应从组成部分重新计算”）就解决了这个问题。这正是要在第一个冲刺而非最后一个冲刺编写指标描述的理由。

扩展到更多数据源

同样的链接机制可以扩展到第三个数据源：通过 Amazon Athena 查询的 Amazon Simple Storage Service（Amazon S3）中的点击流事件、Amazon S3 Tables（Amazon S3 的一项功能）上的 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 Ossie（孵化中）进入 Apache 孵化器。它定义了一种供应商中立的格式，用于描述指标、维度、关系和业务概念，使定义无需重新输入即可在工具之间流转。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、notebook、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 构建语义层

关于作者