Небольшой интерфейс + агентная сетка для решения задач исследований в продуктовой аналитике

Приветики, меня зовут Пётр и я продуктовый аналитик с коммерческим опытом в ПА около 12 лет. В моей работе глобально задачи делятся на 3 типа — разметка событий, аб-тесты и продуктовые рисерчи.

Про разметку я уже писал тут https://habr.com/ru/articles/785320/

Под аб-тесты мы с корешами собрали коммерческий воркспейс (зарегайтесь, потестите, это бесплатно (длинно и не обрезано) если не нужны командные фичи). Было тут: https://habr.com/ru/articles/1064034/

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

В наше время в аналитике работать руками это уже почти моветон, поэтому и эту часть давно пора было переложить на агентов. Вот только это не совсем линейная задача и там постоянно куча своих приколов. Я пробовал разные методы, от простого агента под капотом IDE (я гонял антропиков под Positron), до корпоративного сервиса, у которого агенты ходят в БД. Но всё время было что-то не то.

А «не то» — это по сути не автоматизация, да, агент классно может написать код рисерча, но постановка задачи всё ещё лежала на мне. А иногда ну просто лениво прям сильно вникать в нюансы, строить план исследования и т.д. Но самая большая боль для меня тут в контроле этапов, если закинуть задачу в агента, он её сделает как чувствует от начала и до конца. Мне же нужен контроль на всех этапах, чтобы сразу утвердить где и что он будет анализировать, какие графики рисовать, как оформлять секции и балансировать сторителл, чтобы рисерч не превращался в скучную свалку графиков по мотивам.

Кароч тут я расскажу про своё решение, дам ссылку на гит, можно брать за основу и править под себя, а можно и не править. Ваша жизнь. Полностью его собрал курсор под опусом, за чистоту кода не ручаюсь, но своё дело делает, для локального помощника у меня требования были не высокие.

Там всё достаточно просто — под капотом простой интерфейс и несколько ролей агентов со своими специализациями и скиллами, которые сообща пошагово решают задачу. Каждый этап согласовывается с оператором, можно править в ручную без траты токенов. В бд эта сетка не ходит, поэтому данные предоставить ей всё ещё необходимо руками, навык запросов в SQL пока не умер.

Кароч, го по порядку.

Установка

Репозиторий: https://github.com/Paxdelph/agent-researcher

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

• Docker + Docker Compose

• API-ключ(и) под провайдеров из config.yaml:

  • если агенты на OpenAI — OPENAI_API_KEY

  • если на Anthropic — ANTHROPIC_API_KEY

  • оба нужны только при смешанном конфиге (как в config.example.yaml); можно прописать всем агентам один provider и держать один ключ

• Свободный порт 8787 (ну или правьте docker-compose)

R, Quarto, pandoc, Chromium и R-пакеты для knit уже внутри образа — отдельно ставить не нужно.

Настройка

В гите подробно описано что как заводить, останавлюсь на стартовых настройках:

1. В первую очереь надо настроить .env и config, в энве подключаются свои ключи к провайдерам LLM, а в конфиге можно раскидать конкретные модели под роли. Я выбрал такой сетап, как сейчас в примере конфига, но можно под себя подогнать.

2. В researches/context.md описываем инфу о своей компании, тут можно всё подряд писать, что за бизнес, как работает, есть ли какие-то приколы/нюансы, можно структуру данных в кратце накидать, чтобы в последствии агенты понимали что есть, чего нет, ну и вообще всё, что вам кажется важным загрузить в бизнес-контекст.

3. В конфиге можно выставить лимиты на токены, при желании, по дефолту 0 — без лимитов. Количество использованных токенов пишется в статус баре сверху.

That’s all, folks. Ну и собственно сам флоу работы, почему так и почему это удобнее чем просто через встроенного в IDE работягу.

Планирование задачи

Там в папке researches/ уже есть example/ — чтобы потестить на синтетическом рисерче. На его примере и покажу.

Итак, мы получили задачу от менеджера, зашли в Jira, скопировали текст таски. Заходим в researches/ и создаём папку рисерча, пусть будет mega-hard-research/, в ней создаём на будущее папку data/ куда потом выгрузим csv-шки. Запускаем систему локально.

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

cd ~/agent-researcher/researches/mega-hard-researchagent-research

В docker-compose дефолтный порт на http://127.0.0.1:8787

Открывается интерфейс:

Слева бриф (тот самый текст таски из Jira) + доп. бизнес контекст в табе для конкретного рисерча (опционально, дата релиза, ограничения и тд). Там же статус по этапам и логи агентов.

В центре превью артефактов этапов с возможностью редактирования руками и перекомпиляцией итогового рисерча. Справа чат как панель управления всей этой системой.

Пишем бриф, для примера вот такая задача:

После редизайна мобильного чекаута (релиз ~3 недели назад) конверсия из корзины в покупку на iOS/Android просела. Нужно понять, на каких шагах воронки cart → checkout → payment → purchase теряем пользователей, отличается ли картина от web, и есть ли сегменты, где просадка особенно жёсткая. По итогам — решение: откатывать редизайн, точечно чинить шаг, или это шум/микс трафика.

И вот такой специфический контекст задачи:

Редизайн затронул только мобильный checkout (web без изменений в этом релизе).

Менеджмент смотрит blended cart→purchase в дашборде и видит −X п.п. на mobile; web «как будто стабилен».

Есть подозрение на paywall/платёжный шаг и на новых пользователей, но это догадки.

Нужен описательный / сравнительный разбор, не «докажите, что редизайн виноват» в причинном смысле без дизайна эксперимента.

Горизонт: 2–3 недели до релиза vs 2–3 недели после (точные даты зафиксируем, когда будут данные).

Сохраняем бриф и говорим лиду (в чат) чтобы начал планирование задачи. Лид по дефолту на gtp-5.6-sol, что меня полностью устраивает.

Планирование задачи это довольно важный этап, и тут стоит потратиться на парочку агентов. По дефолту их гоняют две роли — сначала лид пишет план, потом приходит жёсткий Analyst (по дефолту у меня на claude-opus-5) и накидывает своих идей / валидирует поделку лида. В итоге лид фиксирует замечания и правит по красоте. На выходе они отдают первый артефакт — План исследования (в папке появляется analysis-plan.md).

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

Данные

После сбора данных по рекомендации из плана скачиваем их в csv, кидаем в mega-hard-research/data/ и говорим лиду в чат что орёл в гнезде. Он сверяется с данными и делаем небольшой ED-анализ на предмет качества данных. Если где-то чего-то ему не хватит, он корректирует план на основе уже не своих влажных фантазий, а суровой реальности настоящих датасетов. В чате опишет что поменяется в плане, чтобы не перечитывать эту стену ещё раз.

Так же по пути создаст артефакт Сверка данных (data-review.md) в которых покажет таблицы, null, пропуски и т.д.

После этого собираем скелет рисерча, это уже штука более похожа на финальный отчёт.

Скелетон

Это, пожалуй, ключевой этап и на нём стоит чуть задержаться. По сути это уже инструкция кодеру, поэтому лучше пару раз перечитать и подредачить, если что не устраивает.

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

Т.к. это второй важный этап во всём флоу, то тут тоже задействованы несколько работяг:

1. Сначала лид пишет скелет рисерча

2. Потом аналитик его валидирует, ищет логические нестыковки

3. Затем лид корректирует структуру с учётом правок аналитика

4. Потом приходит Storytaller (по дефолту claude-sonnet-5) и рассказывает пацанам где они не правы и почему их скелет получился просто свалкой графиков и таблиц, а не классным и интересным отчётом. Его задача пересобрать структуру в явный нарратив, чтобы инфа подавалась в своей очерёдности от общего к частному, чтобы читатель прослеживал ключевую мысль, понимал почему именно эти секции и почему именно в таком порядке

5. Последним врывается BI-analyst (gpt-5.6-sol), натасканный на современные тренды в визуализации данных и докидывает подробные инструкции по оформлению графиков. Чтобы кодер потом не отсебятину в виде барчартов на все случаи жизни рисовал, а прям по уму, красиво, информативно.

Повторюсь, тут стоит внимательно почитать структуру, понять отвечает ли она на ключевой вопрос рисерча, и только потом переходить на следующий шаг.

Кодинг

После утверждения скелетона переходим к последнему шагу — сборке отчёта.

Тут в дело вступает Coder (claude-sonnet-5) и пишет код. Я приверженец R в вопросах стат. анализа, поэтому и мой кодер тоже фигачит на R. Глобально, наверное, питонистам от этого больно быть не должно, т.к. в идеале мы в код и не лезем, на крайняк в чате можно потыркать лида чтобы он внёс правки. Но R не супер сложный язык, как минимум удалить секции и пофиксить тексты можно и руками через редактирование.

Код пишется сразу через фреймворк для отчётов Quarto, поэтому на выходе будет файл .qmd а не привычный .R. Так задумано, просто Quarto по дефолту веселее чем базовый Markdown чистого R.

После сборки .qmd кодер отправляет файл на рендер и получает собранный красивый (или не очень) интерактивный .html (единым артефактом). И тут подключается последний агент Designer, который уже внимательно смотрит на .html и проводит лёгкий design-review на предмет поехавшей вёрстки, косячных отступов, несоответствия теме и т.д. Сразу в этом потоке отдаёт правки обратно кодеру, тот их применяет и пересобирает рендер.

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

В итоге рендерится отчёт с интерактивными графиками (для них используется plotly) и выводами который можно уже скидывать менеджеру.

Структура репозитория

Ещё разок ссылку на репо: https://github.com/Paxdelph/agent-researcher

Кайфуйте)