Ранас Мукминов – Оркестрация ИИ-агентов. Claude Opus 4.7 (страница 76)
Под «динамическим назначением роли» в литературе и в практике скрываются несколько разных операций с разным уровнем риска. Их полезно различать, потому что управляемость и failure modes у них отличаются на порядок.
Самый мягкий вариант: каталог ролей статичен и заранее проверен, динамически выбирается лишь то, какой роли отдать конкретную задачу или какому физическому агенту-воркеру эту роль присвоить. Оркестратор смотрит на задачу, классифицирует её и направляет роли «специалист по SQL» или роли «специалист по фронтенду» из заранее известного набора. Это, по сути, маршрутизация (см. главу 27) плюс назначение: множество ролей фиксировано, меняется только отображение «задача → роль».
Риск здесь минимален, потому что каждая роль уже прошла проектную проверку: её права, инструменты и границы заданы и неизменны. Ошибиться можно только в выборе — отдать задачу не той роли. Это плохо, но это ограниченный отказ: агент с неподходящей, но корректно сконфигурированной ролью обычно выдаёт бесполезный, а не опасный результат. Большинство «динамических» систем на практике остаются на этом уровне, и это здоровое положение дел.
Следующий уровень: каркас роли фиксирован — известны слоты под инструменты, под права, под формат контракта, — но конкретное наполнение собирается в момент назначения. Системный промпт роли составляется из шаблона и параметров задачи; набор инструментов выбирается подмножеством из общего пула под конкретную подзадачу; бюджет токенов и лимит шагов проставляются исходя из оценки сложности. Роль «исполнитель» существует как тип, но каждый её экземпляр получает свой профиль.
Здесь риск выше: часть конфигурации, которую при статическом подходе писал и проверял человек, теперь собирается программой или, что хуже, самой моделью. Если шаблон промпта склеивается из недоверенных фрагментов, открывается канал для prompt injection (см. главу 86): текст, пришедший из обрабатываемых данных, может попасть в инструкцию роли. Если набор инструментов выбирается эвристикой, эвристика может выдать агенту инструмент, которого роль не должна иметь. Параметризация требует, чтобы пространство возможных профилей было ограничено и каждый профиль оставался в пределах того, что роль вообще имеет право делать.
Самый сильный и самый опасный вариант: роль, которой в каталоге не было, создаётся в момент работы. Оркестратор (или агент-планировщик) приходит к выводу, что для подзадачи нужен исполнитель с такой-то специализацией, и формирует его — промпт, инструменты, права — с нуля. Это уже не выбор и не параметризация, а генерация нового контракта во время выполнения.
Порождение роли смыкается с динамическим порождением работы (см. главу 34): часто новую подзадачу и нового исполнителя под неё создают одним актом. Принципиальная разница с предыдущими уровнями в том, что здесь нет заранее проверенного объекта вообще. Никто не ревьюировал эту роль, её границы не выводимы из статической конфигурации, её права в худшем случае назначает компонент, не предназначенный быть арбитром безопасности. Именно здесь сосредоточена основная часть рисков главы, и именно здесь динамику нужно ограничивать жёстче всего.
Отдельная ось — не создание роли, а смена роли у уже работающего агента. Агент завершил свою часть как исполнитель и переходит в роль ревьюера чужой работы; воркер, простаивающий из-за перекоса нагрузки, перепрофилируется под другой тип задач; агент, обнаруживший проблему, временно берёт на себя роль координатора. Переназначение опасно тем, что нарушает разделение ответственности во времени: агент, написавший код, и агент, его проверяющий, — это в норме разные роли именно для того, чтобы проверка была независимой (см. главы 19 и 65). Если это один и тот же агент, лишь сменивший «шляпу», независимость иллюзорна: он несёт в контексте собственные решения и склонен их подтверждать, а не оспаривать.
Эти четыре операции — привязка, параметризация, порождение, переназначение — образуют шкалу нарастающего риска. Грамотная система по умолчанию остаётся на левом краю шкалы и сдвигается вправо только под конкретную, обоснованную потребность, удерживая каждый сдвиг в заранее заданных рамках.
Прежде чем разбирать конкретные триггеры и механизмы, нужно зафиксировать архитектурный каркас: какие компоненты участвуют в назначении роли во время выполнения и как между ними распределена ответственность. Без этого каркаса динамика быстро вырождается в неконтролируемую — роли возникают «где-то в логике» без единой точки, которую можно наблюдать и ограничивать.
Любая система динамического назначения, чтобы оставаться управляемой, должна явно содержать три вещи.
Первое — источник решения о роли: компонент, который определяет, какая роль нужна. Это может быть детерминированный классификатор (правила, таблица соответствий, обученная модель-маршрутизатор), оркестратор-агент, рассуждающий о составе исполнителей, или сам агент, запрашивающий себе новую роль. Чем менее детерминирован источник, тем менее предсказуема система. Здоровая архитектура предпочитает детерминированный источник там, где это возможно, и относится к решению модели как к предложению, а не как к команде.
Второе — реестр допустимого: заранее заданное описание того, что вообще может быть назначено. Даже при динамическом порождении пространство возможных ролей не должно быть открытым. Реестр задаёт верхние границы — максимальный набор прав, разрешённые инструменты, допустимые шаблоны промптов, лимиты ресурсов. Любая динамически собранная роль обязана быть подмножеством того, что разрешает реестр. Это превращает «роль, придуманную на лету» в «роль, выбранную из заранее очерченного, пусть и большого, пространства», что принципиально безопаснее.
Третье — точка применения с проверкой: единственное место, через которое роль фактически активируется, и где она проходит валидацию против реестра. Если ролей можно «нахватать» в разных местах кода, ни наблюдать их, ни ограничивать невозможно. Точка применения — это аналог reference monitor из теории безопасности: один шлюз, через который проходит каждое назначение, где проверяется, что запрошенная роль укладывается в допустимое, и где факт назначения записывается.
источник решения реестр допустимого
(классификатор / агент) (границы прав, инструментов,
│ шаблонов, лимитов)
│ запрос роли │
▼ ▼
┌─────────────────────────────────────────┐
│ точка применения (единый шлюз): │
│ валидация против реестра → активация │
│ → запись в журнал назначений │
└─────────────────────────────────────────┘
│ активная роль (промпт+инструменты+права)
▼
агент-исполнитель
Эти три компонента — не опциональное украшение, а минимум, отделяющий управляемую динамику от неуправляемой. Если в системе нельзя указать пальцем на каждый из них, динамическое назначение в ней неуправляемо по построению, независимо от того, насколько аккуратны промпты.
Ключевой архитектурный принцип: назначение роли — привилегированная операция, и привилегия назначать должна быть отделена от привилегий, которые роль даёт. Агент-исполнитель не должен иметь возможности расширить собственную роль или присвоить себе новые права; запрос на роль он может сформулировать, но решение и применение остаются за компонентами, которым он не управляет. Это прямое следствие least privilege (см. главу 88): право определять права — само по себе мощнейшее право, и сосредоточение его в руках исполнителя означает, что граница его роли перестаёт что-либо ограничивать.
Нарушение этого принципа — частая и тяжёлая ошибка. Если в системе агент может сказать «мне нужен инструмент выполнения команд» и получить его без независимой проверки, то роль больше не является границей: любой агент при достаточной настойчивости (или под действием инъекции) дрейфует к максимуму прав. Привилегия эскалации, отданная исполнителю, эквивалентна отсутствию ролей вовсе.
Чтобы каркас из трёх компонентов стал конкретным, проследим один акт назначения на обобщённом примере (инфраструктура иллюстративная). Пусть рой обрабатывает входящие задачи разработки. Приходит подзадача «исправить запрос к базе данных, который выдаёт неверную выборку».
Источник решения — детерминированный классификатор — относит подзадачу к домену «работа с данными» и формирует запрос на роль типа «специалист по данным» с профилем, параметризованным под подзадачу: предметная область, ссылка на затронутый артефакт, оценочный бюджет шагов. Запрос уходит в точку применения.
Точка применения сверяет запрос с реестром. Реестр для типа «специалист по данным» задаёт потолок: разрешён инструмент чтения схемы и инструмент предложения правки, запрещён инструмент прямого исполнения команд в продуктивной среде, бюджет шагов не выше заданного предела, формат выходного контракта фиксирован. Запрошенный профиль укладывается в потолок — роль активируется. Факт назначения записывается в журнал: какой вход, какой источник, какой профиль, какое обоснование, какой результат проверки.