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

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

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

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

Решение о специализации сводится к нескольким вопросам, которые стоит задавать в порядке убывания их влияния.

Связность подзадач. Можно ли провести между частями задачи чистую границу, через которую передаётся мало контекста? Если да — специализация дёшева, разрезайте по этой границе. Если любая граница требует гонять почти весь контекст в обе стороны — задача связна, держите её в одной широкой роли.

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

Стабильность структуры задачи. Известны ли границы подзадач заранее и стабильны ли они? Специализация требует, чтобы роли можно было определить до запуска. Если структура выясняется в процессе — склоняйтесь к универсальному агенту или к динамическому назначению ролей, осознавая его цену.

Объём работы на роль против стоимости стыка. Достаточно ли работы внутри предполагаемой роли, чтобы окупить координационный налог вокруг неё? Узкая роль вокруг крошечной операции почти никогда не окупается.

Распределение входов. Какова доля нетипичных случаев? Толстый хвост непредсказуемых входов делает жёсткость специализации хрупкостью; в этом случае гибкость универсального агента ценнее.

Эти вопросы дают не бинарный ответ, а позицию на спектре и раскладку по рычагам роли. Часто итог звучит как «широкий промпт, узкие права, две-три роли по естественным швам, остальное универсально» — а не «специализировать» или «не специализировать».

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

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

— Аналогия с человеческой специализацией обманчива: у людей координация между специалистами дёшева, у роя каждая граница между ролями — это лоссиен handoff. Специализация конвертирует сложность внутри агента в сложность между агентами, и эта сложность часто дороже.

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

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

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

— Failure modes делятся на переспециализацию (рой из микроролей, сложность вытеснена в топологию), ложные границы (разрез поперёк связности), недоспециализацию (нет предсказуемости и ограничения прав там, где они нужны) и иллюзию контроля через промпт. Каждый имеет наблюдаемые симптомы и обратное по знаку лечение.

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

Глава 18. Контракт агента: вход, выход, инварианты

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

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

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

Контракт агента описывает обязательство в трёх частях, и порядок здесь существенен — он повторяет логику предусловий, постусловий и инвариантов.

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