Один большой промпт превратился в систему ИИ-агентов: история, где мы перестали чинить и начали делить

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

Мы притащили в этот промпт всё, что могли. Условия, исключения, «если пользователь просит X, делай Y, но не когда Z». Модель отвечала прилично на восьмидесяти процентах случаев и лажала на остальных двадцати — причём каждый раз по-новому. Ловить регресс становилось всё дороже: правишь один сценарий, отваливается соседний.

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

Что не работало в одиночном агенте

Заявка, которая падает в бизнес, — это редко один вопрос. Клиент пишет «нужен кабель ВВГ 3×2.5 на объект в Подмосковье, до конца недели, счёт на ту же компанию, что и в мае». В одном сообщении сидят четыре разные операции: поиск в номенклатуре, привязка к адресу, дата, реквизиты из истории. И у каждой — своя логика ошибки.

Единый ИИ-агент, который берётся за всё, ведёт себя как человек, которого одновременно спросили о трёх вещах. Он на что-то отвечает уверенно, что-то придумывает, а что-то роняет. Замерить, где именно он сломался, почти невозможно — снаружи это выглядит как «просто плохой ответ».

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

Разделение на роли, а не на функции

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

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

• маршрутизатор — читает входящее сообщение и раскладывает его на элементарные заявки. Ничего не отвечает клиенту, только формирует список подзадач и передаёт их дальше;
• исполнители — узкие агенты, каждый под свою предметку: номенклатура и остатки, реквизиты и договоры, даты и логистика. У каждого свой промпт, свой набор MCP-инструментов и свой список допустимых действий;
• проверяющий — собирает результат от исполнителей, сверяет с исходной заявкой и решает, готов ли ответ уйти клиенту или надо доспросить.

Формально это то, что в индустрии сейчас называют мультиагентной оркестрацией. По духу — это просто разделение труда, к которому пришли бы любые три человека на одной задаче за пару недель.

Как они разговаривают между собой

Между ролями мы намеренно поставили жёсткий контракт. Не свободный текст, а структурированные сообщения — задача, вход, ожидаемый выход. Российские модели вроде GigaChat Pro и YandexGPT спокойно возвращают JSON по схеме, если ей объяснить, чего от неё ждут, и мы этим воспользовались.

Маршрутизатор возвращает список задач с типом. Исполнитель возвращает результат с признаком уверенности и списком того, чего ему не хватило. Проверяющий возвращает вердикт — отправить, доспросить, эскалировать оператору.

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

Что оказалось неочевидным при внедрении ИИ-агентов

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

Второе: латентность честно выросла. Три модели в цепочке — это три сетевых похода вместо одного. Мы отыграли часть времени тем, что запускаем исполнителей параллельно, если задачи независимы. Ещё часть — тем, что маршрутизатор мы посадили на модель полегче: ему не нужен полноценный «мозг», ему нужно разложить сообщение на элементы.

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

Как оценивать то, что оценивать сложно

Отдельная история — как понимать, что настройка ИИ-агентов не деградирует от релиза к релизу. Снапшот-тесты на одиночный промпт мы уже умели писать. Но когда агентов становится несколько и они друг друга дёргают, снапшот на «финальный ответ» перестаёт быть полезным: он либо совпал, либо нет, а почему — непонятно.

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

Что изменилось в работе

Раньше правка любого сценария была маленьким страшным приключением: правишь текст промпта, гоняешь глазами глазами по остальным веткам, надеешься, что не задел. Теперь правка едет в промпт одного из исполнителей и никак не влияет на соседей. Правки в предметке — это правки конкретного агента, а не всей системы.

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

Когда стоит делить, а когда нет

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

Мы для себя вывели простое правило: если единственный промпт начал занимать больше экрана и в нём появились слова «но если», «за исключением», «в случае когда» — это сигнал, что внутри задачи прячется несколько разных задач. Их проще разделить между агентами, чем удерживать в голове одной модели.

А как только у вас появляется несколько агентов — сразу закладывайте состояние в базу, сквозные идентификаторы и оценочный прогон. Иначе через месяц вы окажетесь в ситуации, где систему стало страшно трогать, потому что непонятно, что она вообще делает.

Мы через это уже прошли один раз с большим промптом. Второй раз повторять не хочется.

Похожие статьи

• «Поставьте ИИ-агента прямо на компьютер менеджера»: как мы разбирались, что за этим стоит
• ИИ-агент для 1С под прицелом: чем атаки на автономных отличаются от атак на чат-бота
• ИИ-агент и ИИ-ассистент в разработке: где проходит граница, если ты сам делаешь ИИ-агентов для бизнеса
• Курс по ИИ-агентам для оператора: чему мы учим команду заказчика после запуска