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

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

Динамическое назначение запускается каким-то событием. Разные триггеры дают разную предсказуемость и требуют разных защит.

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

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

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

Опасность — нестабильность управления: если переназначение реагирует на состояние слишком резко, система начинает осциллировать. Воркеры массово перепрофилируются под тип A, очередь A пустеет, очередь B растёт, воркеры массово возвращаются на B — и так по кругу, тратя работу на сами переназначения, а не на задачи. Это разновидность livelock на уровне управления (см. главу 74). Защита — гистерезис и демпфирование: переназначать с задержкой, требовать устойчивого превышения порога, ограничивать частоту смены роли у одного агента.

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

Главный failure mode — неограниченное размножение ролей и работы. Один запрос разворачивается в дерево подзадач, каждая порождает исполнителей, те порождают свои подзадачи, и рой растёт экспоненциально, пока не упрётся в стоимость или лимиты (см. главы 34 и 59). Без жёсткого ограничителя такая система способна за один запрос исчерпать бюджет токенов или загрузить инфраструктуру до отказа. Защита обязательна и многослойна: предел глубины порождения, общий бюджет на дерево, счётчик активных ролей, тайм-аут на всё дерево целиком.

Крайний случай: агент сам решает, какую роль ему принять или какие права запросить. Это максимум гибкости и максимум риска одновременно. Самоназначение нарушает принцип отделения привилегии назначать от привилегий роли (см. выше), если запрос агента удовлетворяется без независимой проверки. Под действием prompt injection самоназначение становится прямым каналом эскалации: инъекция убеждает агента запросить себе более широкую роль, и если запрос проходит, граница роли пробита.

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

Триггер | Предсказуемость | Главный failure mode | Обязательная защита

По содержанию задачи | Высокая при детерминированном классификаторе | Неверная классификация → неподходящая роль | Консервативный дефолт, эскалация при неуверенности

По состоянию роя | Средняя | Осцилляция переназначений (livelock управления) | Гистерезис, демпфирование, лимит частоты смены роли

По результату шага | Низкая | Неограниченное размножение ролей и работы | Предел глубины, бюджет на дерево, счётчик ролей, тайм-аут

Самоназначение | Очень низкая | Эскалация привилегий, в т.ч. через инъекцию | Отделение привилегии назначать; независимое одобрение расширения

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

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

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

Практический вывод: при динамическом назначении необходимо логировать каждое решение о роли вместе с его входом и обоснованием. Без этого посмертный разбор (см. главу 82) упирается в стену — поведение агента невозможно объяснить, не зная роли, в которой он действовал, а роль нигде не зафиксирована.

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

Особенно опасно динамическое переназначение между ролями, которые должны быть независимы. Когда исполнитель становится ревьюером собственной работы, независимость проверки теряется, хотя формально в системе есть и роль исполнителя, и роль ревьюера. Архитектура должна явно запрещать такие переходы: множество ролей, которые агент может последовательно принимать, обязано исключать пары, требующие взаимной независимости.

С точки зрения безопасности (часть XII) динамическое назначение добавляет новый класс целей: сам механизм назначения. Если противник или инъекция могут повлиять на решение о роли, они могут добиться эскалации привилегий, не атакуя ни один инструмент напрямую, — достаточно убедить систему выдать агенту роль с нужными правами. Это особенно остро при самоназначении и при параметризации роли из недоверенных данных.

Канал распространения инъекции (см. главу 86) здесь специфичен: заражённый текст, попав в обрабатываемые данные, влияет не на действие агента, а на назначение роли следующему агенту. Атака отмывается через механизм назначения: исходный агент остаётся в узкой роли, но порождает или запрашивает для соседа широкую. Защита — недоверие к решению о роли так же, как к любым данным: решение, на которое могли повлиять недоверенные источники, не должно автоматически расширять права, и реестр допустимого должен быть жёстким потолком, который инъекция не способна поднять.

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