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

Топология, выбранная для исходного масштаба, не пересматривается, когда масштаб изменился.

Оркестратор, отлично работавший на десяти воркерах, оставляют на тысяче, и центр становится

узким местом, через которое всё сериализуется (узкие места координации, см. часть VIII). Или

наоборот: построенный «на вырост» peer-to-peer продолжает нести налог децентрализации, хотя

нагрузка так и не выросла. Симптом — топология не менялась, а профиль нагрузки изменился на

порядок. Лекарство — привязка пересмотра топологии к измеримому сигналу смены доминирующего

ограничения, а не к календарю и не к интуиции.

Топология деформируется наслоением частных решений без общего замысла, пока её форму перестаёт

быть возможным назвать. Каждая отдельная заплата выглядела разумной — обойти медленный центр

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

но сумма превращается в систему без описуемой архитектуры. Это отказ не разового выбора, а

дисциплины его сопровождения. Симптом — на вопрос «какая у нас топология» нет однозначного

ответа, а схема системы не совпадает с тем, как она работает в реальности. Лекарство — режим, в

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

обоснования, что и исходный выбор; точечные обходы формы запрещены как класс.

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

сравнении, без проверки, совпадает ли структура той задачи со структурой текущей. Конфигурация,

выигрышная для одного класса задач (скажем, состязательная схема для субъективного качества),

переносится на класс, где она бессмысленна (механически проверяемая задача), просто потому, что

«так делают лучшие». Опасность усиливается тем, что публичные сравнения почти всегда умалчивают

о трёх входах: показывают выигрыш в качестве, но не координационный налог, не профиль отказов под

нагрузкой и не стоимость эксплуатации той формы. Перенесённая по одному лишь результату качества,

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

обоснование выбора апеллирует к чужому результату, а не к трём входам собственной задачи. Лекарство

— оценивать топологию по соответствию структуре конкретной задачи; чужой результат — основание

изучить паттерн и понять, на какой структуре он выигрывал, но не основание применить его к задаче

другой формы.

— Топология выводится из трёх независимых входов — структуры работы, профиля рисков и стоимости,

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

входов даёт локально красивый и глобально хрупкий рой.

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

затем профиль рисков проверяет её приемлемость, и только операционный контекст работает

ограничителем, запрещающим формы, которые команда не сможет эксплуатировать.

— Матрица «задача — топология» называет доминирующий паттерн первого приближения, а не финальную

форму; она применяется рекурсивно — к рою целиком и к каждой крупной подзадаче, — потому что

production-системы почти всегда гибриды (глава 14).

— Выбор топологии не однократен: смена масштаба и профиля нагрузки меняет оптимальную форму, и

эволюция должна быть явным архитектурным актом, запускаемым измеримым сигналом смены

доминирующего ограничения, а не наслоением необъявленных заплат.

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

когда переделка дороже на порядок; поэтому выбор требует явной дисциплины, а не интуиции.

— Типовые провалы — топология по умолчанию, преждевременная децентрализация, игнорирование

операционного входа, смешение уровней задачи, фиксация формы при смене масштаба, неявная

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

и лекарство в виде явного критерия.

— Презумпция — простейшая достаточная топология: сложность принимается только под доказанное

требование, потому что необслуживаемая система ненадёжна независимо от изящества её архитектуры.

Глава 16. Роль как тройка: промпт, инструменты, права

Часть II дала топологии: кто кому подчинён, кто кому передаёт работу, через какие узлы проходит управление. Топология отвечает на вопрос «как агенты связаны». Часть III отвечает на вопрос «чем именно отличается один агент от другого внутри этой связи». Ответ на первый взгляд тривиален: у агентов разные роли. Планировщик планирует, исполнитель исполняет, ревьюер проверяет. Но «роль» в мультиагентной системе — не ярлык в документации и не строка в конфиге оркестратора. Это сумма трёх конкретных, технически измеримых механизмов, каждый из которых можно настроить отдельно и каждый из которых по отдельности отказывает.

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

Дальнейшие главы Части III рассматривают, что делать с ролями: когда специализация выгоднее универсальности (см. главу 17), как описать роль контрактом с проверяемыми входом и выходом (см. главу 18), какие роли каноничны (см. главу 19), как избежать зазоров и перекрытий ответственности (см. главу 20). Эта глава — фундамент: она разбирает, из чего роль сделана и какие у каждого её слоя failure modes.

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

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

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

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

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