Несколько ИИ-агентов вместо одного — роли, координация и контроль

Почему один агент рано или поздно упирается в потолок

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

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

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

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

Зачем разделять роли

Разделение даёт четыре выгоды, и все они приземлённые:

• Чистый контекст. Агенту по контенту не нужно знать структуру базы данных. Меньше лишнего в контексте — точнее результат.
• Узкие права. Контентный агент физически не может уронить сервер, если у него нет доступа к серверу.
• Специализированные инструкции. Для кода нужны одни правила, для текстов — другие. В одном промпте они мешают друг другу.
• Параллельность. Пока один собирает отчёт, другой правит вёрстку. Это реальная экономия времени, а не теория.

Какие роли выделять

Набор зависит от бизнеса, но базовое деление выглядит так.

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

Координатор и исполнители

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

Что делает координатор:

1. Уточняет задачу. «Сделай лендинг» превращается в понятные подзадачи: структура, тексты, вёрстка, выкладка.
2. Определяет исполнителей. Тексты — контентщику, вёрстка — разработчику.
3. Передаёт только нужное. Исполнитель получает свой кусок и ровно тот контекст, который ему требуется.
4. Принимает работу. Проверяет, что результат соответствует задаче, и собирает всё вместе.
5. Отчитывается тебе одним сообщением, а не двадцатью.

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

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

Передача задач и общий контекст

Главная боль многоагентных схем — не «как запустить второго», а «как они договариваются».

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

Как выглядит разбор задачи на практике

Ты пишешь координатору: «нужна страница под новую услугу». Дальше он не бежит делать, а раскладывает:

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

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

Что должно быть общим:

• факты о проекте: домены, пути, сервисы, доступы (ссылками, не значениями);
• принятые решения и запреты — «так пробовали, не сработало»;
• текущий статус задач;
• стиль и тон, если речь о внешних материалах.

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

Хранилище под общий контекст обязательно. Это может быть файл с правилами, база, векторное хранилище — выбор зависит от объёма. Главное, чтобы запись была дисциплинированной: решение принято — оно записано, иначе через неделю агенты работают по разным версиям реальности. Подробнее про механику — в статье про память ИИ-агента.

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

Резервирование: что делать, когда инструмент отвалился

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

Практические приёмы:

• Деградация вместо остановки. Недоступен сервис генерации картинок — пайплайн не падает, а ставит заглушку и помечает задачу как незавершённую.
• Запасной маршрут. Для критичных шагов держи альтернативу: другой провайдер, другой способ доставки, ручной режим.
• Очередь с повторами. Задача не выполнена — она не пропадает, а возвращается в очередь с задержкой. Три неудачные попытки — уведомление тебе.
• Явное состояние. У каждой задачи должен быть статус: «в работе», «ждёт», «упала». Без этого ты не отличишь зависшую задачу от выполненной.
• Защита от дублей. Если упавший процесс перезапустился, он не должен выполнить ту же работу второй раз. Два экземпляра одного конвейера, дерущихся за один ресурс, — реальная и неприятная проблема.
• Отдельный сторож. Маленький независимый скрипт, который проверяет, живы ли сервисы, и поднимает упавшее. Он не должен зависеть от самих агентов.

Когда конвейеров много, их удобно разводить по отдельным процессам и связывать через оркестратор — связка n8n и Claude Code закрывает именно эту задачу: n8n держит расписание, повторы и ветвления, агент делает содержательную работу.

Контроль качества

Несколько агентов — это несколько источников ошибок. Проверка должна быть встроена в процесс, а не висеть на тебе.

• Критерий приёмки в самой задаче. «Готово» должно быть проверяемым: тесты зелёные, страница открывается, в тексте есть обязательные блоки.
• Разделение автора и проверяющего. Агент плохо находит собственные ошибки. Отдельный проверяющий с другой инструкцией ловит заметно больше.
• Автоматические проверки. Линтеры, тесты, валидаторы форматов, проверка ссылок на живой ответ сервера. Машинная проверка дешевле человеческой и не устаёт.
• Человек на выходе. Всё, что уходит клиентам, в публичный доступ или касается денег, смотришь ты. Это не формальность: агенты уверенно ошибаются в мелочах, которые дорого стоят.
• Логи решений. Должно быть видно, кто что сделал и почему. Без этого разбор инцидента превращается в гадание.

Права доступа

Самое скучное и самое важное. Правило: агент получает минимум, необходимый для своей роли, и ничего сверх.

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

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

Честно о состоянии дел

Многоагентные схемы дают реальный выигрыш там, где процессы повторяются и их много. Но это не магия:

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

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