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

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

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

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

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

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

Промпт шире инструментов. Агенту поручено то, для чего у него нет инструмента. Отказ мягкий и иногда опасный: вместо честного «не могу» агент, склонный быть полезным, имитирует выполнение — описывает результат действия, которое не совершал, генерирует правдоподобный отчёт о работе, которой не было. В мультиагентной системе такой выдуманный результат уходит дальше по конвейеру как настоящий (см. главу 67 о каскадах ошибок).

Рассогласование | Симптом | Класс отказа

Промпт шире прав | Попытки, отказы доступа, зацикливание | Видимый, шумный, тратит ресурс

Права шире промпта | Молчит в норме, срабатывает на отклонении | Спящий, проходит тесты

Инструменты шире декларации | Репертуар шире контракта | Скрытая поверхность атаки

Промпт шире инструментов | Имитация выполнения, выдуманный результат | Тихий, отравляет конвейер

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

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

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

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

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

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

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

Рычаг | Кто обычно задаёт | Где живёт артефакт | Когда фиксируется

Промпт | Прикладной инженер | Конфиг роли плюс динамический контекст | На каждом шаге заново

Инструменты | Разработчик оболочки/оркестратора | Код оболочки, реестр инструментов | При сборке роли, иногда динамически

Права | Platform/security-команда | Инфраструктура вне репозитория агента | При развёртывании среды

Роль редко статична в пределах сессии. Все три рычага могут меняться по ходу работы агента, и эта динамика — отдельный предмет проектирования, который легко упустить, считая роль фиксированной.

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

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