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

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

— Пункт контракта ценен ровно настолько, насколько он проверяем. Семантические обещания нужно опускать по лестнице проверяемости до уровня структуры и проверяемых свойств; непроверяемый остаток помечать честно. Постусловие, сведённое к проверке схемы, ловит форму, но не смысл, — это главный источник молчаливого распространения мусора.

— Частичный контракт с честным отказом (insufficient_context, cannot_comply) для агента почти всегда честнее тотального: он превращает молчаливую галлюцинацию на необрабатываемом входе в наблюдаемое событие и служит основой деградации на уровне роли.

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

— Рой собирается через совместимость контрактов: постусловие producer должно влечь предусловие consumer. Безопасная замена агента ослабляет предусловия и усиливает постусловия, но не наоборот. Несовместимость контрактов — дефект проектирования ролей, который дешевле устранить, чем обслуживать агентными адаптерами.

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

Глава 19. Каталог канонических ролей

Предыдущие главы части III ввели роль как тройку — промпт, инструменты, права (см. главу 16) — и как проверяемый контракт с входом, выходом и инвариантами (см. главу 18). Эта глава — справочник: она применяет ту же модель к шести ролям, которые повторяются почти в каждой работающей мультиагентной системе независимо от провайдера и фреймворка. Планировщик, исполнитель, ревьюер, критик, тестировщик, маршрутизатор. Это не таксономия «всех возможных» агентов и не догма: реальные рои комбинируют, сливают и дробят эти роли. Но они образуют словарь, на котором удобно проектировать, и набор шаблонов с уже известными failure modes.

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

Перед каталогом — две сквозные оговорки. Первая: разделение ролей не бесплатно. Каждая роль — это отдельный контур (наблюдение, план, действие, проверка), отдельный системный промпт, отдельный бюджет токенов и ещё один стык, на котором теряется контекст. Заводить роль стоит тогда, когда выгода от специализации и разделения прав превышает этот координационный налог (см. главу 5 и главу 17). Вторая: роль — это логическая абстракция, а не обязательно отдельный процесс или отдельная модель. Один и тот же исполнитель может в разные моменты выступать планировщиком и исполнителем; важно, что в каждый момент он действует под конкретным контрактом, с конкретными правами. Смешение ролей в одном вызове без явной смены контракта — частый источник тонких сбоев, к которому глава будет возвращаться.

Чтобы записи каталога были сопоставимы, каждая роль описывается по одной схеме.

Назначение — какую единственную ответственность несёт роль. Если ответственностей несколько и они разной природы (порождать изменения и судить о них), это сигнал, что роль стоит разделить.

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

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

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

Failure modes — как роль ломается характерным для неё образом. Это центральная часть каждой записи: канонические роли ценны ровно тем, что их типовые отказы известны заранее.

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

Свод по всем шести ролям приведён в конце главы перед выводами.

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

Планировщик — это голова паттерна «оркестратор и воркеры» (см. главу 8) и вершина иерархии в дереве агентов (см. главу 9). В простых роях планирование и оркестрация совмещены в одном агенте; в сложных их полезно разделять, потому что планирование (что делать) и диспетчеризация (кому и когда отдать работу) — разные ответственности с разной частотой и разной ценой ошибки.

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

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

Канонический планировщик инструментов действия не имеет вовсе. Он читает (состояние, каталог ролей, ограничения) и пишет план. Если планировщику дают инструменты, то «планировочные»: декомпозиция, оценка стоимости, запрос к каталогу возможностей, иногда — обращение к памяти роя за похожими прошлыми планами (см. главу 50). Доступ к инструментам, изменяющим мир (запись в репозиторий, развёртывание, отправка во внешние системы), планировщику противопоказан.

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

— Слишком мелкое или слишком крупное дробление. Чрезмерная декомпозиция порождает координационный взрыв: подзадач больше, чем выгоды от параллелизма (см. главу 5 и главу 34). Слишком крупные подзадачи не распараллеливаются и возвращают рой к одному агенту.

— Галлюцинация возможностей. Планировщик закладывает в план роль или инструмент, которых в системе нет, либо приписывает роли права, которых у неё нет. Защита — давать планировщику актуальный каталог возможностей как контекст, а не позволять выдумывать его.