搜索准确率从46%到71%，成本还砍了一半

一个工程师在软件公司里搭了个智能体，任务是盯住几十万个潜在客户和存量客户账户，捕捉那些说明"这个客户可能愿意聊聊"的信号：新一轮融资、管理层变动、产品发布，或者招聘规模突然放大——那通常意味着预算要动了。

账户数据本身就在 Databricks 里，躺在受 Unity Catalog 治理的 Delta 表中，还和公司自己的用量数据、销售管道数据做了关联。但真正推动账户状态变化的信号在公司外部，在公开网络上。这个智能体要做的事，就是把两边合起来，持续合成一张关于每个账户的、连贯且随时更新的图景，好告诉销售这周该打哪几个电话。

第一版：能跑，但一团乱

第一版不是一个系统，而是同一套信息补全逻辑被从零重建了三遍，工程师每换一个工具就重写一次。

第一遍跑在 Claude Code 里，智能体该干的部分——判断哪些账户需要重新看一眼、串联多次搜索、写出摘要——占了大部分工作量。后来同事提到 Codex 处理某类批处理脚本更快，工程师就把补全循环搬过去验证。第三份副本干脆绕开工具框架，直接通过 API 调用模型，用于一个轻量的夜间任务，只需要一次提问和一次回答，不需要工具编排。同一件事，三次构建，每次都被当时顺手的工具塑了形。

每个工具框架都自带一套工具、自带一个网络搜索，并按自己的方式接线，所以工程师得把同一套补全逻辑按三种配置格式各写一遍。一天的时间就耗在这里。本该用来改进账户补全效果，结果全花在学 Claude Code 要求怎么声明工具、为什么同一个 MCP 服务在 Codex 里连法不一样、以及裸 API 路径缺了另外两条路免费自带的东西。

工具不等价，结果自然也不等价。一个框架里内置的网络搜索，返回的数据和另一个不一样。在一个里能触达的信息源，在另一个里就被漏掉了。面向大模型的内置网络搜索工具能找到融资轮次、管理层变动这类高层信息，却会漏掉技术栈变化这类颗粒度更细的细节。获取线上信息正是这个智能体存在的理由，但它的质量现在取决于一个无法可靠呈现关键细节的网络搜索。

而且这三套东西上面没有任何统一层。没有共享的计量表，所以没人看得见、也管不住一轮跑几十万个账户要花多少钱。没有共享的规则手册，所以智能体可以读哪些源、什么时候需要人工签字，要么被设成三套，要么根本没设。没有共享的记录，所以当一个结果出错时，没有任何地方能还原智能体读过什么、花了多少、做了什么决定。

它算是能跑，因为它能产出结果。而这恰恰是它永远不会被修好的原因——好用到了值得留着，但没好用到能完全信任。

把散落的定义收成一份

Omnigent 就是用来收拢这种蔓延的一层。它坐在各个工具框架之上，让工程师只定义一次智能体：跑在哪个模型上、能触达哪些工具、在什么策略和限制内运行。三次重建塌缩成一份定义，工程师的注意力回到账户补全本身。工具不再是各框架捆绑什么就是什么，而变成智能体上的声明，设一次，自由替换。

跑在 Databricks 托管的模型上时，模型调用经由 Foundation Model APIs 路由，每一次调用都被记录下来，用于成本、审计和治理，集中在一处，而不是散落在三个运行时里。当模型或成本结构变化时，工程师改一行就行，换一个新模型或者降级到更便宜的模型，不造成中断。

这解决了大部分蔓延问题，但留下了一件关键的事——它由默认值决定，而不是由设计决定。网络搜索是每个工具框架都会捆绑的核心能力之一，但没有两个框架捆的是同一个。同一个查询，走 Claude Code 是一个结果，走 Codex 是另一个结果。Omnigent 提供了在每个任务上定义一致选择的能力，但它不替你做决定，你得自己指派一个搜索能力伙伴。

把搜索这个槽位填上

接入 Nimble 这样的伙伴，就能往这个槽位里放一个会随任务自适应、并让底下每个框架拿到同一份专家级解读的东西。

Nimble 的搜索 API 能通过实时搜索，把答案建立在新鲜的、实时的网络数据之上。对于深度研究类任务，Nimble 的网络搜索智能体会自动编排搜索与抽取流程来完成你的任务，同时处理多个信息源、交叉核对，返回一个带引用的答案，为每一项论断提供依据——这是一条通用路径永远产不出的审计线索。

通用网络搜索工具对所有用例一视同仁，而 Nimble 专攻智能体的具体用例，自学最佳的检索方法。

落到数字上：Nimble 的网络搜索把基准准确率从46%提到了71%，同时把搜索成本砍掉了一半。

一份智能体定义，替代了三次重建；模型调用经由 Databricks Foundation Model APIs 路由，换来统一的成本与治理；搜索槽位交给 Nimble，换来准确率和成本的双重改善。定义一次，在任何地方运行。