Почему мультиагентные системы разваливаются на масштабе

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

Что ломается первым: контекст и токены

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

Пока агентов двое-трое и шагов немного — незаметно. Но если у вас N агентов обмениваются сообщениями по принципу «каждый видит всё», объём передаваемого контекста растёт примерно как квадрат числа участников и линейно по числу раундов. На практике это выглядит так: диалог из 15 обменов между пятью агентами легко упирается в лимит окна модели, а счёт за один пользовательский запрос становится непредсказуемым.

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

Компаундинг ошибок

Второй эффект коварнее. Допустим, каждый агент выполняет свой шаг с надёжностью 95 процентов — по меркам LLM это оптимистично. Если задача проходит через цепочку из десяти последовательных шагов, где каждый зависит от предыдущего, итоговая вероятность пройти всю цепочку без единой ошибки — это 0,95 в десятой степени, около 60 процентов. Двадцать шагов — уже около 36 процентов.

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

Три архитектурных паттерна и их пределы

Не всякая многоагентность масштабируется одинаково плохо. Многое решает топология связей.

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

Отладка, которой никто не занимается заранее

Отдельная боль — наблюдаемость. Когда монолитный промпт выдал ерунду, вы видите один вход и один выход. Когда ерунду выдала система из семи агентов с ветвлениями и повторными вызовами, вам нужно восстановить, кто что кому сказал, в каком порядке и почему координатор решил вызвать агента дважды.

Без сквозной трассировки это невозможно. Минимально вам нужно логировать по каждому шагу:

• идентификатор агента и роль;
• входной контекст (или ссылку на него) и итоговый промпт;
• полный ответ модели, включая вызовы инструментов;
• потраченные токены на вход и выход, задержку;
• trace ID^*, общий для всей цепочки одного запроса, чтобы связать шаги.

^* Trace ID — сквозной идентификатор, который присваивается запросу на входе в систему и протаскивается через все внутренние вызовы. По нему в системе трейсинга (например, OpenTelemetry-совместимой) собираются все звенья одной операции в единую цепочку.

Псевдокод обёртки для трассировки

Идея простая: любой вызов агента оборачивается в span с общим trace_id и записью стоимости. Ниже — минимальный набросок на Python, без привязки к конкретному фреймворку.

import time, uuid

def run_agent(agent, prompt, context, trace_id=None):
    trace_id = trace_id or str(uuid.uuid4())
    span_id = str(uuid.uuid4())
    started = time.time()

    full_prompt = agent.build_prompt(prompt, context)
    response = agent.model.complete(full_prompt)

    log_span({
        "trace_id": trace_id,
        "span_id": span_id,
        "agent": agent.name,
        "tokens_in": response.usage.prompt_tokens,
        "tokens_out": response.usage.completion_tokens,
        "latency_ms": int((time.time() - started) * 1000),
    })
    return response, trace_id

Такой лог сразу отвечает на два вопроса, которые убивают проекты в продакшене: куда уходят токены и где именно застряла цепочка. Без него вы отлаживаете вслепую.

Когда мультиагентность вообще оправдана

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

1. Оцените связность. Если подзадачи сильно зависят друг от друга последовательно — конвейер даст вам компаундинг ошибок, а не выигрыш.
2. Изолируйте контекст. Передавайте агентам минимум, а не всю историю. Сжимайте результаты перед передачей дальше.
3. Ставьте бюджеты. Лимит на число раундов, на токены, на глубину рекурсии вызовов — иначе mesh-топология зациклится.
4. Добавьте проверяющий узел с правом отклонить. Не косметический критик, а гейт, который может вернуть шаг на доработку или прервать цепочку.
5. Логируйте всё с первого дня. Ретроспективно восстановить трассировку почти невозможно.

Мультиагентные системы масштабируются не как микросервисы, где добавление узла линейно наращивает нагрузку. Здесь стоимость и хрупкость растут быстрее числа агентов, а выигрыш — медленнее. Практический вывод обычно скучный: начинайте с наименьшего числа агентов, которое решает задачу, и добавляйте новых только когда доказали, что без них не обойтись.