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

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

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

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

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

— Вырождение в похвалу. Без устойчивой состязательной установки критик подтверждает решение вместо его атаки. Это сводит на нет смысл роли.

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

— Состязательность без меры. Перекалиброванный критик отвергает всё, делая прогресс невозможным; рой не сходится (см. главу 66). Критика должна иметь порог существенности.

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

— Игнорируемый по построению. Если выход критика никуда не подаётся и ни на что не влияет, роль создаёт стоимость без пользы — частый результат добавления критика «для галочки».

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

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

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

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

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

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

— Слабое покрытие. Тестировщик проверяет очевидные случаи и пропускает граничные и нетипичные — те самые, на которых рой ломается. «Зелёный» отчёт при слабом покрытии опаснее красного, потому что создаёт ложную уверенность.

— Тест под результат. Если тестировщик и исполнитель — одна модель или делят контекст, тесты подгоняются под уже полученный артефакт и подтверждают его вместо независимой проверки. Разделение и независимость критичны.

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

— Хрупкие проверки. Тесты ложно падают или ложно проходят из-за недетерминизма среды, а не свойств артефакта; рой реагирует на шум. Стабильность проверок — отдельная инженерная забота.

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

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

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

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

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

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

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

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

— Неверная классификация. Маршрутизатор относит задачу не к тому типу и направляет не туда; задача попадает к роли без нужных возможностей или прав. Защита — явная и проверяемая схема классификации и поведение по умолчанию для неоднозначных случаев.

— Перекос нагрузки и голодание. Маршрутизатор систематически грузит одних исполнителей и обходит других; часть работы голодает в очереди (см. главу 33 и главу 35). Нужны учёт загрузки и справедливость.