Почему мультиагентная разработка — это распределённый консенсус, и AGI вас от этого не спасёт
FLP, теорема Лэмпорта о византийских генералах и CAP объясняют, почему мультиагентные пайплайны падают одинаково — и почему AGI это не вылечит. Что с этим делать прямо сейчас.
Если вы запускаете несколько ИИ-агентов параллельно на одной кодовой базе и время от времени получаете кашу — конфликты в git, циклы «один агент починил, другой откатил», тесты, которые ловят ровно те ошибки, которые вы не ожидали — у этого есть имя и сорокалетняя теория. Это распределённый консенсус, и никакой будущий AGI его не отменит. На прошлой неделе исследователь верификации Киран Гопинатан опубликовал заметку «Multi-agentic Software Development is a Distributed Systems Problem (AGI can't save you from it)», в которой формально показал: проблема координации между агентами — это та же FLP, тот же Лэмпорт, та же CAP. Разбираем, почему это меняет то, как нужно проектировать мультиагентные пайплайны.
Ключевые выводы
- Координация между ИИ-агентами — это распределённый консенсус с асинхронной доставкой сообщений и отказами процессов. Это формально та же задача, что в распределённых БД и протоколах согласования.
- Теорема FLP (Fischer-Lynch-Paterson, 1985): в асинхронной системе с возможностью хотя бы одного crash-отказа нельзя гарантировать одновременно safety, liveness и fault-tolerance. Это работает для агентов так же, как для серверов Paxos.
- Теорема Лэмпорта (1982): чтобы прийти к консенсусу при f «византийских» агентах (тех, кто неправильно понял промпт и потащил систему не туда), нужно как минимум 3f + 1 агентов всего. Жёсткий предел, не зависящий от качества модели.
- Тесты, статический анализ и формальная верификация работают как «детекторы ошибок» — они конвертируют неправильную интерпретацию в честный crash, после чего FLP всё ещё запрещает идеал, но даёт более слабые и достижимые гарантии.
- Подход «давайте подождём пару поколений моделей, и проблема рассосётся» теоретически не работает: умные агенты могут уменьшить константы в алгоритмах, но не отменить границы, заданные импоссибилити-результатами.
Возражение «просто подождём пару поколений»
Тезис, который Гопинатан слышит чаще всего — даже от коллег по верификации:
Лучшее решение проблем агентной координации — просто подождать пару месяцев.
Логика обычно собирается так:
- Текущие мультиагентные LLM-системы не умеют автономно строить большой софт — согласен.
- Это сводится к проблеме координации — согласен.
- Следующее поколение моделей будет умнее — согласен.
- Следовательно, у следующего поколения не будет проблем координации — стоп, что?
Отсюда вывод, что строить языки и инструменты под мультиагентность — сизифов труд: новые модели всё равно сделают эти инструменты ненужными. Именно с этим Гопинатан и спорит. Распределённые системы — это область с рекомендованными ответами на каждый из этих вопросов, и большинство из них доказаны как теоремы 30–40 лет назад. Они не зависят от ума участников.
Формальная модель агентной разработки
Чтобы говорить о консенсусе строго, нужно сначала формализовать сам процесс. Промпт P — например, «сделай мне приложение для трекинга рецептов» — определяет множество Φ(P) всех программ, согласующихся с этим промптом. Натуральный язык по своей природе недоспецифицирован: любое описание, не являющееся кодом, оставляет простор для дизайн-решений. Соответственно, любая программа из Φ(P) — валидное прочтение промпта.
Когда мы запускаем одного агента, мы просим его выбрать один элемент из Φ(P). Когда запускаем n агентов, мы просим каждого построить компонент φ_i такой, что все они уточняют одно и то же прочтение φ ∈ Φ(P):
Это и есть распределённый консенсус. Агенты должны договориться, какое именно прочтение они уточняют, без явного протокола согласования. Если агент сети выбирает callback-стиль API, агент интеграции должен это учесть — а узнать он об этом может только постфактум, по уже сделанным изменениям. Любое ваше решение «давайте делать так» создаёт ограничение для других агентов.
Можно возразить: «давайте сделаем одного супервайзора, который мерджит PR-ы». Не помогает: вы не решили проблему конкуренции, вы захардкодили конкретный (и не лучший) её способ. Когда супервайзер мерджит одно решение, что делать с работой, требующей rebase? А если конфликты? Часть работы теряется.
FLP: теорема невозможности консенсуса
В любой распределённой системе с произвольными задержками сообщений и возможностью хотя бы одного crash-отказа узла никакой детерминированный протокол не может гарантировать достижение консенсуса всеми работоспособными узлами за конечное время.
Семинальная работа, известная как FLP, утверждает простую вещь: в асинхронной системе с возможностью отказа нельзя одновременно иметь safety, liveness и fault-tolerance. Возьмите любые два — третий потеряете.
Применимо ли это к агентам? Гопинатан показывает, что да, оба условия выполнены:
- Асинхронные сообщения. Доставка сообщений к LLM-агентам асинхронная: агент сам решает, когда «прочитает» входящее (когда закончит размышление, когда отработает вызов tool-а). Бесконечной задержки исключить нельзя.
- Crash-отказы. Агенты крашатся регулярно: процесс умирает, bash-цикл уходит в бесконечность, агент случайно
pkill-ает сам себя или тот, с кем должен был общаться. Отказы происходят необъявленно.
Следствие: в любом мультиагентном пайплайне, как бы умны ни были участники, нельзя одновременно гарантировать:
- Safety — итоговый софт корректен и удовлетворяет промпту.
- Liveness — агенты всегда приходят к согласию о финальном решении.
Liveness — это не «процессы что-то делают», а именно «доходят до общего решения». Знакомый паттерн «один агент выбрал дизайн, другой откатил, выбрал другой, первый снова откатил» — это не баг конкретной модели, это поведение системы без живого failure detector-а или явного протокола.
Любопытная техническая деталь, которую упоминает Гопинатан: Чандра и Тоуг в работе «Unreliable Failure Detectors for Reliable Distributed Systems» доказали, что консенсус в FLP-условиях возможен при наличии (даже ненадёжного) детектора отказов. Если процесс «жив» эквивалентно «прогрессу», тогда обычная команда ps | grep claude уже даёт что-то похожее на failure detector. Один из практических выводов: давайте агентам инструмент проверять, что соседние агенты живы, а не висят.
Византийские генералы и неправильные интерпретации
В синхронной message-passing системе с f византийскими агентами, которые могут отклоняться от протокола произвольным образом, согласие между честными процессами достижимо только если общее число процессов n > 3f + 1.
Византийский узел — это худший случай отказа: процесс не просто умирает, он начинает делать произвольные вещи. Подделывает сообщения, шлёт не туда, повторяет старое, активно мешает остальным.
Зачем это в контексте агентов — никто же не пытается специально сломать систему? Гопинатан предлагает интерпретацию: византийский агент = агент, который неправильно понял промпт. Для остальных участников протокола результат тот же — он генерирует решения, не совместимые с тем прочтением, которое разделяют остальные.
Лэмпорт доказал: чтобы консенсус был возможен при f византийских участниках, всего участников должно быть больше 3f + 1. Иначе говоря, если из n агентов больше (n − 1) / 3 неправильно понимают промпт — консенсус невозможен в принципе. Никакие умные модели этого порога не сдвинут: он не про качество мышления, а про арифметику голосов.
Голосование между LLM-агентами как алгоритм консенсуса работает плохо — пространство возможных реализаций софта слишком большое, чтобы совпали два независимых выбора. Но из теоремы есть практический урок: надёжные внешние валидаторы конвертируют византийские отказы в crash-отказы. Тесты, статический анализ, формальная верификация — каждый из них даёт агенту шанс заметить расхождение и либо упасть, либо подправить интерпретацию. После такой конверсии остаётся (более слабый) FLP-режим, в котором уже работают известные подходы.
Что это значит на практике
Гопинатан явно подчёркивает: не то чтобы мультиагентная разработка была невозможна. Люди уже шипают код, написанный агентами, и будут шипать дальше. Дело в другом: они неявно решают проблемы координации ad-hoc-методами, без чётких гарантий и понимания, что и где может сломаться. Сорок лет распределённых систем дают точные формализмы для каждого из этих механизмов и чёткие правила, какой подход когда применим.
Из теории следует несколько практических правил:
- Не ждите, что AGI решит координацию. Импоссибилити-результаты не зависят от интеллекта участников. Умные агенты могут сократить константы в алгоритмах, но не отменить границы.
- Заводите failure detectors. Дайте агентам способ проверять, живы ли соседи и есть ли прогресс. Это легально расширяет FLP до consensus-возможной среды.
- Внешние валидаторы важнее, чем кажется. Тесты и линтеры — не «нормальная гигиена», а способ конвертировать византийские отказы в crash-отказы, чтобы вообще иметь шанс на согласие. Без них больше чем
(n − 1) / 3агентов с неправильным прочтением промпта обрушают весь пайплайн. - Партициализируйте задачу как в распределённых БД. Чем меньше пересечений в файлах между задачами агентов — тем меньше нужен консенсус. Worktree-pattern (см. недавнюю статью Шиппера про tmux + параллельных агентов) — это, по сути, partition tolerance из CAP.
- Тайм-ауты и rebound-механизмы из Partial Synchrony (Dwork-Lynch-Stockmeyer, 1988) — стандартный escape hatch вокруг FLP в проде. Если агент думает 30 минут — это не фича, это потенциальный hang, который надо лечить рестартом с новым контекстом.
Дальше: Common Knowledge, Partial Synchrony, CAP
Если хочется копнуть глубже, Гопинатан перечисляет три ключевых результата, которые тоже имеют прямое отношение к мультиагентности:
- Common Knowledge (Halpern & Moses, 1990) — формальная модель того, как знание распространяется по распределённой системе и почему «общее знание» в строгом смысле в ней недостижимо. Объясняет, почему «у меня в CLAUDE.md написано» не равно «все агенты это учли».
- Partial Synchrony (Dwork, Lynch & Stockmeyer, 1988) — стандартный обход FLP в реальных распределённых системах. Накладываются верхние границы на задержки сообщений, и консенсус становится решаемым ценой увеличенной message complexity. На практике — таймауты и реквесты повторов.
- CAP-теорема (Gilbert & Lynch, 2002) — известная всем триада: Consistency, Availability, Partition tolerance — выбирайте две. Для мультиагентной разработки partition tolerance может быть не главным требованием, и тогда выбор сводится к CA — что само по себе подсказывает правильный архитектурный шаблон.
Часто задаваемые вопросы
Что такое FLP-теорема простыми словами?
Доказательство 1985 года: в распределённой системе, где сообщения могут идти сколь угодно долго, а узлы могут падать, нельзя написать алгоритм, который гарантированно приведёт всех живых участников к общему решению за конечное время. Можно иметь либо безопасность (никаких неверных решений), либо живость (всегда есть прогресс), но не оба одновременно.
Почему агенты — это распределённая система?
Каждый агент — независимый процесс с собственным состоянием (контекстом, историей сообщений, набором tool-вызовов). Они не делят память, обмениваются сообщениями через файловую систему или message queue, и каждый принимает решения автономно. Это в точности определение распределённой системы — со всеми вытекающими ограничениями.
А если поставить главного агента-супервайзора?
Не помогает: вы не убрали проблему конкуренции, вы выбрали один её обработчик. Когда супервайзер мерджит решение от одного агента, работа второго, требующая rebase, либо отбрасывается, либо порождает конфликт. Это знакомая боль из обычного git-флоу с несколькими разработчиками — и теоретически она в мультиагенте та же.
Помогут ли тесты и валидация?
Да, и неожиданно много. Тесты, статический анализ и формальная верификация конвертируют неправильное прочтение промпта (византийский отказ) в честное падение (crash). После этой конверсии система переходит из настоящего «византийского» режима в более лёгкий FLP-режим, где консенсус всё ещё ограничен, но достижимыми способами (с failure detector-ами, partial synchrony и т. д.).
Что делать прямо сегодня, если я уже запускаю мультиагентный пайплайн?
Минимум: партициализируйте задачи между агентами по файлам/модулям через git worktree, заведите внешние валидаторы (тесты, линтеры, типовая проверка) на каждом шаге, дайте агентам способ узнавать о состоянии других (даже простой ps | grep) и поставьте таймауты на каждое действие. Это не отменяет FLP, но превращает плохо-определённое поведение в предсказуемое.
Что думать
Главный вывод поста Гопинатана — не в том, чтобы перестать пользоваться мультиагентными пайплайнами, и не в том, чтобы дождаться более умных моделей. Главный вывод в том, что у нас уже есть теория, которая говорит, что именно сломается и почему. Сорок лет работы Лэмпорта, Линч, Фишера, Патерсона, Халперна и других дают готовые ответы. Игнорировать их — значит каждый раз изобретать половинчатый Paxos и удивляться, что агенты в третий раз за день уронили ваш CI.
Если коротко: относитесь к мультиагентному пайплайну как к распределённой системе — с протоколом, fault model и доказуемыми границами. Не как к «чату с несколькими ботами», который как-нибудь сходится. Тогда выясняется, что половина граблей, на которые вы наступаете, имеет знакомое имя и уже описанный workaround.
Источник: Kiran Gopinathan — Multi-agentic Software Development is a Distributed Systems Problem (AGI can't save you from it). Дополнительно — упомянутые в посте классические работы: Fischer-Lynch-Paterson, 1985; Lamport-Shostak-Pease, 1982; Dwork-Lynch-Stockmeyer, 1988; Gilbert-Lynch, 2002.
