在AWS上使用Stardog和Amazon Bedrock AgentCore构建用于代理式AI的语义层

企业分析二十年来一直追求同一个目标：缩短从业务问题到可信答案的时间。预定报告让位给仪表盘，仪表盘又让位给自助式商业智能（BI）。然而，即使自助式分析也依赖于数据工程师预先为特定问题构建正确的模型，而人类分析师仍然是准备数据集之外的瓶颈。生成式AI代理是下一步。它们不是可视化数据，而是对数据进行推理。它们自主规划、编写查询、评估结果、优化，并根据需求在公司实时数据上进行迭代。代理式分析就是这个转变的术语：每个业务用户身边都有一个自主代理，无需等待请求队列即可完成分析师的工作。

难点不再是基础模型。Amazon Bedrock上可用的基础模型已经能够规划多步骤工作流，推理模式，并生成足以胜任初级分析师的SQL。难点在于模型推理的数据。企业数据分散在各系统中，这些系统对相同事物的定义不同。客户关系管理（CRM）系统中的“客户”与计费系统中的“客户”不是同一条记录。北美团队计算的“收入”与欧洲团队产生的数字不同。AI代理直接访问这些碎片化数据将编写技术上有效但返回错误、冲突或无法解释答案的查询。当两个代理对同一问题返回两个不同数字时，信任就会崩溃。

在AWS上，这些数据分布在常见的混合环境中。运营记录存储在Amazon Aurora和其他Amazon RDS引擎中。分析历史存储在Amazon Redshift中。非结构化数据存储在Amazon S3中，通过Amazon Athena查询，并且越来越多地采用开放表格式，如Apache Iceberg，在Amazon S3 Tables上，Athena、Amazon EMR和Amazon Redshift都可以读取。每层都是针对其存储内容而构建的，大多数企业将保持这种结构。挑战在于帮助AI代理同时跨所有这些进行推理，就像高级人类分析师对同一问题的流畅度一样。

基础模型提供语言，AWS数据应用程序提供事实。今天连接它们的常见方式是检索增强生成（RAG）：将政策文档、手册和支持工单索引到Amazon Bedrock知识库中，并在查询时将匹配段落拉入模型的上下文。当答案存在于搜索可找到的文本中时，RAG效果良好。但对于分析性问题，答案取决于跨系统连接实时记录、一致应用业务规则以及遵守行级或列级访问策略，RAG效果不佳。

介于语言和事实之间且通常缺失的是业务上下文和业务指标。以典型的零售示例为例：对客户是什么的共同定义，订单如何与客户关联，什么算作大额支出者或高风险账户，哪个系统拥有哪些事实，以及业务报告的数字如何计算。相同的差距也出现在其他领域（保险中的索赔和保单，医疗保健中的患者和就诊，供应链中的零件和发货），只是名称不同。语义层一次捕获该上下文，并让每个代理和工具重用。有了它，AI代理可以从多个来源组合答案，并为其返回的数字提供支持。语义层并不取代RAG，而是补充它。大多数生产系统两者都需要，并通过同一个代理可访问。

语义层是企业数据的本体驱动视图。本体捕获对业务重要的概念、关系、属性和规则。映射声明这些概念如何从每个实时来源的行中映射。代理查询该层，层在运行时将每个查询转换为针对底层系统的SQL。数据保留在原处，含义被捕获一次并重用。

当语义层像Stardog那样实现时（本体、每个实体的稳定标识符、派生新事实的规则以及验证数据是否符合本体的约束），结果就是知识图谱。数据作为业务实体的图而不是表中的行连接，每个实体都有一个称为IRI的稳定URL式唯一标识符，查询通过一种称为SPARQL的W3C定义、基于标准的查询语言遍历这些连接。文中反复出现两个术语：命名图是图的标记子集，由它自己的IRI标识；虚拟图是内容不存储在Stardog中的命名图，它们存在于外部系统（Aurora、Redshift、Athena）中，Stardog使用映射按需获取行。

通过本文，您将了解：语义层如何与RAG配合以及何时选择每种；如何跨Amazon Aurora和Amazon Redshift联邦Stardog，并扩展到其他AWS数据源；为什么推荐AgentCore运行时、网关和身份用于生产中的代理；从代理到Stardog的两种集成路径：直接SPARQL工具和Stardog Cloud MCP服务器作为网关工具目标；关于治理、部署以及GA与测试版的权衡。

代理所需的三个层 给出可靠、业务上下文感知答案的AI代理依赖于三个协同工作的组件。每个组件解决其他组件无法解决的问题。

1. 模型层：能够规划并编写代码的基础模型。Amazon Bedrock提供单一API访问多个模型系列。我们使用Anthropic Claude Sonnet 4.6。模型懂语言，不懂您的业务。
2. 含义层：为模型提供对业务问题背后数据的可信、受控访问的语义层。本体声明概念和从它们派生新事实的规则，联邦在查询时从每个来源拉取实时行。该层完成工作：确定哪些数据相关，将SPARQL查询重写为每个来源的SQL，并在共享标识符上连接行。模型的任务更窄：读取用户问题，在需要数据时调用该层，并用通俗英语编写答案。实际的数据推理，如在联邦源上应用Big_Spender规则，保留在Stardog内而不是提示中。我们使用Stardog在Aurora和Redshift上的联邦知识图谱实现这一层。
3. 代理运行时层：托管代理、终止入站请求、管理工具凭证并提供安全与治理操作表面的计算。在AWS上，您有一系列选择：一端是Amazon Bedrock AgentCore等托管运行时，另一端是Amazon ECS、Amazon EKS或AWS Lambda等自管理选项。正确的选择取决于您希望拥有多少代理操作。我们使用Amazon Bedrock AgentCore，因为它是AWS上生产代理中最具规范性的选项。

在这三个层中，含义层是本文要解决的缺口，其余的演练构建了它。代理运行时层是大多数团队低估的：代理如何被调用，如何认证，其语义层凭证在哪里，以及如何扩展。AgentCore将这些问题打包到一个托管服务中，这就是我们在此使用它的原因。

示例用例：跨Aurora和Redshift的客户360代理 我们选择客户360（C360）用于本文的其余部分，因为它展示了AI代理在执行真正分析工作时遇到的每一个缺口，并让我们展示语义层如何在几百行映射和规则中关闭每个缺口。在典型的零售设置中，客户资料、地址、信用卡和奖励信息存在于运营数据库中。订单、产品、类别和供应商存在于数据仓库中进行分析。每一方都针对其功能进行了优化。任何一方都无法单独回答关于客户整体的问题。试图回答“我们最有价值的客户是谁，他们在买什么？”的代理必须协调两个数据库、两个模式、两个“客户”定义和一个衍生概念（“最有价值”），该概念不存在于任何列中。C360使这些缺口具体化。

C360代理为分析团队运行。它接受来自销售负责人、营销人员或欺诈分析师的普通英语问题。它编写查询，跨公司数据运行，并回复简短的叙述答案和支持数据。用户看不到SQL或SPARQL，代理看不到它不允许看到的数据。

用户用普通英语问C360代理：“威斯康星州的大额支出者是谁？”客户资料和地址在Aurora中。订单总额在Redshift中。代理必须在稳定的客户标识符上连接它们，而该连接是语义层添加的三件事之一：

1. 通过共享含义跨系统连接。语义层使用共享业务键将Aurora和Redshift的客户记录映射到共同客户身份。这使得连接可以通过语义模型表达，而不是物理集成管道。没有它，该连接通常需要维护一个管道，该管道物化数据的第三份副本，并且每次任一源发生更改时都必须保持同步。
2. 作为规则而非查询的派生事实。像“大额支出者”这样的定义可以作为规则存在于本体中，而不是在每个查询中重新表达，并且每个提到它的查询获得相同的答案。没有它，该定义会在仪表盘、笔记本和报告中重复。当阈值更改时，副本会漂移，同一问题开始返回不同答案。
3. 图级别访问控制。命名图安全性在图形级别控制访问，因此不同角色看到企业知识图谱的不同子集。对于更细粒度的保护，您可以指定敏感属性，如:ssn和:cardNumber作为受保护属性。有权限的用户看到实际值，而其他人默认看到掩码值。通过这种方法，不同角色可以运行相同查询，而知识图谱对访问它的每个应用程序强制执行一致的安全策略。

我们采用了Stardog的C360知识工具包，它最初加载本地CSV，并改编为跨Aurora PostgreSQL（客户方）和Amazon Redshift（订单方）进行联邦。该工具包包含本体、映射和规则，全部使用Stardog的语法。我们部署了Stardog服务，配置了虚拟图指向Aurora和Redshift，并测试了代理查询。结果证明，语义层成功地将来自两个源的客户数据整合在一起，正确识别了大额支出者，并提供了支持数字。代理能够回答原本不可能的问题，而无需预先构建的集成数据管道。