--- title: "Сервисы и модели" id: "1330" type: "page" slug: "services" published_at: "2026-08-15T22:46:45+00:00" modified_at: "2026-10-04T01:22:05+00:00" url: "https://pastukhov.com/agents/research/docs/services" markdown_url: "https://pastukhov.com/agents/research/docs/services.md" excerpt: "Раздел Service — единая точка настройки всех внешних сервисов Research Agent. Поисковые провайдеры, методы скачивания…" --- # Сервисы и модели [https://pastukhov.com/agents/research/docs/services.md](https://pastukhov.com/agents/research/docs/services.md) Раздел Service — единая точка настройки всех внешних сервисов Research Agent. Поисковые провайдеры, методы скачивания и LLM-модели подключаются здесь, в интерфейсе, а не через переменные окружения. ## Категории сервисов - **Поисковые провайдеры** — Serper, Keenable, Brave, Tavily и JSON SEO (API-ключи; у JSON SEO дополнительно выбирается поисковая система — Яндекс, Google или Bing — и, по желанию, регион) и SearXNG (base URL собственного экземпляра); по одному экземпляру-сервису на провайдера; - **Методы скачивания** — пять способов получить страницу: Direct HTTP (обычный запрос), Proxied HTTP (через прокси), Browser Emulation (локальный браузер), Nodriver (локальный недетектируемый браузер для защищённых страниц) и Remote Browser (внешний сервис управления браузером). От вас нужны только прокси для Proxied и адрес сервиса для Remote Browser — браузеры для локальных методов скачиваются сами при первом использовании; - **LLM** — любые OpenAI-совместимые провайдеры для извлечения данных. - **Python script (search / fetch / LLM)** — свой источник поиска, свой способ скачивания страницы или свой шлюз к модели, написанный скриптом на Python. Такой сервис встраивается в штатную цепочку приоритетов и запасных вариантов и не требует доработки самого продукта. Подробнее — в разделе [Python-скрипты](/agents/research/docs/scripts) . Готовую конфигурацию сервиса можно повторить, не набирая настройки заново: у строки сервиса есть кнопка копирования — она кладёт в буфер обмена всю конфигурацию вместе с ключами. Скопировать можно и сразу все сервисы: кнопка копирования есть у всего списка. Рядом с кнопкой «Добавить сервис» — вставка из буфера: из скопированных настроек создаётся один сервис или сразу несколько (продукт сообщит, сколько добавил), остаётся дать им имена. Удобно перенести всю настройку на другой сервер или завести второй похожий сервис. ## Приоритеты и запасные варианты Внутри категории сервисы упорядочиваются приоритетом: при ошибке или недоступности запрос уходит к следующему — автоматически, без вмешательства. Для извлечения данных рекомендуется дешёвая модель с низким приоритетом (номер меньше — выбирается раньше) и платная по требованию с более высоким — как запасной вариант. У каждого сервиса задаётся предел одновременных заданий — сколько запросов уходит к провайдеру разом; у новых сервисов он равен десяти. Если провайдер ограничивает частоту обращений, рядом можно задать лимит: не больше определённого числа запросов за промежуток времени. ## Ключи через переменные окружения Секрет в настройках сервиса можно не записывать в файл настроек, а оставить ссылкой на переменную окружения сервера: `$NAME` или `${NAME}`. При каждом обращении продукт подставляет значение переменной — реальный ключ в файле настроек не появляется. В интерфейсе такая ссылка показывается как есть: это указатель, а не сам ключ, поэтому маскировать её незачем. Что это даёт: чтобы сменить ключ, не нужно править файл настроек — достаточно поправить значение переменной в окружении и перезапустить контейнер. Если переменная не задана, продукт сообщит об этом понятной ошибкой с именем переменной (например, «ApiKey references environment variable “X” which is not set…»), а не отправит запрос без ключа. ## Где хранятся настройки сервисов Все сервисы — поисковые провайдеры, методы скачивания, модели — записаны в одном файле `settings.yml` внутри папки исследований (`/project/apps/research/settings.yml`). Это единственный источник правды: файл правится и из интерфейса, и обычным текстовым редактором, а изменения подхватываются меньше чем за секунду, без перезапуска. В том же файле живёт секция `scripts:` — общие правила для Python-скриптов: общий выключатель, предельное время запуска, число одновременных запусков, предел размера вывода и два места обработки — Markdown после скачивания и строки извлечения до записи. Из интерфейса эта секция не правится: она для тех, кто расширяет продукт скриптами (подробнее — [Python-скрипты](/agents/research/docs/scripts) ). Что это даёт владельцу. Папка исследований лежит отдельно от базы, поэтому вместе с ней на другой сервер переезжают и сами сервисы: ключи, приоритеты и лимиты не нужно настраивать заново. Файл удобно держать в системе контроля версий — видно, кто и когда менял настройки, а откат к прежней версии ничего не стоит. В базе остаётся только рабочее: сессии, скачанные страницы, статистика. Опечатка не остановит работу: если файл не читается, продукт продолжает работать на последней удачной настройке и пишет об ошибке в журнал — достаточно поправить файл, перезапускать ничего не надо. Путь к файлу при необходимости меняется переменной `RESEARCH_APP_SETTINGS_FILE`. ## Модели и стоимость Для извлечения данных подходят любые OpenAI-совместимые модели. Рекомендация автора — DeepSeek-V4-Flash: исследование целиком стоит 9–27 рублей; ещё дешевле обойдётся DeepSeek-V4-Flash-Mini (OpenRouter). Для более тяжёлых задач (написание отчётов, планирование) работает агент с той моделью, что настроена у него, — сервисы Research Agent касаются только извлечения. Каждый запрос к поставщику моделей помечается строкой `PastukhovResearchAgent/0.1.42` — название продукта и его версия, так что провайдеры видят, какой продукт к ним обращается. ## Заголовок сессии LLM Каждый запрос к модели при извлечении несёт идентификатор сессии задания — он передаётся в отдельном заголовке запроса. Имя заголовка задаётся в настройках LLM-сервиса (поле «Имя заголовка сессии»): если оставить его пустым, продукт подставит имя сам — `X-Opencode-Session` для провайдера opencode.ai и `X-Agent-Session` для всех остальных. Зачем это нужно: провайдер может группировать весь трафик одной задачи под одной сессией — удобно следить за расходом и логами по задачам, а не по отдельным вызовам. Идентификатор одинаков для всех вызовов задания, даже когда запрос автоматически переключается на запасную модель. Заголовок уходит и в проверку сервиса из интерфейса (со служебным значением) — иначе шлюзы, которым сессия обязательна, отвечали бы на тест ошибкой, хотя с рабочим ключом всё в порядке. ## Тестирование сервисов Каждый сервис проверяется прямо из интерфейса — тестеры выполняют реальный запрос к провайдеру и показывают ответ. Битый ключ виден до того, как он сломает исследование. При редактировании сервиса рядом показывается индикатор «Сохранено/Изменено» — всегда видно, применились ли правки. ## Статус agent API В Settings → Agent API показано, включён ли REST-доступ для внешних агентов (сам ключ не отображается). Управляется переменной `RESEARCH_APP_HASH` — подробнее в разделе [Интеграция с Pastukhov Agent](/agents/research/docs/agent) . ## Статистика - **Completions** — история LLM-вызовов: токены, стоимость, скорость по каждому; - **Sessions** — исследовательские сессии: поиски, скачивания и извлечения одной темы с итоговыми счётчиками. - **Выгрузка в ClickHouse** — статистику исследований можно выгружать во внешнюю базу ClickHouse для собственной аналитики: задайте строку подключения переменной `RESEARCH_APP_CLICKHOUSE_URL`, и продукт сам создаст базу с таблицей; дальше данные уходят сразу после изменений — в течение примерно секунды, а пока исследований нет, выгрузка ничего не делает. Без переменной выгрузки нет; при включённой внизу страницы «Аналитика» появляется кнопка «Дозаполнить статистику ClickHouse» для переноса всей истории сразу. Подробнее — в разделе [Установка](/agents/research/install) . [← Оглавление документации](/agents/research/docs)