使用Unity Catalog大规模治理AI代理

一年前，你的组织可能只有十几个AI代理。如今，可能已有成千上万个。每个开发团队都有编码代理，负责编写、审查和部署代码；分析团队构建了预测代理；销售运营部署了潜在客户评分；支持团队自动化了工单分派；市场营销启动了个性化推荐；财务部门开发了对账工作流。每个团队都看到了机会并迅速行动。

现在有人问：“哪些代理在访问客户PII？”答案需要从多个系统中提取日志，手动关联，然后希望没有遗漏。每个代理的日志记录、身份验证和数据访问方式各不相同，没有一个统一的查看点。相反，如果你选择了完全锁定的路线，没有代理能在未经严格审查的情况下部署，安全保持良好，但你会落后于竞争对手六个月。开发者和用户感到沮丧，有些人甚至离开了公司，去那些真正能使用AI工具的地方。

两种极端都不可行。不受治理的代理会带来无法衡量的风险，而锁定环境则带来另一种风险：落后于人，人才流失。传统的治理假设人类做出决策，应用程序可预测地执行它们。但代理不是这样工作的。它们是自主的，每次做出不同选择，并以无法通过阅读代码预测的方式链接工具。你不能通过审查代理可能做什么来治理它，而是通过控制它能访问什么并监控它实际做了什么来治理。

AI代理治理的四大支柱

Unity Catalog自2021年起已通过统一权限模型、统一血缘和跨所有资产的一致审计轨迹治理企业数据。现在，我们将相同的治理基础设施扩展到AI系统接触的每一个资产：LLM、MCP服务器、技能和代理。已经知道谁能访问你的客户数据的目录，现在也管理哪些代理可以调用哪些工具，以及在什么条件下。

Unity AI Gateway是代理世界中的执法层。每一次模型调用、每一次工具调用、每一次代理交互都流经网关。每个请求在执行前都会根据Unity Catalog中定义的策略进行评估，并在执行后记录。传统治理工具是为静态应用构建的，对此毫无可见性，而Unity AI Gateway则能做到。

支柱一：委托访问

代理必须在明确定义的权限边界内运行，包括它们代表谁行动以及可以访问什么。大多数平台像处理应用权限一样处理这个问题：使用静态凭据和广泛访问的服务账户。这导致责任缺失，无法控制爆炸半径。Databricks采用不同方法：身份从头到尾流动，从提问的用户到代理检索的特定表行。代理通过实时委托令牌传递继承调用用户的数据权限，而不是共享服务账户。如果你无法访问Unity Catalog中的表，代表你行动的代理也无法访问。每个动作都根据两个身份记录：触发请求的真实用户和代表他们行动的代理，记录访问了哪些表、运行了什么操作以及何时发生。

我们将此模型扩展到MCP服务器。团队在Unity Catalog中注册外部MCP服务器（如GitHub、Jira、Slack等），并像管理其他可安全对象一样管理它们：权限、凭据管理以及集中审计日志。我们还认识到同样的原则不仅适用于访问时间，也适用于运行时。知道代理被允许调用GitHub并不能告诉你它是否应该删除文件或合并拉取请求。因此我们构建了服务策略，这些策略是UC函数，在UC中管理并附加到Unity Catalog中注册的MCP上，控制哪些工具调用成功。每个工具调用在执行前都会根据工具名称、参数或调用者身份进行评估，策略返回允许、拒绝或请求用户同意。

在模型层面，护栏实时检查流经推理的内容，扫描输入以查找PII和越狱尝试，在输出到达用户前检查幻觉和敏感内容。它们在每个请求上内联运行并失败关闭。权限控制谁能调用什么，服务策略控制特定工具调用是否应在给定请求的上下文中进行，护栏控制什么内容流入和流出。

支柱二：以数据为中心的AI治理

大多数AI治理工具忽略了一个原则：代理的行为几乎完全由其可访问的数据决定。它能读取什么、数据有多新鲜、敏感字段是否被屏蔽——这些不是AI治理问题，而是数据治理问题。分开处理会导致两个不完整的系统，而统一处理则能使治理自我强化。

首先你需要完整的审计轨迹，监管使这成为必需。新兴AI法规要求组织展示其AI系统做了什么、得到了什么以及产生了什么。AI Gateway将每个模型调用的完整负载写入推理表：确切提示、确切响应、令牌计数和延迟。Unity Catalog在审计日志中捕获每个访问操作，包括哪个主体调用了什么、来自哪个代理以及何时发生。两者都以表的形式存入你的湖仓，可按你的意愿保留。

其次，审计数据只有在你能够分析时才有用。分析需要数据平台，而不是日志工具。代理轨迹是Unity Catalog中的表，可用与你用于其他一切相同的SQL查询。没有新查询语言，没有单独工具。

第三，你需要知道代理依赖的数据是否可信。数据质量监控持续跟踪整个目录的新鲜度和完整性。将其与代理轨迹结合，你可以从“代理给出了错误答案”推进到“代理查询了一个已被标记为过时的表”，将代理行为与底层数据质量联系起来。数据分类增加了另一层：AI系统持续扫描和标记敏感列（如PII、HIPAA和GDPR监管数据），这些标记直接反馈到访问控制。无论哪个代理或框架请求，被屏蔽的列仍然保持屏蔽。你已有的数据治理自动成为你的AI治理。

支柱三：成本智能

每次模型调用都有代价。大多数企业不知道谁在增加成本、为了什么，或者是否有效，直到账单到达，财务部门不得不解释一个没人预见到的数字。根本原因是缺少基础设施：没有查看所有AI流量的计量层，没有将其归因于团队或用例的标记系统，没有与访问控制并行的支出控制。我们将其构建到Unity Catalog和Unity AI Gateway中。使用跟踪将所有请求记录到使用表中，包括令牌计数、延迟、请求者身份和模型目标，无论模型是Databricks托管的还是外部提供商的，都在一个表中。它允许你按团队、项目或成本中心标记请求。由于它像代理轨迹和业务数据一样以表的形式存储，你可以将成本与结果联系起来。

Unity AI Gateway中的预算增加了策略层。管理员为每个用户或组设置月度支出阈值，并在消费接近或超过时收到警报——这是支出成为问题之前的信号。硬执行是自然的下一步。

支柱四：开放和互操作

每个企业AI治理策略最终都会面对同样的驱动力：新团队选择不同框架，新提供商发布更好模型。如果你的治理内置于当前工具选择中，你就处于跑步机上：每个新框架都是新集成，每个新模型都是新策略。我们认识到这一点，因此采取了不同于大多数治理工具的方法。治理不能只存在于代理层，还需要存在于代理访问的数据和服务中，无论这些服务是否由Databricks管理。基于LangGraph和CrewAI的代理都查询相同的Unity Catalog，调用相同的受治理MCP服务器，并流经相同的AI Gateway。框架无关。治理随资源而非调用代码流动。

开放标准使这具体化。MCP为代理提供通用工具连接协议：在Unity Catalog中注册一次，从任何框架调用，具有相同的权限和审计轨迹。Unity AI Gateway为Databricks托管模型、Azure OpenAI、AWS Bedrock和Anthropic提供单一受治理端点，跨提供商具有统一策略、审计轨迹和成本归因层。MLflow跟踪自动检测LangChain、LlamaIndex、AutoGen、OpenAI SDK、Anthropic SDK等，轨迹以表形式存入Unity Catalog，无需每个框架自定义检测。

最终结果是治理成为平台的属性，而不是你为每个新框架或模型重建的东西。你部署的每个代理，无论它是如何构建的或由哪个模型驱动，都访问相同的受治理资源。