Одноагентные архитектуры упираются в потолок. Ваш кодовый агент пишет — но не может проверить собственный вывод. Ваш агент по биллингу решает запросы — но не может поговорить с отделом доставки. Один и тот же взгляд, одни и те же слепые зоны.
Вы добавляете всё больше инструментов. Задержка раздувается. Контекстные окна переполняются. Потолок структурный, а не в промпте.
Решение: специализированные агенты — узкая экспертиза, параллельное выполнение, определённые протоколы.
Вы получите три паттерна оркестрации (Supervisor-Worker, Peer-to-Peer, Hierarchical) с кодом на Python, сопоставление ролей с моделями, сокращающее затраты на 50–70%, и топологию trace, превращающую плоский список span в карту системы.
Когда ломается одиночный агент?
Потолок сложности
Одиночные агенты предсказуемо отказывают в четырёх сценариях:
Экспертиза в нескольких доменах. Один агент должен одновременно быть экспертом по коду, юридическим рецензентом и финансовым аналитиком. Раздувание промпта — системный промпт растёт, чтобы вместить все три домена. Спутанность ролей — модель смешивает тона и приоритеты. Юридическая рецензия, написанная на развязном инженерном жаргоне. Финансовый анализ, пропускающий проверки соответствия, потому что доминирует персона «эксперта по коду».
Параллельное выполнение. Три независимые подзадачи, которые можно было бы выполнять параллельно — изучить цены конкурентов, проанализировать отзывы пользователей, суммировать характеристики продукта — обрабатываются одиночным агентом последовательно. Общая задержка — сумма всех трёх. С тремя специализированными агентами, работающими параллельно, задержка равна максимуму из трёх.
Самокритика. Одиночный агент генерирует вывод и оценивает собственный вывод. Тот же когнитивный процесс, который произвёл ответ, просят найти его недостатки. Он не может. Рецензирование равными — отдельный агент с другим промптом, другой моделью, другим взглядом — ловит ошибки, которые агент-генератор не видит.
Взрыв масштаба инструментов. Пятнадцать инструментов — нормально. Двадцать пять — точность выбора инструментов моделью заметно падает: она чаще выбирает не тот инструмент, пропускает нужный или вызывает инструменты в неверном порядке. Специализированные агенты с 5–8 инструментами у каждого превосходят одного универсала с 25.
Мультиагентность не всегда ответ
Мультиагентные системы добавляют реальный оверхед: задержку межъагентной коммуникации, токен-затраты на сообщения между агентами, риск несогласованности, когда два агента дают противоречивые ответы, и сложность отладки, когда нельзя понять, какой агент в цепочке из пяти произвёл неверный вывод. Если вашу задачу решает один хорошо спромпченный агент с 5–10 грамотно ограниченными инструментами, не вносите мультиагентную сложность. Начните с одиночного. Переходите к мульти, только когда одиночный очевидно не справляется — путаница инструментов, несогласованность ролей или последовательная задержка, которую устранило бы параллельное выполнение.
Наше руководство по архитектуре одиночного агента охватывает основы. Эта статья предполагает, что вы довели дизайн одиночного агента до предела и теперь упираетесь в потолок.
Три паттерна оркестрации
Паттерн 1: Supervisor-Worker
Один агент-супервизор оркестрирует. Он декомпозирует задачу, назначает подзадачи работникам, агрегирует результаты и прогоняет контроль качества перед выдачей вывода. Работники специализированы — у каждого свой системный промпт, набор инструментов и модель. Работники не общаются друг с другом. Они взаимодействуют только с супервизором.
class SupervisorAgent:
def __init__(self, model: str, workers: list[WorkerAgent]):
self.model = model
self.workers = {w.name: w for w in workers}
async def execute(self, task: str) -> dict:
plan = await self._decompose(task)
results = {}
for subtask in plan["subtasks"]:
worker = self.workers[subtask["assigned_to"]]
results[subtask["id"]] = await worker.execute(subtask)
synthesis = await self._synthesize(task, results)
quality = await self._quality_gate(synthesis)
if quality["passed"]:
return synthesis
else:
return await self._retry_or_escalate(task, quality["issues"])Лучше всего подходит для: задач, которые чисто раскладываются на независимые подзадачи, требуют централизованного контроля качества и имеют относительно фиксированную структуру команды. Компромисс: супервизор становится узким местом и единой точкой отказа. Не подходит, когда работникам нужно динамически договариваться друг с другом.
Паттерн 2: Peer-to-Peer
Иерархии нет. Все агенты — равные. Любой агент может начать общение с любым другим через общую шину сообщений. Агенты обнаруживают способности друг друга и динамически договариваются о передаче задач.
class PeerAgent:
def __init__(self, name: str, role: str, model: str, message_bus: MessageBus):
self.name = name
self.role = role
self.model = model
self.bus = message_bus
self.bus.subscribe(self.name, self._handle_message)
async def _handle_message(self, msg: Message):
if msg.type == "request":
result = await self._execute_task(msg.content)
await self.bus.send(Message(
to=msg.from_agent,
type="response",
content=result,
correlation_id=msg.correlation_id
))Лучше всего подходит для: динамических переговоров — агент-ревьюер кода обнаруживает баг и напрямую пишет кодовому агенту с исправлением, без супервизора в цикле. Без узких мест. Гибкие рабочие процессы. Компромисс: отладка сложнее — граф разговоров может стать запутанным, а бесконечные циклы сообщений или противоречивые выводы между равными требуют явных механизмов обнаружения циклов и разрешения конфликтов.
Паттерн 3: Hierarchical
Многоуровневая эскалация. Агенты первой линии обрабатывают типовые случаи. Сложные или необычные случаи эскалируются старшим агентам. Самые трудные случаи доходят до главного агента или человека. Качество и стоимость модели растут с уровнем — Tier 1 использует дешёвые модели, Tier 2 — средние, Tier 3 — фронтирные.
class TieredAgentSystem:
def __init__(self, tiers: list[AgentTier]):
self.tiers = sorted(tiers, key=lambda t: t.level)
async def execute(self, task: str) -> dict:
for tier in self.tiers:
result = await tier.agent.execute(task)
if result["confidence"] >= tier.confidence_threshold:
return result
return await self._escalate_to_human(task)Лучше всего подходит для: поддержки с естественными уровнями сложности, модерации контента с автофильтром — проверкой старшим — эскалацией человеку, и любых доменов, где большинство запросов простые, а меньшинство требует глубокой экспертизы. Компромисс: логика эскалации требует настройки по производственным данным — нужна обратная связь для калибровки порогов уверенности на каждом уровне.
Протоколы коммуникации агентов
Function Calling как межъагентный протокол
Самый простой подход: агент A вызывает инструмент send_message_to_agent_b. Инструмент определён в схеме function calling агента A. Совместим с существующей инфраструктурой. Ноль новых протоколов для изучения. Ограничение: синхронная блокировка. Каждое сообщение — полный цикл вызова инструмента. В многоходовых разговорах агентов задержка накапливается линейно. Когда сами определения инструментов должны охватывать несколько провайдеров с несогласованными схемами, наше руководство по function calling и использованию инструментов описывает слой нормализации, делающий межъагентные вызовы инструментов переносимыми между моделями.
MCP для коммуникации агентов
Каждый агент раскрывает свои возможности как MCP-сервер. Другие агенты, выступая MCP-клиентами, обнаруживают и вызывают эти возможности. Наше руководство по MCP охватывает основы протокола. В мультиагентных системах MCP обеспечивает стандартизированное обнаружение возможностей — агенту не нужно заранее знать, что умеют другие агенты. Он запрашивает экосистему MCP и обнаруживает возможности динамически.
Google A2A
Создан специально для коммуникации агент-к-агенту (спецификация A2A). Agent Cards для обнаружения возможностей. Структурированный жизненный цикл Task: submitted — working — completed или failed. Стриминговые обновления во время выполнения задачи. Обмен мультимодальным контентом. Кросс-фреймворковый — агенты, построенные на разных фреймворках, могут взаимодействовать, если говорят на A2A. Лучше всего подходит для гетерогенных мультиагентных систем, где разные команды используют разные стеки.
Собственная шина сообщений
Redis Pub/Sub или NATS со структурированной схемой сообщений. Максимальный контроль над маршрутизацией, персистентностью, ретраями и наблюдаемостью. Максимальные усилия по реализации. Схема: {agent_id, correlation_id, message_type, payload, timestamp}. Выбирайте это, когда ваши паттерны межъагентной коммуникации настолько уникальны, что не подходит ни один стандартный протокол, — или когда вам нужны гарантии (доставка ровно один раз, упорядоченная доставка), которых не дают высокоуровневые протоколы.
Сопоставление роли и модели
Крупнейшая ловушка затрат в мультиагентных системах: каждый агент получает фронтирную модель. Вашему агенту-классификатору, маршрутизирующему «биллинг» против «техподдержки», не нужен Claude Opus за $15/M входных токенов. Ему достаточно GPT-4o Mini за $0.15 — и точность классификации идентична.
| Роль агента | Рекомендуемая модель | Стоимость/1M входа | Обоснование |
|---|---|---|---|
| Классификатор/роутер | DeepSeek V3.2 / GPT-4o Mini | $0.14-0.15 | Простая классификация. Дешёвые модели работают так же, как фронтирные. |
| Базовый Q&A / FAQ | GPT-4o Mini / Claude Haiku | $0.15-0.25 | Retrieval-дополненные фактологические ответы. Возможности среднего уровня по минимальной цене. |
| Генерация контента | GPT-4o / Claude Sonnet 4 | $2.50-3.00 | Важны тон, структура и креативность. Надбавка за средний уровень оправдана. |
| Генерация кода | Claude Sonnet 4 / DeepSeek V4 Pro | $0.42-3.00 | Данные SWE-bench определяют этот выбор. Производительность кода DeepSeek в пересчёте на доллар исключительна. |
| Ревью кода / контроль качества | Claude Opus 4 / GPT-5.5 | $10-15.00 | Поиск багов требует фронтирного мышления. Один пропущенный баг стоит дороже надбавки за модель. |
| Финальный синтез | Claude Opus 4 | $15.00 | Вывод, который видит пользователь. Надбавка оправдана за тон, точность и следование инструкциям. |
Учёт затрат на агента — gen_ai.cost.total на каждом span LLM с agent_id как атрибутом span — даёт отчёт о затратах на агента. Вы быстро заметите агента, потребляющего 40% вашего мультиагентного бюджета. Понизьте его с Opus до Sonnet и проверьте, меняется ли качество вывода. Часто — нет. Помимо выбора модели на агента, наше руководство по 12 способам оптимизации затрат на LLM API охватывает кэширование промптов, пакетную обработку и паттерны семантического кэширования, которые дают накопительный эффект по всему вашему флоту агентов.
Отладка и мониторинг мультиагентных систем
Проблема топологии trace
Один пользовательский запрос может запустить: агент A (классификация) — агент B (исследование) + агент C (код) параллельно — агент A (синтез) — шесть вызовов LLM, десять вызовов инструментов, три межъагентных сообщения. Плоский список из 19 спанов не поддаётся отладке. Вы не видите граф выполнения.
Решение: kind span OpenInference AGENT с иерархическим моделированием. Корневой span: пользовательская сессия. Уровень 1: решение оркестратора. Уровень 2: выполнение по агентам. Уровень 3: вызовы инструментов по агентам. Ваш просмотрщик trace рендерит граф выполнения, а не плоский список. Когда вызов инструмента агента C падает, вы видите это в контексте — какой агент, какой шаг, что происходило до и после.
Полную настройку OpenTelemetry смотрите в нашем руководстве по наблюдаемости.
Типичные режимы отказа мультиагентных систем
Бесконечный цикл сообщений. Агент A — агент B — агент A — агент B. Предотвращение: лимит глубины разговора и обнаружение циклов на уровне шины сообщений. На уровне API ограничения запросов на агента добавляют бюджетный потолок — когда агент превышает свою квоту запросов, цикл останавливается независимо от того, что разрешает логика шины сообщений.
Противоречивые выводы. Агент A говорит — вернуть деньги. Агент B говорит — не возвращать. Механизма разрешения нет. Предотвращение: паттерн супервизора с явным разрешением конфликтов или механизм голосования между агентами.
Утечка прав на инструменты. Кодовый агент случайно получает доступ к инструменту возврата средств агента по биллингу из-за неверно настроенного реестра инструментов. Предотвращение: списки разрешённых инструментов на агента. Идентичность агента в каждом журнале аудита инструментов.
Тихий отказ агента. Один агент выбрасывает необработанную ошибку. Оркестратор этого не замечает. Пользователь получает частичный ответ без критичной информации. Предотвращение: структурированная отчётность об ошибках в межъагентном протоколе. Проверки состояния на уровне оркестратора перед синтезом.
FAQ
Когда НЕ стоит использовать мультиагентную архитектуру?
Если вашу задачу решает один хорошо спромпченный агент с десятью или менее хорошо определёнными инструментами, не вносите мультиагентную сложность. Оверхед на коммуникацию, сложность отладки и стоимость межъагентных сообщений перевешивают выгоды. Сначала одиночный агент. Мульти — только когда одиночный очевидно не справляется: путаница инструментов, несогласованность ролей или последовательная задержка, которую устранило бы параллельное выполнение.
Со скольких агентов начинать систему?
Два-три, покрывающих явно разные роли. Не начинайте с шести. Сложность координации масштабируется нелинейно — система из 6 агентов не в 3 раза сложнее системы из 2. Это ближе к 9×. Добавляйте агентов, только когда существующий агент стабильно отказывает на конкретной подзадаче, требующей отдельной экспертизы.
С какого паттерна оркестрации начать?
Supervisor-Worker. Централизованное управление, ясное управление состоянием, самая простая отладка. Переходите на Peer-to-Peer, только когда работникам действительно нужно динамически договариваться друг с другом. Переходите на Hierarchical, только когда у вас есть чёткие уровни сложности с измеримыми порогами уверенности. Начинайте просто. Добавляйте сложность, только когда данные доказывают, что она нужна.
Как справиться с агентом, который постоянно ошибается?
Не начинайте с правки его промпта. Сначала: анализ trace. Найдите паттерн отказа — какие входные данные вызывают ошибку? Какой шаг выполнения даёт сбой? Во-вторых: сузьте область агента. Возможно, он обрабатывает слишком много типов задач. В-третьих: добавьте агента-контроль качества — рецензента, проверяющего выводы до того, как они попадут к пользователю. В-четвёртых: если агенту не хватает знаний домена, добавьте RAG — не fine-tuning и не больше промптов.
Какова фактическая эксплуатационная стоимость системы из 5 агентов на 3 уровнях моделей?
Эксплуатационная стоимость — не в токенах, а во фрагментации. Каждый уровень агентов потенциально попадает на другого провайдера. Это отдельные API-ключи, отдельное отслеживание лимитов, отдельные дашборды затрат. Когда ваш агент-классификатор (DeepSeek Flash за $0.14/M) и ревьюер кода (Claude Opus за $15/M) работают через разных провайдеров, вы тратите больше времени на управление учётными данными, чем на оптимизацию поведения агентов. Решение архитектурное: один endpoint для всех агентов независимо от модели. Атрибуция затрат на агента становится атрибутом span, а не упражнением с таблицами между провайдерами. Для наблюдаемости и настройки задержки, делающих этот подход с одним endpoint готовым к продакшну, руководство TokSpan по оптимизации продакшна охватывает пулы соединений, очередь запросов и конфигурацию таймаутов на модель по всему вашему флоту агентов.
Мультиагентная архитектура — это не более высокая сложность, а реакция на конкретные режимы отказа. Когда ваш одиночный агент путает инструменты между доменами, когда последовательное выполнение делает задержку неприемлемой, когда самопроверка не может поймать собственные ошибки — вот сигналы. Не раньше.
Начните с Supervisor-Worker. Безжалостно сопоставляйте роли с моделями — вашему классификатору не нужен Opus. Инструментируйте span каждого агента с agent_id. Наблюдайте за отчётом затрат на агента неделю. Вы найдёте как минимум одного агента с избыточной моделью, которого можно понизить на уровень без потери качества.
Паттерн оркестрации значит меньше, чем дисциплина знания, когда не нужно добавлять ещё одного агента.
Отчёт о затратах вашего флота агентов не должен требовать склейки CSV-экспортов из четырёх разных дашбордов провайдеров. Разверните агентов на TokSpan — атрибуция затрат на агента, централизованные лимиты запросов и все модели, нужные вашим агентам, за одним endpoint.