Mozilla AI 提问：谁在为你的智能体搜索网络？

Mozilla AI 正通过 Otari 对捆绑式智能体搜索提出挑战；该产品让团队能够独立于模型选择搜索服务。谁在为你的智能体搜索网络？其 10 月 19 日的文章将这个问题具体化：选择 AI 模型，并不必然决定其搜索查询会流向何处。

Otari 位于智能体（即使用工具完成任务的软件）与模型提供商之间。Mozilla AI 表示，这一位置使其能够在保留受支持客户端接口的同时重定向搜索。该方案所涉及的改变，是由谁控制信息检索，而非由哪个模型撰写答案。

两种竞争方案很直接：接受随模型服务捆绑的搜索，或将搜索作为独立依赖项进行管理。Claude Code 是一个有用的参考，因为其内置搜索使用 Anthropic 的后端。Otari 则通过将搜索路由变为独立决策来挑战这种安排，同时也将额外责任交给作出该决策的一方。

谁在为你的智能体搜索网络？Otari 让选择变得明确

Mozilla AI 在其 智能体搜索分析中描述了三种选择：由 Otari 运营的搜索、客户自己的搜索账户，或自托管端点。该公司列举了 Brave、Exa 和 Tavily，作为客户可以使用自有凭据连接的服务。

据 Mozilla AI 称，客户可以在更换处理搜索的服务时保留 Claude、GPT 或 Gemini。搜索凭据保留在负责路由请求的中间层网关中，而不会传递给智能体。该公司还介绍了与模型使用相关的工作区控制和搜索记录。

其影响深远的改变，是让团队能够将搜索作为独立于模型之外选择的依赖项。

当应用只呈现一个答案输入框时，这种区别很容易被忽略。用户提出问题、等待，然后收到含有引用的回复。即使由不同服务分别执行检索和推理，界面也可能让它们看起来像一次操作。

将这些操作分离，会改变买方评估系统的方式。模型评估回答的是模型是否能遵循指令并有效推理。搜索评估则考察系统是否检索到合适证据、能否妥善处理查询，以及是否满足组织的运营要求。

两种评估不能互相替代。再好的推理也无法找回从未进入证据集的文档。强大的检索也无法阻止每一个缺乏依据的结论。分别对待二者，能让团队更清晰地调查故障，而不将一切都归咎于模型。

Mozilla AI 的文章也应被准确理解为对产品方向和已记录能力的说明。其发布日期并不能证明每项底层功能何时都已可用。该公告也不能证明客户已经获得了更好的答案或更低的运营成本。

因此，眼前的新闻范围比“智能体搜索已被解决”的说法更窄。Mozilla AI 正将搜索供应商变为采购和架构讨论中的明确组成部分。这为接受所选模型附带的任何检索服务提供了一个切实可行的替代方案。

对于已经满意于捆绑搜索的团队，这一替代方案需要证明其运营负担是合理的。对于受不可接受的搜索安排阻碍的团队，将该依赖项分离则是在解决完全不同的问题。他们需要的是一个可以评估的选择，而不是另一份模型排行榜。

查询本身也值得审视

搜索查询是一种对外披露，即使所请求的答案涉及公开信息。

设想一名代码助手正在调查软件故障。一个有用的公开查询或许会描述错误信息和库的版本。一个不必要地过于具体的查询，则还可能包含内部服务名称、客户标识符或尚未发布的项目名称。

这里的区别在于什么信息离开了组织，而不是公开文档是否可以安全阅读。助手可能有合理理由进行搜索，却仍可能构造出不恰当的查询。选择搜索供应商解决的是接收方问题；审查查询构造解决的是内容问题。

这种分离对工程经理和企业买家很重要。批准某个模型，并不能回答有关其附带工具的所有问题。每增加一项服务，就引入一种值得单独评估的运营关系，尤其是在查询源自私有工作上下文时。

合理的应对方式是追踪一项实际任务。哪些信息进入了提示词？哪些文本变成了搜索查询？哪个服务收到了它？返回了哪些结果，其中哪些结果影响了答案？

这些问题让采购讨论变得更具体。它们也揭示了某项主张的边界。知道目的地可以建立对路由的可见性，却不能证明每个查询都有必要、措辞恰当，或受到可接受处理条款的约束。

同样的推理也适用于客户研究。设想一名助手正在为潜在客户准备简报。公开的公司信息本就属于研究流程的一部分。私密的销售记录、拟议合同措辞和内部评估，在出现在外部查询前则需要作出单独决定。

这些是说明性场景，并非有文档佐证的 Otari 客户部署案例。它们的价值在于表明，搜索选择的重要性不仅在于开发者偏好。一次看似普通的查询，可能跨越最终答案无法揭示的边界。

知识工作者还需要区分公开发现与搜索自己的材料。个人知识库 所满足的信息需求，不同于寻找新的公开来源。有效的工作流应在决定去哪里搜索之前，先识别任务需要哪种证据。

对于产品经理而言，这可能意味着在请求最新竞品信息前先查阅内部研究。对于工程师而言，这可能意味着在查找公开文档前先核查私有设计决策。重点在于有目的的检索，而不是将每一个不确定性都发送到开放网络。

这给批准智能体部署的人带来了压力。他们需要足够的可见性，以解释信息路径及其边界。公开搜索目的地的产品可以支持这种解释，但组织仍必须决定哪些信息应当进入这条路径。

谁在为你的智能体搜索网络？对买家而言，一个充分的答案应包括运营方、相关协议以及所发送信息的范围。仅仅说出一个知名模型的名称，并不能完成这个答案中有关搜索的部分。

捆绑搜索提供便利，而独立搜索增加问责

捆绑搜索最有力的理由是便利。开发者无需自行组装检索的每个部分，便能获得受支持的工具接口。当组织的要求与提供商服务及其已记录行为相符时，可能会偏好这种安排。

Anthropic 的 网页搜索工具 展示了集成式方法。Claude 决定何时搜索，服务执行搜索，最终回复包含引用。其文档还介绍了域名控制和不同的工具版本。

这些能力很重要，因为可配置搜索并非独立网关独有。客户应区分对搜索行为的控制与对搜索供应商的控制。提供商可以提供有用的限制，同时仍负责运营底层服务。

核心选择在于：谁拥有检索决策，以及谁承担维护它们所需的工作。

Otari 的主张吸引希望拥有这种控制权的团队。但独立性也带来了捆绑服务所承担或简化的责任。必须有人管理凭据、评估服务行为、调查故障，并维护智能体与其搜索工具之间的正常关系。

Ollama 提供了另一个有用的比较。其 托管网页搜索 文档规定了对 ollama.com/api/web_search 的认证请求。响应包含结果，其中含有页面标题、地址和内容摘要。

这个例子证明了一个有限但重要的观点：使用本地模型并不能证明其网页搜索会保留在本地。文档中描述的搜索请求会到达托管服务。在评估处理发生的位置时，客户需要分别审查推理、搜索和页面检索。

这并不意味着托管搜索天生不合适。当其条款、行为和可靠性满足组织需求时，托管服务可以是可接受的选择。真正的问题在于假设一项架构选择会自动决定其他每一个组件。

同样的严谨也适用于答案质量。更换搜索服务会改变模型可获得的证据。同时更换模型和搜索的评估，难以解释究竟是哪项改变改善或损害了结果。

将这些变量分离，有助于进行更有信息量的比较。团队可以在考察检索时保持模型不变，再在考察综合能力时保持证据不变。这类评估仍需谨慎设计，但能避免将整个应用视为不可分割的黑箱。

因此，对 Otari 网页搜索的评估应从团队自身的任务开始。公开文档查询、最新企业研究和专业技术发现，可能需要不同的证据。若要普遍声称某一搜索服务最佳，则需要超出这些个别工作负载的证据。

Mozilla AI 的公告没有提供证明存在此类胜者的独立比较研究。更有力的解读是，客户应该能够选择和测试这一依赖项。这是在主张控制与评估，而非展示搜索引擎的排名。

压力同时落在两种方案上。捆绑服务提供商需要足够清晰地说明其搜索安排，供买家进行评估。独立基础设施则需要证明，在客户端、模型和工具接口发生变化时，额外控制权仍然可用。

Otari 网页搜索依赖于保留客户端的预期

可配置搜索服务只有在智能体能够正确使用时才有帮助。应用需要的不只是一份链接列表。它们依赖于可识别的工具响应、错误行为，以及足够的来源信息来继续完成任务。

Otari 的 搜索拦截文档 描述了在启用拦截时接管受支持的、以提供商命名的搜索声明。拦截意味着处理原本会发送给提供商工具的请求。该文档将这种行为与转发提供商原生请求区分开来。

它还描述了工作区限制，包括禁用搜索、限制结果数量以及缩小可搜索域名范围。文档警告称，捆绑的 SearXNG 设置在持续使用时会受到速率限制。在评估生产就绪程度而非短暂演示时，这一警告至关重要。

保留接口可以减少集成工作，但并不意味着行为完全一致。

客户端可以接受响应，却获得不同的证据。它也可能正确处理一次成功的查询，却在服务不可用时反应不佳。因此，兼容性需要涵盖正常运行，以及中断正常运行的各种情况。

一个假设性的编码任务能让这种差异显现出来。助手搜索迁移指南，阅读结果，并提出代码变更建议。一项有价值的评估会考察：检索到的指南是否对应相关的软件版本，以及它是否能支持所提出的变更。

当搜索没有返回结果时，同一任务也应当依然易于理解。能够清晰报告证据缺失的代理，与即兴编造答案的代理，其行为截然不同。网关的响应格式很重要，但客户端如何理解失败也同样重要。

这正是仅基于答案流畅度的比较会产生误导的地方。一段精致的说明可能掩盖薄弱的证据。能够说明自身局限、即使不那么流畅的回答，对于影响重大的技术决策反而可能更有用。

Otari 的搜索配置文档记录了具名搜索实例和默认选择。它还说明了特定供应商的设置和凭据要求。这些细节表明，搜索独立性是一种运行配置，而不只是提示词中表达的偏好。

对于平台团队而言，配置会带来熟悉的维护问题。谁可以更改默认设置？变更如何传达至不同工作区？哪些证据能够证明请求使用了预期的服务？这些问题的答案决定了控制权能否在日常组织活动中持续存在。

一项设置可以存在，却未必成为有效政策。评估需要确定在实际部署配置下会发生什么，包括允许的例外情况。否则，对可选搜索的演示可能被误认为是对每一次生产请求的保障。

当应用程序有多种途径访问外部信息时，这一区别尤其重要。搜索工具、页面抓取器和浏览器可能代表不同路径。控制其中一条路径，并不意味着控制了所有路径。

这一观察是一项架构考量，并非认定 Otari 存在特定绕过方式。采购方应要求与其客户端和已启用工具相匹配的覆盖证据。“所有代理流量”之类的宽泛表述，需要比一次成功拦截的搜索更广泛的验证。

这一机制很有前景，因为它将路由决策置于模型判断之外。它的实际价值取决于周边应用是否始终使用受控路径。评估必须跟踪完整任务，包括预期路径失效的时刻。

自托管改变责任归属，但不会消除依赖关系

自行运行搜索中介服务，并不意味着运营一个独立的网络索引。

SearXNG 的元搜索架构会聚合其他搜索引擎的结果。这使自托管的含义变得明确：组织可以运营聚合服务，同时仍依赖上游搜索引擎提供结果。

对于使用 SearXNG 的 Otari 部署而言，这一区别能够避免夸大的隐私主张。运营方控制自己的实例，但该实例配置的上游关系依然重要。完整评估应当让查询追踪越过组织的第一台服务器。

这是检验更广泛主张的一项有用的审慎测试。如果自托管被描述为完全独立，元搜索会使这一承诺变得复杂。如果它被描述为对既定组件的控制，这一主张就更为有限，也更易于评估。

同样的严谨性也应适用于成本比较。取消捆绑搜索费用，并不会消除运营检索服务的工作量。基础设施、维护、事件响应和员工投入，都应纳入评估，即使它们并未以每次查询的账单形式出现。

没有依据可以断言自托管在所有情况下都更便宜。相关比较取决于工作负载、服务要求以及组织现有能力。已经运营相关基础设施的团队，与缺乏这类专业能力的团队，面临的是不同的决策。

凭据控制同样需要精确解读。让凭据远离代理可减少一种暴露路径。持有这些凭据的服务仍是敏感系统，需要适当的管理和访问控制。

搜索记录带来另一项权衡。它们可以帮助解释代理为何生成某个答案，但也可能保留敏感查询文本。寻求可问责性的组织应决定谁可以查看这些记录，以及它们在多长时间内仍有价值。

因此，更高的可见性本身也带来治理任务。详细记录并非在所有情境下都自动更好。目标是为调查提供足够证据，同时制定与记录所含信息相适应的处理规则。

域名限制同样具有边界明确的价值。它们可以约束符合条件的信息源范围，却不能证明每个获允许域名上的所有页面都准确、最新，或适合具体任务。

选择搜索供应商也无法解决提示词注入问题，即旨在重定向助手行为的恶意内容。检索到的页面仍是外部输入。代理必须将其视为需要评估的证据，而不是对其任务拥有权威的指令。

这些限制并未否定独立搜索的价值。它们界定了这一主张所能支持的范围。选择一种依赖关系，为组织提供行使判断的空间；但这并不能保证判断必然正确。

可信的结果是对可识别选择承担更多责任。采购方可以询问为何选择某项服务、哪些假设支持这一选择，以及何种情况会触发变更。即使最终选择的是托管供应商，这些问题仍然有价值。

Otari 的网络搜索部署应依据这些具体责任来评判。仅凭公告，无法证明其检索效果更优、具有普遍兼容性，或能实现完整的隐私结果。来自团队实际环境的证据必须支撑这些结论。

关注兼容性、比较证据和供应商披露

下一个观察期应关注可观察到的变化，而不是有关更开放 AI 技术栈的承诺。到 2026 年末和 2027 年初，有价值的信号在于独立搜索是否变得更易运营、更易评估。

最有力的证据将表明，在真实任务中，包括故障和变更发生时，控制依然可靠。

第一个信号是针对团队实际使用的客户端和工具接口所发布的兼容性证据。一项有用的发布应明确已测试的行为、支持的版本和已知限制。可复现示例将增强这一论点：客户可以在更换搜索服务的同时保留其应用程序。

相反，反复出现的客户端专属变通方案会削弱独立性的实际主张。如果每次替换都需要大量修复应用程序，那么理论上可替换的服务提供的自由度就十分有限。随着周边软件不断演进，兼容性仍需保持可理解性。

第二个信号是在受控工作负载下开展比较评估。保持模型和任务不变，再考察检索相关性、时效性、响应时间、失败情况和总体运营投入。结果应指出每种安排在哪些场景下有效，包括捆绑搜索仍然更可取的情况。

一项令人信服的评估会公布足够细节，使读者理解其边界。文档查询的结果不应被延伸为关于所有研究任务的主张。选择性优势的证据，会比未经解释的整体优越性宣称更可信。

第三个信号是捆绑供应商提供更清晰的披露或额外的供应商选择。更明确的文档能帮助客户在不采用另一层中介的情况下评估现有服务。由供应商支持的选择也将检验：客户主要追求的是独立性，还是仅仅需要更清晰的控制。

这种发展将强化 Mozilla AI 的核心论点，同时改变 Otari 的竞争地位。即使采购方在其他地方行使这种选择，搜索仍会成为更显性的采购决策。持久的问题在于：谁能够做出并解释这一决策。

谁在为你的代理搜索网络？随着这些信号的发展，答案应变得更具体。它应指出实际的信息路径及其使用依据，而不是依赖从模型名称中推导出的假设。

在扩展代理工作流之前，应从提示词到最终答案审查一项具有代表性的任务。识别出站查询、其接收方、返回的信息源，以及支持结论的证据。然后询问，这种安排是否符合工作内容的敏感性和目的。当捆绑搜索的已记录行为满足这些需求时，应继续使用它。当供应商选择、运营控制或更清晰的记录能够满足具体要求时，再评估独立搜索服务。对于结合私有知识和公开研究的任务，应明确审视这一边界，而不要将每次查询都视为同一种情况。下一步应形成团队能够解释的决策：该代理应使用哪种搜索服务，以及哪些证据能够证明这一选择合理？