Блог Hard&Soft Skills · Продуктовая AI-разработка · Level 2
Курс «Продуктовая AI-разработка»: итоги первого потока – что освоила группа и где споткнулась
Мы завершили первый поток курса «Продуктовая AI-разработка» – второго уровня линейки AI-Driven Development. Курс про то, как довести ИИ-агента от прототипа до системы, которую можно эксплуатировать: MCP-сервер, RAG, агент и мультиагентная система на LangGraph, восстановление после сбоя, evals, трассировка в Langfuse, себестоимость и защита от атак через недоверенный контент. Поток вели Сергей Голубев и Павел Вейник.
По итогам мы свели вместе результаты проверки девяти домашних заданий, циклы проверки и коммиты в репозиториях участников. Получилась картина, которая полезна не только группе. Если вы строите агентов в команде, она показывает, где у инженеров уже уверенная рука, а где ошибки повторяются у большинства.
Коротко, что показал поток:
- Собрать агентную систему смогли все, кто дошёл до конца. До седьмого модуля дошли 7 из 11 участников, и все семь закрыли все девять заданий с продвинутым сертификатом.
- Самое трудное задание – evals. Доработка понадобилась в 5 из 7 сдач, и у всех пяти среди причин был один и тот же шаг: порог воспроизводимости судьи.
- Самая частая ошибка – два слоя повторов на одной операции. Она нашлась у 8 из 9 участников, сдавших задание про устойчивость агента.
- Трудность курса лежит в замере. Число описывает уже другую версию системы, сравнение версий идёт в разных условиях, размер замера не планируется от ожидаемого эффекта.
Если вам нужны только выводы для своей работы с агентами, переходите сразу к разделу «Что из этого взять себе»: там шесть проверок, на которые стоит обратить внимание в своей системе.
Что такое курс «Продуктовая AI-разработка»
Это курс для разработчиков и инженеров, которые хотят выйти за пределы готовых AI-инструментов и делать свои продукты на базе LLM. На первом уровне линейки инженер учится работать с кодинг-агентом. На втором он строит агентную систему, которая выдерживает живой трафик, сбои, счёт за токены и атаки.
Каждый модуль заканчивается практическим заданием, и за курс их девять:
| Задание | Что строит участник |
|---|---|
| 1.3 | MCP-сервер, через который агент проводит сущность по жизненному циклу и не может сделать недопустимый переход |
| 2.3 | RAG с гибридным поиском и слиянием результатов RRF; коллекция пересоздаётся одной командой |
| 3.3 | агент на LangGraph со своим условием остановки и паузой перед необратимым действием |
| 4.3 | мультиагентная система на LangGraph и сравнение с той же системой на n8n в числах |
| 5.3 | выбор агентного стека в ADR и устойчивость к сбоям: ключи идемпотентности, восстановление после убийства процесса |
| 6.4 | evals: датасет, судья другого вендора, рубрика, baseline |
| 6.5 | трассировка в Langfuse и оценка живого трафика судьёй |
| 7.2 | себестоимость прогона агента, прогноз месячного счёта, эксперимент оптимизации |
| 7.4 | защита агента от атак через недоверенный контент и регрессионный тест с порогом |
Задания проверялись по критериям приёмки. Работу принимали, принимали с замечаниями или возвращали на доработку. Участник выбирал уровень сдачи: normal или advanced.
Как шёл поток
В потоке 11 участников, между первым и последним коммитом в репозиториях группы прошло около 10 недель. Первые три задания сдали и закрыли все 11.
Кто начал шестой модуль, тот не остановился: все 7 участников закрыли и седьмой. Именно те же семь закрыли все девять заданий.
Как шёл поток
Кто начал модуль 6, дошёл до конца
По горизонтали – задания по порядку: номер модуля и номер задания в нём.
Сертификат получили все 11 участников. Продвинутый – 7, это те, кто закрыл все девять заданий. У остальных четверых принято от 3 до 5 заданий, ниже порога базового сертификата в 7, и они получили сертификат уровня «Прослушал».
Сертификаты
Сертификат получили все 11
Продвинутый сертификат – все 9 заданий из 9, базовый – от 7 принятых из 9, «Прослушал» – меньше 7 принятых.
| Задание | Что строит участник | Принято | Из них с замечаниями | На доработке | Не сдавали |
|---|---|---|---|---|---|
| 1.3 | MCP-сервер, через который агент проводит сущность по жизненному циклу и не может сделать недопустимый переход | 11 | 1 | 0 | 0 |
| 2.3 | RAG с гибридным поиском и слиянием результатов RRF; коллекция пересоздаётся одной командой | 11 | 0 | 0 | 0 |
| 3.3 | агент на LangGraph со своим условием остановки и паузой перед необратимым действием | 11 | 0 | 0 | 0 |
| 4.3 | мультиагентная система на LangGraph и сравнение с той же системой на n8n в числах | 9 | 7 | 1 | 1 |
| 5.3 | выбор агентного стека в ADR и устойчивость к сбоям: ключи идемпотентности, восстановление после убийства процесса | 9 | 9 | 0 | 2 |
| 6.4 | evals: датасет, судья другого вендора, рубрика, baseline | 7 | 4 | 0 | 4 |
| 6.5 | трассировка в Langfuse и оценка живого трафика судьёй | 7 | 6 | 0 | 4 |
| 7.2 | себестоимость прогона агента, прогноз месячного счёта, эксперимент оптимизации | 7 | 1 | 0 | 4 |
| 7.4 | защита агента от атак через недоверенный контент и регрессионный тест с порогом | 7 | 3 | 0 | 4 |
«На доработке» – работы, которые на момент подведения итогов оставались возвращёнными. Сколько сдач возвращали на доработку хотя бы раз, показывает таблица самых трудных заданий ниже.
Уровень сдачи говорит о группе не меньше, чем число принятых работ. Из 53 проверенных сдач 46 сданы на advanced, а в шестом модуле normal не выбрал никто.
Как группа работала
Статистику работы мы собрали по 10 участникам, у которых есть репозиторий курса. Всего в них 3779 коммитов. Разброс большой: от 16 до 1274 коммитов на человека при медиане 219, кода вместе с тестами – от 4970 до 82 954 строк при медиане 30 962.
Код группа писала днём и вечером. С 18 до 24 часов сделано 1532 коммита из 3779 – 41%, с 12 до 18 – 1382, или 37%. На утро приходится 17% коммитов, на ночь – 6%. Вечер – самое частое время у 6 из 10 участников, день – у 4 из 10.
Когда группа работала
Больше всего коммитов – вечером, с 18 до 24
Время коммитов по часам их авторов, 10 репозиториев группы.
Основная масса строк в репозиториях – логи сессий с агентом и данные: у 7 из 10 участников их доля выше половины. Работа с агентом оставляет большой след, и по нему потом видно, как человек шёл к результату.
К доработке после разбора возвращались 7 из 10. Самая быстрая доработка у каждого из них заняла от 2,4 часа до 7 суток, медиана среди них – 38,4 часа.
Самые трудные задания
Трудность задания мы считали по двум числам: в скольких сдачах понадобилась доработка и сколько циклов проверки было в среднем. Первые три задания принимались в основном без развёрнутых разборов, поэтому сравнение идёт по модулям 4–7.
| Задание | Что строит участник | Проверено сдач | С первого цикла | Понадобилась доработка | Циклов в среднем |
|---|---|---|---|---|---|
| 4.3 | мультиагентная система на LangGraph и сравнение с той же системой на n8n в числах | 10 | 7 | 3 | 1,2 |
| 5.3 | выбор агентного стека в ADR и устойчивость к сбоям: ключи идемпотентности, восстановление после убийства процесса | 9 | 9 | 0 | 1,0 |
| 6.4 | evals: датасет, судья другого вендора, рубрика, baseline | 7 | 2 | 5 | 1,9 |
| 6.5 | трассировка в Langfuse и оценка живого трафика судьёй | 7 | 4 | 3 | 1,6 |
| 7.2 | себестоимость прогона агента, прогноз месячного счёта, эксперимент оптимизации | 7 | 5 | 2 | 1,1 |
| 7.4 | защита агента от атак через недоверенный контент и регрессионный тест с порогом | 7 | 6 | 1 | 1,0 |
Три самых трудных задания – evals, трассировка и мультиагентная система. Во всех трёх ломалась не сборка.
Доработки
Evals возвращали на доработку чаще всего
Задания 1.3–3.3 принимались в основном без развёрнутых разборов и в сравнение не входят.
Evals: порог, который не записали до прогона
Основу набора evals собрали все 7 сдавших. Развести модели по трём ролям – система, генератор датасета и судья, – написать рубрику судьи с выходом Unknown и разобрать провалы по трассировке смогли все семеро.
Схема задания 6.4
Три роли у моделей разных вендоров – и порог, который пишут до прогона
Генератор
модель вендора A собирает датасет
Датасет
плюс трудные, пустые и враждебные кейсы руками; заморожен до прогона
Система
модель вендора B отвечает на кейсы
Судья
модель вендора C, рубрика на одно свойство, выход Unknown
Порог
два прогона судьи сверяются с числом, записанным заранее
Сборку сделали все 7 сдавших. Оранжевый шаг – тот, что был среди причин возврата во всех 5 доработках.
Ломался один шаг – порог воспроизводимости судьи. Во всех 5 сдачах, ушедших на доработку, он был среди причин первого возврата. В 4 из 5 числового порога не было вовсе, в 2 из 5 объявленный порог не выдержали. Двое, кто сразу объявил порог числом и сверил с ним измеренное, прошли задание с первого цикла.
Задание требует, чтобы два прогона судьи давали близкие оценки. Слово «близко» в нём не уточнено. Проверяющие объясняют провалы так: «близко» – это ваше число, записанное до прогона, и пока числа нет, следующий замер сравнить не с чем.
Трассировка: снимок показывает не то, что пишет код
В задании про Langfuse у всех 7 сдавших хотя бы одно понижение касалось того, что видно на снимке экрана. На кадре дерева трассировки нет спана поиска с найденными фрагментами или не раскрыты аргументы инструмента, выборка по пользователю и сессии не показана интерфейсом, число из ответа не читается с виджета дашборда. Все три возврата на доработку связаны с деревом трассировки.
Отдельная ловушка заложена в самом инструменте. Интеграция LangChain даёт всем вызовам модели одно имя ChatOpenAI, и разрез стоимости по имени наблюдения отвечает на вопрос «какая модель дороже» вместо «какой агент дороже». Это отмечено у 3 из 7. Если вы считаете стоимость агентов в Langfuse, проверьте, как называются ваши наблюдения. Проверяющие советуют: перед съёмкой откройте критерий приёмки и снимайте под него.
Мультиагентная система: сравнение в разных условиях
Доработка в задании 4.3 – мультиагентная система на LangGraph и сравнение с той же системой на n8n в числах – понадобилась в 3 из 10 сдач, а трудность сидит в его третьей части – сравнении с версией на n8n в числах. Целиком оно доказано только у 1 из 10. Условия двух версий различались: модель, состояние экспорта n8n, средние по разным подвыборкам запросов. Или оценка качества стояла на одном прогоне без названного дефекта. Сколько минут занимает новое условие маршрутизации в n8n, у 4 из 10 осталось без замера.
Сравнение двух систем держится, только когда нагрузка, модель и состояние кода одинаковы для обеих сторон. Это условие легче всего потерять. При этом критиковать n8n группа научилась правильно: у 9 из 10 ограничения инструмента названы через цену сложности, без претензий к возможностям, которые у него есть.
Чему группа научилась
Умения ниже подтверждены у большинства сдавших соответствующее задание. Доля дана от числа сдавших: задание 4.3 (мультиагентная система) сдали 10 участников, 5.3 (выбор стека и устойчивость к сбоям) – 9, задания модулей 6 и 7 – по 7.
Подтверждённые умения
Модули 6 и 7 освоили все, кто до них дошёл
4.3Мультиагентная система на LangGraph и сравнение с той же системой на n8n в числах
5.3Выбор агентного стека в ADR и устойчивость к сбоям: ключи идемпотентности, восстановление после убийства процесса
6.4Evals: датасет, судья другого вендора, рубрика, baseline
6.5Трассировка в Langfuse и оценка живого трафика судьёй
7.2Себестоимость прогона агента, прогноз месячного счёта, эксперимент оптимизации
7.4Защита агента от атак через недоверенный контент и регрессионный тест с порогом
Доля – от сдавших задание: 4.3 – 10 участников, 5.3 – 9, модули 6 и 7 – по 7. Полная полоса – умение подтверждено у всех сдавших.
В задании про себестоимость все 7 сдавших откатили или отклонили хотя бы один рычаг оптимизации по замеру качества. В задании про устойчивость у 4 из 9 вывод об окупаемости durable-слоя оказался отрицательным и подтверждён своими числами. Пределы своего замера и собственные дефекты участники называли сами – это отмечено в разборах всех 10 участников с репозиторием.
Где группа ошибалась чаще всего
Ошибки ниже повторялись у половины группы и больше. Три из пяти – про то, что работа сделана, но не доказана.
Типовые ошибки
Самая частая ошибка нашлась у 8 из 9
Две политики повторов на одной операции
Число попыток перемножается, бюджет и нагрузку при сбое не предсказать по конфигурации
Число в отчёте описывает другое состояние системы
Решение принимают по числу уже не той версии, коллега его не воспроизведёт
Сделано, но показано не там, где ищет критерий
Читатель документа не откроет ваши рабочие файлы, и решение теряется
Ключ уходит в репозиторий через выгрузки сессий и снимки экрана
Ключ приходится перевыпускать: значение остаётся в истории репозитория
Размер замера не планируется от эффекта
Оптимизацию или защиту принимают и отклоняют по шуму
Кольцо – сколько участников из сдавших задание с этой ошибкой. Слева сверху – самая частая.
Повторы в двух местах
Самая частая ошибка курса встретилась в задании про устойчивость агента. У 8 из 9 сдавших повторы клиента модели срабатывали внутри единицы повтора durable-слоя. У троих видна целая цепочка: max_retries, поднятый по требованию задания 4.3 (мультиагентная система на LangGraph), в задании 5.3 (устойчивость к сбоям) стал второй политикой поверх политики слоя.
Две политики повторов перемножают число попыток. Например, при сбое провайдера три попытки клиента внутри каждой из трёх попыток слоя дают уже девять вызовов модели, и бюджет, тайм-ауты и нагрузку по конфигурации больше не предсказать. Рядом шла вторая ошибка того же задания: у 7 из 9 импорт или декоратор фреймворка оставался в коде агента мимо адаптера. Такой протекающий шов превращает замену фреймворка в переписывание.
Повторы в два слоя
Одна операция при сбое провайдера: 3 × 3 = 9 вызовов модели
durable-слой
попытка слоя 1
3 попытки клиента
попытка слоя 2
3 попытки клиента
попытка слоя 3
3 попытки клиента
Пример для трёх попыток на каждом уровне. Такая схема нашлась у 8 из 9 сдавших задание 5.3.
Число описывает уже другую систему
Замер снят до последних правок кода; систему правили внутри окна замеров; числа прошлого захода остались рядом с новыми; число набрано руками и разошлось с логом. Так было у 6 из 10, в семи заданиях из девяти.
Средство здесь техническое: печатать таблицу отчёта тем же скриптом, который считает числа. У двоих, кто перешёл на такой вывод после замечания, следующие сверки сошлись.
Ключ в репозитории при чистом коде
У 5 из 9 ключ попал в репозиторий, хотя код был чистым: ключи читались из переменных окружения. Утекали они через выгрузки сессий IDE и снимки экрана. У двоих был настроен даже сканер секретов, но он не знал префикса открытого ключа Langfuse. «Ключей нет в коде» и «ключей нет в репозитории» – разные требования, и для работы с агентом второе важнее: логи сессий агента обычно лежат в репозитории.
Что группа теперь умеет уверенно
Если собрать всё, что принято в работах потока, получится стек, с которым можно строить агентный продукт:
Что из этого взять себе
Если вы строите агентную систему в команде, вот что по итогам потока мы советуем проверить у себя:
- Порог – до прогона. Записывайте числом, что значит «достаточно близко» или «достаточно хорошо», до того как запустить замер. Без этого следующий прогон сравнить не с чем.
- Одна политика повторов. Если повторы есть в durable-слое, отключите их у клиента модели внутри него. Проверьте, что
max_retriesнигде не стоит вторым этажом. - Отчёт печатает скрипт. Таблица с числами должна выходить из того же кода, который их считает, и на той же версии системы, о которой отчёт.
- Baseline – два-три раза. Прогоните базовую конфигурацию несколько раз до эксперимента и посмотрите на разброс. Разница меньше разброса – это шум.
- Сравнение – в одинаковых условиях. Та же модель, та же нагрузка, то же состояние кода для обеих версий.
- Секреты – вне логов. Добавьте в сканер секретов префиксы ключей всех сервисов, которыми пользуется агент, и проверяйте выгрузки сессий перед коммитом.
Evals, трассировка и замер стоимости – не единственный путь проверить агента. Ревью трассировок вручную, канареечный деплой на часть трафика, сравнение с ручной разметкой тоже дают ответ. Но все эти способы упираются в тот же вопрос, на котором спотыкалась группа: какое число вы заранее назвали приемлемым и на какой версии системы его сняли.
Отдельное спасибо Сергею Голубеву за этот поток. Вместе с ним группа прошла путь от MCP-сервера до регрессионного теста на атаки, и семеро из одиннадцати закрыли все задания и получили продвинутый сертификат. Сергей, спасибо – и надеемся на дальнейшее сотрудничество!
Следующий поток «Продуктовой AI-разработки»
Программа и запись