Когда в OpenClaw начинают настраивать поиск, чаще всего всё смешивают в одну кучу: Brave, Tavily, встроенный web-search у Codex, обычный web_search, research-контур. А потом начинается классика: что-то вроде работает, но непонятно, какой слой за что отвечает и почему агент то жжёт лимиты, то тащит не тот контекст.
Если упростить до человеческого уровня, логика такая:
• Brave нужен для быстрого обычного веб-поиска.
• Tavily нужен для research-задач, когда мало просто найти ссылки — нужно собрать и подготовить фактуру.
• Codex native web search нужен, когда ты работаешь именно на Codex-модели и хочешь, чтобы сама модель использовала свой встроенный поиск прямо внутри длинной задачи.
То есть это не три одинаковых инструмента. Это три разных слоя.
Когда брать Brave
Brave — хороший быстрый поисковый слой. Он нужен, когда задача звучит так:
• найти официальный релиз;
• быстро проверить факт;
• собрать 5–10 релевантных ссылок;
• сделать первый проход по теме без глубокой обработки.
Проще говоря, Brave — это режим «быстро найти». Если тебе не нужен сложный research, не нужно вытаскивать контент страниц и не нужен длинный агентный цикл, Brave часто закрывает задачу дешевле и быстрее.
Когда брать Tavily
Tavily — это уже ближе к AI-native research. Он нужен, когда задача не в том, чтобы просто найти ссылки, а в том, чтобы:
• отфильтровать шум;
• собрать фактуру;
• ограничить домены;
• учитывать свежесть;
• при необходимости вытаскивать контент из URL.
Для контентных задач в OpenClaw это обычно полезнее, чем простой поисковик. Если ты готовишь Dzen-статью, технический разбор, сравнение инструментов или исследование по релизу, Tavily обычно уместнее.
То есть Tavily — это режим «собрать и подготовить материал».
Когда нужен Codex native web search
Вот это уже не отдельный поисковик, а встроенный режим для Codex-capable моделей. Он нужен, когда модель не просто ищет ссылки, а работает как агент внутри длинной задачи: ищет, читает, связывает, делает выводы, пишет итог.
То есть Codex native search — это не замена Brave или Tavily, а верхний слой над ними. Это режим «довести до результата прямо внутри агентной работы».
Если сказать ещё проще:
• Brave — найти;
• Tavily — собрать;
• Codex — дожать до финального результата.
Теперь самое важное — как это включить в OpenClaw.
Конфиг правится в файле:
/opt/openclaw/config/openclaw.json
Самый простой путь без ручной возни:
openclaw configure --section web
Но если руками, то вот рабочая схема.
1. Включаем Brave
Если хочешь, чтобы обычный web_search в OpenClaw ходил через Brave, нужен BRAVE_API_KEY.
Ключ хранится здесь:
plugins.entries.brave.config.webSearch.apiKey
А сам провайдер задаётся здесь:
tools.web.search.provider = "brave"
Обычно этого уже достаточно, чтобы generic web_search начал использовать Brave.
2. Включаем Tavily
Если основной упор на research, лучше включать Tavily. Нужен TAVILY_API_KEY.
Ключ хранится здесь:
plugins.entries.tavily.config.webSearch.apiKey
А провайдер задаётся так:
tools.web.search.provider = "tavily"
После этого обычный web_search пойдёт через Tavily.
Но тут важен нюанс: у Tavily есть не только generic поиск, но и свои более полезные инструменты:
• tavily_search
• tavily_extract
И вот в этом как раз смысл Tavily. Если нужен не просто поиск, а глубина, фильтры, домены и выжимка контента — лучше использовать уже не общий web_search, а именно Tavily-контур.
3. Включаем native web search для Codex
Если используешь Codex-capable модель и хочешь встроенный поиск прямо внутри работы модели, включается это отдельно.
Основные поля такие:
• tools.web.search.openaiCodex.enabled = true
• tools.web.search.openaiCodex.mode = "cached"
• tools.web.search.openaiCodex.contextSize = "high"
При необходимости можно ещё ограничить домены через:
• tools.web.search.openaiCodex.allowedDomains
Здесь важны три вещи.
Во-первых, это работает только для Codex-capable моделей.
Во-вторых, для остальных моделей OpenClaw продолжит использовать обычный managed web_search.
В-третьих, mode: "cached" — нормальный дефолт, с него и стоит начинать.
Где люди чаще всего косячат
Самая частая ошибка — включить сразу и Brave, и Tavily, но не прописать provider.
Тогда OpenClaw может выбрать провайдера автоматически. И порядок автодетекта там не «какой тебе логичнее», а фиксированный. Если ключи стоят у обоих, раньше обычно подхватится Brave, а не Tavily.
Поэтому если нужен именно Tavily как основной research-контур, лучше писать явно:
provider = "tavily"
А если нужен именно Brave — так же явно:
provider = "brave"
Иначе потом начинается путаница в стиле «я вроде включил Tavily, а поведение как у обычного поиска».
Что я бы выбрал для нормального OpenClaw-контура
Если задача — контент, research и статьи, то базовая рабочая схема выглядит так:
• Tavily — как основной research-контур;
• Brave — как быстрый поисковый слой для первого прохода;
• Codex native web search — только там, где реально нужен длинный агентный цикл прямо внутри Codex.
Если выбирать один основной вариант для повседневной работы, я бы ставил Tavily. Если хочется ещё и быстрый разведочный поиск, тогда рядом имеет смысл держать и Brave. А встроенный Codex search — это уже не обязательная база, а скорее усиление для тех сценариев, где модель должна сама долго искать и собирать результат внутри одной задачи.
Главная мысль тут простая: в OpenClaw не нужно пытаться решить всё одним слоем. Когда каждый инструмент делает свою работу, система становится и дешевле, и понятнее, и стабильнее.
Если тебе интересны такие практические разборы по OpenClaw, AI, инфраструктуре и self-hosted-инструментам — заходи в наш Telegram-канал Pro IT: @pro_it_news.
Там регулярно публикуем прикладные гайды, рабочие схемы, заметки по автоматизации и реальные кейсы без воды и маркетинговой мишуры.