Новые инструменты Web Search и Web Fetch от OpenRouter: Полное руководство

Разработка интеллектуальных агентов на базе больших языковых моделей (LLM) часто упирается в одну фундаментальную проблему: разрозненность инструментов. Если вы строите сложного агента, способного самостоятельно искать информацию в интернете, вы сталкиваетесь с тем, что каждый провайдер моделей — будь то OpenAI, Anthropic или Google — предлагает свои собственные, несовместимые друг с другом механизмы интеграции. Это создает технический долг еще до того, как вы напишете первую строку логики вашего приложения. Сегодня OpenRouter решает эту проблему, выпуская два новых серверных инструмента: openrouter:web_search и openrouter:web_fetch. Это не просто очередная функция, а архитектурный сдвиг, который позволяет разработчикам писать код один раз и запускать его на любой модели без переписывания логики взаимодействия с интернетом.

В этой статье мы подробно разберем, как работают новые инструменты, почему они превосходят старые плагины, как настроить параллельные запросы для экономии контекста и как правильно мигрировать существующие проекты. Мы рассмотрим технические детали, а также примеры конфигураций, которые помогут вам интегрировать эти возможности в свои AI-продукты.

01Проблема «разнообразия» инструментов и решение OpenRouter

Раньше, если вы хотели, чтобы ваша LLM могла искать информацию в интернете, вам приходилось использовать так называемые плагины. Однако этот подход имел критические недостатки. Во-первых, каждый провайдер моделей имел свой собственный встроенный инструмент поиска с уникальной схемой данных. Переключение с одной модели на другую (например, с GPT на Claude) требовало переписывания кода: нужно было менять способы определения параметров, конфигурации и парсинга результатов.

Во-вторых, поведение инструментов не было гарантированно одинаковым. Если вам требовалась строгая фильтрация доменов или специфические настройки контекста, вы могли обнаружить, что новая модель просто не поддерживает эти функции. Это создавало хрупкую архитектуру, где логика приложения была жестко привязана к конкретному провайдеру.

Новые серверные инструменты openrouter:web_search и openrouter:web_fetch устраняют эту проблему. Они работают на стороне сервера OpenRouter. Когда модель принимает решение использовать инструмент, OpenRouter выполняет запрос самостоятельно и возвращает результат модели в унифицированном формате. Вам больше не нужно реализовывать клиентскую часть для выполнения HTTP-запросов. Вы просто указываете тип инструмента, и система делает всю грязную работу.

02Web Search: Гибкий поиск с выбором движка

Инструмент Web Search предназначен для агентов, которым нужно выполнять поиск от нуля до N раз за один запрос. Это дает модели полную автономию: она сама решает, когда искать, какие запросы формулировать и сколько результатов нужно проанализировать. Поддерживаются четыре основных движка поиска, каждый из которых имеет свои особенности.

Движки поиска: сравнение и выбор

Выбор движка критически важен для качества результатов и контроля затрат. Вот подробный разбор доступных опций:

• Auto (по умолчанию): Система автоматически использует нативный поиск провайдера модели, если он доступен. Если нативного поиска нет, используется Exa. Стоимость варьируется в зависимости от выбранного провайдера.
• Native: Встроенный поиск от провайдеров (OpenAI, Anthropic, Google, xAI, Perplexity). Он тесно интегрирован с моделью, но часто лишен гибких настроек, таких как размер контекста результатов. Стоимость соответствует тарифам провайдера.
• Exa: Передача запроса в Exa с оплатой через кредиты OpenRouter. Стоимость: $0.005 за запрос (включает до 10 результатов), далее $0.001 за каждый дополнительный результат. Exa предлагает мощные возможности фильтрации и настройки контекста.
• Parallel: Аналогично Exa, использует инфраструктуру Parallel. Стоимость такая же: $0.005 за запрос (до 10 результатов), $0.001 за дополнительные. Parallel также обеспечивает высокое качество извлечения данных.

Важно отметить, что движки Exa и Parallel поддерживают параметр search_context_size, который позволяет контролировать объем контекста, передаваемого модели. Нативные движки часто игнорируют этот параметр, что может приводить к потере важной информации или, наоборот, к переполнению контекстного окна. Также все движки, кроме, возможно некоторых нативных реализаций, поддерживают фильтрацию доменов через allowed_domains и excluded_domains.

Пример конфигурации поиска

Давайте посмотрим, как выглядит запрос к API с использованием движка Exa и фильтрацией по научным доменам. Это типичный сценарий для создания исследовательского агента.

{
  "type": "openrouter:web_search",
  "parameters": {
    "engine": "exa",
    "max_results": 5,
    "search_context_size": "high",
    "allowed_domains": [
      "arxiv.org",
      "nature.com"
    ]
  }
}

В этом примере мы ограничиваем поиск научными источниками, устанавливаем высокий размер контекста для получения полных аннотаций статей и запрашиваем 5 результатов.

Источник: OpenRouter ↗