Многоагентная разработка ПО как задача распределённых систем

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

Постановка задачи

Промпт на естественном языке P порождает множество допустимых реализаций Φ(P). Когда работа делится между несколькими параллельными агентами, каждый из них должен выдать код, совместимый с результатами остальных. Всем им нужно сойтись на единой согласованной интерпретации промпта. Это и есть distributed-consensus - та же самая задача, над которой базы данных, блокчейны и реплицированные автоматы состояний бьются десятилетиями.

Почему действуют теоремы о невозможности

LLM-агенты асинхронны (нельзя предсказать время ответа) и подвержены сбоям (падения, таймауты, ограничение частоты запросов). Теорема flp-impossibility 1985 года доказывает, что ни один алгоритм не может гарантировать достижение консенсуса в асинхронной системе при падении хотя бы одного процесса. Приходится жертвовать одним из трёх свойств: безопасностью / safety (никогда не принимать неверное решение), живучестью / liveness (в итоге принять решение) или отказоустойчивостью (переживать сбои).

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

Византийские сбои из-за неверной интерпретации

Падения - это простой случай: видно, что агент упал, и можно повторить попытку. Сложнее, когда агент неверно понял промпт и уверенно выдал правдоподобный, но некорректный код. Это byzantine-fault - агент вроде бы работает как положено, но молча расходится с тем, чего ждут остальные.

Результат Лэмпорта гласит, что для устойчивости к f византийским узлам требуется больше 3f+1 узлов в сумме. Если один из трёх агентов неверно истолкует промпт, надёжно определить ошибку только по выданным результатам невозможно.

Практическая защита

В статье не утверждается, что многоагентное написание кода обречено. Речь о том, что эти сценарии сбоев нужно закладывать в архитектуру явно:

• Превращать византийские сбои в сбои с остановкой (crash faults) - использовать тесты, проверки типов и статический анализ в качестве внешних валидаторов. Если агент выдаёт код, не проходящий тесты, это уже явный сбой, а не скрытое расхождение.
• Встраивать обнаружение сбоев - не считать, что агент отработал успешно, только потому, что он вернул результат. Проверять всё на границах интеграции.
• Осознанно проектировать протоколы координации - не полагаться на неявное согласие между агентами. Делать протокол явным: общие интерфейсы, контрактные тесты, валидация при слиянии.

Сюда же относится human-in-the-loop как ещё одна форма внешней валидации: человек, проверяющий вывод агентов, по сути выступает оракулом консенсуса, способным разрешать спорные ситуации и замечать неверные трактовки, которые пропускают автоматические тесты.

Главный вывод

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

Пример распределённой LLM-системы, которая обходит проблему византийского доверия за счёт предположения о собственной mesh-сети, описан в mesh-llm: там речь идёт о распределённом инференсе поверх p2p-транспорта, а не о многоагентном консенсусе.