В предыдущей главе мы разобрали, как подключить к одному агенту внешние инструменты через MCP. К этому моменту у вас работает один автономный агент с «головой, инструментами, памятью и циклом». Однако, когда задача разрастается, конструкция, где всё запихано в одного агента, где-то даёт трещину. В этой главе мы на уровне концепций, не завязанных на фреймворк, разберём «проектирование мультиагентных систем», где роли разделены и задачу решают несколько агентов, и подход к их кооперации (A2A: Agent-to-Agent).
Цель — уметь судить, «когда и как разделять, чтобы стало сильнее»
Когда одного агента становится мало
Один агент прост, обозрим и его действия легко отследить — именно поэтому сначала правильно делать одного. Проблема возникает, когда в него начинают одну за другой добавлять роли. Если в один промпт напихать обязанности — «изучи, напиши, отревьюь, переведи, да ещё и опубликуй…» — с некоторого момента точность резко начинает падать.
Причин в основном три. ① Инструкция становится длинной и расплывчатой (чем больше всего в неё пишут, тем сильнее модель путается, что приоритетнее). ② Раздувается контекст (набивается даже не относящаяся к делу информация, и ключевая инструкция размывается). ③ Слишком много инструментов (чем больше вариантов, тем легче выбрать неверный). Состояние «запихано слишком много в одного» — это словно «рабочее место, где один человек совмещает кучу ролей и потому в замешательстве».
💡 Смена подхода. Вместо того чтобы бесконечно умнеть одного, переключитесь на идею «собрать несколько маленьких агентов, каждый сосредоточенный на одной роли, и заставить их сотрудничать». Это отправная точка проектирования мультиагентных систем. По той же логике, что разделение труда в человеческой организации, чем уже и яснее обязанности каждого, тем стабильнее целое.
Но — разделишь не значит обязательно станет лучше. Разделению труда всегда сопутствуют затраты на согласование. Поэтому главная тема этой главы — не только «как разделять», но и «стоит ли вообще разделять». Сначала посмотрим на три характерные формы, а затем перейдём к критериям выбора.
Три базовых паттерна
Конфигураций мультиагентных систем можно нарисовать бесчисленно, но повторяющийся на практике каркас сводится к трём. Скомбинировав эти три, можно описать почти любую конфигурацию. Сначала по одному уловим роль, сильные и слабые стороны каждой.
Родитель (оркестратор) составляет общий план, раздаёт задачи детям (исполнителям), а результаты собирает и сводит воедино. Дети не знают друг о друге и смотрят только на родителя. Сила — в централизованном и удобном контроле.
Когда подходит: задачу можно разбить и хочется запускать параллельно.
Выстраиваем этапы и по порядку передаём выход предыдущего агента на вход следующему. Например: «исследование → написание → вычитка». Каждая ступень отвечает лишь за один этап, поэтому обязанности ясны и проверка проще.
Когда подходит: порядок линеен и этапы определены.
Как «отвечающий за исследование», «за код», «за ревью» — готовим экспертных агентов, каждый со своей сильной областью, и вызываем их по ситуации. Можно сузить инструкции и инструменты каждого, поэтому растёт специализация.
Когда подходит: требуемые способности сильно различаются по областям.
Эти три не взаимоисключающи. Реальная система нередко получается вложенной: например, «оркестратор связывает исполнителей экспертного типа, а один из них внутри устроен как конвейер». Удобнее наращивать так: сначала определить один самый внешний каркас, а внутри только там, где нужно, применять другой паттерн.
📊 Сомневаетесь — начните с ①. Самый универсальный из трёх — оркестратор + исполнители. Родитель централизованно держит планирование и сведение, поэтому контролировать удобно, и это базовая форма многих мультиагентных конфигураций. Для обзора паттернов в целом см. также что такое мультиагентность, а для взгляда как на систему — что такое мультиагентная система.
Когда разделять, а когда — нет
Узнав паттерны, невольно хочется разделять всё подряд. Но разделению труда всегда сопутствуют «затраты на согласование» — хлопоты передавать информацию между агентами, состыковывать её и ждать друг друга. Мультиагентность — верный выбор только тогда, когда выигрыш от разделения превосходит эти затраты на согласование. Сначала положим обе стороны рядом.
- Можно параллелить: независимые подзадачи запускаются одновременно и сокращают время
- Нужна специализация: сузив инструкции и инструменты по областям, повышаем точность
- Широкий поиск: хочется распределить несколько ракурсов или кандидатов
- Хочется разделить контекст: разрезав контекст по ролям, предотвращаем смешение
- По сути просто: то, что тянет один агент, без нужды усложняется
- Растут затраты: чем больше агентов, тем больше накапливается вызовов LLM и токенов
- Тяжёлое согласование: хлопоты передач и ожиданий съедают выигрыш от разделения
- Сильная последовательная зависимость: всё сильно зависит от предыдущего результата, простора для параллели почти нет
⚠️ Сначала спросите «достаточно ли одного». Мультиагентность мощна, но это не то, что выбирают первым ходом. Железное правило — наращивать по шагам: один агент → доработать промпт → добавить инструменты → и только если всё равно мало, разделять. Сложность добавляйте, убедившись, «действительно ли нынешний один агент на пределе». Разделить можно и потом.
Как практический ориентир, представьте: «если бы вы описывали эту роль коллеге-человеку, уместилась бы она естественно в одну должностную инструкцию». Если можно описать одним названием должности — пока хватает одного агента. Момент, когда хочется сделать их разными людьми — «это человек по исследованию, это — по написанию», — и есть время задуматься о разделении. Полную картину суждений см. также в как создать мультиагентную систему.
Связь между агентами (A2A)
Решив разделять, следующая проектная задача — «как агенты обмениваются информацией друг с другом». В человеческой команде это соответствует определению формата передачи дел и правил отчётности. Если здесь размыто, целое не состыкуется, как бы ни были хороши отдельные участники. В кооперации нужно усвоить в основном два пункта.
Определить, что и в какой форме передавать. Если «инструкцию к задаче, нужный вход и ожидаемый формат выхода» сделать явным соглашением, принимающий не запутается. Структурированная передача стабильнее, чем сброс произвольного текста.
Этап, где несколько выходов сводятся в один. Заранее определите, кто несёт финальную ответственность за сведение. В проект также включите приоритеты при противоречивых результатах и способ сведения (обобщение, сопоставление, голосование большинством).
Стремление стандартизировать этот подход — «агенты разделяют роли и кооперируются» — и есть A2A (Agent-to-Agent). Если MCP из предыдущей главы был соглашением, соединяющим «агент ↔ инструменты / данные», то A2A — соглашение, соединяющее «агент ↔ агент»: воспринимайте его как общий уклад, чтобы узнать, что умеет агент-партнёр, поручить ему задачу и получить результат.
💡 MCP и A2A запоминайте в противопоставлении. Грубо говоря, MCP = подключить агенту «руки», A2A = «соединить» агентов друг с другом. Первое — подключение инструментов и данных, второе — уклад кооперации. Для начала достаточно усвоить как концепцию, а конкретных протоколов мы коснёмся и в следующих главах. Подробнее — что такое протокол A2A. Если сопоставить с MCP и подключением инструментов из предыдущей главы, различие станет отчётливее.
Важно не запомнить название протокола, а проектная установка: «для связи нужны явные соглашения». Кто какую задачу держит, с какого входа начинается, что возвращает и кому уходит при сбое — заранее определить эти соглашения и есть фундамент системы, которая не разваливается с ростом масштаба.
Управление контекстом и затратами
Крупнейший практический риск мультиагентности — раздувание контекста и затрат. Чем больше агентов и чем больше они передают информацию друг другу, тем толще контекст у каждого и тем сильнее накапливаются число вызовов LLM и объём токенов. Оставишь без присмотра — система склонна стать медленной, дорогой и нестабильной. Взять поводья нужно ещё на стадии проектирования.
Детям передавать только необходимое для их задачи. Не гнать всю историю как есть. Не относящийся к делу контекст снижает и точность.
Длинные результаты сначала сводить к сути и потом передавать дальше. Идея — вручать «вывод и обоснование», а не сырой лог.
Задать предел на число одновременно работающих детей. Наращивать без ограничений — путь к краху из-за затрат и rate limit.
Для родителя с тяжёлыми рассуждениями и детей с простой работой использовать модели разного размера. Не всех ставить на топовую модель.
Особенно «сужать передаваемую информацию» — проектное решение с большим эффектом. В типе «оркестратор + исполнители» родитель держит общую картину, а детям передаёт только вырезанную задачу и минимально необходимый вход. Чем меньше контекст, который держат дети, тем выше точность и ниже затраты. Воспринимайте это как контекстную инженерию, о которой шла речь в предыдущих главах, расширенную на несколько агентов.
⚠️ Затраты работают как «число агентов × число шагов». Добавите одного агента — соответствующие вызовы накопятся на число оборотов цикла. Учтите: чем больше агентов, тем во много раз по всей системе раздувается потеря на каждого из них. Заранее задайте и предел на число параллелей, и предел шагов каждого агента (момент остановки). Разговор о том, чтобы измерять «сколько всего используется», ведёт к наблюдаемости из следующей главы.
Подводные камни и как их предотвратить проектированием
У мультиагентности есть свои сбои, которых не было у одиночного агента. Все они предотвращаются в основном заранее, проектированием, а не на удачу во время выполнения. Усвоим три характерных и меры против них.
Несколько агентов дважды делают одну и ту же работу, либо «чья это обязанность» размыто, и не делает никто.
Как предотвратить: разрезать обязанности каждого без пересечений и без пробелов так, чтобы границу можно было выразить одной фразой.
A — к B, B — к A… перекладывают работу друг на друга, всё никак не заканчивается или повторяется один и тот же обмен.
Как предотвратить: обязательно задать условие завершения и предел числа переходов и шагов. Если финальное решение держит центр (родитель), выхода из-под контроля меньше.
Ошибка или неверный выход одного агента как есть утекает к следующему и останавливает целое или строит неверный результат.
Как предотвратить: перед передачей проверять выход и заранее определить откат при сбое (повтор, замена, эскалация к человеку).
Общий урок этих трёх — определить «границы, условия завершения и проверку» до того, как писать код. Кто за что отвечает (границы), когда останавливается (условия завершения) и что проверяется перед передачей (проверка). Вплетя эти три пункта в проект, вы предотвратите большую часть проблем, свойственных именно мультиагентности.
📊 «Не видно — не починишь». Эти сбои замечаешь лишь тогда, когда состояние таково, что можно задним числом проследить, какой агент что сделал. Когда завязано несколько агентов, «где что произошло» видно ещё хуже, чем у одиночного, — именно поэтому оценка и наблюдаемость из следующей главы в мультиагентности становятся ещё важнее.
- Запихаешь слишком много в одного — точность падает. Решать нужно кооперацией маленьких агентов с узко разделёнными ролями.
- Базовых паттернов три — оркестратор + исполнители, конвейер, разделение ролей. Их можно вкладывать друг в друга.
- Разделять — когда нужны параллель, специализация, широкий поиск. Если просто — оставить одного. Сначала спросите «достаточно ли одного».
- Связь ведут явным соглашением (A2A = уклад соединения агентов друг с другом). Контекст и затраты — сужать и держать под управлением.
- Свойственные ловушки (дублирование, перекидывание, цепная ошибка) предотвращаются, если границы, условия завершения и проверку определить проектированием заранее.
Когда несколько агентов приходят в движение, следующее, что понадобится, — «измерять, действительно ли всё работает как надо, и делать работу видимой». В следующей главе 5 «Оценка и наблюдаемость» перейдём к тому, как измерять качество агента и приводить внутренние действия в состояние, которое можно отследить.