OpenRouter 上线实时网页搜索基准：如何为 Agent 选择搜索引擎、深度和模型

对大多数 LLM 请求来说，网络搜索是克服知识截止的必备手段。各家实验室和搜索提供商都在快速演进，让搜索更有效、更高效，这也让我们面临一系列棘手的选择：是采用某些实验室内置的原生搜索，还是接入 Exa、Parallel 或 Perplexity 这样的第三方引擎？一次搜索够不够，如果不够，我该让智能体继续搜索多久？更多的搜索轮次是否值得它们换来的质量提升？

我们构建了实时排行榜，帮助你用数据决定最佳的搜索配置。查看数据请访问我们新的 Benchmarks 页面。

我们对所有组合进行基准测试，以找出各自的优势与短板

在设置搜索请求时，你有四个决策点：

• 模型。负责写出提交给搜索引擎的确切查询，并处理返回结果。
• 引擎。你可以选择特定引擎，也可以依赖某些实验室提供的捆绑引擎。在 OpenRouter 上，我们提供 Exa、Parallel 和 Perplexity，以及来自 OpenAI、Anthropic 和 Google 等实验室的原生引擎。
• 搜索方式。你既可以在调用模型之前先执行搜索，把结果作为上下文传入，也可以给模型配备一个网络搜索工具，由它自行决定何时调用。
• 搜索预算。如果你选择搜索工具方式，还可以给模型设定一个允许执行多少次搜索的预算。这让模型可以在不满意结果时调整查询，或进行后续搜索。我们的运行使用 1、5 或 25 轮。

为了全面了解网络搜索的表现，我们定期在多个模型、引擎和搜索配置上运行四项基准测试：

• BrowseComp：需要真实浏览的硬核事实查找
• DeepSearchQA：多跳研究问题
• WideSearch：广泛的“填满整张表”式信息收集
• HLE：带搜索的专家考试题

每个页面都按质量、性价比和速度对配置进行排名，让你能根据对自身工作负载最重要的因素来做决策。排行榜是实时的，因此随着新运行结果落地以及新模型和引擎加入，数字会不断变化。今天的领先者未必是明天的领先者。本文不会花太多篇幅讨论当下的领先者，因为我们预计这会随时间改变。相反，让我们看看数据告诉我们，如何为你的工作负载做出决策。

搜索预算比其他任何因素都更重要

把引擎预算从一轮提高，对质量的提升超过你能做的任何其他单一改动。举例来说，这是我们在 Perplexity 上对 BrowseComp 的初始运行，覆盖三种不同预算：

这一模式在我们测量的所有提供商上都成立：

这些运行仅覆盖 BrowseComp，使用服务器工具，每次搜索返回十条结果，不进行页面抓取或代码执行，每个配置取最新的合格运行。

增加搜索深度是我们发现的提升质量最便宜的方式。从 1 轮增加到 25 轮，分数大约翻倍，而每个问题的成本只增加 2.5 到 7 倍。

你可能会认为这普遍会拖慢响应时间，但事实并非总是如此。例如，Luna 在 1 轮时每个问题耗时 140 秒，在 25 轮时为 111 秒。在我们同时以 1 轮和 5 轮运行的 35 种配置中，超过三分之一在轮数更少时反而更慢。这些全都是 OpenAI 的模型。这些模型通过额外的推理来应对受限的搜索预算。

另一方面，在较简单的任务上，搜索深度可能会损害成本。例如，在 HLE 上，GPT-5.6 Sol 搭配 Perplexity 在 1 轮和 25 轮之间得分相近，但成本却是三倍。如果你的搜索往往比较简单，那么限制预算可能仍然值得。

你最坏情况的成本由你的失败率驱动

预算扩大反而有害的另一种情况，是模型无法找到答案时。我们发现，即使模型最终会失败，它们也会耗尽预算去尝试寻找答案。

我们记录到的最深尝试，是在 WideSearch 表格上进行了 81 次搜索，但最终仍被评为错误。如果你的工作负载失败率很高，那么降低搜索深度很可能是降低成本的有效途径。

虽然引擎重要，但模型更重要

一旦预算设定好，下一个最重要的问题就是使用哪个模型。

上表展示了 25 轮时的 BrowseComp 结果，比较了前沿模型与预算模型在不同搜索引擎上的表现。

在保持模型不变的情况下更换引擎，得分平均变化 10 分，而前沿模型与高性价比模型之间的平均差距更大，为 15 分。在各引擎之间，前沿模型的成本差异最大，最贵的引擎成本是最便宜引擎的 2.5 倍，而高性价比模型为 1.5 倍。

之所以能进行这样的比较，是因为服务器工具位于提供商之上。在请求中更换模型，搜索行为保持一致，包括那些提供商自身不提供搜索的模型。

当然，基准测试只是可能性能的参考。它们告诉你哪些配置值得尝试，以及大致成本。这些选择在你自己的真实任务中的成本和质量会有所不同，所以你能用这些页面做的最有价值的事，就是把它们当作候选清单，然后把你自己的问题跑一遍前几个配置。

在你自己的工作负载上试试

以上所有内容都是你今天就可以在 OpenRouter 上设置的请求参数。

• Web 插件。web 插件在模型开始写作前运行一次搜索，对于只需要最新事实的问题来说，这是快速、便宜的选择。
• 服务器工具。服务器工具把搜索工具交给模型，让它决定接下来查什么，当答案需要好几步才能找到时，这正是你想要的。
• 引擎。在 OpenRouter 上，你可以将 engine 设置为 exa、parallel、perplexity 或 native；auto 会先尝试原生，再回退到第三方。
• 搜索预算。顶层请求字段 max_tool_calls 限制它获得多少智能体轮次，也就是在必须回答之前可以搜索多少轮，而 max_results 设置每次返回多少条结果。

一个合理的起点：选择最接近你任务的套件，在得分最高几分以内的配置中选最便宜的那个，然后用你自己的评估集重新测试它上面两三行的配置，看看多花的钱是否体现在你的结果中。

基准测试方法

每次运行都通过公共 OpenRouter API 针对生产端点进行，使用我们的开源基准测试工具。

• 仅限于搜索性能。为确保我们只比较搜索配置，我们统一设定每次搜索返回十条结果，不抓取页面，也不执行代码。推理按模型固定，如表所示。
• 评分严格。每个被评估的答案对照官方答案键判定对错，在需要语义比较时使用 LLM 评判。WideSearch 还单独报告答案项准确率。
• 成本和速度按问题计算。成本是总支出（包括评分）除以被评估的问题数。速度是每个被评估问题的候选生成时间。
• 每个页面显示每个配置的最新合格运行。一次运行在完成最少问题数后即合格，新运行会取代旧运行。

常见问题

这些分数与已发布的供应商智能体排行榜相比如何？

它们不能直接比较。这些基准的大多数已发布表格衡量的是结合搜索、完整页面抓取和代码工具的完整智能体产品。这些排行榜隔离了搜索配置：模型只读取搜索结果摘录，页面抓取和代码工具关闭。这允许在配置之间直接比较，但不会最大化基准分数。

我应该选择哪个搜索引擎？

这取决于模型和任务，这正是这些页面存在的原因。对于某些模型，引擎之间的差距很大，而对于其他模型则微不足道，而且提供商自己的原生搜索并不自动是其最佳选项。查看最接近你工作负载的套件的实时排行榜，结合分数阅读成本和延迟，并随时间重新检查，因为随着新运行的出现，排序会变化。

这些数字有多新？

排行榜始终显示每个配置的最新合格运行，这些运行在 OpenRouter 的基准测试工具上针对生产端点执行。新运行会取代页面上的旧运行。

在 Discord 的#feedback中告诉我们接下来应该对哪些引擎或模型进行基准测试。