Команда из 6 AI-агентов: как мы строим мультиагентные системы и на чём спотыкаемся
Один бот не тянет сложный процесс. Берётся за задачу из пяти шагов, держит в голове первые два, к третьему теряет нить, на четвёртом начинает выдумывать, а на пятом отдаёт результат, который потом переделываешь вручную. Мы упирались в это раз за разом, пока не разнесли работу по нескольким агентам с чёткими ролями. Дальше - как устроена наша команда из шести агентов и где мы набили шишки.
Зачем вообще шесть, а не один
Сложная задача - это не один большой запрос, а цепочка разных операций. Найти данные, написать черновик, проверить факты, записать результат в систему, оценить, годится ли он. Каждая операция требует своего набора навыков, своих инструментов и своего фокуса.
Когда всё это валится на одну модель, она держит в контексте сразу все роли. Инструкции исследователя мешаются с инструкциями редактора, промежуточные данные забивают окно, и к концу цепочки агент работает с замусоренной головой. Качество падает не потому, что модель слабая. Просто мы заставили её делать пять дел одновременно.
Мы строим мультиагентные системы на движке Hermes - агентном фреймворке с оркестратором и субагентами. У каждого агента свой набор инструментов, свои ключи доступа и своя память. Никто не лезет в чужую зону. Обычное разделение труда, только вместо людей - специализированные агенты.
Можно ли обойтись двумя-тремя? Иногда да. Но как только в процессе появляются проверка качества, запись во внешние системы и финальный контроль, роли начинают конфликтовать внутри одного агента. Проверяющий не должен переписывать, писатель не должен лезть в базу, а тот, кто говорит с пользователем, не должен утонуть в технических деталях. Шесть ролей - это не самоцель, а минимум, на котором каждый шаг получает чистую голову.
Кто за что отвечает
В рабочей конфигурации у нас шесть агентов: один оркестратор и пять специалистов.
Оркестратор держит диалог с пользователем и понимает задачу целиком. Разбивает её на шаги, раздаёт их специалистам и собирает результат обратно. Сам «чёрную работу» не делает - не ищет, не пишет, не дёргает API. Его дело - думать о задаче как о целом и управлять остальными. Это единственный агент, который видит всю картину.
Исследователь ищет и собирает информацию. Ходит по источникам, вытаскивает факты, проверяет, что данные не противоречат друг другу. Отдаёт оркестратору не сырой дамп страниц, а собранную фактуру.
Писатель превращает фактуру в текст или материал нужного вида. Статья, пост, письмо, описание - его задача оформить содержание так, как требует формат. Факты он не проверяет, он работает с тем, что собрал исследователь.
Редактор-проверяющий ловит ошибки писателя. Факт-чек, качество, логика, тон. Это отдельный агент специально потому, что писатель плохо видит собственные огрехи - та же история, что и у людей. Свежий взгляд с чистым контекстом находит то, что автор пропустил.
Интегратор пишет результат туда, где он должен оказаться. Дёргает API, кладёт запись в базу, отправляет в нужный сервис. Это руки команды - агент, который соприкасается с внешними системами.
Оценщик - финальный контроль. Смотрит на готовый результат и сверяет с критериями: соответствует ли тому, что просил пользователь, нет ли явных провалов. Если что-то не так, задача уходит на доработку, а не пользователю. Последний фильтр перед выдачей.
Как они передают работу
Оркестратор - единая точка решений. Он получает задачу, раскладывает её на шаги и раздаёт специалистам. Дальше агенты передают работу по цепочке: исследователь собрал - писатель оформил - редактор проверил - интегратор записал - оценщик подтвердил. Эту передачу мы называем handoff.
Есть общее состояние задачи, к которому агенты обращаются: что уже сделано, что на каком шаге, какой результат ждём на выходе. При этом у каждого агента свой чистый контекст. Исследователь не видит черновик писателя, писателю не нужны логи интегратора. Каждый получает ровно то, что нужно для его шага, и ничего лишнего.
В этом вся суть. Не один агент с раздутой памятью, а несколько с узким фокусом и строгой передачей результата между ними.
Оркестратор при этом не запускает все шесть агентов всегда. Если задача простая, он может пройти короткой веткой: исследователь и писатель, без полного конвейера. Кого подключать, решает он сам - смотрит на задачу и собирает цепочку под неё. Так что шесть агентов - это не жёсткий поток, через который всё прогоняется одинаково, а набор ролей, из которых оркестратор каждый раз строит нужный маршрут.
Грабли, которые мы собрали
Звучит стройно, но первые сборки работали плохо. Вот пять проблем, на которые мы наступили, и что с каждой сделали.
Переполнение контекста. Общий контекст разбухал. Результаты одного агента подмешивались к другому, окно забивалось, агенты теряли фокус и начинали путать, что от них хотят. Решение - жёстко резать память по ролям. Каждый агент видит только своё: исследователь - запрос и источники, писатель - собранную фактуру, и так по цепочке. Никакого общего котла, в который сваливается всё подряд.
Кривые handoff. На передаче между агентами терялись детали. Писатель отдавал результат свободным текстом, редактор понимал его по-своему, и на выходе получалось не то, что задумывалось. Решение - строгий формат передачи. Агент отдаёт не «вот что я написал, разбирайтесь», а структурированный результат с полями, которые следующий агент точно поймёт. Свободный текст между агентами мы убрали.
Стоимость токенов. Шесть агентов жрут больше, чем один. Очевидно, но в первых прогонах счёт удивлял. Решение - не сажать дорогую модель на каждую роль. Простые задачи вроде форматирования или раздачи шагов отдаём дешёвым моделям, а тяжёлое рассуждение - дорогим. Плюс кэшируем то, что повторяется, чтобы не платить дважды за одно и то же.
Дубли работы. Агенты делали одно и то же или начинали ходить по кругу: исследователь собирал данные, которые писатель потом собирал заново, оценщик отправлял на доработку без ясной причины. Решение - чёткие границы ответственности. Каждый агент знает, где его зона начинается и где заканчивается, а оркестратор остаётся единственной точкой, которая решает, кто что делает следующим. Никаких самостоятельных инициатив в чужой зоне.
Сложно отлаживать. Когда что-то ломалось, было непонятно, кто из шести виноват. Результат плохой, а на каком шаге он испортился - загадка. Решение - логировать каждый шаг и каждое решение оркестратора. Мы держим трейс по всей цепочке: что получил агент на входе, что отдал на выходе, почему оркестратор отправил задачу именно сюда. Когда есть полный след, разбор сбоя занимает минуты, а не часы.
Что это даёт на практике
Эта архитектура - не теория, она работает в наших продуктах.
AI-секретарь ведёт деловодство голосом. Человек надиктовывает поручение, а команда агентов разбирает его, оформляет нужный документ, проверяет и кладёт в систему. Одним ботом такое не сделать - слишком много разных шагов от распознавания смысла до записи в базу.
AI Контент-завод - конвейер из агентов, который превращает новость в готовый набор материалов. Исследователь собирает контекст вокруг новости, писатель готовит статью, редактор вычитывает, дальше из статьи рождаются посты под разные площадки, а интегратор готовит баннеры. Новость на входе, готовый комплект на выходе. Без разделения на роли этот конвейер захлёбывался бы на первом же звене.
С чего начать
Если у вас есть процесс, который один бот не вытягивает - это кандидат на мультиагентную систему. Признак простой: задача состоит из разных по характеру шагов, и на каждом нужен свой фокус.
Начинать стоит не с шести агентов сразу, а с разбора процесса на роли. Где сбор данных, где творческая часть, где проверка, где запись в систему. Когда роли понятны, архитектура собирается сама.
Мы строим такие системы под конкретную задачу - от разбора процесса до рабочего конвейера агентов. Опишите, что у вас не тянет один бот, и мы посмотрим, как это разложить: puramind.ai#contacts.