如何在保留治理的同时将Genie Agents接地到结构化数据与文档

构建一个自动化简单业务任务的智能体可能很容易。但创建一个真正理解你的业务并尊重你现有数据治理的智能体则困难得多。

长期以来，团队不得不使用不同的系统来分析结构化和非结构化数据，往往花费数周时间仅仅为了连接这两者。通过直接从表和文件中进行分析，Genie Agents简化了这一架构，允许你用结构化和非结构化数据同时为一个智能体提供基础。

当你整合这些数据时，一个关键问题出现了：如果一个智能体能访问所有数据，什么能阻止它向错误的人泄露错误的信息？

好消息是，通过Databricks，答案存在于你已经拥有的数据治理基础中。你目前依赖的Unity Catalog机制（身份同步、对象权限、ABAC、行过滤器和列掩码）会自动管理Genie Agents，无需额外设置。这种无缝继承依赖于精心设计的治理策略，我们将在下文详细探讨。

为了使这些概念变得生动，我们将使用Brickstore（一家虚构的全球砖块零售商）的示例来探讨这些场景，作为参考点。

治理契约：Genie Agents以最终用户的凭据运行

核心架构原则很简单：Genie Agents以最终用户的凭据运行。Unity Catalog默认执行治理，确保对表和目录的访问直接与最终用户现有的身份和权限绑定。

这一点至关重要，因为许多自建系统赋予智能体广泛访问权限，并依赖提示工程来在模型层过滤结果。这实际上使LLM成为你的安全边界——考虑到模型可能被操纵或绕过，这是一个危险的赌注。告诉审计员“我添加了说明不显示受限数据”不是可辩护的治理控制。

通过本文概述的治理框架，Unity Catalog（而非模型）仍然是你的安全边界，就像在Databricks的其他部分一样。虽然Genie决定如何查询数据，但它无法返回最终用户未被授权查看的记录，因为每个答案在离开Lakehouse之前，已经在数据层进行了过滤。

步骤0：从身份开始：自动身份管理（AIM）和即时（JIT）供应

架构基础始于确保你的企业身份既准确又最新。

访问控制从根本上只与其评估的身份一样可靠。如果Databricks中的组成员关系是身份提供者中内容的过时、手工维护的副本，那么“brickstore_apac成员只能看到APAC订单”的策略就毫无意义。

自动身份管理（用于Microsoft Entra ID和Okta）弥补了这一差距。启用后，用户、组、组成员关系和服务主体从这些身份提供者自动同步到Databricks，无需SCIM应用程序。即时供应始终开启，因此从未登录过Databricks的用户在首次登录时即被供应，并已带有其现有的组成员关系。

以下是逐步流程：

1. 身份提供者是事实来源。有人加入APAC销售组织；你的身份提供者将他们放入brickstore_apac组。
2. AIM将该信息同步到Databricks——包括组成员关系。JIT用户首次打开Genie One时在Databricks上供应。
3. Unity Catalog策略以这些组为关键——对象权限、ABAC策略、行过滤器和列掩码都在查询时评估组成员关系。
4. 用户向Genie Agent提问，答案完全由其组权限允许的内容塑造。不多不少。

其好处是治理是持续的，而不是一次性设置。当员工从APAC调往AMER时，IdP将他们从组中移动，同步传播，他们问Genie的下一个问题立即返回AMER视图——无需任何人提交工单或更改Genie Agent。当员工离职时，他们从IdP被停用，他们对每个Genie Agent的访问立即被移除。

步骤1：为结构化数据提供基础并控制四层访问

一旦正确建立了身份，我们现在可以关注他们被允许看到什么。对于结构化数据，Genie Agent可以访问任何Unity Catalog数据资产——表、视图、物化视图、指标视图、流式表，甚至来自外部系统的联邦外部表。

例如，Delta表是事实和维度。在Brickstore中，这是brickstore.sales.orders（每个订单，带有region和customer_email）以及brickstore.sales.products（砖块目录）。指标视图是上面的治理语义层——它们用YAML一次编码业务指标的定义（例如“净收入”是什么意思，“砖块销量”如何计算，什么算作“畅销砖块”），以便每个消费者以相同方式计算它们。定义你的业务指标（例如“净收入”的含义、“售出砖块数”如何计算、“畅销砖块”指什么）一次，用 YAML 编写，这样每个消费者都以相同方式计算它们。

在这些资产之上，有四层访问控制，人们通常混淆它们：

对象权限是第一层访问：没有SELECT，Genie 无法代表最终用户查询表。但授予表访问权限并不意味着你需要授予所有访问权限。你可以在这些授权之上叠加行过滤器和列掩码，因此区域经理可以查询订单表，但只能看到自己区域的订单行，且永远看不到原始客户电子邮件。这些行和列控制基于你的授权已经使用的相同组——is_account_group_member('brickstore_apac')等。接下来要讲的 ABAC 并不会取代这些；它只是一种通过策略（而非逐表）来附加相同过滤器和掩码的方式。

ABAC：定义一次策略，让它自动传播

旧的行和列安全方式是逐表进行：编写一个行过滤器，将其附加到orders；编写一个列掩码，附加到另一张表；如此反复。这种方法仍适用于一次性逻辑，但在数百张表的情况下，这是一种容易出现漏洞的配置。

ABAC 策略（现已与受治理标签和自动数据分类一起在 Unity Catalog 中正式发布）扭转了这一点。你使用受治理标签（账户级、访问受控的键值对，如pii:email）标记敏感数据，并编写一个策略，声明“无论此标签出现在何处，都应用此保护”。新表在打上标签的瞬间即继承保护，因此无需逐表操作。

一个列掩码 + ABAC 策略，保护目录中每个电子邮件列，仅需一条语句：

以及一个行过滤器 + ABAC 策略，使每位经理只能看到自己区域的订单，由组成员身份驱动：

结果是：APAC 经理询问关于订单的问题时，Genie Agent 仅返回 APAC 区域的订单行，且customer_email列被掩码。AMER 经理查询同一张表，得到的是 AMER 区域的订单行。

第二步：将相同的治理扩展到文档

历史上，处理非结构化数据时，团队的治理策略一直更具挑战性。虽然结构化数据在数据仓库或数据库中受到安全管理，但文档通常保存在由独立 ACL 管理的隔离存储系统中。

解决方法是让文件保留在内部与结构化数据相同的治理平面中。你可以将它们放入Unity Catalog Volumes，它们就像其他所有对象一样成为安全对象。你向应查看这些卷的组和用户授予 READ VOLUME 权限，Genie 在相同的身份契约下对它们进行推理：

在设计你的代理之前，有一个行为值得了解：当你将卷附加到 Genie Agent 时，它会成为必需的数据源。这意味着代理在加载时会验证对所有附加数据源的访问权限，因此，如果某个用户对附加的卷没有 READ VOLUME 权限，则该用户完全无法使用该代理。换句话说，卷授权将文档作为使用代理的先决条件来进行管理，因此请确保将每个代理的文档源限定在应使用该代理的受众范围内。如果两个受众需要不同的文档，你可能需要给他们不同的 Genie Agent（每个代理仅挂载该用户可读取的卷）。

还要记住，Unity Catalog Volume 是最小的安全单元，因此权限适用于整个卷，而不是单个文件。你不能挑选要共享的特定文件；你必须授予对整个卷的访问权限，或者不授予任何权限。

考虑到这些因素，可以将卷直接附加到 Genie Agent 作为知识源，就像对表或视图那样。Genie Agent 的读取范围远不止 PDF——支持的文件格式包括 PDF、图像文件（JPG、JPEG、PNG、TIFF、TIF）以及 Office 文档（DOC、DOCX、PPT、PPTX），还有纯文本和 Markdown。实际上，这意味着扫描的合同、幻灯片和规格说明书都可以处理，而不仅仅是干净的 PDF。（请参阅Genie Agents 卷文档获取完整列表和当前限制。）

为确保准确的路由和最佳性能，请遵循以下配置卷的最佳实践：

• 添加清晰的描述：准确描述卷中包含的内容、组织方式以及代理应如何使用它。不要使用通用占位符。例如，不要用“区域文件”，而要用“APAC 市场报告——APAC 区域的需求驱动因素、趋势和关注项”。Genie 依靠此描述来选择正确的卷。
• 避免重复内容：附加多个包含重叠信息的卷会使代理更难检索相关文档。卷内的单个文件也是如此。
• 避免无关文件：仅包含与代理领域相关的文件。无关文件可能会混淆代理。
• 使用清晰的文件名：使用描述性文件名，以便代理区分文件。

第三步：生产环境中的 Genie Agents：相同问题，不同答案

此时，Genie Agent 已完全有能力充当真正的领域专家——能够完全访问结构化数据和非结构化数据。底层知识库仍然通过基于每个用户权限的行过滤器、列掩码和卷授权得到全面保护。

我们通过让两个不同用户提出完全相同的问题来测试我们的实现，这应该产生两个截然不同但都正确的答案。

考虑两个并发的 Genie Agent 会话，两者都基于相同的资产——orders表、products目录，以及market_report卷。一位请求者属于brickstore_apac，另一位属于brickstore_amer，他们提交了完全相同的查询：

“本季度我们最畅销的产品是哪个？是什么推动了这种需求？并列出这些销售背后的顶级客户及其电子邮件。”

响应 1 - 针对 APAC 经理

响应 2 - 针对 AMER 经理

有三点值得指出：

• 数字不同，但两者都是正确的。两位经理的“最畅销砖块”查询都从相同的表中提取数据——差异纯粹在于各自主管权限范围内的行，而不是指标计算方式的不同。
• 这种差异无需任何针对每个用户的提示工程。没有人写过“如果用户是亚太地区用户，则隐藏其他地区。”代理的指令是相同的。Unity Catalog 在查询时进行了过滤——既在行上，也在被屏蔽的列上。请注意，电子邮件列已被屏蔽以保护个人身份信息。
• 由非结构化知识增强的结构化数据。如果没有区域文档，Genie 可能能够轻松识别“是什么”问题，但很难弄清哪些因素在推动需求。有了非结构化数据，Genie 就能全面了解业务背景。

需要注意的模式

当您将本文的经验应用到生产环境时，需要注意几个模式：

• 先打标签，再定策略。不要逐个表地进行屏蔽。直觉反应是保护您面前的三张表。请抵制这种直觉。定义受治理的标签和基于属性的访问控制（ABAC）策略，以便为未来的数据治理做好准备。
• 每个卷对应一个受众。由于卷是最大的可授权单位，请在卷边界处决定文档访问权限。如果两个文档需要不同的读者，则它们需要不同的卷和不同的 Genie 代理——请提前规划好布局。
• 当通过 MCP 或 API 对外公开 Genie One 或 Genie 代理时要小心——您必须谨慎处理身份信息。与通过 Databricks UI 运行不同，您并不总是被授予使用最终用户身份的权限（例如，在使用服务主体进行身份验证时）。需要采用特定的模式，Databricks 在以下文档中详细说明了 U2M、M2M 和 OBO 配置：随处访问 Genie。
• 通过模拟测试，而非检查。不要通过阅读策略并说服自己它是正确的方式来验证治理——请以每个组的成员身份提出相同的问题，并比较响应。将其作为回归测试，并在策略或分组发生变化时运行。

要点总结

构建代理可能很容易，但治理它需要真正的设计工作。在 Databricks 中，企业身份从身份提供者（IdP）同步，对象权限控制访问，ABAC 和受治理的标签提供大规模保护，行过滤器和列掩码控制返回的内容，文档与数据存储在同一系统中。

通过这种设置，Genie 代理无需任何额外配置即可继承所有治理措施。

要开始构建您的第一个受治理的 Genie 代理，请访问Genie 文档 和ABAC 策略文档。