Data-Native AI Agents: Why Agents Must Move to Your Data

数据原生AI代理：为何代理必须迁移到您的数据 | Databricks 博客

跳至主要内容

最佳实践

2026年7月15日

数据原生AI代理：为何代理必须迁移到您的数据

企业AI代理应部署在数据、治理和策略已存在的位置。

作者：Kaan Kuguoglu 和 John Karlsson

摘要

• 外部代理在规模扩展时失效：当AI代理运行在独立架构中时，企业将面临叠加的代价：治理碎片化、出站成本攀升、多跳延迟缓慢，以及可观察性缺口使生产部署充满风险。

• 治理无法事后补救：事后控制失效，因为代理对数据进行计算而非简单检索。由未受管控的数据行生成的财务摘要无法事后删除。政策必须在查询规划阶段强制执行，而只有数据原生代理能将治理直接嵌入计算过程。

• Databricks上的数据原生代理：通过在数据智能平台内运行代理，团队可获得统一目录治理、AI搜索检索、MLflow追踪、Lakebase状态管理以及AI网关流量控制的集成堆栈，从而更快交付内置安全性和血缘关系的可信AI功能。

大多数企业AI试点都通过了同样的低标准：将大语言模型连接到数据，插入向量数据库，向管理层演示。真正的挑战出现在后期。安全系统会标记治理漏洞。多步骤代理的延迟会破坏用户体验。模型提供商的账单持续上涨。这些问题通常可追溯到一个决策：将数据从受控系统中提取到从未设计用于执行您策略的AI堆栈中。

本文主张采用不同的架构方向：将模型和代理迁移到数据所在位置，而非相反。您无需构建独立的AI基础设施并重新连接到数据湖，而是将代理视为原生工作负载，在数据平台内部运行，接受与数据相同的治理、安全和可观测性控制。

数据湖屋为您提供了统一治理数据的场所。下一个问题是：您的代理是位于该边界内还是外？目前出现两种新兴范式：

外部代理

代理和大语言模型在独立的AI架构中运行。数据通过网络导出或查询到外部向量数据库、SaaS大语言模型或定制服务层。治理、安全和可观测性需要为AI单独重新实现。

数据原生代理

代理、模型、工具、检索和代理记忆在与数据相同的平台内运行，受统一的治理和安全层保护。AI成为您现有数据堆栈上的另一类工作负载。

外部代理的隐性成本

数据具有引力。计算成本易于迁移；数据则不然，尤其当数据量增长且模态多样化时。提取数据会引入熟悉的代价：

• 治理弱化。在每个集成中重新实现访问控制、血缘关系和驻留要求，会导致审计发现的漏洞。

• 延迟累积。每次跳转到外部向量存储、大语言模型并返回，都会在多工具代理中叠加。

• 成本碎片化。出站流量、重复存储和跨供应商的每token定价从三个方向冲击预算。

• 生命周期变成供应商协调。模式、索引和模型在缺乏共享部署流水线的系统间漂移。

• 可观测性碎片。端到端追踪一个请求意味着需要将来自三四个工具的日志拼接在一起。

• 业务上下文被遗留下来。指标定义、业务术语表和领域分组存储在您的治理层中；外部代理需要从列名中重新构建它们，或进行猜测。

为什么事后治理对代理无效

在所有这些代价中，治理需要特别关注，因为它是在事后无法修补的唯一因素。大多数AI治理方法将其视为代理访问数据后的过滤器，例如从响应中删除敏感字段、在输出层阻止某些主题，或在事后审计日志。这在简单的问答演示中有效。但一旦代理开始对数据进行计算，这种方案就会崩溃。

考虑一个需要在行级安全约束下跨多行计算财务摘要的代理。聚合本身（总和、平均值、趋势）是一个衍生值，其结果取决于包含哪些行。如果在查询执行前未强制实施治理，结果已经包含了用户不应影响的数据。无论后续进行多少次内容删除，都无法逆转这个计算。治理决策必须在查询规划阶段做出，而不是在响应生成阶段。

这就是基于边界或事后治理的根本缺陷：它假设数据到达代理后可以被安全地审查。实际上，一旦发生聚合或转换，治理意图就已经丢失。事后控制本质上是不完整的。

错误处理还会带来第二个代价，这会体现在账单上。问题不仅在于代理被允许访问的内容（尽管这也是其中的一部分）。当治理在事后而非源头解决时，代理最终需要自行进行协调：遍历审计日志、跨外部系统连接碎片、从多个位置拉取相同记录以判断是否可以使用、对每个部分结果重新推理。这些都不是代理的职责。这是代理在补偿一个从未提前提供的治理答案。被阻止或删除的输出只会加剧这种循环，因为代理会将它们视为失败并再次尝试。会话时间被拉长，每次跳转都会向模型加载更多上下文，一个请求悄无声息地变成了数千个计费标记。这就是标记消耗循环，而事后治理正是引发这种循环的根源。

数据原生代理通过将策略执行直接嵌入查询规划和计算中来解决这些挑战。每个中间结果都反映了相同的治理约束。治理必须在执行前和执行期间进行评估，这无法等到计算完成后才作为事后处理。Unity AI Gateway中的自定义防护措施就是这种理念的具体体现：可组合、确定性的策略，网关会在每个请求和响应中强制执行，而不是要求模型在事后遵守的过滤器。在规划阶段基于已经存在于一个治理位置的数据做出策略决策，也意味着代理可以在单次遍历中获得清晰答案，而无需跨系统挖掘以组装或证明答案。

到目前为止，我们主要关注了代理如何读取数据。但生产环境中的代理也需要写入数据：对话历史、任务进度、用户偏好、缓存结果以及用于后续审计的工具输出。随着代理承担的任务越来越多，状态层与数据层同样重要。如果将状态层排除在治理边界之外，所有关于端到端可审计性的承诺都将存在漏洞。

状态是代理的短期工作区：正在进行的对话、当前执行的任务、刚刚填充的缓存。而记忆则是会超越会话生命周期的信息：代理处理过的客户信息、用户的偏好、值得复用的过往输出。两者都需要事务性存储，一旦离开平台，两者都会导致治理失效。例如“用户X是高价值的欧盟客户”这类记忆本身属于敏感数据，受与它所总结的记录相同的访问和驻留规则约束。同时它也是事务性工作负载：Delta表适用于大规模分析扫描，但代理状态需要快速的行级读写、键查找和原子更新。

通常的变通方案是使用外部的PostgreSQL或Redis。但这又回到了本文反对的问题：代理状态会离开受控边界，进入治理层无法看到的系统，需要独立管理其安全性和生命周期。你构建了一个数据原生的代理，却引入了不受控的依赖。

当一个代理变成多个代理时，问题会进一步加剧。一个群体协作完成更大目标（如规划者委托专家、监督者协调结果）需要共享内存，而保持一致性正是这些系统容易出错的地方。当每个代理维护私有状态并通过点对点传递上下文时，就没有单一的事实来源。代理之间产生分歧，写入操作发生冲突，每次交接都成为另一个不受控的通道，随着群体规模扩大，问题呈指数级增长。结果证明，共享内存是真正的难点。

Lakebase填补了这些空白。它是完全托管的PostgreSQL存储，集成在Databricks平台内，与其他所有组件处于同一治理平面下。代理状态成为受控资产：继承平台的访问控制策略，与代理的数据和工具共存，无需独立的基础设施团队。由于每个代理都读写同一事务层，它同时充当群体的单一事实来源。状态保持一致，原子更新防止两个代理破坏同一任务，一个代理视图中的策略会自动应用到后续写入，任何记忆都可以追溯到群体中的具体代理：是哪个代理写入的，哪个代理读取的，深度结论如何溯源到原始来源。

数据原生代理的优势

治理层面的论点最为尖锐，但优势远不止于此。当代理运行在数据栈内部时，优势会叠加到所有操作维度：安全性、质量、可观测性、部署、延迟和成本。工具和数据依赖项与模型一起配置和记录，因此整个系统默认具备版本控制、可审计性和可复现性。

以下对比总结了这两个范式在生产系统最关键维度上的差异：

信任与控制方式

数据原生代理

外部代理

治理

数据和代理的单一控制平面，策略执行直接嵌入查询规划和执行过程。

Security

数据和模型始终保留在您的云环境/VPC内部。

数据经常离开您的安全边界，从而创建了额外的攻击面。

Agent Quality

端到端追踪能够实现系统化、平台原生的评估。

评估过程碎片化且依赖人工，日志分散在多个外部供应商处。

Data Quality

通过共享数据管道内置一致性；新鲜度由平台统一管理。

断开的数据质量控制需要脆弱的定制化同步流程来保持代理数据的新鲜度。

Observability & Monitoring

全面的评估和监控可集中捕获所有步骤，同时记录模型和代理版本。

日志分散在不同工具中，导致端到端故障排除困难且耗时。

Agent Memory

对话历史、用户偏好和学习上下文持久化存储在Lakebase中，由Unity Catalog治理，可与底层业务数据关联，并与堆栈其他部分使用相同的标识模型。

记忆存储在独立的Redis或Postgres实例中，拥有自己的访问模型，无源数据血缘信息，且治理无法查看代理保留的用户信息。

Business Context

统一目录不仅治理数据模型，还定义其业务含义。指标、术语表、领域和Genie本体论会自动为代理提供业务定义，按权威等级排序并尊重源ACL。

业务含义存在于边界外的BI工具、电子表格或领域专家头脑中。每个代理都需要重新构建这些定义，通常仅基于列名。

Deployment

通过全栈（数据、模型、代理）统一版本控制实现简化的CI/CD。

需要独立的CI/CD流水线，并在多个供应商之间进行复杂协调。

Latency

低延迟，因为代理靠近数据运行，最大限度减少网络跳转。

由于每次检索和工具调用都需要多次网络往返，导致高延迟。

Cost

通过集中式服务和存储（数据仅存储一次）避免出站成本。

碎片化定价和大规模数据移动的显著出站成本。

Databricks上数据原生代理的实际形态

数据智能平台将这一理念付诸实践。您无需构建独立的"AI堆栈"并将其连接到数据，而是在数据堆栈内部构建AI代理。Databricks上的数据原生代理是指：

• 所有模型和代理流量都通过Unity AI网关路由，每个请求在执行前都会被检查，每个响应在执行后都会被检查，确定性ALLOW/DENY/ASK策略取代事后最佳努力过滤。访问控制、速率限制、负载日志和成本跟踪都位于同一控制平面，包括对外部LLM提供商和编码代理的调用。

• 将每个AI原语（模型、代理、MCP、技能及其调用的工具）视为与表和函数并列的Unity Catalog资产，使身份、血缘和访问控制在整个AI表面上统一适用。

• 通过MLflow 3捕获完整请求追踪：每个LLM调用、工具调用、评分、评估、检索文档和端到端监控循环都可审计合规并用于调试观察。

• 在Model Serving上于您的Databricks安全边界内执行推理，无需将数据传输到第三方AI堆栈进行不受管控的处理。

• 通过AI Search从Delta索引中检索上下文，该索引遵循Unity Catalog ACLs并自动追踪血缘关系。

• 通过Lakebase支持的状态和记忆实现跨会话持久化：短期对话上下文、多步骤任务进度、长期用户偏好，以及与代理推理数据并行的过往工具调用情景记忆。

• 通过Unity Catalog语义（指标、业务术语表、领域）和Genie本体（从团队现有表、查询、仪表板和应用中自动提取的知识图谱）将推理根植于业务上下文。

• 将专业推理委托给其他代理，包括Genie处理结构化数据问题，平台边界内实现跨领域、多步骤的协同。

• 通过Omnigent（一个元级控制框架）将相同治理扩展到代码代理，该框架通过Unity AI Gateway共享会话和审计轨迹，统一调度Claude Code、Codex和Cursor。

从何处开始

一些企业已经开始以这种方式构建系统。他们的代理与数据运行在相同的安全边界内，由Unity Catalog策略统一管控，状态存储在Lakebase，流量通过Unity AI Gateway。没有哪家企业是通过单次平台迁移项目实现的，而是通过每次试点逐步弥合湖仓与AI堆栈之间的缝隙，之后停止开启新的缝隙。

对于处于早期阶段的团队，工作并不戏剧化。平台侧的大部分组件已经存在：Model Serving、Unity Catalog、Lakebase、MLflow。缺失的是将它们视为代理的"家园"而非平行堆栈数据源的决策。这个决策往往是最难迈出的一步。

最有效的起点是清点当前已运行在安全边界外的系统。这将是下一次治理事件的来源，也是使其他所有工作成为可能的关键。

如果想深入了解如何通过正确护栏和模式实现数据原生代理的运营化，以下资源是很好的下一步：

• 要将战略转化为具体控制措施，请阅读《企业实用AI治理框架》，该文档展示了如何在Databricks数据智能平台上将高层目标转化为角色、策略和工作流程。

• 要了解负责任AI的更广泛实践，请阅读《负责任且有效的AI项目最佳实践》，该文档介绍了可跨团队采用的原则和运营模型。

要探索本文讨论的平台能力：

• Unity AI Gateway：2026数据与AI峰会新特性 —— 所有模型和代理流量的单一控制平面，配备确定性的ALLOW/DENY/ASK自定义护栏。

• Agent Bricks：2026数据与AI峰会 —— 作为平台一级受控工作负载提供的自动优化代理。

• Omnigent：组合、控制和共享代理的元级框架 —— 通过Unity AI Gateway共享审计轨迹，统一调度Claude Code、Codex和Cursor等代码代理。

• Genie One、Genie代理和Genie本体介绍 —— 自动维护的知识图谱，将代理根植于您的业务上下文。

• AI代理的内存扩展 —— Lakebase上代理状态和内存的扩展方式，由平台内的Unity Catalog进行管控。

订阅获取最新文章更新

订阅我们的博客，最新文章将通过电子邮件发送到您的收件箱。

注册

查看所有博客

slice-start id="_gatsby-scripts-1"

slice-end id="_gatsby-scripts-1"