Ранас Мукминов – Оркестрация ИИ-агентов. Claude Opus 4.7 (страница 48)
Ключевое архитектурное следствие: в peer-to-peer обнаружение принципиально неполно и устаревает. Агент в любой момент имеет лишь частичное и слегка устаревшее представление о составе сети. Это не дефект реализации, а свойство топологии: собрать полную свежую картину можно только в центре, а центра нет. Любая логика, рассчитывающая на то, что агент знает обо всех участниках точно и сейчас, в peer-to-peer некорректна.
Обнаружив часть сети, агент должен уметь доставить сообщение узлу, которого, возможно, нет среди его прямых знакомых. В централизованной топологии маршрутизация тривиальна: всё идёт через хаб, хаб знает всех. В peer-to-peer хаба нет, и маршрут приходится прокладывать через цепочку посредников — других равноправных узлов.
Здесь возникает фундаментальный компромисс между связностью и стоимостью. Один полюс — полная связность: каждый узел знает каждого и шлёт напрямую. Маршрутизация тогда тривиальна (один переход), но число связей растёт квадратично числу узлов (см. главу 5 о цене координации), и поддержание этих связей в актуальном состоянии само становится доминирующей нагрузкой. Полная связность работает для небольших сетей и быстро становится неподъёмной с ростом.
Другой полюс — структурированная маршрутизация. Узлам и адресатам присваиваются идентификаторы из общего пространства, и каждый узел хранит связи лишь с логарифмически малым числом других, выбранных так, чтобы любой адрес достигался за логарифмически малое число переходов. Это идея распределённой хеш-таблицы (DHT): сеть совместно реализует отображение «идентификатор — узел, отвечающий за этот идентификатор», и ни один узел не держит всю таблицу. Маршрутизация перестаёт быть прямой, но каждый узел хранит мало связей, и сеть масштабируется. Цена — многошаговая доставка (сообщение проходит через несколько посредников) и сложность поддержания структуры при входе и выходе узлов.
Для роя агентов важны два следствия структурированной маршрутизации. Первое: многошаговая доставка означает, что сообщение проходит через узлы, которым оно не адресовано. Это сразу ставит вопрос доверия к посредникам (см. ниже) и наблюдаемости: путь сообщения распределён, и восстановить его посмертно труднее, чем в звезде, где все пути проходят через центр (см. главу 81 о реконструкции сессии). Второе: адресация по содержанию, а не по узлу. В DHT-подобной схеме естественно адресовать не «агенту номер семь», а «тому, кто отвечает за ключ K» — например, за определённую тему или часть состояния. Адресат вычисляется из ключа, а не задаётся явно. Это удобно для распределения состояния, но означает, что при изменении состава сети ответственность за ключ переходит от узла к узлу, и адресат «того же» ключа со временем меняется.
Третья функция центра — доверие. В централизованной топологии доверие иерархично: воркер доверяет оркестратору, потому что оркестратор — корень авторитета. Проверять оркестратора не нужно; он по построению доверенный. В peer-to-peer корня нет. Сообщение приходит от равного узла, который мог быть скомпрометирован, мог ошибиться, мог получить инъекцию через свой вход (см. главу 86) или сам оказаться внедрённым противником. Доверие приходится устанавливать без апелляции к авторитету.
Это самая трудная из трёх функций, и ей посвящена отдельная глава о zero-trust в рое (см. главу 85); здесь — лишь то, что специфично именно для топологии. Без центра доверие строится на трёх механизмах, обычно комбинируемых. Первый — проверяемая идентичность: узлы подписывают сообщения, и получатель может убедиться, что сообщение исходит от того, за кого себя выдаёт, не спрашивая центр. Это не делает отправителя доверенным — лишь устанавливает, кто он. Второй — репутация, распространяемая по сети: узлы обмениваются оценками поведения других узлов, и репутация участника складывается из мнений многих. Репутация в peer-to-peer сама децентрализована, и потому сама уязвима — её можно накручивать сговором, можно отравлять ложными оценками (см. ниже о sybil-атаках). Третий — верификация результата вместо доверия к источнику: вместо того чтобы верить, что узел выполнил работу правильно, получатель проверяет результат независимо (см. часть V о верификации итога). Это самый надёжный механизм, потому что не опирается ни на чью добросовестность, но он применим лишь там, где результат дешевле проверить, чем произвести.
Главное архитектурное следствие: в peer-to-peer доверие не транзитивно по умолчанию. То, что узел A доверяет узлу B, а B доверяет C, не означает, что A может доверять C. Каждое ребро доверия устанавливается отдельно. Системы, которые неявно предполагают транзитивность доверия (раз сообщение пришло через доверенного посредника, ему можно верить), открывают путь к отмыванию доверия через цепочку посредников (см. главу 84) — атаке, которой в иерархии с явным корнем авторитета нет.
Функция | В централизованной топологии | В peer-to-peer | Чем платим
Обнаружение | Адрес центра известен всем | Bootstrap-точки плюс gossip или распределённый реестр | Знание о составе неполно и устаревает
Маршрутизация | Всё через хаб, хаб знает всех | Многошаговая через посредников или DHT по идентификаторам | Путь распределён, доставка многошагова, наблюдаемость падает
Доверие | Иерархично, корень авторитета не проверяется | Подписи плюс распределённая репутация плюс верификация результата | Доверие не транзитивно, репутация сама уязвима
Три протокола не независимы: маршрутизация опирается на обнаружение (нельзя маршрутизировать к неизвестному), доверие пронизывает оба (посредникам маршрута и источникам сведений об обнаружении нужно доверять). Проектируя peer-to-peer, эти три слоя приходится держать вместе, потому что слабость любого подрывает остальные.
Три протокола восстанавливают функции центра, но не отменяют главную трудность децентрализации — согласование. Когда нескольким равноправным узлам нужно прийти к единому решению или единому представлению о состоянии, без арбитра это превращается в задачу распределённого консенсуса, со всей её известной тяжестью.
В централизованной топологии согласование тривиально: центр — единственный писатель, его решение и есть истина. Хочешь узнать, кому досталась задача, — спроси центр. Хочешь изменить состояние — попроси центр, он сериализует все запросы и разрешит конфликты порядком их поступления (см. главу 41 о single-writer). Центр превращает распределённую проблему в локальную.
Убрав центр, мы возвращаем проблему в её исходной, трудной форме. Теперь, чтобы два узла согласились, кому достанется задача, они должны провести протокол: предложить, узнать о встречных предложениях, разрешить конфликт по общему правилу. Если узлов больше двух, протокол усложняется. Если сообщения теряются, задерживаются и приходят не по порядку (а в распределённой системе они так и делают — см. главу 30), протокол должен это переживать. Это и есть распределённый консенсус, и теория распределённых систем давно показала, что он принципиально труден: в асинхронной сети с возможными отказами узлов нельзя одновременно гарантировать и согласие, и завершимость при произвольных задержках. Практические протоколы консенсуса обходят это ценой допущений (например, частичной синхронности) и ценой раундов коммуникации.
Для роя агентов это означает, что любое решение, требующее согласия многих равных, стоит раундов сообщений и не гарантировано завершиться в худшем случае. Согласовать, кто возьмёт подзадачу, какое значение состояния истинно, достигнут ли результат, — каждое такое согласие в peer-to-peer платит координационным налогом, которого в централизованной топологии просто нет.
Особенно остро трудность согласования проявляется в работе с общим состоянием. В peer-to-peer нет единого носителя истины (см. главу 46): состояние распределено по узлам, и у разных узлов могут быть разные, рассогласованные представления о нём. Это не временный сбой, а нормальное положение дел между моментами согласования.
Здесь приходится сделать выбор модели согласованности (см. главу 49), и в peer-to-peer этот выбор почти всегда смещён к слабой согласованности. Сильная согласованность — гарантия, что все узлы видят одно и то же значение в любой момент — требует согласования на каждой записи, то есть консенсуса на каждом изменении, что в децентрализованной сети непомерно дорого. Поэтому peer-to-peer обычно опирается на eventual consistency: узлы расходятся в представлениях, но при отсутствии новых изменений со временем сходятся к общему. Между моментами сходимости система живёт с противоречивыми копиями состояния.
Жить со слабой согласованностью можно, но это накладывает требование на содержательную логику: операции над общим состоянием должны быть устроены так, чтобы их можно было применять в разном порядке на разных узлах и всё равно прийти к одному результату. Это сильное ограничение. Не всякая работа агента так устроена; многие операции по природе своей чувствительны к порядку, и для них слабая согласованность даёт расходящиеся, несводимые результаты. Когда операции не коммутируют, eventual consistency не спасает — узлы сходятся к разному, и согласовать их постфактум невозможно без потери чьих-то изменений (см. главу 40 о разрешении конфликтов).