Ранас Мукминов – Оркестрация ИИ-агентов. Claude Opus 4.7 (страница 78)
Часть failure modes уже названа при разборе триггеров и цены; здесь они собраны явно как самостоятельный список, потому что именно их отсутствие в проектной модели чаще всего и приводит к авариям динамических роёв.
Агент получает права шире, чем должен, не через захват инструмента, а через механизм назначения роли. Возникает при самоназначении без проверки, при параметризации роли из недоверенных данных, при отсутствии отделения привилегии назначать от привилегий роли. Последствие — нарушение least privilege с потенциалом тяжёлого ущерба, поскольку широкие права получает агент, который не должен был их иметь. Контрмеры: жёсткий реестр-потолок, единая точка применения с валидацией, независимое одобрение любого расширения сверх дефолта.
Каскадное порождение ролей выходит из-под контроля: дерево исполнителей растёт быстрее, чем закрывается, рой исчерпывает бюджет или ресурсы. Возникает при назначении по результату шага без ограничителей. Последствие — взрыв стоимости и нагрузки за один запрос, вплоть до отказа инфраструктуры. Контрмеры: предел глубины порождения, общий бюджет на всё дерево, счётчик одновременно активных ролей, тайм-аут на дерево целиком, обязательное условие завершения у каждого уровня порождения.
Система реагирует на состояние роя сменой ролей слишком резко и начинает колебаться, тратя работу на сами переназначения. Возникает при назначении по состоянию без демпфирования. Последствие — деградация пропускной способности, livelock управления (см. главу 74). Контрмеры: гистерезис, минимальный интервал между сменами роли у одного агента, требование устойчивого превышения порога перед реакцией.
Назначенная роль постепенно расходится с тем, что агент фактически делает: профиль, собранный под одну задачу, переиспользуется для соседней, для которой не подходит; параметры роли, заданные в начале, перестают соответствовать изменившейся задаче. Возникает при параметризации и переназначении без переоценки соответствия. Последствие — агент действует в роли, не отвечающей задаче, выдавая бесполезный или вредный результат под видом легитимного. Контрмеры: привязка профиля роли к конкретной подзадаче и его аннулирование при смене задачи, периодическая переоценка соответствия роли работе.
Агент последовательно принимает роли, которые должны быть независимы (исполнитель → ревьюер собственной работы), и независимость становится фиктивной. Возникает при динамическом переназначении без запрета на конфликтующие пары ролей. Последствие — иллюзия проверки: формально проверка есть, фактически агент подтверждает собственные решения. Контрмеры: явный список взаимоисключающих ролей, запрет на их последовательное принятие одним агентом, маршрутизация проверки заведомо другому агенту.
Решения о роли принимаются в разных местах и нигде не фиксируются; посмертный разбор не может объяснить поведение агента, потому что роль, в которой он действовал, неизвестна. Возникает при отсутствии единой точки применения и журнала назначений. Последствие — непрозрачность роя, невозможность реконструкции сессии и постмортема. Контрмеры: единый шлюз назначения, обязательная запись каждого назначения с входом и обоснованием, корреляция назначений с действиями в общей трассировке (см. главу 77).
Failure mode | Корневая причина | Уровень риска | Ключевая контрмера
Эскалация через назначение | Привилегия назначать у исполнителя; параметризация из недоверенных данных | Высокий (безопасность) | Реестр-потолок, единый шлюз, независимое одобрение расширения
Размножение ролей | Порождение без ограничителей | Высокий (стоимость, доступность) | Предел глубины, бюджет на дерево, счётчик ролей, тайм-аут
Осцилляция переназначений | Реакция на состояние без демпфирования | Средний (пропускная способность) | Гистерезис, лимит частоты смены роли
Дрейф роли | Переиспользование профиля без переоценки | Средний (качество) | Привязка профиля к подзадаче, переоценка соответствия
Потеря независимости | Конфликтующие роли у одного агента | Средний (качество проверки) | Запрет взаимоисключающих пар ролей
Неотслеживаемость | Нет единой точки и журнала назначений | Средний (наблюдаемость) | Единый шлюз, журнал назначений, корреляция в трассировке
Динамика — не достижение и не цель; это инструмент с высокой ценой управляемости, оправданный лишь при конкретных условиях. Статическое назначение следует считать значением по умолчанию и отходить от него осознанно.
Динамическое назначение оправдано, когда пространство задач заранее неизвестно настолько, что статический каталог ролей либо не покрывает реальную нагрузку, либо вынужден быть нелепо широким. Если заранее нельзя перечислить специализации, которые понадобятся, потому что они зависят от содержания каждого конкретного запроса, статический подход вырождается: придётся либо держать один универсальный агент (теряя выгоду специализации, см. главу 17), либо завести десятки узких ролей «на всякий случай», большинство которых простаивает. В таких условиях динамическое порождение или параметризация роли под фактическую задачу — обоснованный выбор.
Второе условие — переменная и непредсказуемая нагрузка, при которой статическое распределение воркеров по ролям систематически приводит к простою одних и перегрузке других. Динамическое переназначение по состоянию роя здесь окупается, если оно демпфировано и не осциллирует.
Динамика противопоказана, когда пространство ролей мало и стабильно: если в системе по сути три роли и они известны, динамическое назначение добавляет риск, не давая ничего взамен. Она противопоказана там, где важнее всего воспроизводимость и аудит, — в регулируемых контурах, где нужно уметь объяснить, почему конкретный агент действовал именно так; динамика размывает этот ответ. Она противопоказана при слабой изоляции и широких правах: чем выше потенциальный ущерб от агента, тем дороже обходится эскалация через назначение, и тем меньше оснований давать механизму назначения свободу.
Общее правило: динамическое назначение тем безопаснее, чем уже остаётся пространство возможного (реестр-потолок), чем детерминированнее источник решения и чем строже изолированы роли (см. главу 88). Динамика без этих трёх ограничителей — это отказ от ролей как инструмента управления под видом гибкости.
На практике зрелые системы редко бывают чисто статическими или чисто динамическими. Типичная конфигурация: статическое ядро из проверенных, наиболее ответственных ролей (оркестратор, ревьюер, роли с широкими правами) плюс динамический слой исполнителей, параметризуемых под задачу в пределах жёсткого реестра. Ответственные роли, ошибка в которых дорога, фиксируются и проверяются заранее; массовые исполнители с узкими правами собираются на лету. Это сочетает предсказуемость там, где она критична, с гибкостью там, где пространство задач действительно непредсказуемо, и согласуется с гибридными топологиями (см. главу 14) и с версионированием ролей в долгоживущем рое (см. главу 22).
— Динамическое назначение ролей переносит на время выполнения риск, который статическая роль гасила на этапе проектирования: вместе с гибкостью система получает новые failure modes, расширенную поверхность атаки и усложнённую отладку. Статическое назначение — значение по умолчанию; отход от него должен быть обоснован.
— Под «динамикой» скрываются четыре операции нарастающего риска: привязка задачи к существующей роли, параметризация роли, порождение новой роли и переназначение роли у работающего агента. Грамотная система держится левого края этой шкалы и сдвигается вправо только под конкретную потребность.
— Управляемая динамика требует трёх явных компонентов: источника решения о роли, реестра допустимого как жёсткого потолка и единой точки применения с валидацией и журналированием. Если на каждый из них нельзя указать пальцем, динамическое назначение неуправляемо по построению.
— Привилегия назначать роль должна быть отделена от привилегий, которые роль даёт: исполнитель может запросить роль, но не присвоить себе права. Иначе граница роли перестаёт что-либо ограничивать, а под действием prompt injection назначение становится каналом эскалации.
— Ключевые failure modes — эскалация через назначение, размножение ролей, осцилляция переназначений, дрейф роли, потеря независимости при переназначении и неотслеживаемость назначений. Каждый требует заранее заложенной контрмеры: реестра-потолка, лимитов на дерево порождения, демпфирования, привязки профиля к задаче, запрета конфликтующих пар ролей и журнала назначений.
— Динамика оправдана, когда пространство задач заранее неизвестно настолько, что статический каталог либо не покрывает нагрузку, либо вынужден быть избыточно широким; и противопоказана при малом стабильном наборе ролей, требованиях аудита и широких правах агентов.
— Норма зрелой системы — гибрид: статическое проверенное ядро ответственных ролей плюс динамический слой узкоправных исполнителей в пределах жёсткого реестра. Предсказуемость там, где ошибка дорога; гибкость там, где задачи действительно непредсказуемы.
Глава 22. Версионирование ролей и совместимость
Предыдущие главы части рассматривали роль в статике: роль как тройка из промпта, инструментов и прав (см. главу 16), как проверяемый контракт входа и выхода (см. главу 18), как элемент каталога канонических ролей (см. главу 19). Глава о динамическом назначении (см. главу 21) ввела время в одном измерении — роль выбирается на лету под конкретную задачу. Эта глава вводит время в другом измерении: роль не статична и в более длинном масштабе. Промпт переписывают, потому что модель сменилась или нашёлся дефект формулировки. Набор инструментов расширяют. Схему выходного артефакта меняют. Права урезают после инцидента. Каждое такое изменение порождает новую версию роли, и в системе, которая живёт дольше одного запуска, версии неизбежно сосуществуют.