LLM-агенты — это распределённые системы

Сообщество ИИ строит мультиагентные системы — команды LLM, которые делят работу, общаются и сотрудничают, чтобы решать задачи, с которыми не справится ни одна модель в одиночку. Агент-«исследователь» собирает информацию, агент-«кодер» пишет реализацию, агент-«ревьюер» проверяет качество, а агент-«координатор» управляет процессом. Идея привлекательная: специализированные агенты работают вместе, как хорошо налаженная инженерная команда.

Звучит знакомо, и не зря. Исследователи распределённых систем изучают координацию независимых процессов уже 40 лет. Мультиагентные LLM-системы заново открывают с нуля проблемы, которые сообщество распределённых систем решило (или доказало, что они неразрешимы) десятилетия назад. Понимание этих параллелей помогает не изобретать велосипед и не строить системы, которые ломаются предсказуемо и по уже известным причинам.

Налог на координацию

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

Мультиагентные LLM-системы сталкиваются с этим сразу же. Агент-«исследователь» готовит отчёт. Агенту-«кодеру» нужно понять отчёт, чтобы написать код. Агенту-«ревьюеру» нужно понять и отчёт, и код, чтобы дать полезную обратную связь. Каждая передача требует сериализовать контекст в промпт, который принимающий агент должен разобрать и понять. Это ровно та проблема общего состояния из распределённых систем, и с каждым новым агентом она только усугубляется.

Single agent vs. multi-agent for a coding task:
Single agent:
1. Understand the problem         (1 LLM call)
2. Research relevant APIs          (2 LLM calls)
3. Write implementation            (1 LLM call)
4. Review and fix                  (1 LLM call)
Total: 5 LLM calls, full context throughout
Multi-agent (researcher + coder + reviewer):
1. Coordinator describes task      (1 LLM call)
2. Researcher reads and plans      (1 LLM call)
3. Researcher does research        (3 LLM calls)
4. Researcher summarizes findings  (1 LLM call)
5. Coder reads summary             (1 LLM call)  ← context lost here
6. Coder writes implementation     (1 LLM call)
7. Reviewer reads code + summary   (1 LLM call)  ← context lost here
8. Reviewer provides feedback      (1 LLM call)
9. Coordinator synthesizes         (1 LLM call)
Total: 11 LLM calls, context degraded at each handoff
More agents = more communication = more cost = worse context.

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

Проблема консенсуса

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

Для консенсуса LLM-агенты хуже традиционных распределённых процессов, потому что они недетерминированы. Задайте одному и тому же агенту один и тот же вопрос дважды, и ответы могут различаться. Два агента, проверяющие один и тот же код, могут разойтись во мнениях о его корректности. Агент-«координатор», которого попросили разрешить спор, может просто бросить монетку.

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

Знакомые режимы отказа

Мультиагентные системы ломаются так, что инженеры распределённых систем узнают сразу.

• Каскадные сбои. Агент A выдаёт плохой результат. Агент B, работая с результатом A, выдаёт ещё худший. Агент C, проверяя работу B, не замечает исходной ошибки, потому что унаследовал неверные допущения. Это аналог распространения ошибок в распределённых системах: мусор на входе, мусор на выходе, усиленный на каждом этапе.
• Взаимные блокировки. Агент A ждёт результат агента B, чтобы продолжить. Агент B ждёт обратную связь от агента A. Ни один не может двигаться дальше. На практике это выглядит как бесконечные циклы, в которых агенты перебрасывают работу туда-обратно и никак не сходятся.
• Split brain. Два агента, работающие над связанными задачами, формируют несовместимые представления о проблеме. Один считает, что API возвращает JSON, другой — что XML. Их результаты по отдельности корректны, но несовместимы друг с другом.
• Thundering herd. Координатор одновременно отправляет работу нескольким агентам. Все они обращаются к одному API, исчерпывают один и тот же лимит запросов или пытаются изменить один и тот же файл. Конкуренция за ресурсы, с которой один агент никогда бы не столкнулся.

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

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

Задачи, идеально поддающиеся распараллеливанию. Если нужно проанализировать 50 кодовых баз на предмет одного и того же паттерна, 50 агентов, работающих независимо, действительно будут в 50 раз быстрее. Координация не нужна: каждый агент работает со своим входом и выдаёт независимый результат. Это паттерн MapReduce, и для LLM-агентов он работает так же хорошо, как для распределённой обработки данных.

Разные точки зрения. Если попросить трёх агентов с разными системными промптами проверить один и тот же код, они могут выявить проблемы, которые пропустил бы один ревьюер. Это паттерн избыточности, как несколько ревьюеров в одном PR. Цена — втрое больше вычислений, зато охват шире.

Специализация с чистыми интерфейсами. Агент перевода, который принимает текст и возвращает перевод, имеет чистый интерфейс. Агент суммаризации, который принимает документ и возвращает саммари, — тоже. Их композиция (перевести, затем суммировать) хорошо работает, потому что интерфейс между ними простой. Аналог из распределённых систем: микросервисы с хорошо определёнными API работают лучше, чем микросервисы с болтливыми и сложными интерфейсами.

Уроки из распределённых систем

Если вы строите мультиагентные LLM-системы, десятилетия накопленного опыта распределённых систем применимы напрямую.

1. Предпочитайте меньше, но более способных агентов многим узким специалистам. Так же как хорошо спроектированный монолит превосходит плохо спроектированную микросервисную архитектуру, один сильный агент с хорошим промптингом обойдёт команду узких агентов в большинстве задач. Добавляйте агентов, только когда доказано, что один агент не справляется с нагрузкой.
2. Определяйте чёткие интерфейсы между агентами. Вход и выход каждого агента должны быть хорошо определены. Расплывчатые передачи («разберись, что нашёл исследователь, и реализуй») ведут к потере контекста и неверному толкованию. Структурированные контракты данных между агентами работают лучше свободного текста.
3. Делайте агентов идемпотентными. Если агент упал на полпути, его должно быть можно перезапустить с тем же входом и получить корректный результат. Для этого агенты не должны хранить скрытое состояние и не должны производить побочные эффекты, пока не убедятся, что их результат корректен.
4. Добавляйте наблюдаемость. Логируйте каждое сообщение между агентами, каждое решение и каждый сбой. Когда мультиагентная система выдаёт неверный результат, нужно проследить ошибку до агента, который принял неверное решение, и понять почему. Без наблюдаемости отладка превращается в угадывание.
5. Проектируйте с учётом частичных отказов. Любой агент может упасть, выдать мусор или не уложиться в таймаут. Система должна обрабатывать это достойно: повторять попытку, переходить на более простой подход или обращаться к человеку. Никогда не предполагайте, что все агенты непременно справятся.

Неудобная правда

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

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