В прошлых постах на тему харнессов мы разобрали теорию: контекст, а также скиллы, инструменты и оркестрацию.
В них же я обещал рассказать, как это реализовано у нас в компании.
Что ж, смотрите схему.
Она построена по пути задачи: от постановки до публикации результатов. Всего пять этапов: 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 и идёт по всей базе.
Ищет все, что лежит в репозитории не на своих местах: устаревшие факты, неописанные таблицы, устаревшие скрипты или ссылки и тд. Далее он складывает находки в пулл-реквест и отдаёт владельцу направления.
Ускорило ли это мою работу?
Однозначно да.
Хотя, по-началу я очень много времени тратил на настройку, проверки, корректирование ошибок и тд.
Но со временем, харнесс настроился под мои задачи и теперь я практически не могу без него: задачи можно выполнять параллельно встречам или работать сразу над несколькими проектами.
Порой такая многозадачность выжигает мне мозг. Об этом писал в посте «Многозадачность - это ложь».
Но отказаться я уже не могу.
На этом я планировал закончить серию постов про харнессы, но если хотите узнать какие-то детали, то ставьте 🔥 и пишите вопросы в комментах. Могу детальнее рассказать про конкретные скиллы, инструкции и тд.
В этом посте были ссылки, но мы их удалили по правилам Сетки
