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

Шрифт

— Петли маршрутизации. Адресаты возвращают задачу маршрутизатору, тот направляет её обратно по кругу — livelock на уровне потоков (см. главу 74). Нужны счётчики переадресаций и предел.

— Единая точка отказа. Если весь поток роя проходит через один маршрутизатор, его отказ останавливает систему (см. главу 75). Маршрутизатор-SPOF требует тех же мер, что и оркестратор.

— Недетерминизм там, где не нужен. Маршрутизация на модели вносит стоимость и непредсказуемость в операцию, которая часто могла быть детерминированной; решения трудно воспроизвести при отладке (см. главу 80).

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

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

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

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

Сводная таблица по четырём осям:

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

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

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

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

— Роль определяется не названием и не промптом, а четырьмя осями: профилем контекста (что видит и чего не видит), инструментами, правами (жёсткими границами среды) и контрактом. Две роли с одним именем, но разными правами — разные роли с разными отказами.

— Право изменять предметное состояние мира в каноне принадлежит ровно одной роли — исполнителю, и именно она работает в самой жёсткой изоляции. Планировщику, ревьюеру, критику, тестировщику и маршрутизатору запись в мир противопоказана; это прямое следствие least privilege.

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

— Главные failure modes канона: у планировщика — дробление и галлюцинация возможностей; у исполнителя — уверенно неверный результат; у ревьюера — соглашательство; у критика — вырождение в похвалу; у тестировщика — слабое покрытие и тест под результат; у маршрутизатора — неверная классификация и петли.

— Самое опасное слияние — исполнитель и проверяющая роль в одном прогоне с общим контекстом: проверка вырождается, ошибки коррелированы. Разнообразие модели и ракурса — паллиатив, а не замена разделения.

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

Глава 20. Границы ответственности и зазоры

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

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

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

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

Различие принципиально. Инструменты определяют возможность; зона ответственности определяет обязанность. Роль может иметь доступ к файловой системе, но не отвечать за консистентность данных в ней. Две роли могут иметь одинаковые инструменты, но непересекающиеся зоны ответственности — например, исполнитель и ревьюер оба читают код, но один отвечает за то, чтобы код был написан, а другой за то, чтобы он был проверен. Возможность пересекается; ответственность — в идеале нет.

Зону ответственности удобно описывать через три вопроса к каждой ситуации:

71 72 73 74 Вперед