AI代理必须原生运行于数据平台
Databricks 主张将AI代理作为原生工作负载运行在数据平台内，以解决数据外迁带来的治理漏洞和成本飙升问题。
企业AI代理应直接运行在数据平台内部，而非将数据抽至外部AI栈。后置治理（在代理访问数据后再过滤）无法防止聚合计算中的权限泄露，且会导致令牌浪费循环（代理因结果被阻断而反复重试）。数据原生架构将策略嵌入查询计划，从根本上解决治理和成本问题。
正文摘录
数据原生 AI Agent：为何 Agent 必须迁往你的数据 - 来源公司：Databricks 企业 AI Agent 应当存在于你的数据、治理与策略所在之处。 大多数企业 AI 试点项目都跨过同一个低门槛：将 LLM 连接到你的数据，放入一个向量数据库，向领导层做演示。困难的部分随后才出现。安全团队标记出治理漏洞；多步 Agent 中的延迟毁掉了用户体验；来自模型提供商的账单不断攀升。这些问题通常可以追溯到同一个决策：将数据从受治理的系统中拉出，放入一个从未为执行你的策略而构建的 AI 堆栈中。 本文主张一种不同的架构方向：将模型和 Agent 迁移到数据处，而不是反过来。与其构建一套并行的 AI 基础设施再将其接回你的湖仓，不如将 Agent 视为原生工作负载，运行在你的数据平台内部，置于你已信任用于数据的那同一套治理、安全与可观测性控制之下。 湖仓为你提供了一个治理数据的地方。下一个问题是：你的 Agent 是生活在该边界之内，还是之外？当前存在两种涌现的范式。 范式 1：Agent 与 LLM 运行在独立的 AI 堆栈中。 数据通过网络被导出或查询到外部向量数据库、SaaS LLM 或定制服务层。治理、安全与可观测性被重新为 AI 在侧面实现。 范式 2：Agent、模型、工具、检索以及 Agent 记忆与数据本身运行在同一平台内，位于统一的治理与安全层之下。 AI 成为你现有数据栈上的另一种工作负载。 数据有引力。计算是廉价的，可以重新定位；数据则不然，尤其是在数据量增长且模态增多的情况下。将数据拉出来会引入一系列熟悉的代价： 在这些代价中，治理尤其值得关注，因为它是事后无法修补的。大多数 AI 治理方法将其视为一个过滤器，在 Agent 已经访问数据之后才应用——例如，从响应中删除敏感字段、在输出层阻止某些主题、事后审计日志。这对于简单的问答演示是可行的。