howdeploy/kisa-stack/researcher

Researcher

Примечание по инструментам. Скилл писался в среде Hermes: web_search / web_extract / terminal / execute_code / delegate_task — ее инструменты. В Claude Code / Codex используй аналоги: веб-поиск (Tavily / WebSearch), извлечение страниц (tavily_extract / WebFetch), shell (Bash), субагенты (Agent). Логика скилла от рантайма не зависит.

Короткий и практичный ресерч без ступора, если один источник поиска умер.

Основные режимы

1. quick-scan

Когда нужен быстрый, но нормальный обзор.

Что делать:

• быстро проверить тему через web_search
• взять 3–5 сильных источников
• дать короткую выжимку
• оставить достаточно контекста, чтобы потом можно было углубиться без повторного старта с нуля

Когда использовать:

• нужно быстро понять, стоит ли тема внимания
• нужен короткий обзор без перегруза
• нужно подобрать, куда копать дальше

2. deep-research

Когда нужен уже не обзор, а нормальное погружение.

Что делать:

• собрать несколько качественных источников с разных углов
• сравнить версии, подходы, противоречия
• выделить практические выводы
• сохранить достаточно контекста в ответе, чтобы пользователь мог продолжить разговор с уже собранной базой

Когда использовать:

• нужно реально разобраться в теме
• нужно сравнить инструменты / подходы / мнения
• нужен ресерч для статьи, дайджеста, решения или стратегии

Триггеры

Используй естественные фразы, не требуй от пользователя специального синтаксиса.

Триггеры для quick-scan

• быстро посмотри тему
• дай быстрый ресерч по ...
• коротко разберись, что там с ...
• глянь, стоит ли вообще в это копать
• быстрый обзор по ...
• собери краткую выжимку по ...

Триггеры для deep-research

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

Выбор режима

Если пользователь явно не назвал режим, выбирай его сама:

• если запрос звучит как быстрый обзор или первичная разведка — quick-scan
• если нужно сравнение, решение, подбор workflow, исследование с нескольких сторон или тема явно сложная — deep-research

Не заставляй пользователя каждый раз формализовать запрос через двоеточия или служебные метки.

Ключевой принцип — signal-only

Это не отдельный режим, а обязательное правило для любого поиска.

Всегда:

• ищи достоверную и полезную информацию
• предпочитай первоисточники и сильные разборы
• отсекай SEO-мусор, маркетинговую шелуху и слабые пересказы
• не тащи в вывод все подряд только потому, что оно найдено

Если источник сомнительный — помечай это прямо. Если тема спорная — не опирайся на один источник.

Базовый принцип работы

Сначала пробуй нативный контур Hermes:

• web_search
• web_extract

Не считай старые ошибки актуальными автоматически. Если раньше Tavily или другой поиск падал, сначала сделай короткий живой smoke test сейчас, а уже потом уходи в фолбэк.

Рабочий порядок

1. Smoke test

• короткий web_search
• при надобности web_extract на 1 URL

1. Развертка темы

• если тема многослойная, сама разложи ее на 2–4 исследовательские ветки
• сама придумай дополнительные поисковые формулировки и углы атаки

1. Сбор источников

• сделай 2–4 запроса с разных углов
• отдели сильные источники от мусора

1. Извлечение сути

• читай приоритетные страницы
• доставай тезисы, цифры, ограничения, практические выводы

1. Синтез

• отвечай коротко
• но оставляй в ответе достаточно контекста, чтобы потом можно было естественно углубиться в уже проведенный ресерч

Когда звать сабагентов

Используй delegate_task, если тема реально выигрывает от распараллеливания.

Автоматически зови сабагентов, если одновременно выполняются оба условия:

• тема естественно делится минимум на 2 независимые исследовательские ветки
• каждая ветка дает отдельную ценность, а не просто дублирует другие

Подходит для случаев вроде:

• нужно исследовать одну тему с нескольких сторон
• нужно подобрать решение для сложного workflow
• нужно сравнить несколько инструментов или подходов
• нужно быстро разделить тему на независимые ветки и исследовать их параллельно

Пример: Если пользователь ищет решение для ComfyUI workflow, можно самой разбить задачу на ветки вроде:

• готовые workflow и community practices
• ноды и расширения
• performance / VRAM / stability
• альтернативные подходы и trade-offs

Не зови сабагентов, если:

• вопрос маленький и прямой
• можно самой закрыть его за несколько запросов без потери качества
• распараллеливание даст больше шума, чем пользы

То есть темы для отдельных поисковых веток и сабагентов формируешь ты сама, если это помогает качеству ресерча.

Фолбэк

Если web_search / web_extract не работают, используй:

• Brave Search HTML через curl -L -A 'Mozilla/5.0'
• DuckDuckGo HTML как запасной вариант
• requests / curl / execute_code для чтения и чистки страниц

Специальный случай: мануалы, PDF и вендорские страницы

• страницы вида .../manual у магазинов и брендов часто оказываются бесполезной storefront-оберткой без самого текста инструкции
• если в поисковой выдаче видно прямую ссылку на PDF/manual asset, лучше сразу идти в нее, а не тратить ходы на витрину магазина
• если web_extract не тянет PDF или дает пустоту, скачай файл через python3 + requests или curl -L и попробуй локальное извлечение текста
• порядок предпочтения для локального чтения PDF:

1. pdftotext, если установлен
2. Python-библиотеки вроде pypdf / PyPDF2, если доступны
3. если нормальный парсинг недоступен, используй поисковые сниппеты, alternate manuals mirrors и даже strings как грубый последний шанс для поиска коротких сочетаний клавиш, названий режимов и других маркеров

• для железа и клавиатур особенно полезно скрещивать: официальный manual/snippet + Reddit/форумы с практическим подтверждением сочетания клавиш

Специальный случай: Reddit

• если обычный URL reddit.com/... плохо извлекается через web_extract, сразу пробуй тот же тред через https://old.reddit.com/...
• для текстового чтения и цитирования old.reddit часто вытаскивается гораздо надежнее обычного Reddit
• если нужен именно живой срез мнений, сочетай web_search для поиска тредов и web_extract по old.reddit.com для чтения содержимого
• если web_extract на old.reddit внезапно ругается, будто в URL есть API key or token, не делай из этого общий вывод про Reddit: это может быть ложное срабатывание. Практичный порядок такой:

1. ретрайнуть URL по одному, а не пачкой;
2. попробовать вариант с завершающим /;
3. если один тред все равно блочится, добрать смысл через web_search snippets по exact title и соседние треды, а blocked URL не тащить дальше в пакетный extract.

Специальный случай: поиск автора / источника по картинке или скриншоту

Когда user присылает арт, мем, скриншот поста или кадр анимации и просит найти автора, не начинай с голых текстовых запросов — сначала выжми из изображения поисковые признаки.

Рабочий порядок:

1. используй vision и выпиши максимально конкретно: персонажи, фандом, цвет/паттерн (например calico), поза, стиль, текст на кадре, watermark, возможные теги;
2. затем делай несколько узких запросов по этим признакам в 2 параллельных ветках поиска:

• обычный web/X поиск по ключевым словам;
• tag/booru/secondary-source поиск по описанию персонажей и фандома;

1. если находится booru/post mirror/secondary dataset entry, не останавливайся на нем — используй его как мост к alias художника: booru-artist-name -> Pixiv/X handle -> профиль;
2. затем триангулируй alias через вторичные источники, где автора могут упоминать явно: model cards, dataset READMEs, reposts, quote-posts, mirrors;
3. после этого проверяй прямой social handle через X/web_search и только потом называй кандидата;
4. после нахождения кандидата проверь его по стилю и серии работ: ищи соседние посты с тем же фандомом/персонажами, а не хватай первый совпавший handle;
5. если уверенность неполная, так и помечай; если user подтверждает «да, это он», считай идентификацию закрытой.

Полезные эвристики:

• для anime/furry/game art Danbooru/Gelbooru и похожие индексаторы часто лучше обычного веб-поиска как первый alias-bridge;
• booru-страницы часто содержат строку drawn by <alias> — это отличный pivot;
• Hugging Face / Civitai / dataset/model-card страницы иногда содержат прямую привязку alias -> X handle, например artist on X: @handle в LoRA README;
• если X плохо извлекается, используй search snippets и зеркала как подтверждающий слой, а не единственный источник истины; выпиши видимые handle, display name, текст поста и дату;
• X search results по exact phrase из сниппета ("Minecraft cat", название серии и т.п.) часто приводят к оригинальному посту даже без логина.

Подача ответа:

• если уверенность не 100%, говори похоже, это ... и коротко объясни цепочку атрибуции;
• если найден не точный твит, а профиль автора — отдай профиль и предложи отдельно добить именно исходный пост/анимацию.

Специальный случай: перевод текста со стикеров / мемов / маленьких UI-скринов

Когда user просит прочитать и перевести текст с картинки, стикера, скрина пака стикеров или auto-captioned media, сначала отдели реальные пиксели от словесного описания вложения.

Рабочий порядок:

1. если есть настоящий image attachment / local image path / screenshot — сначала используй vision по самому изображению;
2. если в сообщении есть только auto-описание вида The user sent a sticker ... It shows: ..., не выдавай это за OCR и не утверждай точные иероглифы, которых ты не видела;
3. на маленьких сетках стикеров сначала дай честную карту уверенности: что читается точно, что частично, что слишком мыльно;
4. если pack/page не отдает сами превью, проси у пользователя скрин конкретного стикера или пачку скринов, а не выдумывай текст по vibe-описанию;
5. если раньше ты уже назвала точный текст по описанию, а user просит «проверь еще раз», признай неопределенность прямо и попроси именно изображение/скрин;
6. когда позже приходит реальный пиксельный стикер, перепроверь прежние догадки и прямо исправь их, не защищая старую версию.

Формат ответа на таких задачах:

• точный текст, если реально прочитан с пикселей;
• похоже, тут ..., если это только лучшая догадка по размытом изображению;
• без изображения: по смыслу это ..., точный оригинал не вижу без самого изображения — только перевод смысла описания, с явной пометкой, что это не посимвольный OCR;
• отдельно: буквальный перевод и живой русский вариант по смыслу.

Критичный pitfall:

• не путай caption-level description от платформы с фактическим OCR; если нет изображения, можно подтверждать только смысл описания, но не точную китайскую/японскую строку.

Специальный случай: Telegram sticker pack / addstickers link

Когда пользователь кидает ссылку вида https://t.me/addstickers/<set> и просит посмотреть все стикеры / перевести текст на картинках / понять, что там написано, не делай вид, что содержимое уже доступно из обычного HTML.

Рабочий порядок:

1. сначала проверь сам addstickers URL через обычный extract/fetch — иногда там есть хоть базовый метадатный след;
2. затем попробуй найти публичное зеркало / каталог / индекс по shortname пака и exact URL;
3. если зеркала с превью нет, честно считай, что у тебя нет самих изображений, даже если landing page открывается;
4. в таком случае не выдумывай перевод и не обещай «посмотреть все картинки» без доступа к картинкам — прямо попроси пользователя прислать скриншоты, сами стикеры или пересланные изображения;
5. как только изображения даны напрямую, переходи из режима ресерча в vision/OCR-задачу: вытаскивай текст, помечай нечитабельные места, различай буквальный перевод и перевод по смыслу.