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

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

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

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

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

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

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

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

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

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

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

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

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

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

— Проверка совместимости с прошлым — новая версия читает представительную выборку артефактов, записанных предыдущими версиями; старая версия читает то, что записала новая (тест откатываемости).

Эти гейты прямо отражают четыре шва. Каждый закрывает свой шов; пропуск любого оставляет открытым соответствующий класс тихих отказов.

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

Наблюдаемость (см. часть XI) без версионной маркировки слепа: при разборе многоагентного инцидента первый вопрос — какие версии каких ролей участвовали и что менялось перед сбоем; без версии в трассах и артефактах на него нет ответа. Координация (см. часть VI) на версиях завязана через контракты: согласование изменений предполагает, что стороны говорят на совместимых версиях контрактов, иначе конфликт возникает не из-за расхождения по существу, а из-за рассогласования версий. Безопасность (см. часть XII) — потому что версия роли включает права: расширение прав в новой версии увеличивает поверхность атаки, а несоответствие фактической версии заявленной открывает путь к подмене (потребитель верит метаданным о версии-авторе — значит, эти метаданные должны быть достоверны, а не только присутствовать). Динамическое назначение ролей (см. главу 21) добавляет измерение: если роли назначаются на лету, версионируется не только каждая роль, но и правило назначения — изменение логики выбора роли есть изменение поведения системы и подчиняется той же дисциплине.

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

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

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

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

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

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

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