В них же я обещал рассказать, как это реализовано у нас в компании.
Что ж, смотрите схему.
Она построена по пути задачи: от постановки до публикации результатов. Всего пять этапов:
1. Постановка задачи
2. Определение способа решения
3. Решение задачи
4. Оценка результатов
5. Публикация и обновление артефактов харнесса
1. Постановка задачи
Все задачи сейчас заходят через сессию с агентом, но могут иметь разный формат: карточка в трекере Kaiten, сообщение в мессенджере или скриншот или описание задачи в сессии с агентом.
В любом случае её всегда подхватывает скилл
`task-groomer`. Его работа - выжать из запроса конкретику: что считаем, на какой выборке, что считаем за результат и по каким критериям его принимаем.Если в постановке дыра, он останавливается и задает пользователю уточняющие вопросы.
Далее определяем способ решения задачи.
2. Определение способа решения
Состоит из двух подэтапов:
1. Определение домена, к которому определена задача
2. Определение агента, который будет эту задачу решать
Сначала
`task-router` смотрит, к какому направлению относится задача.Если направление ещё не активировано в репозитории (это управляется отдельным флагом админом репозитория), он говорит об этом и предлагает активировать. Писать в неактивное направление он не станет: оно доступно только на чтение.
Потомподключается
domain-agent.Он знает нюансы своих данных: где какие косяки, что с чем нельзя складывать, какие таблицы врут. Он же выбирает исполнителя и передаёт ему все необходимые детали вместе с описанием задания.
3. Решение задачи 🔬
За решение задач отвечает несколько агентов.
`ab-lead` отвечает за эксперименты и определяет, какой это тип теста (клиентский, квази, свитчбэк) и что надо сделать (задизайнить, оценить результаты, сделать пост-анализ). Далее он отдаёт задачу одному из шести скиллов (пример скиллов: дизайн клиентского теста, дизайн свитчбэка, оценка клиентского теста и тд). `bi-analyst` собирает дашборды в Superset и Databricks. Если ему нужны пайплайны или витрины - идёт за этим к data-engineer.`researcher` ведёт исследования, `debugger` разбирается, почему числа в дашбордах или витринах не сходятся, `metadata-specialist` отвечает, что значит таблица и когда обновлялась, `local-specialist` работает под уникальные задачи направления (пример: парсинг цен).4. Оценка результатов
Перед публикацией результат уходит к
`reviewer`.Он не видел, как считали, и получает только результат с доказательствами.
Дальше смотрит глазами скептика: откуда взялась выборка, повторяются ли числа, что осталось за скобками.
Вердикт он отдаёт в сессию, и если нужны правки, агент направления перезапускает того же специалиста с замечаниями.
5. Публикация и обновление артефактов харнесса
Когда ревью пройдено, включается
`report-agent`. Он пишет отчёт по единому шаблону, и он единственный, кому разрешено писать в базу знаний.Кроме того, раз в неделю запускается
`librarian` и идёт по всей базе.Ищет все, что лежит в репозитории не на своих местах: устаревшие факты, неописанные таблицы, устаревшие скрипты или ссылки и тд.
Далее он складывает находки в пулл-реквест и отдаёт владельцу направления.
Ускорило ли это мою работу?
Однозначно да.
Хотя, по-началу я очень много времени тратил на настройку, проверки, корректирование ошибок и тд.
Но со временем, харнесс настроился под мои задачи и теперь я практически не могу без него: задачи можно выполнять параллельно встречам или работать сразу над несколькими проектами.
Порой такая многозадачность выжигает мне мозг. Об этом писал в посте «Многозадачность - это ложь».
Но отказаться я уже не могу.
На этом я планировал закончить серию постов про харнессы, но если хотите узнать какие-то детали, то ставьте 🔥 и пишите вопросы в комментах.
Могу детальнее рассказать про конкретные скиллы, инструкции и тд.