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

— План без критериев приёмки. Подзадачи сформулированы как намерения («улучшить обработку ошибок»), а не как проверяемые контракты. Тогда ни исполнитель не знает, когда закончил, ни ревьюер — что проверять.

— Залипание в перепланировании. При каждом отклонении планировщик переписывает план целиком вместо локальной коррекции, и рой не сходится (см. главу 66). Нужен предел частоты и глубины перепланирования.

— Игнорирование зависимостей. План задаёт порядок, нарушающий причинные зависимости подзадач; диспетчер запускает то, что ещё не готово к запуску (см. главу 32).

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

Исполнитель — лист в дереве агентов и единица параллелизма в fan-out/fan-in (см. главу 8). Свойства роя на масштабе во многом определяются тем, насколько исполнители изолированы друг от друга: share-nothing-исполнители масштабируются, исполнители, конкурирующие за общее изменяемое состояние, — нет (см. часть VIII).

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

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

Выход исполнителя — артефакт (изменение, файл, фрагмент) плюс отчёт о том, что сделано, относительно контракта подзадачи.

Исполнитель — самая инструментально оснащённая роль: ему доступны действия, изменяющие мир в пределах его подзадачи. Состав набора зависит от специализации (исполнитель-кодер, исполнитель-интегратор с внешними API, исполнитель работы с данными). Ключевой принцип — инструменты выдаются под подзадачу, а не «на всякий случай»: чем шире инструментальный набор исполнителя, тем больше поверхность отказа и поверхность атаки (см. главу 88).

Права исполнителя должны быть минимальными и ограниченными его рабочей областью. Канонический безопасный исполнитель работает в изолированной песочнице (отдельная ветка, отдельный воркспейс, ограниченный egress) и не может менять то, что вне его подзадачи (см. главу 55). Он не утверждает собственную работу — приёмка принадлежит ревьюеру и тестировщику. Право «слить своё изменение в общий результат» исполнителю не принадлежит; это право контура контроля.

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

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

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

— Дрейф от контракта. Получив неполный контекст, исполнитель решает не ту задачу, которую имел в виду планировщик, но формально близкую. Чем хуже контракт подзадачи, тем чаще этот дрейф.

— Тихий отказ инструмента. Внешний вызов завершился ошибкой, но исполнитель интерпретировал её как успех или проигнорировал. Нужна явная семантика ошибок инструментов (см. главу 30).

— Залипание. Исполнитель повторяет один и тот же неудачный подход; без внешнего тайм-аута и предела попыток он расходует бюджет без прогресса (см. главу 72 и главу 74).

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

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

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

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

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

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

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

Тонкий момент прав — может ли вердикт ревьюера быть окончательным или он совещательный. Окончательный вердикт даёт ревьюеру власть остановить рой (полезно для безопасности, опасно для пропускной способности); совещательный делает его одним из голосов в последующем согласовании (см. главу 39). Это решение про права, и его надо принимать осознанно.

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

— Проверка не того. Ревьюер судит стиль и форму, пропуская соответствие контракту и инварианты. Защита — давать ревьюеру явные критерии приёмки, а не абстрактное «оцени качество».

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

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

— Блокировка пропускной способности. Слишком строгий ревьюер с окончательным вердиктом превращается в узкое место конвейера (см. главу 57); слишком мягкий — пропускает дефекты. Калибровка строгости — отдельная инженерная задача.

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

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