When one agent is not enough

Одиночный агент ломается предсказуемо, и первый навык оркестратора — распознавать эти сигналы до того, как система развалится в продакшене. Симптом первый: перегрузка инструментами. Когда агенту выдано 30–40 tools, точность выбора нужного инструмента заметно падает — модель путает похожие по описанию функции и тратит ходы на неверные вызовы. Симптом второй: конфликт ролей в одном системном промпте. «Ты одновременно строгий ревьюер и креативный автор» — это две несовместимые политики поведения; агент начинает смешивать критерии и делает обе работы посредственно. Симптом третий: контекст не вмещает задачу — исследование на сотни источников или рефакторинг на десятки файлов физически не укладываются в одно окно.

Мультиагентность решает эти проблемы разделением: каждому агенту — своя роль, свой узкий набор инструментов и своё чистое контекстное окно. Anthropic в отчёте о своей research-системе приводит конкретные цифры: мультиагентная конфигурация с ведущим агентом на Opus 4 и суб-агентами на Sonnet 4 обошла одиночного агента на Opus 4 на 90,2% на внутреннем исследовательском эвале. Ключевой фактор — параллелизм: суб-агенты изучают источники одновременно, каждый в своём окне.

Но у выигрыша есть ценник: по тем же данным агент тратит примерно в 4 раза больше токенов, чем чат, а мультиагентная система — примерно в 15 раз больше. Мультиагентность — это покупка качества и скорости за токены, и сделка окупается только на задачах, которые реально параллелятся.

Топология supervisor — самая распространённая отправная точка. Один агент-координатор принимает задачу, решает, какому воркеру передать следующий шаг, и собирает результаты. Воркеры друг с другом не разговаривают: после каждого шага управление возвращается супервизору.

from langgraph.graph import StateGraph, START, MessagesState

def supervisor(state: MessagesState):
    # LLM решает: "researcher", "coder" или "FINISH"
    ...

builder = StateGraph(MessagesState)
builder.add_node("supervisor", supervisor)
builder.add_node("researcher", researcher)
builder.add_node("coder", coder)
builder.add_edge(START, "supervisor")
builder.add_edge("researcher", "supervisor")
builder.add_edge("coder", "supervisor")

Сильные стороны: единая точка контроля и политики, понятная трассировка («кто и почему получил задачу»), простая замена воркеров. Слабые стороны фундаментальны. Во-первых, супервизор — бутылочное горлышко: каждый результат воркера проходит через его контекст, и на длинной задаче окно координатора раздувается быстрее всех. Во-вторых, возникает эффект испорченного телефона: супервизор пересказывает задачу воркеру своими словами, и если пересказ потерял ограничение из исходной постановки, воркер об этом не узнает.

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

Swarm — децентрализованная топология: нет координатора, агенты передают управление друг другу напрямую через hand-off-инструменты. Агент поддержки понимает, что вопрос про возврат денег, и вызывает tool «передать биллинг-агенту»; вместе с управлением уезжает и диалог. Паттерн популяризовала экспериментальная библиотека OpenAI Swarm, а в экосистеме LangGraph он реализован в пакете langgraph-swarm. Сильная сторона — минимальная задержка на маршрутизации: нет лишнего хопа через супервизора, активный агент меняется по мере разговора. Слабая — глобальное поведение системы никем не контролируется: цепочку передач сложно предсказать и ещё сложнее отладить, поэтому swarm лучше всего работает в диалоговых сценариях с небольшим числом специализаций.

Pipeline — конвейер с фиксированным порядком: выход одного агента становится входом следующего, как «спека → код → ревью». Это самая дешёвая и предсказуемая топология: маршрутизации нет вообще, каждый этап можно тестировать отдельно, а стабильный порядок хорошо дружит с кэшированием промптов. Ограничение симметричное: конвейер не умеет адаптироваться. Если ревьюер нашёл проблему, а обратного ребра нет, конвейер просто выдаст плохой результат. Поэтому в реальных системах pipeline почти всегда дополняют циклом обратной связи с лимитом итераций — мы построим ровно такой в капстоуне.

Выбор топологии сводится к вопросу о том, где живёт решение «что дальше»: у координатора (supervisor), у текущего агента (swarm) или зафиксировано заранее (pipeline).

Команда Cognition (авторы Devin) в эссе «Don’t Build Multi-Agents» приводит главный аргумент против моды на команды агентов: параллельные агенты не видят решений друг друга, и их результаты строятся на конфликтующих предположениях. Классический пример — два суб-агента делают две части задачи, каждый принимает свои неявные дизайн-решения, а собранный результат несовместим внутри себя. Каждая передача управления — это точка потери контекста, и чем больше передач, тем хрупче система.

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

Антипаттерны, которые стоит называть вслух на ревью архитектуры: «агент на каждую должность в оргсхеме» (пять агентов там, где хватит одного промпта с этапами), «агент ради названия» (маркетинговая мультиагентность без параллелизма) и «мультиагентность вместо декомпозиции» (задачу не разложили на шаги, а размазали по агентам). Помните про ценник ×15 по токенам: каждая лишняя роль — это не бесплатная абстракция, а множитель стоимости и новая поверхность отказа. Хорошая мультиагентная система начинается с честного ответа на вопрос, что именно в задаче нельзя сделать одним агентом.