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

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

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

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

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

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

Все пять не-случаев объединяет одно: в каждом из них присутствует либо более чем один вызов модели, либо граф из нескольких шагов, и потому каждый внешне похож на «много агентов». Путаница устойчива, потому что наблюдаемый признак (несколько обращений к модели или ветвящийся граф) не совпадает с сущностным (распределение по трём осям между недетерминированными узлами). Проектировщик видит N вызовов и заключает, что строит рой; на деле он строит stateless-сервис, ансамбль, одиночного агента с многошаговым рассуждением или детерминированный workflow.

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

Конфигурация | Распределение работы | Общее состояние | Распределённая ответственность | Оркестрация

Параллельный вызов одной модели | нет | нет | нет | нет

Батч-обработка независимых входов | нет | нет | нет | нет

Ансамбль с агрегатором | нет | нет | нет | нет

Цепочка промптов в одном контуре | нет | один контекст | один контур | нет

Агент с набором инструментов | нет | один контекст | один контур | нет

Workflow с детерминированными шагами | да | да | да | задач, не агентов

Система из агентов (предмет книги) | да | хотя бы одно из трёх | да | да

Таблица читается так: оркестрация агентов возникает, когда узлы недетерминированы И присутствует хотя бы одно из трёх распределений. Параллелизм, число вызовов модели и наличие графа — не признаки оркестрации.

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

Распределение работы означает, что задача разбита на части, и разные агенты делают разные части. Это не дублирование (как в ансамбле) и не последовательные фазы одного рассуждения (как в цепочке промптов), а разделение труда: агент A производит то, что агент B не производит, и итог собирается из непересекающихся вкладов.

Сразу же появляются вопросы, которых не было у одного агента. Как провести границы подзадач, чтобы их можно было вести параллельно (см. главу 31)? Что делать с зависимостями между подзадачами — частичным порядком, в котором B не может начать, пока A не закончил (см. главу 32)? Как собрать результат из частей и убедиться, что части совместимы (см. главу 37)? Распределение работы — это всегда декомпозиция плюс сборка, и обе операции стоят. Сама возможность параллелизма ограничена последовательной долей задачи; для роёв агентов эта доля велика, и закон Амдала здесь работает жёстче, чем кажется (см. главу 56).

Failure mode распределения работы: зазоры и перекрытия. Если границы подзадач проведены неточно, между ними остаётся работа, которую не делает никто (зазор), или которую делают двое независимо и несовместимо (перекрытие). Зазор проявляется как пропущенное требование в итоговом результате; перекрытие — как конфликт при сборке. Диагностике зазоров посвящена глава 20; здесь важно зафиксировать: распределение работы не бесплатно и вводит собственный отказ, отсутствующий у одиночного агента.

Распределение состояния означает, что знание о задаче, её прогрессе и промежуточных результатах не сосредоточено в одном месте, а размазано по агентам и носителям. У одного агента всё состояние — в его контексте; он его полностью наблюдает и полностью контролирует. Как только агентов становится несколько, состояние неизбежно фрагментируется: часть знает A, часть — B, часть лежит в общем хранилище, часть — в очереди сообщений.

Это превращает систему в распределённую в самом точном смысле. Возникает вопрос согласованности: видит ли B то, что уже сделал A, и насколько свежую версию (см. главы 49, 48 о моделях согласованности и shared против share-nothing). Возникает вопрос передачи контекста: что именно нужно передать от A к B, чтобы B мог продолжить, и что при этой передаче теряется (handoff, см. главу 47). Возникает вопрос локализации порчи: если состояние одного агента испорчено — галлюцинацией, инъекцией, накопленной ошибкой, — как не дать этому распространиться по общей памяти (см. главу 53).

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

Важная оговорка: распределённое состояние — это риск, а не цель. Лучшие архитектуры минимизируют разделяемое изменяемое состояние, а не наращивают его; share-nothing как основа надёжного параллелизма разбирается в главе 54. Но даже при максимальной изоляции какое-то состояние пересекает границы агентов — хотя бы handoff между стадиями, — и этого достаточно, чтобы законы распределённых систем вступили в силу.

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