Раздел Service — единая точка настройки всех внешних сервисов Research Agent. Поисковые провайдеры, методы скачивания и LLM-модели подключаются здесь, в интерфейсе, а не через переменные окружения.
Категории сервисов
- Поисковые провайдеры — Serper, Keenable, Brave, Tavily, TinyFish, Exa, Anysite и JSON SEO; все требуют API-ключ. У JSON SEO выбирается поисковая система (Яндекс, Google или Bing) и, по желанию, регион, у Anysite — тоже поисковая система (Bing, Brave, Baidu, Startpage или Яндекс). Отдельно подключается SearXNG — адресом собственного экземпляра; по одному экземпляру-сервису на провайдера;
- Методы скачивания — пять способов получить страницу: Direct HTTP (обычный запрос), Proxied HTTP (через прокси), Browser Emulation (локальный браузер), Nodriver (локальный недетектируемый браузер для защищённых страниц) и Remote Browser (внешний сервис управления браузером). От вас нужны только прокси для Proxied и адрес сервиса для Remote Browser — браузеры для локальных методов скачиваются сами при первом использовании;
- LLM — любые OpenAI-совместимые провайдеры для извлечения данных.
- Python script (search / fetch / LLM) — свой источник поиска, свой способ скачивания страницы или свой шлюз к модели, написанный скриптом на Python. Такой сервис встраивается в штатную цепочку приоритетов и запасных вариантов и не требует доработки самого продукта. Подробнее — в разделе Python-скрипты.
Готовую конфигурацию сервиса можно повторить, не набирая настройки заново: у строки сервиса есть кнопка копирования — она кладёт в буфер обмена всю конфигурацию вместе с ключами. Скопировать можно и сразу все сервисы: кнопка копирования есть у всего списка. Рядом с кнопкой «Добавить сервис» — вставка из буфера: из скопированных настроек создаётся один сервис или сразу несколько (продукт сообщит, сколько добавил), остаётся дать им имена. Удобно перенести всю настройку на другой сервер или завести второй похожий сервис.
Приоритеты и запасные варианты
Внутри категории сервисы упорядочиваются приоритетом: при ошибке или недоступности запрос уходит к следующему — автоматически, без вмешательства. Для извлечения данных рекомендуется дешёвая модель с низким приоритетом (номер меньше — выбирается раньше) и платная по требованию с более высоким — как запасной вариант.
У каждого сервиса задаётся предел одновременных заданий — сколько запросов уходит к провайдеру разом; у новых сервисов он равен десяти. Если провайдер ограничивает частоту обращений, рядом можно задать лимит: не больше определённого числа запросов за промежуток времени.
Ключи через переменные окружения
Секрет в настройках сервиса можно не записывать в файл настроек, а оставить ссылкой на переменную окружения сервера: $NAME или ${NAME}. При каждом обращении продукт подставляет значение переменной — реальный ключ в файле настроек не появляется. В интерфейсе такая ссылка показывается как есть: это указатель, а не сам ключ, поэтому маскировать её незачем.
Что это даёт: чтобы сменить ключ, не нужно править файл настроек — достаточно поправить значение переменной в окружении и перезапустить контейнер. Если переменная не задана, продукт сообщит об этом понятной ошибкой с именем переменной (например, «ApiKey references environment variable “X” which is not set…»), а не отправит запрос без ключа.
Где хранятся настройки сервисов
Все сервисы — поисковые провайдеры, методы скачивания, модели — записаны в одном файле settings.yml внутри папки исследований (/project/apps/research/settings.yml). Это единственный источник правды: файл правится и из интерфейса, и обычным текстовым редактором, а изменения подхватываются меньше чем за секунду, без перезапуска.
В том же файле живёт секция scripts: — общие правила для Python-скриптов: общий выключатель, предельное время запуска, число одновременных запусков, предел размера вывода и два места обработки — Markdown после скачивания и строки извлечения до записи. Из интерфейса эта секция не правится: она для тех, кто расширяет продукт скриптами (подробнее — Python-скрипты).
Что это даёт владельцу. Папка исследований лежит отдельно от базы, поэтому вместе с ней на другой сервер переезжают и сами сервисы: ключи, приоритеты и лимиты не нужно настраивать заново. Файл удобно держать в системе контроля версий — видно, кто и когда менял настройки, а откат к прежней версии ничего не стоит. В базе остаётся только рабочее: сессии, скачанные страницы, статистика.
Опечатка не остановит работу: если файл не читается, продукт продолжает работать на последней удачной настройке и пишет об ошибке в журнал — достаточно поправить файл, перезапускать ничего не надо. Путь к файлу при необходимости меняется переменной RESEARCH_APP_SETTINGS_FILE.
Модели и стоимость
Для извлечения данных подходят любые OpenAI-совместимые модели. Рекомендация автора — DeepSeek-V4-Flash: исследование целиком стоит 9–27 рублей; ещё дешевле обойдётся DeepSeek-V4-Flash-Mini (OpenRouter). Для более тяжёлых задач (написание отчётов, планирование) работает агент с той моделью, что настроена у него, — сервисы Research Agent касаются только извлечения.
Каждый запрос к поставщику моделей помечается строкой PastukhovResearchAgent/0.1.50 — название продукта и его версия, так что провайдеры видят, какой продукт к ним обращается.
Заголовок сессии LLM
Каждый запрос к модели при извлечении несёт идентификатор сессии задания — он передаётся в отдельном заголовке запроса. Имя заголовка задаётся в настройках LLM-сервиса (поле «Имя заголовка сессии»): если оставить его пустым, продукт подставит имя сам — X-Opencode-Session для провайдера opencode.ai и X-Agent-Session для всех остальных.
Зачем это нужно: провайдер может группировать весь трафик одной задачи под одной сессией — удобно следить за расходом и логами по задачам, а не по отдельным вызовам. Идентификатор одинаков для всех вызовов задания, даже когда запрос автоматически переключается на запасную модель. Заголовок уходит и в проверку сервиса из интерфейса (со служебным значением) — иначе шлюзы, которым сессия обязательна, отвечали бы на тест ошибкой, хотя с рабочим ключом всё в порядке.
Тестирование сервисов
Каждый сервис проверяется прямо из интерфейса — тестеры выполняют реальный запрос к провайдеру и показывают ответ. Битый ключ виден до того, как он сломает исследование. При редактировании сервиса рядом показывается индикатор «Сохранено/Изменено» — всегда видно, применились ли правки.
Статус agent API
В Settings → Agent API показано, включён ли REST-доступ для внешних агентов (сам ключ не отображается). Управляется переменной RESEARCH_APP_HASH — подробнее в разделе Интеграция с Pastukhov Agent.
Статистика
- Completions — история LLM-вызовов: токены, стоимость, скорость по каждому;
- Sessions — исследовательские сессии: поиски, скачивания и извлечения одной темы с итоговыми счётчиками.
- Выгрузка в ClickHouse — статистику исследований можно выгружать во внешнюю базу ClickHouse для собственной аналитики: задайте строку подключения переменной
RESEARCH_APP_CLICKHOUSE_URL, и продукт сам создаст базу с таблицей; дальше данные уходят сразу после изменений — в течение примерно секунды, а пока исследований нет, выгрузка ничего не делает. Без переменной выгрузки нет; при включённой внизу страницы «Аналитика» появляется кнопка «Дозаполнить статистику ClickHouse» для переноса всей истории сразу.