7 ошибок при создании ИИ-агента и как их избежать

Почему у всех в ленте получается, а у тебя нет

Лента полна обещаний: команда агентов работает, пока ты спишь, тысяча скиллов научит агента всему, SaaS собирается за выходные без строчки кода. Повторяешь шаги один в один, а результат не тот.

Это нормально. Любой продукт собирают маленькими итерациями, и с агентами так же. Агент не снимает с тебя необходимость понимать свою задачу: он берёт на себя исполнение, ожидание и проверки, а правило, критерий готовности и исключения остаются за человеком.

Ниже семь ошибок, из-за которых не получается создать ИИ-агента, который работает, и что делать вместо них.

Ошибка 1. У задачи нет критерия готовности

Самая частая причина провала мультиагентных систем не координация агентов и не слабая модель, а плохая спецификация задачи. Она появляется, когда человек передаёт агенту не только исполнение, но и описание цели и критериев приёмки.

До запуска агента стоит ответить на три вопроса, которые не про код и не про синтаксис:

• как я пойму, что задача готова;
• как я пойму, что она сделана хорошо;
• как я пойму, что она провалена.

Когда ответы есть, часть задач уже можно отдавать агенту. Когда их нет, агент придумает их сам. С этого начинается первое занятие интенсива «Разработка агентных систем»: выбираешь задачу, описываешь ожидаемый результат и готовишь примеры для проверки.

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

Никита Шилов

Ошибка 2. Агент сам себе ставит оценку

Дай агенту доступ ко всему, что о тебе известно, и попроси «крутой пост». Он напишет текст, сам решит, что значит «крутой», проверит его тем же вкусом и оценит работу высоко. Отправь тот же пост в новый чат без контекста, и его с той же уверенностью разгромят.

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

Ошибка 3. Все тесты зелёные, а продукт не работает

Логика «постоянного клиента» у бизнеса: два и больше заказа за 90 дней. Агент без явного правила решил, что это три заказа за всё время, и написал тесты под свою догадку. Все тесты зелёные. Приёмка по правилу бизнеса проходит в двух случаях из пяти.

Большие агентные фреймворки, которые ведут продукт от идеи до тикетов, без вмешательства превращаются в очень реалистичный симулятор бурной деятельности: много отчётов и токенов при формально выполненной задаче.

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

Глеб Михеев

Ошибка 4. Тысяча чужих скиллов

Популярные наборы скиллов полезны, но это чужой процесс. Они работают в той логике, которую заложил их автор. Скиллы, которые агент пишет себе сам, в среднем не помогают, а выверенные человеком дают ощутимый прирост к доле решённых задач.

Скиллы, которые агент делает себе сам, практически всегда отвратительны.

Никита Шилов

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

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

Ошибка 5. Память из всего подряд

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

Граф заметок сам по себе преимуществ не даёт. Если сложить в него всю переписку и все звонки, выдача станет хуже. Агент не понимает, какая из двух заметок о цене актуальна, если в них нет дат и статусов.

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

На интенсиве «Разработка агентных систем» память это отдельный практикум: сравнишь работу без памяти, с заметками в файле и с системой памяти и задашь правила сохранения, обновления и удаления записей.

Ошибка 6. Запрет в промпте вместо запрета в правах

Для модели письмо и твоя команда составляют один поток текста. Скрытая инструкция в письме может заставить агента пересказать договор без опасных условий. Пакет с post-install скриптом может найти все файлы с переменными окружения и отправить их на чужой сервер.

Никогда нельзя доверять модели. Если ей сказали этого не делать, не надо ждать, что она этого не сделает. Поэтому запрещаем физически, а не на уровне промпта.

Глеб Михеев

Чувствительные данные проще всего защитить, не передавая их модели: паспорт, email и ФИО заменяют плейсхолдерами до запроса, а настоящие данные подставляют на выходе. Обработку отказов и журнал критичных действий проектируют заранее. В готовых наборах скиллов их почти никогда нет.

Ошибка 7. Команда агентов там, где хватит одного

Мультиагентная система оправдана в двух случаях. Первый: этапы сильно отличаются по данным и инструментам, как бэкенд, фронтенд и инфраструктура. Второй: одну роль нужно противопоставить другой. Разработчик хочет быстрее выпустить фичу, а безопасник защищает данные. Если отдать обе цели одному исполнителю, хуже будет и то, и другое.

Пять одинаковых агентов при этом не нужны. Если оркестратор передаёт субагенту весь контекст, получается клон того же агента с тем же загрязнённым контекстом. Агент, который только что писал код, критикует его слабее, чем свежий. Команду из 2–3 агентов с оркестратором, правами и лимитами собирают на последнем практикуме ступени PRACTICE и сравнивают с одним агентом на одинаковых задачах: смотреть программу.

Как создать ИИ-агента: идти по ступенькам

Создавать ИИ-агента стоит по ступенькам, а не прыжком: простую задачу довести с агентом руками, обернуть в навык, автоматизировать запуск и только потом собирать команду.

По этой же лестнице устроен интенсив «Разработка агентных систем». На START собираешь первого агента с навыком и правилами памяти. На PRACTICE подключаешь базу знаний и рабочие системы, настраиваешь права, автозапуск и команду из 2–3 агентов. На SYSTEM фиксируешь требования, сохраняешь версии в репозитории и готовишь пакет восстановления.