Ранас Мукминов – Оркестрация ИИ-агентов. Claude Opus 4.7 (страница 51)

Третья причина — эволюция системы во времени. Рой почти никогда не проектируется целиком и сразу. Он начинается с простого паттерна — чаще всего оркестратор с парой воркеров — и наращивается под давлением новых требований. На каждом шаге добавляется фрагмент, удобный для конкретной потребности: сюда — конвейер постобработки, туда — критика для повышения качества, здесь — кэширующий слой через общую доску. Через несколько итераций система оказывается гибридом, даже если изначально мыслилась как одна топология. Это не порок процесса; это его естественный исход. Вопрос лишь в том, осознаются ли стыки и спроектированы ли они, или накапливаются как технический долг.

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

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

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

При вложении одна топология находится внутри узла другой. Воркер в схеме «оркестратор — воркеры» сам внутри устроен как конвейер или как маленькая иерархия. Снаружи он выглядит как один узел с контрактом «вход — выход»; внутри он — целая подсистема. Это самый частый и самый управляемый способ комбинирования, потому что внешний контракт узла остаётся прежним: оркестратору безразлично, что воркер внутри — конвейер, лишь бы он принимал задачу и возвращал результат в оговорённом формате.

Вложение естественно отображается на иерархию агентов (см. главу 9): родитель видит ребёнка как чёрный ящик с контрактом, а внутреннее устройство ребёнка — его частное дело. Глубина вложения соответствует глубине иерархии, и каждый уровень может иметь свою топологию. Типичная трёхуровневая система: оркестратор сверху раздаёт работу (fan-out), каждый воркер — конвейер из нескольких стадий, а отдельная стадия конвейера, где нужна повышенная надёжность, — ансамбль из нескольких попыток с голосованием.

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

При последовательном соединении топологии стоят друг за другом, и выход одной служит входом другой. Классический пример: fan-out/fan-in на входе (много воркеров параллельно собирают и нормализуют данные), затем результат уходит в линейный конвейер обработки, затем — в ансамбль для финального решения. Каждая стадия системы целиком — это отдельная топология, и они соединены последовательно, как звенья.

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

Критическая точка последовательного соединения — стык между топологиями. На стыке меняется форма данных: fan-in агрегирует много частичных результатов в один объект, и этот объект должен соответствовать контракту входа следующей стадии. Если агрегатор и потребитель расходятся в ожиданиях относительно формата, полноты или семантики данных, стык становится точкой тихого отказа: данные проходят, но обработка дальше идёт по неверным предпосылкам. Стык — это всегда место смены контракта, и контракт стыка нужно специфицировать так же строго, как контракт отдельного агента (см. главу 18).

При наложении две топологии работают над одним множеством агентов одновременно, по разным осям. Функциональная топология определяет, как течёт содержательная работа; инфраструктурная — как агенты находят друг друга, как ограничивается конкурентность, как ведётся аудит. Это не «одна внутри другой» и не «одна за другой», а две координатные сетки, наложенные на один рой.

Самый распространённый случай наложения — содержательная иерархия плюс инфраструктурный pub/sub. Содержательно агенты образуют дерево «оркестратор — воркеры — субворкеры»; но физически они не вызывают друг друга напрямую, а общаются через шину сообщений с темами и подписками (см. главу 28). Шина — это вторая топология, наложенная на первую. Она не отменяет иерархию координации, но меняет способ доставки и добавляет свои свойства: развязку по времени, возможность широковещания, единую точку наблюдения за всеми сообщениями.

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

Способ | Где живёт вторая топология | Главное наследуемое свойство | Где зарождается отказ

Вложение | Внутри узла внешней топологии | Локализация отказа границей узла (при строгом контракте) | Дырявый контракт узла — внутренний сбой протекает наружу

Последовательное | За предыдущей топологией, выход → вход | Слабейшее звено и сумма латентностей | Стык: рассогласование формата и семантики на границе

Наложение | По другой оси над тем же роем | Свойства обоих слоёв сразу | Противоречие между слоями (порядок, адресация, доверие)

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

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

На стыке двух топологий обычно меняется протокол коммуникации. Внутри конвейера агенты передают артефакты прямой передачей по цепочке; на границе с blackboard коммуникация становится косвенной — через запись и чтение общего пространства. Внутри иерархии вызов синхронный и адресный; на границе с pub/sub он становится асинхронным и широковещательным. Смена протокола означает смену гарантий: то, что внутри одной топологии было гарантировано (порядок, доставка, адресность), на другой стороне границы может не гарантироваться вовсе.

На границе меняется и модель координации. Внутри оркестрированной части есть явный дирижёр, принимающий решения; внутри эмерджентной части (например, рыночной или peer-to-peer) решения возникают из взаимодействия без центра (см. главу 44). Когда оркестрированная топология соединяется с эмерджентной, на границе встречаются две несовместимые модели ответственности: с одной стороны кто-то отвечает за исход, с другой — исход никому не принадлежит. Если эту встречу не спроектировать, возникает зазор ответственности (см. главу 20): оркестратор считает, что отдал работу и она будет сделана, а эмерджентная часть не гарантирует завершения вовсе.

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

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