Пользователь Deepseek Harness описал на r/LocalLLaMA ситуацию, знакомую почти каждому, кто запускает локальную модель: webfetch-плагины в среде работают, интернет модель видит, но URL приходится указывать вручную. Модель не формулирует запрос сама, не получает список ссылок и не выбирает релевантные. Полноценные возможности поиска и браузера, по его наблюдению, требуют API-ключей, а большинство поисковых API платные. Бесплатные и безлимитные варианты вроде SearXNG он называет ненадёжными: они часто упираются в rate-limit.
Короткий ответ: поисковый слой к локальной модели нужно добавлять отдельно. Вариантов четыре. Self-hosted метапоисковик (SearXNG и аналоги), поисковый API с бесплатным тиром, платный поисковый API и браузерный агент на headless-браузере. Выбор зависит от частоты запросов, требований к стабильности и готовности платить.
Ниже три уровня доступа и разбор каждого варианта с ограничениями, о которых лучше узнать до настройки, а не после.
Почему webfetch-плагинов недостаточно для полноценного веб-поиска
Три уровня доступа: URL, поиск, браузер
Эти три вещи часто смешивают в одну, а разница между ними определяет и стоимость, и сложность настройки.
- Открытие конкретного URL (webfetch). Модель получает ссылку и вытягивает содержимое страницы. Откуда взялась ссылка, среда не знает и решить не может. Если URL не дал пользователь, модель либо ничего не открывает, либо выдумывает адрес.
- Поисковый API. Модель формирует запрос, инструмент отправляет его провайдеру и возвращает список ссылок с заголовками и сниппетами. Дальше модель решает, какие страницы открыть через webfetch. Это отдельный слой, которого в webfetch-плагинах нет по определению.
- Браузерный агент. Headless-браузер исполняет JavaScript, кликает, заполняет формы, проходит авторизацию и отдаёт модели уже отрендеренный DOM. Это не API, а инструмент с состоянием, таймаутами и ошибками, которые нужно обрабатывать.
Стоимость и сложность растут по этим уровням: webfetch почти ничего не требует, поисковый API нуждается в ключе и лимитах, браузер съедает CPU и RAM и требует кода для обработки сбоев.
Что именно ломается без поискового слоя
Задачи, где поиск нужен по-настоящему: проверить актуальную версию библиотеки, найти свежую документацию, сравнить цены, отследить релиз или новость, уточнить факт, который модель могла запомнить устаревшим. Без поискового слоя модель или отвечает по памяти и ошибается на свежих данных, или ждёт URL от пользователя.
Второй сценарий превращает вас в ручной поисковик: вы находите ссылки, вставляете их в промпт, потом снова ищете. Именно об этом писал автор поста про Deepseek Harness: webfetch есть, полноценного поиска нет.
Вариант 1: self-hosted поисковые движки (SearXNG и аналоги)
Как SearXNG работает и почему упирается в лимиты
SearXNG не хранит собственную поисковую базу. Это метапоисковик: он проксирует запрос к внешним движкам и собирает выдачу. Когда такие запросы идут с одного IP и в заметном объёме, внешние движки видят автоматизированный трафик и отвечают капчей, пустой выдачей или ошибкой. Нестабильность берётся не из SearXNG, а из архитектуры: между вами и поисковым движком нет договора и квоты, поэтому правила игры меняет противоположная сторона.
Автор поста на r/LocalLLaMA описывает это так: бесплатные и безлимитные решения ненадёжны и часто упираются в rate-limit, SearXNG в их числе. Важная оговорка: это личный опыт одного человека из обсуждения, а не результат замеров. У разных инстансов картина расходится. При десяти запросах в день SearXNG может месяцами работать без сбоев, при агентном прогоне с сотней запросов падает на первых минутах.
В трекере проекта есть обсуждение ошибок rate-limit на движке Google: пользователи сообщают о блокировке с формулировкой «too many search attempts», причём напрямую через Google поиск работает, а блокировка возникает даже на инстансах с очень низким использованием. Это подтверждает механику, но не даёт универсальной статистики по всем движкам и инстансам.
Когда self-hosted всё же оправдан
Self-hosted разумен, если совпадает несколько условий: запросы редкие, использование личное, бюджета на API нет, ошибку можно пережить и повторить запрос. Для продакшена, агентов с частыми вызовами и задач, где важна предсказуемость, он не подходит.
Что снижает боль на практике:
- Свой инстанс вместо публичного: публичные перегружены чужим трафиком.
- Кэш результатов: агент часто повторяет одинаковые запросы, и повторный вызов из кэша не уходит во внешний движок.
- Ограничение частоты на своей стороне: лучше отдать десять запросов в минуту и не получить бан, чем двести и потерять IP.
- Прокси или ротация исходящих адресов, если провайдер это допускает.
Другие self-hosted фронтенды поисковиков, например Whoogle или 4get, решают похожую задачу, но их надёжность и текущее состояние стоит проверять самостоятельно: проверенной сравнительной статистики по ним в разобранном обсуждении нет.
Вариант 2: бесплатные и условно-бесплатные поисковые API
На что смотреть в бесплатном поисковом API
Главный факт из источника: большинство поисковых API платные. Бесплатные тиры существуют, но это компромисс, а не решение навсегда. Перед регистрацией проверьте:
- Лимит запросов. В сутки, в месяц или в минуту. Формулировка может скрывать потолок RPM, который упрётся раньше дневного.
- Поведение при превышении. Ответ 429 с ожиданием, временная блокировка ключа или списание с привязанной карты. Разница принципиальная.
- Задержка. Для агентного цикла важна не только выдача, но и скорость ответа: медленный API растянет прогон.
- Качество выдачи и поддержка русского языка. Русскоязычные запросы у разных движков дают заметно разный результат.
- Условия использования. Разрешена ли коммерческая эксплуатация, что с хранением и логированием запросов.
- Нужна ли карта при регистрации и есть ли региональные ограничения. Часть сервисов недоступна без карты или из отдельных стран.
Условия бесплатных тиров меняются чаще, чем обновляются статьи о них, поэтому сверяйтесь с текущей страницей провайдера, а не с чужими скриншотами годичной давности.
Как встроить API в локальную LLM
Общая схема одинакова почти везде. Модель через function calling (вызов инструментов) формирует поисковый запрос. Среда отправляет его в API. Список ссылок и сниппетов возвращается в контекст, и модель уже строит ответ, при необходимости открывая выбранные страницы через webfetch. Поиск должен быть доступен модели как инструмент, а не как ручная вставка ссылок.
Формат реализации зависит от среды: плагин внутри приложения, отдельный MCP-сервер или собственный код на Python, который вызывает API и подкладывает результат в промпт. Часть платформ закрывает вопрос на своей стороне. AWS вывела Web Search для Amazon Bedrock в общую доступность: это серверный встроенный инструмент, который даёт моделям доступ к актуальной информации из интернета, а включение поиска сводится к одному параметру в API-запросе, без подключения сторонних поисковых сервисов и внешних API, разбор механики и затрат здесь. Отдельно у Amazon Bedrock AgentCore есть Web Search Tool — управляемая, MCP-совместимая возможность веб-поиска, которая подключается как managed connector к AgentCore Gateway, описание коннектора в документации AWS. Это разные продукты и разные формулировки, поэтому не стоит переносить параметр включения из одного описания в другое.
Вариант 3: платные поисковые API с бесплатными лимитами
Когда платный API дешевле, чем возня с SearXNG
Считайте не цену за запрос, а стоимость своего времени. Свой SearXNG это контейнер, прокси, кэш, мониторинг ошибок, разбор капчи и периодическая диагностика, когда выдача внезапно опустела. Всё это требует поддержки, даже если софт бесплатный.
Логика выбора простая. Если запросов немного, бесплатный тир платного API закрывает задачу в первый же день, а вы не тратите вечер на настройку. Если запросов тысячи в день, бесплатный тир закончится быстро, и дальше придётся считать бюджет и сравнивать тарифы. Конкретных цен и названий провайдеров в разобранном источнике нет, поэтому цифры придётся смотреть в актуальных тарифах.
Гибридная схема: локальная модель + облачный поиск
Локальность означает, где считаются токены и лежат промпты, а не запрет выходить в сеть. Поисковый запрос уходит в облачный API, обратно приходит список ссылок. Данные и контекст остаются на вашей машине, если вы сами не отправите их в тексте запроса.
Компромисс очевиден: поисковые запросы видны провайдеру. Для чувствительных тем формулируйте запрос без личных деталей или держите self-hosted поиск для этой части работы, а облачный API используйте для общего поиска.
Как это реализуется в Deepseek Harness и аналогичных средах
Требования к API-ключам и настройке
В Deepseek Harness webfetch-плагины включены по умолчанию, а для полноценного поиска, по описанию пользователя, нужны ключи. Типовой минимум выглядит так: аккаунт и API-ключ у поискового провайдера, ключ в конфигурации среды, выбор движка или региона, если провайдер это предлагает, и учёт лимитов в логике агента.
Важная оговорка: официальной документации DeepSeek Harness в разобранных материалах нет. Сведения ниже взяты из сторонних проектов и гайдов с пометкой о том, что они не связаны с DeepSeek AI, поэтому точные поля конфигурации зависят от версии среды и требуют проверки по её актуальной документации.
По данным стороннего гайда по плагинам, официальный пакет tool-web даёт модели веб-поиск и операции fetch, поставляемые провайдерами ctx.web; среди официальных поисковых провайдеров названы DeepSeek, Exa и Perplexity, а HTTP fetch поставляется отдельным официальным провайдером (гайд по плагинам Web Search & Fetch). Там же указано, что стандартный пресет Standard загружает tool-web, но в его конфигурации fetch установлен в false, поэтому HTTP fetch по умолчанию отключён, даже если веб-поиск работает.
Отдельный community-проект DeepSeek-Harness-Web-Tools описывает ситуацию иначе: из коробки требуется платный API-ключ и используется один поисковый провайдер, а поиск выполняется в облаке DeepSeek, поэтому локальный OpenAI-совместимый сервер (vLLM, llama.cpp, Ollama) не может его обслуживать. Это неофициальный проект, и его утверждения стоит сверять с текущим состоянием среды.
Заодно полезно понимать, как в harness-обвязку подключают сторонние модели и инструменты через OpenAI-совместимый API и MCP: разбор связки GLM 5.3 и DeepSeek Harness объясняет эту архитектуру и то, как замерить скорость провайдера на своих промптах.
MCP и плагины как способ подключения поиска
MCP (Model Context Protocol) — открытый протокол, который обеспечивает стандартизированную интеграцию LLM-приложений с внешними источниками данных и инструментами (спецификация MCP). В нём определены роли: host — LLM-приложения, инициирующие соединения; client — коннекторы внутри host-приложения; server — сервисы, предоставляющие контекст и возможности. Серверы предлагают клиентам resources, prompts и tools, а также предусмотрено согласование возможностей сервера и клиента. На практике поисковый сервер поднимается отдельно, среда получает список доступных инструментов, модель вызывает нужный. Ядро среды при этом править не нужно, что удобно при обновлениях.
Альтернатива это плагин внутри самой среды. В Open WebUI веб-поиск поддерживается: в Native/Agentic режиме он предоставляется модели как инструмент, и модель должна решить вызвать этот инструмент и вернуть корректный структурированный tool call (документация Open WebUI по веб-поиску). Кроме того, Open WebUI интегрируется с поисковыми движками для получения актуальной информации, а поддержка MCP в последних версиях открывает дополнительные возможности для подключения внешних инструментов. Для LM Studio и Continue официальной документации о веб-поиске в разобранных материалах нет, поэтому утверждать про них что-то конкретное не стоит: проверяйте документацию конкретного релиза, а не общие описания.
Как дать модели доступ к браузеру, а не только к поиску
Когда поиска и webfetch достаточно
Найти информацию, открыть статью, вытянуть текст, сравнить несколько страниц: это закрывается поисковым API плюс webfetch. Большинство задач на этом и заканчивается. Браузер нужен, когда сайт рендерит контент через JavaScript, требует авторизации или предполагает взаимодействие: заполнить форму, нажать кнопку, пройти по пагинации.
Что нужно для браузерного агента
Состав решения: headless-браузер (Playwright, Puppeteer, Selenium и подобные инструменты), слой управления, который модель вызывает для навигации, кликов и извлечения DOM, обработка таймаутов и падений страниц, а также ресурсы CPU и RAM. Браузерные воркеры заметно дороже обычного HTTP-запроса, а параллельных сессий на домашней машине помещается немного.
В локальных средах браузерный доступ обычно собирают через плагины или агентные фреймворки. Пример того, как браузер и MCP уживаются в одном self-hosted продукте, есть в разборе PersonalJarvis: заявлены локальные модели, браузер, routines, плагины и MCP при явных рисках молодого проекта, детали и требования к железу здесь.
Для старта браузерный агент почти никогда не нужен. Сначала поиск и webfetch, браузер только когда накопились конкретные сайты, которые иначе не открываются.
Сравнение вариантов: что выбрать под свою задачу
Таблица сравнения: стоимость, надёжность, сложность
| Вариант | Стоимость | Надёжность | Сложность настройки | Кому подходит |
|---|---|---|---|---|
| SearXNG и self-hosted движки | API бесплатно, нужен свой сервер или контейнер | низкая: rate-limit и капчи со стороны внешних движков | средняя: прокси, кэш, мониторинг | эксперименты, редкие запросы, личное использование |
| Поисковый API с бесплатным тиром | ноль в пределах лимита | средняя, зависит от провайдера | низкая: регистрация и ключ | личное использование с умеренной частотой |
| Платный поисковый API | по тарифу провайдера | выше, у части провайдеров есть SLA | низкая | продакшен, агенты, предсказуемость |
| Браузерный агент | ресурсы CPU и RAM плюс время на разработку | зависит от конкретных сайтов | высокая | JS-сайты, авторизация, интерактивные сценарии |
Рекомендации по сценариям использования
- Эксперименты и редкие запросы. SearXNG в контейнере. Ноль расходов, терпимые сбои, минимум обязательств.
- Личное использование с умеренной частотой. Бесплатный тир поискового API плюс webfetch. Меньше возни, чем с self-hosted, и предсказуемее выдача.
- Продакшен и агенты. Платный API. Лимиты и SLA важнее экономии на тарифе, потому что падение поиска посреди задачи дороже подписки.
- Интерактивные сайты. Браузерный агент, и только после того, как поиск с webfetch перестали справляться.
Идеального варианта для всех задач нет. Комбинация тоже рабочая: self-hosted для чернового поиска, платный API как основной канал, браузер для отдельных сайтов.
Ограничения и подводные камни, о которых стоит знать заранее
Почему бесплатные решения часто разочаровывают
Бесплатное экономит деньги и тратит время. Rate-limit, капчи, внезапно изменившаяся выдача, отсутствие поддержки и документации: это не баг, а следствие того, что вы не платите за инфраструктуру. По опыту автора поста на r/LocalLLaMA, бесплатные и безлимитные решения ненадёжны. Это наблюдение одного человека, а не замеры, поэтому ваш результат может отличаться. Подтверждённый пример ограничения — блокировки Google в SearXNG с формулировкой «too many search attempts», о которых сообщают пользователи в обсуждении проекта. Но ожидания стоит держать реалистичными: бесплатный поиск для локальной модели это компромисс, а не фундамент продакшена.
Что делать, когда rate-limit всё-таки случился
Основные приёмы:
- Кэшировать результаты: агент часто повторяет одинаковые запросы, и повторный вызов не должен уходить во внешний сервис.
- Ставить задержку между запросами и ограничивать частоту на своей стороне.
- Держать второй источник и переключаться на него при ошибке.
- Ротировать инстансы или ключи, если это не нарушает условия провайдера.
- В агенте обрабатывать ошибку поиска как штатную ситуацию: инструмент возвращает ошибку, модель продолжает работу, а не ломает весь прогон.
Дополнительные ограничения, о которых стоит помнить: платные API обычно требуют карту и могут иметь региональные ограничения, браузерный доступ ресурсоёмок, качество поиска зависит от движка и языка запроса, а поддержка любого выбранного решения требует времени. Один инструмент не закроет сразу все задачи.
Практичный старт выглядит так. Поднимите SearXNG для экспериментов и параллельно оформите бесплатный тир одного поискового API, чтобы сравнить выдачу на своих запросах. Через неделю использования вы увидите реальную частоту обращений и поймёте, нужен платный тариф, хватает бесплатного тира или self-hosted закрывает ваши сценарии. Дальше решение станет очевидным без чужих советов.