Databricks 称其数据智能体在质量和成本上优于通用编程智能体

Databricks 表示，其数据智能体在 401 项真实任务中击败了三款领先的编程智能体，尽管使用的工具调用更少、运行成本也更低。这一结果挑战了人们对智能体 AI 的一种普遍假设：更多探索、更多重试和更多 token，并不总能带来更好的答案。

Databricks 对这一现象的解释聚焦于上下文，而非模型的原始能力。Genie Code 已经理解其运行环境中的大量信息，而通用编程智能体则必须在时间限制内重建这些环境信息。

这种差异之所以重要，是因为企业数据工作很少始于一个干净的代码仓库和一套测试。智能体必须找到正确的表、理解业务语言、检查血缘关系，并判断哪个资产代表当前事实。编程智能体可以通过 Model Context Protocol 访问同一工作区，却仍可能将大部分预算耗费在搜索上。

因此，Databricks 将一项产品基准测试延伸为关于 AI 架构的更广泛论点。该公司认为，专用上下文可以同时提升准确率并降低资源消耗。包括围绕前沿模型构建的系统在内，通用编程智能体如今正面临压力：它们需要证明广泛能力可以与深度集成竞争。

Databricks 为何认为其基准测试挑战了 Token 经济学

Databricks 报告的不只是 Genie Code 能回答数据问题，而是质量与计算投入之间常见关系的逆转。

该公司的智能体评估使用了从真实内部 Genie Code 会话中提炼出的 401 项独立任务。这些任务涵盖数据发现、代码创建、查询修改、调试、代码解释和精确查找。

这并非一次小规模的 text-to-SQL 测试。有些任务要求智能体先定位相关表、notebook、dashboard 或支持文档，才能形成答案；另一些任务则要求在运行中的数据环境内修改代码或查询。

Databricks 让 Genie Code 和三款未具名的编程智能体完成每一项任务。这些通用智能体使用各自的运行框架，以及来自领先 AI 实验室的当前模型。每个智能体也都通过 MCP 获得了对 Databricks 的访问权限；MCP 是一种让 AI 应用连接工具和数据源的开放协议。

每个系统完成单项任务的时限均为 20 分钟。独立评审者评估其回答是否正确且有用。超时计为失败。

Genie Code 的准确率为 76.6%。表现最接近的编程智能体达到 72.1%，另外两款则分别为 55.9% 和 56.1%。

成本走势与许多买家的预期正好相反。Genie Code 每项任务的消耗约为最接近竞争对手的一半。Databricks 还表示，其每个正确答案的成本不足该竞争对手结果的一半。

这两项发现应当结合看待。一个产出廉价却错误工作的智能体，并没有带来有价值的效率；而一个消耗算力难以预测的准确智能体，也会变得难以大规模部署。

据称，Genie Code 避开了这两类问题。只有 16% 的任务超过了该公司的高成本阈值，而通用智能体的这一比例为 33% 至 40%。

Databricks 将差异归因于采取行动的数量和质量。Genie Code 平均每项任务进行 8.3 次工具调用，少于比较中的任何一个智能体。在一个重点案例中，它仅用五次调用便找到正确的表并完成回答。

通用智能体的失败并非因为无法使用前沿模型。Databricks 表示，每个参测系统使用的模型均处于相近的广泛能力层级。它们失败的原因在于，其运行框架将工作区发现变成了漫长而不确定的搜索。

因此，Databricks 的解释并不是某个更小或更便宜的模型突然变得更聪明，而是恰当的系统架构减少了为重新发现已知上下文所必须耗费的智能。

这一主张构成了本文的核心张力：如果深度上下文能够持续同时减少错误和消耗，那么模型选择只是智能体质量的一部分。检索、记忆、元数据、权限以及周边产品，都可能决定模型是否能高效地运用其智能。

通用编程智能体正承受来自代码仓库之外的压力

当环境提供明确文件、清晰目标和测试时，通用编程智能体最具优势；而企业数据工作往往会同时移除这三项优势。

一个软件问题通常会将智能体引向某个代码仓库、故障行为或所需变更。智能体可以检查代码、编辑文件并运行测试。这些测试为判断拟议方案是否有效提供了相对清晰的信号。

一项数据请求可能以“活跃账户收入”或“当前客户表”这样的表述开始。这两个短语未必对应某个显而易见的对象。工作区中可能存在旧 dashboard、重复表、实验性 notebook，以及名称陌生的列。

智能体首先必须确定用户真正的含义，随后定位承载这一含义的资产，最后决定应当信任哪个版本。

这使得分析开始之前就先出现了发现问题。通用编程智能体可以列出表并检查 schema，但仅有访问权限并不能识别组织所偏好的指标，也无法揭示某个 dashboard 已在上个季度被另一个替代。

MCP 有助于标准化模型与外部系统之间的连接。Anthropic 的协议文档将 MCP 描述为应用向语言模型提供上下文和工具的标准方式。它解决了一个重要的集成问题，但集成并不会自动带来理解。

Databricks 为竞争智能体提供了 MCP 访问权限，这使上述区别尤为重要。该基准测试并不是将一个已连接的产品与脱离系统的聊天机器人进行比较，而是在比较不同系统如何利用对同一工作环境的访问。

据称，通用智能体陷入了 Databricks 所称的“随机游走式探索”。它们检查资产、发起查询、跟随部分线索，有时还会对大型表执行无上限扫描。漫长的搜索增加了 token 使用量，也导致超时。

这种行为并不难理解。当智能体缺少可靠地图时，探索就会成为其后备策略。每一项新的工具结果都会扩展上下文，但也可能带来更多可能性和矛盾。

更长的执行轨迹未必包含更多有效信号。它可能包含重复 schema、过时文档、无关查询输出，以及基于先前猜测生成的猜测。模型随后还要耗费额外 token，从一套具备领域认知的系统原本可能排除的材料中筛选信息。

这一弱点的影响超出了 Databricks。编程智能体厂商正日益将其产品定位为广泛适用的数字员工。数据工程、分析、dashboard 创建和运营调查，都是自然的扩展方向。

但这些工作依赖的机构知识很少存在于单一代码仓库中。它可能分散在目录描述、查询历史、notebook、文档、dashboard、对话以及资深员工的工作习惯之中。

团队在检索技术材料时已经会遇到同样的问题。一个可搜索知识库只有在保留关系和上下文、而非仅仅提供文件访问时才真正有用。智能体在更大的运营规模上面临类似要求。

这项基准测试促使通用编程智能体改进其上下文层。它们可以通过更强的语义搜索、持久化工作区记忆、更丰富的元数据支持，或与数据平台建立合作来应对。

它们也可以质疑这一前提。接入同等成熟上下文系统的通用智能体或许能够缩小差距。Databricks 并未披露竞争产品、模型、提示词，或独立复现该比较所需的全部配置细节。

这种不确定性并不会抹去结果，而是澄清了竞争对手必须展示的能力：如果智能体反复将自身能力浪费在定位正确起点上，那么广泛的模型能力已不再足够。

语义上下文改变了智能体的搜索问题

Genie Code 的优势来自于：在昂贵的探索开始前，先缩小决策空间。

Databricks 将 Genie Code 描述为用于分析、数据工程、调试、pipeline 和 dashboard 创建的智能体。其产品文档称，该系统可在多个 Databricks 界面中使用 Unity Catalog 的表、列和血缘信息。

Unity Catalog 充当治理和元数据层，记录数据资产及其结构、关系、血缘和访问规则。这些信息给予 Genie Code 的不只是一份可用表清单。

智能体可以使用语义搜索，即按含义而非精确文本检索资产。用户可能询问客户留存，却不知道官方表名。语义检索可以将该请求关联到与组织留存逻辑相关的表、notebook 或 dashboard。

持久化记忆带来了另一项优势。Databricks 表示，Genie Code 会记住用户依赖的表和业务逻辑。这种记忆可以避免智能体在每个会话中重复相同的发现过程。

深度企业上下文则完善了这一机制。业务术语往往具有因团队而异的定义。“活跃用户”“已确认收入”和“已解决工单”都可能依赖内部规则，而不是词典含义。

通用编程智能体可以从查询和文档中推断这些规则。Genie Code 的设计则是在进行大范围猜测之前，从工作环境中检索这些规则。

这一机制解释了为何更少的工具调用能够提升质量。每次调用都可能引入无关结果、低效扫描或错误分支。当系统消除了低价值探索而非跳过必要验证时，减少调用才有价值。

这一发现过程类似于有地图和无地图的导航。两个智能体都可以穿行于同一工作区，但其中一个从关于目的地、关系和可信路径的信息开始，另一个则通过逐扇开门来了解布局。

独立研究也支持这一问题的更广泛重要性。Data Agent Benchmark评估了异构系统中的数据工作，而非将任务局限于 SQL 生成。其作者构建了涵盖 12 个数据集、九个领域和四种数据库系统的 54 个查询。

该研究中表现最佳的前沿模型仅达到 38% 的 pass-at-one 准确率。由于任务、环境和评分者不同，这一结果无法与 Databricks 的内部评估直接比较。但它表明，端到端数据工作仍远比生成语法正确的查询困难。

另一项近期研究比较了开放网络检索与在元数据丰富的数据集上运行的语义智能体。语义元数据研究发现，对于可操作、机器可读的数据，结构化检索能够带来更高的准确率。

基线系统能够覆盖更多问题，但往往返回的是散文页面或门户落地页，而非可直接使用的数据集。这种取舍与 Databricks 的论点相呼应：广泛探索可以提高覆盖率，却会降低结果在实际操作中有用的概率。

对于企业智能体而言，找到相关内容还不够。所选资产必须可访问、最新、受治理，并且兼容预期的计算任务。

Genie Code 的架构正是围绕这一标准设计的。该智能体可以检查数据血缘，在用户权限范围内工作，并在 notebooks、SQL、管道、仪表板和机器学习工作流之间执行操作。

模型本身仍然重要。它必须理解请求、规划行动、编写代码、解读结果，并在证据不完整时识别出来。然而，周边的上下文系统决定了模型必须从零开始解决哪些问题。

这也是为什么这项基准测试更适合被理解为架构比较，而不是纯粹的模型竞赛。Databricks 并没有推出一个突然超越所有对手的新基础模型。它将前沿模型与专为一种复杂环境构建的上下文层结合在一起。

这种方法类似于计算领域其他地方的专业化。通用处理器能够执行许多工作负载，但专用索引、编译器和存储系统可以减少完成特定任务所需的工作量。底层能力依然重要，而系统设计决定了实际性能。

同样的逻辑也适用于智能体。更大的上下文窗口可以容纳更多 schema 和文档，但它无法决定哪个 schema 才是权威来源。更多的推理 token 可以支撑更长时间的调查，却不能保证调查从正确的证据开始。

Genie Code 的目标是在 token 消耗扩大之前解决这些选择问题。如果 Databricks 的发现能够推广，企业智能体的效率将越来越取决于系统已掌握的信息。

Databricks 的数据未能证明什么

这项基准测试支持一种可信的机制，但并未终结专业化智能体与通用智能体之间的竞争。

Databricks 从其内部 Genie Code 使用情况中构建了评估集。这一选择使任务更贴近产品目标环境中的真实情况，但也意味着环境和任务分布天然与 Genie Code 的设计相匹配。

内部基准测试可以揭示产品是否能处理其用户的工作，却无法自动证明同样的排名适用于其他公司、平台或数据架构。

三款编程智能体均未具名。读者无法审查每种产品的配置方式、运行的具体模型、引导它们的提示词，或其供应商是否会建议采用不同设置。

这些智能体使用各自的 harness，这反映了真实的产品行为。然而，harness 的差异让归因变得更困难。一次失败可能源自模型、工具选择策略、查询保护措施、上下文打包方式或超时管理。

独立评委也带来了另一层不确定性。Databricks 表示，回答根据正确性和实用性进行评分，但文章并未公布完整任务集、评委提示词或人工审计流程。

基于 LLM 的评审可以将评估扩展到数百次运行，但也可能继承任务描述和参考答案中的模糊之处。因此，一项可信的基准测试应披露足够细节，让其他人能够审查分歧并复现评估。

科技行业已经在编程基准测试中面对这一问题。OpenAI 最近报告称，一项审计发现 SWE-Bench Pro 存在严重问题。其评估审计估计，约 30% 的已审查任务存在缺陷。

这一发现并不会否定 Databricks 的基准测试。它说明，基准构建本身也应受到与模型性能同等程度的审查。即使是真实任务，也可能包含定义不足的指令、不完整的参考资料或评分缺口。

Databricks 的成本估算同样需要谨慎看待。该公司表示，这些数字代表对用户费用的估计，从相对比较角度看更具参考价值。实际部署会随模型选择、供应商合同、缓存、查询执行和平台控制而变化。

共同的 20 分钟限制也塑造了结果。时间限制是可比测试所必需的，但会奖励那些能迅速找到可行路径的智能体。若采用更严格的查询限制、更长的预算，或更好的工作区索引，通用智能体的表现可能不同。

还存在比较不同层面成熟度的风险。Genie Code 受益于 Databricks 原生元数据和产品集成。通过通用接口连接的编程智能体可能无法获得同样的语义表示，即使两者在技术上都可以访问该工作区。

这并不意味着对买家而言这种比较不公平。用户关心的是完整产品，而不是实验室条件下抽象模型的平等性。但这确实限制了对于“专业化本身是否造成了差距中每一部分”的结论。

该基准测试还禁用了 Genie Ontology，因为它尚未在全球范围内可用。Databricks 预计，该系统将通过组织业务概念及其关系来增强 Genie Code。在客户广泛使用之前，其额外影响仍属于公司的预期，而非既定结果。

安全与治理同样值得关注。持久记忆可以减少重复发现，但存储的上下文必须保持最新并具备权限感知能力。智能体不应仅仅因为另一位用户曾依赖某项资产，就将其呈现出来。

Databricks 表示 Genie Code 遵循 Unity Catalog 权限。买家仍应测试：当权限发生变化、表被弃用，或不同团队之间的指标定义出现冲突时，记忆会如何表现。

陈旧的语义上下文可能造成自信的错误。通用智能体的探索行为效率较低，但它能够暴露专业检索层可能掩盖的矛盾。最佳系统必须将定向检索与新鲜度和来源检查结合起来。

正确的结论比 Databricks 的标题更为有限：在该公司的评估设计下，Genie Code 在 Databricks 内部任务分布中优于三款未具名的编程智能体。报告中的优势与一种合理、且得到独立支持的架构机制相一致。

这一结果并不能证明每个数据智能体都会胜过每个编程智能体，也不能说明通用智能体无法获得等效的语义上下文。

这种区分之所以重要，是因为最可能的竞争回应是趋同。编程智能体将加入特定领域的记忆和检索能力；数据平台则会将其智能体扩展到更广泛的编程和运营任务中。

竞争不会持续停留在专业产品与永久缺乏上下文的通用产品之间。它将变成一场比拼：哪个系统能最有效地构建、更新、治理和应用企业上下文。

成本与质量正在成为同一个智能体问题

Databricks 最重要的论点是，浪费性的探索会通过同一条事件链同时损害准确性和成本。

人们常将智能体经济学视为模型定价问题。团队会比较 token 费率、上下文限制和单次工具调用的成本。这些指标很重要，但无法捕捉智能体在完整任务中的行为方式。

廉价模型在进行数十次不必要调用时也可能变得昂贵。更强大的模型同样可能浪费资源，如果它的 harness 不断向其输入无关的 schema 和失败的查询结果。

有意义的单位是获得一个正确、有用结果的成本。Databricks 强调这一指标，是因为它将质量与消耗结合起来。一个迅速定位到错误表的智能体，并没有带来节省。

发现错误会不断放大。智能体先选择一个质量较差的候选表，然后针对该表编写查询、解读输出、发现不一致之处，并开始另一轮搜索。每一步都会消耗 token，并增加再次作出错误假设的概率。

大规模扫描会带来额外风险。Databricks 表示，通用智能体出现超时，往往是因为它们针对超大表执行了低效且未设上限的查询。因此，智能体可能同时消耗模型资源和数据计算资源，却无法给出答案。

语义上下文会从上游改变这条成本曲线。如果智能体在查询前识别出可信资产，它就能避开整条分析分支。分支更少，意味着调用更少、提示词更短、输出更小，以及纠错推理更少。

这种关系使质量和成本成为同一检索问题的两种表达。更好的 grounding 能减少所需工作量；工作量减少，也就减少了智能体偏离轨道的机会。

因此，企业买家应评估执行轨迹，而不仅仅是最终回答。最有价值的问题在于：智能体如何找到来源、为何信任这些来源、检查了多少替代选项，以及消耗集中在哪些环节。

一次成功的回答仍可能暴露不稳定的过程。如果智能体经过漫长而随机的搜索才得到正确结果，工作区的一项小变化就可能让下一次运行失败。更短、基于证据的路径更容易审计和复现。

这种方法也改变了团队对上下文窗口的理解。向提示词加载更多材料看似更安全，因为答案可能就在其中。实际上，过多上下文会提高成本，并使相关证据更难以辨别。

经过筛选的语义检索提供了另一条路径。它通过元数据、血缘、使用模式和业务含义，向模型发送一组更小的资产。模型随后可以将推理预算用于任务本身，而不是工作区考古。

这并不意味着不再需要验证。数据智能体仍应检查新鲜度、行数、查询逻辑和来源之间的冲突。目标是让验证有明确目的，而不是将发现过程变成不受控制的扫描。

同样的原则也适用于持久记忆。只有当记忆包含来源信息，并且始终与工作区保持同步时，记住首选表才能节省时间。否则，昨天的捷径就会成为明天隐藏的错误。

考虑采用数据智能体的组织，应将元数据质量视为 AI 就绪度的一部分。糟糕的目录描述、重复的指标、被遗弃的仪表板和未文档化的转换，都会限制任何智能体，无论其模型为何。

专业产品拥有初始优势，因为它们能够利用外部智能体可能看不到的原生信号。平台活动可以揭示人们使用哪些资产、哪些查询反复出现，以及数据如何在系统之间流动。

通用编程智能体则保留另一项优势。它们可以跨代码仓库、终端、云控制台、工单和服务工作，而无需将每项任务都强行纳入一个平台。许多真实事件恰恰需要这种广度。

正在浮现的设计挑战，是将广泛行动能力与狭域专业知识结合起来。智能体应当跨系统移动，同时在每一步咨询特定领域的上下文层。无约束的探索与孤立的专业化，都无法解决每一种企业工作流。

Databricks 的基准测试捕捉了这一未来的一个侧面。它展示了当一个领域智能体带着语义地图进入工作区，而更广泛的智能体带着通用工具到来时，会发生什么。

据报道的结果更有利于地图。接下来的较量将检验：地图是否仍是平台优势，还是会成为每个严肃智能体的标准组件。

三个信号将检验 Databricks 的下一步理由

下一阶段取决于可复现性、有竞争力的上下文系统，以及外部客户提供的证据。

第一个信号是基准测试披露。Databricks 表示，正扩大基于真实任务的评估，并将继续发布结果。若能公开一个可供独立复现的测试子集，这一比较将更具说服力。

复现应包括任务定义、评分标准、智能体配置、超时规则，以及计算资源消耗的方法。还应说明如何在不抹去企业数据工作中关键模糊性的前提下，移除敏感信息。

如果独立运行仍能保持 Genie Code 在质量和效率上的领先，Databricks 的理由就更有力。若排名会因配置或评分方式而大幅变化，当前结果则更像是特定产品条件下的快照。

第二个信号是通用编程智能体厂商的回应。在这项测试中，通过 MCP 接入并未消除 Genie Code 的上下文优势。竞争对手如今需要具备理解数据资产的语义检索和记忆能力，而不只是暴露工具接口。

值得关注的是，编程智能体是否会吸收目录元数据、血缘关系、指标定义、查询历史和组织偏好。还要观察这些系统能否遵守不断变化的权限，并说明其为何选择某个信息源。

如果通用智能体在获得同等语义层后能够匹敌 Genie Code，那么“需要长期独立的智能体类别”这一论点就会被削弱。这反而会强化 Databricks 更深层的观点：上下文架构比单纯堆砌 token 使用量更重要。

第三个信号是客户在 Databricks 内部测试之外的表现。外部部署将面对更混乱的权限、更薄弱的元数据、混合平台，以及团队从未记录下来的业务定义。

最有价值的证据将包括任务完成率、超时频率、人工修正率和工具调用分布。买方还应考察准确性是否能覆盖数据发现、调试、管道创建和仪表盘工作等场景。

强劲的外部结果将表明，Genie Code 的上下文优势能够在塑造该产品的环境之外依然成立。疲弱的结果则可能意味着，该基准测试捕捉到的是一个异常有利的内部环境。

Genie Ontology 提供了另一项相关检验。Databricks 在已发布的对比中禁用了它，因为它当时尚未全球可用。其更广泛的发布将揭示：正式的业务概念层究竟能提升结果，还是会带来新的维护负担。

这些信号的重要性不止于数据工程师。产品经理、分析师和企业 AI 买方正越来越依赖智能体，将机构知识转化为行动。他们面临的最大风险，并不总是模型不会写代码。

更大的风险在于，智能体针对错误的数据源、过时的定义或无权访问的资产写出了看似可靠的代码。这类错误可能显得很精致，却依然在运营上毫无用处。

Databricks 提出了一个清晰的假设：在智能体开始搜索前为其提供语义上下文，质量可以提升，同时资源消耗可以下降。其 401 项任务的基准测试支持这一说法，但证据仍来自销售该产品的公司。

务实的回应既不是盲目接受，也不是一概否定。团队应在自身存在模糊性的工作流中测试智能体，并检查每个答案背后的路径。他们应衡量正确结果，而不只是活动量或 token 使用量。

这才是 Databricks 的真正理由。前沿正从能够执行更多步骤的模型，转向知道哪些步骤值得执行的系统。未来三个月将显示，这一优势究竟属于 Genie Code，还是更广泛的架构转变。