Databricks 推出 Omnigent，统一 Agent 定义与 Web 搜索
Databricks 发布 Omnigent，把散落在多个 Agent 框架里的同一条逻辑收成一份定义，并统一模型调用与 Web 搜索。
一个工程团队为同一份客户信息补全逻辑，在 Claude Code、Codex 和裸 API 上各写了一遍，各自捆绑的 Web 搜索返回的数据还不一样。Databricks 的 Omnigent 想坐在这些工具之上：Agent 只定义一次，模型、工具、策略和成本都在一处管控。
正文摘录
你继承下来的那套 Web Search，撑不起你的 Agent 在 Omnigent 里把 agent 定义一次，Nimble 在哪里运行都能选它。 一家软件公司的工程师正在构建一个 agent，用来让公司对市场的认知保持最新。它监控几十万个潜客与客户账户，捕捉那些说明账户愿意互动的信号：新一轮融资、管理层变动、产品发布，或者暗示有预算的招聘激增。 账户记录本身已经在 Databricks 里，位于受 Unity Catalog 治理的 Delta 表中，并已与公司自己的用量数据和销售管道数据做了 join。但真正推动一个账户变化的信号，住在公司之外——在 Web 上。这个 agent 的任务就是持续把这两者合成一张连贯、实时的全景图，覆盖每一个账户，从而告诉销售这周该打那几通电话。 第一版并不是一个系统。同一套 enrichment 逻辑（为账户补齐外部信息）被从零重建了三遍，每用一种工具就重来一次。第一版跑在 Claude Code 里，其中 agentic 的部分（判断哪些账户需要重新扫描、串联搜索、撰写摘要）占了大部分工作量。当同事提到 Codex 处理某类批处理脚本更快时，工程师就把 enrichment 循环移植过去验证。第三份拷贝干脆完全跳过 harness（承载 agent 的运行框架），直接用 API 调模型，用于一个轻量的 nightly job，只需要一次 prompt 和一次响应，不需要任何工具编排。同一个任务，三次构建，每一次都被当时手边最顺手的工具塑了形。 每个 harness 都自带自己的工具和自己的 Web Search，并按自己的方式把它们接起来，所以工程师把同一套 enrichment 逻辑建了三遍，每一遍都要适配对应 harness 的配置格式。一天就这么过去了。