Agent内置网页搜索不够好：跨工具重复构建

一个需要接触外部世界的智能体

一家软件公司的工程师正在构建一个智能体，用来让公司对市场的认知保持最新。它监控数十万个潜在客户和客户账户，寻找表明某个账户愿意互动的信号：新一轮融资、领导层变动、产品发布，或表明有预算的招聘激增。

账户记录已经存放在 Databricks 中，位于由 Unity Catalog 治理的 Delta 表里，并与公司自己的使用数据和销售管道数据相连接。但推动账户变化的信号存在于公司之外，在网络上。这个智能体的任务是把两者结合起来，持续地整合成一幅关于每个账户的连贯且实时的图景，从而能告诉销售人员本周该给哪几个账户打电话。

1.0 版：一个勉强可用的烂摊子

第一个版本并不是一个系统。它是同一套丰富化逻辑，从头重建了三次，在工程师当时随手使用的每个工具中各建一次。第一遍在 Claude Code 中运行，其中智能体相关的部分（判断哪些账户需要重新查看、串联搜索、撰写摘要）占了大部分工作。当一位同事提到 Codex 处理某类批处理脚本更快时，工程师把丰富化循环移植过去验证。第三份副本完全跳过运行框架，直接通过 API 调用模型，用于一个轻量的夜间任务，只需要单个提示和响应，不需要工具编排。同样的工作，三套构建，每一套都由当时最合适的工具塑造。

每个运行框架都捆绑了自己的工具和自己的网页搜索，并以自己的方式连接它们，所以工程师把同一套丰富化逻辑构建了三次，在每种运行框架的配置格式中各一次。一天的时间就这样过去了。工程师并没有改进账户丰富化的方式，而是在学习 Claude Code 希望如何声明工具、为什么同一个 MCP 服务器在 Codex 中连接方式不同，以及原始 API 路径缺少了另外两者免费提供的东西。

这些工具并不等价，因此结果也不等价。一个运行框架中捆绑的网页搜索返回的数据与另一个不同。在一个中可访问的来源在另一个中会被遗漏。面向 LLM 的内置网页搜索工具可以找到高层次信息，比如融资轮次和领导层变动，但会遗漏细粒度的细节，比如技术栈变化。获取在线信息正是这个智能体存在的目的，但它的质量如今取决于无法可靠地在网络上呈现关键细节的网页搜索。

而且没有任何东西统辖这三者。没有共享的计量，所以没人能看到或限制一个周期在数十万个账户上的成本。没有共享的规则手册，所以智能体可以读取哪些来源、何时需要人工签核，要么被设成三套，要么根本没有设置。没有共享的记录，所以当结果出错时，没有任何地方可以重建智能体读了什么、花了多少、决定了什么。

它算是能工作，因为它能产出结果。而这恰恰是它永远不会被修复的原因。它工作得足够好，可以保留，但还不足以完全信任。

Omnigent：一次定义，适配任何运行框架

Omnigent 是约束这种蔓延的层。它位于各个运行框架之上，因此工程师只需定义一次智能体、它运行的模型、它可以访问的工具、它运作所遵循的策略和限制。三套重建塌缩为一个定义，工程师的注意力回到账户丰富化上。工具不再是每个运行框架捆绑的那些，而是成为智能体上的声明，设置一次即可自由替换。运行在 Databricks 托管的模型上，模型调用通过 Foundation Model APIs 路由，每次调用都在一处被捕获，用于成本、审计和治理，而不是分散在三个运行时中。而当模型或经济性发生变化时，工程师只需改一行，选择一个新模型或降级到更便宜的模型，而不会造成中断。

这解决了大部分蔓延问题，但留下了一个关键的东西，它是由默认决定的，而不是由设计决定的。网页搜索是每个运行框架都捆绑的核心能力之一，而没有两个捆绑的是同一个。同样的查询通过 Claude Code 给出一个结果，通过 Codex 给出另一个结果。Omnigent 让你有能力为每个任务定义一致的选择，但它不会替你做出决定。你必须指定一个合作伙伴搜索能力。有了像 Nimble 这样的合作伙伴，你可以在那个位置放入能适应任务的东西，并让下面的每个运行框架获得同样的专家级解读。

Nimble：填补搜索空位

Nimble 的 Search API 可以通过实时搜索，把答案建立在新鲜、实时的网络数据之上。对于深度研究任务，Nimble 的 Web Search Agents 自动化网页搜索和抽取编排以完成你的任务，处理许多来源、交叉核对它们，并返回带有引用以支撑每个断言的答案，这是通用路径永远无法产生的审计轨迹。

通用网页搜索工具对所有用例一视同仁，而 Nimble 专注于智能体的特定用例，自学最佳检索方法，并调整网页搜索和抓取，深入领域以捕获通用搜索工具遗漏的数据。它能获取 JavaScript、过滤器和分页背后的数据，而普通爬虫会放弃这些。而且因为它记住了检索相关数据的最佳方式，它会复用数据检索路径，而不是从头重新发现一切，从而降低 token 成本。在配置中被指定为提供方，这就是为你的智能体获得更完整网络上下文的快速路径。

在 Nimble 的测试中，加入 Nimble 的网页搜索将 LLM 基准准确率从 46% 提升到 71%，同时将网页搜索成本减半（Claude 对比 Nimble网络搜索成本）。Web Search Agents 可以被指向某个领域并留在那里，因此它会记住哪些来源和哪些检索路径产出了正确的数据，并在下次复用它们。它在某个领域工作得越久就越敏锐，而在它最常运行的账户上，重新发现某个信号位于何处的成本会下降。

版本 2.0：在 Databricks 和 Nimble 上一次性构建

回到这位工程师，该智能体现在正走在成为连贯、可管理、可信整体的道路上。该智能体在 Omnigent 中一次性定义，运行在 Databricks 托管的模型上，其工具、策略和限制都在单一规范中。三次重建已成为过去。管道维护税也已成为过去；这位工程师重新回到数据丰富化上，而不是纠结于每个 harness 希望如何声明其工具。

网络搜索现在是一个决策，而不是三个。在 web_search 内置工具上指定 Nimble，会让底层每个 harness 都指向同一个 Nimble Search API，以实现快速高效的网络搜索：

对于那些需要可辩护答案而非原始网络数据的账户，Omnigent 可以调用 Nimble 的 Web Search Agents，它们为研究、数据丰富化或数据集构建自动化网络搜索和提取。

密钥来自 Nimble 账户，你可以免费开始。

控制现在只有一个归属地。模型调用在治理下经由 Foundation Model APIs 路由，成本在一个地方可见并有上限，而智能体读取、花费和决定的内容都在一个治理面上被一致地捕获。

而图景的两半终于合在一起。Databricks 中的内部记录和来自 Nimble 的外部信号，在同一处，被同一个智能体治理和读取。版本 1.0 是三个 harness，却没有一个观察点。这是一个智能体，以公司所知和网络所能告诉它的内容为基础，在数据已经所在的地方运行。它在过去漂移之处保持一致，在过去浅薄之处保持深入，并对外部网络上下文检索拥有完整治理。

今天就来试用

搭建起来只需两步。

将 Omnigent 连接到 Databricks。Databricks 为你运行 Omnigent 服务器。在你自己的机器上，安装带 Databricks 集成的 CLI，并将该机器注册为主机：

然后使用你的工作区身份登录，并在 Databricks 托管的模型上运行你的第一个智能体。Databricks 上的 Omnigent是起点；它端到端地介绍了托管设置，并链接了 CLI 步骤。首先需要检查两个前提条件：必须为你的工作区启用 Omnigent Beta，并且工作区必须位于支持 Unity AI Gateway 的区域。对于其他安装方法和要求，完整的安装参考中都有。

你的智能体运行在托管服务器上，因此相同的会话会跟随你跨越每个界面：

• 你安装所用的终端，
• 桌面应用，一个原生窗口，带有通知和用于等待你的智能体的程序坞徽章
• 移动端，原生 iOS 和 Android 应用，或在任何手机浏览器中通过输入你的工作区 URL 使用 Web UI

将搜索指向 Nimble。在 web_search 内置工具上指定 Nimble，也就是前面那一行改动，每个 Databricks 托管的智能体都会通过它为其答案提供依据。对于可辩护、可审计的工作，请使用研究流程。Nimble 连接器文档涵盖了这两者。你需要一个 Nimble 密钥，开始免费试用即可获取一个。

内部记录已经属于你。这就是让你的智能体对网络其余部分进行推理所需的一切，并由同一个平台同时承载这两半。