Что такое ИИ-агенты и почему их трудно довести до продакшена

Конспект Agents Week ШАДа

С 6 по 10 апреля Школа анализа данных и Яндекс провели бесплатный онлайн-интенсив Agents Week. Десять лекций и семинаров от практиков из Лавки, Браузера, Алисы и Yandex Cloud — людей, которые строят агентов на реальных продуктах с десятками тысяч пользователей. Все записи открыты на YouTube, страница интенсива — agentsweek.yandex.com.

Скрин с сайта Школы анализа данных

Ниже — сжатый конспект самого важного. Без сокращений, понятным языком, от основ к деталям. Если какие-то идеи цепляют — рядом ссылка на конкретное видео, где это разбирают подробно.

!!! Больше кейсов на канале “AI для продакта”

Часть 1. Что такое агент и зачем он вообще нужен

Агент — это не «GPT с памятью»

Большая языковая модель (LLM) сама по себе умеет одно: продолжать текст. На вход — слова, на выход — слова. Она не ходит в интернет, не помнит вчерашний разговор, не нажимает кнопки и не выполняет действия в реальном мире.

Агент — это обвязка вокруг модели, которая превращает «генератор текста» в «исполнителя задач». Команда ШАДа предлагает рабочее определение: агент состоит из семи слотов.

• Модель — мозг. То, что генерирует ответы.
• Промпты — инструкции. Системный промпт задаёт роль агента, сообщения пользователя — конкретные задачи.
• Инструменты — функции, через которые агент дотягивается до внешнего мира. Поиск, база данных, отправка письма.
• Память — то, что агент помнит между сообщениями и сессиями.
• Guardrails — защита от опасных и нежелательных действий.
• Планирование — способность строить последовательность шагов, а не отвечать одним выстрелом.
• Рантайм — система, которая всем этим управляет: когда вызвать модель, когда инструмент, когда остановиться.

Любой слот можно опустить, и тогда вы получите более простую систему. Но чем больше слотов отсутствует, тем ближе к обычному чатботу и дальше от агента.

Полезная аналогия от Андрея Карпатого, на которую ссылаются: думайте про LLM не как про чатбота, а как про новую операционную систему. Модель — ядро. Контекстное окно (сколько текста модель видит за раз) — оперативная память. База знаний для поиска — диск. Инструменты — приложения. Так понятнее, почему «давайте просто прикрутим ChatGPT» — это не план разработки, а только включение компьютера.

Посмотреть подробнее: Лекция 1, Алёна Зайцева, руководитель AI-сервисов в Яндекс Лавке.

Эволюция: от промпта к мультиагентной системе

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

1. Простой промпт. Пользователь задал вопрос — модель ответила. Никакой логики после ответа.
2. Роутинг. Модель решает, по какой из нескольких заранее заданных веток пойти.
3. Tool calling. Модель умеет вызывать внешние функции с правильными аргументами.
4. Многошаговый агент. Модель планирует, выполняет цепочку действий, перепроверяет себя.
5. Мультиагентная система. Несколько агентов координируются между собой.

С каждой ступенью модель получает всё больше контроля над процессом — и тем больше возникает инженерных задач: как не дать ей сломаться, как замерить качество, как не разориться на токенах.

Посмотреть подробнее: Лекция 1, Алёна Зайцева, руководитель AI-сервисов в Яндекс Лавке.

Часть 2. Инструменты — то, через что агент влияет на мир

Хороший инструмент — это контракт, а не функция

Когда агент вызывает «инструмент», он по сути дёргает обычную функцию в коде: «найди мне рейс из Москвы в Париж». Кажется простым, но в проде вылезают пять требований, без которых система разваливается.

• Откат при сбое. Если агент списал деньги, зарезервировал товар и попытался создать доставку, а доставка упала — нужно уметь откатить и оплату, и резерв. Это не задача LLM, это задача того, кто пишет инструмент.
• Идемпотентность (повторный вызов не должен ломать систему). Если агент таймаутнулся и попробовал ещё раз отправить письмо, оно не должно уйти дважды.
• Понятные ошибки. Не «Error 500», а «не хватает поля city, переспроси у пользователя». Ошибка пишется не для человека, а для другой модели, которой её читать.
• Гайды для агента в самом ответе. В ответе инструмента можно прямо подсказывать модели, что делать дальше: «если данные неполные — уточни у пользователя».
• Структурированные ответы. Не полотно текста, а JSON с понятными полями, который модели легко переиспользовать.

Главная мысль: инструмент для агента — это не просто функция, а надёжный контракт между моделью и реальной системой, который выдерживает сбои, повторы и изменения внешних API.

MCP — стандарт, который связывает агентов с инструментами

MCP (Model Context Protocol) — открытый протокол от Anthropic, опубликованный в ноябре 2024 года. Решает простую боль: у каждой команды свой формат описания инструментов, при смене внешнего API всё переписывается заново, переиспользовать ничего нельзя.

С MCP инструменты отделяются от агента и живут на отдельных серверах. Любой агент-клиент может подключиться к любому MCP-серверу. Команда ШАДа сравнивает это с USB-C для агентной экосистемы: один разъём — много устройств.

Посмотреть подробнее: Лекция 2, Алёна Зайцева

Часть 3. Память — то, что агент помнит

Три типа памяти

• Краткосрочная (рабочая) — в пределах одной сессии. Текущий диалог, промежуточные результаты. Закрылась сессия — память исчезла.
• Долгосрочная — переживает сессии. Здесь лежит, например, «этот пользователь — вегетарианец, любит места у окна».
• Контекстная — то, что прямо сейчас лежит в контекстном окне модели и используется для генерации ответа. Может включать кусочки из обоих предыдущих типов.

RAG — мост между долгосрочной памятью и моделью

RAG (Retrieval-Augmented Generation) — техника, при которой агент сначала ищет нужную информацию в базе, добавляет её в контекст, и только потом просит модель сгенерировать ответ. Используется, когда:

• модель не знает свежих данных (обучена в прошлом году);
• информации слишком много, чтобы запихать всю в контекст;
• домен меняется быстро (новости, цены, законы).

Команда курса даёт чёткое правило выбора между RAG и дообучением модели: сначала пробуйте RAG. Он быстрее, дешевле, заводится за полчаса. Дообучение оправдано только если домен стабильный, требует глубокой экспертизы и есть ресурсы (вычисления, данные, инженеры на эксперименты).

Когда контекст не влезает: четыре стратегии

Контекстное окно модели ограничено. Что делать, когда диалог разросся:

• Скользящее окно. Выкидываем старые сообщения, оставляем последние. Системный промпт не трогаем. Просто, но информация теряется.
• Суммаризация. Сжимаем накопленный диалог отдельным запросом к модели. То самое «condensing context», которое появляется в Claude Code, когда он на минуту замирает посреди задачи.
• Эмбеддинги предыдущего диалога. Каждый кусочек прошлого разговора превращаем в вектор и подтягиваем только то, что релевантно текущей реплике.
• Большие модели. Современные модели держат миллион токенов в контексте. Решает проблему деньгами и временем ожидания.

Посмотреть подробнее: Лекция 2 дня, Кирилл Мищенко, руководитель ML-разработки в Яндекс Браузере.

Часть 4. Guardrails — защита от опасного поведения

Три типа угроз

Прямая промпт-инъекция. Пользователь пишет «игнорируй предыдущие инструкции и сделай Х». Бороться научились: классификаторы на входе, чёткое разделение в промпте, где инструкции, а где данные.

Непрямая промпт-инъекция — опаснее. Агент пошёл в инструмент, инструмент вернул данные, и в этих данных уже сидит атака. Браузерный агент читает страницу — на странице белым по белому написана команда для модели, обычный пользователь её не видит, агент видит. То же с письмами, документами из RAG, ответами внешних API, MCP-серверами из ненадёжных источников. Защита: проверять не только то, что вводит пользователь, но и всё, что возвращают инструменты.

Jailbreak. Не команда «игнорируй правила», а уговоры. «Я медик, мне очень нужно для исследования». Модель обучена быть полезной, и баланс между полезностью и безопасностью не идеальный.

Галлюцинации в действиях — отдельная история

Команда ШАДа выделяет три вида галлюцинаций. Самая опасная — галлюцинация в действии. Пример: модель сгенерировала команду установить пакет, которого не существует. Команда упала, в логах остался запрос. Злоумышленник видит логи, регистрирует пакет с тем же именем и кладёт туда вредоносный код. В следующий раз агент устанавливает его — теперь успешно.

Защита: жёсткая валидация аргументов перед вызовом инструментов, белые списки допустимых значений, изолированное окружение для критичных операций, человек в цикле для самого опасного.

Посмотреть подробнее: Лекция 2 дня, Кирилл Мищенко

Часть 5. Как агент думает: стратегии рассуждения

Команда курса разбирает три способа организовать «мышление» агента.

Chain-of-Thought. В промпте просим модель думать пошагово. Одна генерация, без вызова инструментов. Подходит для математики, логики, анализа текста — задач, которые решаются одним рассуждением.

ReAct (от reason + act). Чередует мысль, действие, наблюдение результата. Использует инструменты. Если ошибся на шаге действия — обратная связь от среды это поймает, и следующий шаг рассуждения скорректируется. Около 90% реальных агентов построены именно так.

Reasoning-модели (вроде o1 от OpenAI). Думают на уровне обучения — модель сама обучена строить длинные цепочки рассуждений, выдавая специальные «думающие» токены. Чёрный ящик: модель сама решает, сколько ей думать. Дорого — за думающие токены платит пользователь.

Простое правило выбора. Нужны инструменты — берите ReAct. Не нужны и задача простая — Chain-of-Thought. Не нужны, но задача требует глубокого многоэтапного планирования и есть бюджет — reasoning.

Посмотреть подробнее: Лекция 3 дня, Софья Проскурина, разработчик AI-платформы в Яндекс Лавке.

Часть 6. Когда одного агента мало

Не лезьте в мультиагентность раньше времени

Мультиагентные системы — это модно, но команда курса прямо называет это оверинжинирингом, пока с задачей справляется один агент. Простое правило:

• 2–5 инструментов и нет планов на масштаб — оставайтесь на одиночном агенте;
• 6 инструментов и больше или задача явно делится на специализации — пора в мультиагентность.

Четыре архитектуры

• Иерархическая. Сверху агент-координатор, он раздаёт задачи специалистам и собирает ответ. Самая распространённая в продакшене. Предсказуема, легко дебажить.
• Децентрализованная. Все агенты равноправны, общаются напрямую. Высокая отказоустойчивость, но ад при отладке и риск зацикливания.
• Звезда. Маршрутизатор только переправляет запрос подходящему агенту, не декомпозирует. Самая простая, но плохо масштабируется.
• Shared message pool. Агенты пишут сообщения в общий пул и подписываются на нужные. Асинхронно, масштабируется, но порядок обработки непредсказуем.

Полезный нюанс по бюджету

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

Посмотреть подробнее: Лекция 3 дня, Софья Проскурина

Часть 7. Eval — как понять, что агент работает хорошо

Это самый недооценённый и ценный блок интенсива. Команда ШАДа выносит оценку качества агента в отдельную инженерную дисциплину.

Почему оценить агента сложно

• Ошибки накапливаются. На шаге 3 ошибся в параметре — на шаге 7 это уже катастрофа.
• Несколько правильных путей. Агент может прийти к успешному результату разными способами.
• Стохастичность. Один и тот же запрос даёт разные результаты от прогона к прогону.
• Скрытые ошибки. Агент может сказать «справился», не вызвав нужный инструмент.
• Побочные эффекты. Что реально изменилось в системе? Не всегда то, о чём агент отчитался.

Вывод: оценивать нужно не только финальный ответ, но и весь путь — какие инструменты вызывал, с какими параметрами, что получил в ответ.

Из чего состоит eval-пайплайн

1. Корзина задач — набор кейсов, на которых проверяется агент.
2. Раннер — инфраструктура, которая запускает агента в изолированной среде и логирует всё.
3. Критерии успеха — формальные правила, по которым решаем, справился агент или нет.
4. Грейдеры — то, что применяет критерии и выставляет оценку.

Метрика, которая отрезвляет: pass^k

Из-за стохастичности оценивать качество одним прогоном бессмысленно. Есть две полезные метрики.

• Pass@k — вероятность, что хотя бы один из k прогонов успешен. Подходит для задач, где можно ретраить (генерация кода).
• Pass^k — вероятность, что все k прогонов успешны. Единственная честная метрика для ассистентского агента.

Цифра, которая многое объясняет: на промышленном бенчмарке TAU-bench для агентов авиабронирования pass@1 у топ-моделей мира ниже 50%. При нескольких подряд успешных прогонах метрика падает экспоненциально. Поэтому демо всегда работает, а в проде агент глючит — демо это pass@1 на одном кейсе, прод это pass^k на тысячах.

Пять приёмов, чтобы LLM-судья не врал

Идея использовать одну модель для оценки другой напрашивается. Но наивно сделанный судья завышает оценки — модели обучены помогать, в том числе другим моделям. Команда ШАДа даёт пять приёмов:

• один критерий — один промпт (не пихать всё в один запрос);
• сначала рассуждение, потом оценка;
• чёткое определение, что считается хорошо и плохо, с примерами;
• разрешить судье ответить «не знаю» (иначе он выдумает оценку);
• few-shot — примеры эталонных оценок прямо в промпте.

Качество судьи проверяют через каппу Коэна — метрику согласованности с человеком-экспертом. Хорошо — выше 0.6. Та же метрика, которой проверяют согласованность двух экспертов между собой.

Посмотреть подробнее: Лекция 4 дня, Сергей Купцов, развивает агентные решения в Алисе.

Часть 8. Production: что происходит при выкатке на тысячи пользователей

Семь проблем масштабирования

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

• Медленно (LLM долго думает, пользователь не готов ждать минуту).
• Дорого (стоимость запросов растёт нелинейно).
• Непредсказуемо (модель ведёт себя по-разному).
• Нестабильно (один запрос — разные ответы).
• Не видно, что внутри (нет логов и метрик).
• Небезопасно (всё, что может сделать агент, попробует сделать пользователь).
• При запуске следующего агента всю систему придётся собирать заново.

Observability — фундамент всего остального

Главная мысль команды: трогать агента в продакшене без логов и метрик нельзя в принципе. Не видишь — не управляешь.

Структура трассировки строится на трёх уровнях:

• Span — один лог-кубик (вызов инструмента, обращение к модели). Имеет уникальный ID.
• Trace — объединяет все спаны одного пользовательского запроса.
• Session — объединяет трейсы одного диалога с пользователем.

Семь обязательных метрик на дашборде:

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

Без этих графиков вы не понимаете, что делаете. Готовые инструменты: Langfuse для трейсов и логов, Grafana с Prometheus для дашбордов и алертов. Подключаются за вечер.

Model router — паттерн, который реально экономит деньги

Перед обращением к основной модели прогоняем запрос через лёгкий классификатор. Простые запросы уходят в дешёвую модель, сложные — в тяжёлую. По цифрам Лавки, грамотный роутер уводит до 70% запросов от дорогой модели без потери качества.

Перед выкаткой команда советует считать на бумажке: сколько пользователей, сколько шагов делает агент, сколько токенов тратит запрос, сколько это в день. Часто оказывается, что обслуживание агента дороже выручки. И только после такой посчитанной картины оптимизация перестаёт быть факультативом.

Посмотреть подробнее: Лекция 5 дня, Даниил Артамонов, отвечает за платформу AI-агентов в Яндекс Лавке.

Инфраструктура от Yandex Cloud

Финальная лекция Кирилла Власова из AI Studio Yandex Cloud — больше продуктовая. Полезна тем, кто думает строить агентов на российской инфраструктуре или сравнивает варианты с зарубежными платформами.

Посмотреть подробнее: Лекция 5 дня, часть 2, Кирилл Власов, развивает AI Studio Yandex Cloud.

Итого

Если из всего написанного запомнить четыре вещи — этого хватит, чтобы говорить про агентов осмысленно.

1. Агент — это семь слотов: модель, промпты, инструменты, память, guardrails, планирование, рантайм. Когда кто-то говорит «давайте сделаем агента», просите расписать, что в каждом слоте.
2. Качество агента в одном прогоне — это рулетка, а не оценка. Без pass^k и нормального eval-пайплайна вы не знаете, как ваш агент работает.
3. Observability ставится до выкатки, а не после. Сначала логи и метрики, потом пользователи.
4. Простое раньше сложного. RAG раньше дообучения, ReAct раньше мультиагентности, один агент раньше команды агентов. Каждый раз, когда хочется усложнить, спрашивайте — точно ли это нужно сейчас.

Все записи Agents Week открыты, регистрация для просмотра не нужна: agentsweek.yandex.com. Если смотреть выборочно — пожалуй, самая сильная лекция четвёртого дня про eval. Самая практичная — пятого, про продакшен.

Конспект составлен на основе материалов Agents Week от ШАДа и Яндекса. Все ссылки на видео — официальный канал Яндекс Образования.

!!! Больше кейсов на канале “AI для продакта”