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

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

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

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

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

Слой реализации — то, как роль добивается своего контракта: текст системного промпта, разбиение на под-шаги, эвристики, примеры в few-shot. Реализацию можно переписать целиком, сохранив контракт неизменным, — и наоборот, мелкая правка промпта может незаметно сдвинуть контракт.

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

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

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

Из теории интерфейсов приходит привычное деление. Обратная совместимость (backward) — новая версия роли принимает всё, что принимала старая, и её выход по-прежнему годен для существующих потребителей. Прямая совместимость (forward) — старые потребители переживают выход новой версии, даже если он содержит то, чего они не понимают (например, новые поля, которые они игнорируют). В рое нужны обе: оркестратор может оказаться старее воркеров, а воркеры — старее друг друга.

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

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

Класс изменения | Что меняется | Пример | Риск для соседей

Совместимое расширение | В контракт добавляется необязательное | Новое опциональное поле в выходе; новый инструмент, не меняющий выход | Низкий, если потребители игнорируют незнакомое

Совместимое улучшение реализации | Меняется только реализация | Переписан промпт, контракт прежний | Низкий по контракту, ненулевой поведенческий

Ломающее изменение контракта | Меняется обязательная часть границы | Переименовано/удалено поле; ужесточён инвариант входа; изменён формат | Высокий: старые потребители ломаются

Сужение прав | Убирается инструмент или разрешение | Роль лишается доступа к записи | Средний: ломается реализация, молча зависевшая от инструмента

Поведенческий сдвиг | Контракт тот же, распределение поведения иное | Смена носителя; правка тона; иной уровень детальности | Скрытый: проверки проходят, качество падает

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

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

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

Не все роли требуют одинаковой строгости версионного режима. Чувствительность роли к изменению определяется тем, сколько потребителей и насколько тесно завязано на её выход. Из каталога канонических ролей (см. главу 19) видно расслоение.

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

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

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

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

Шов оркестратор–воркер. Оркестратор и воркеры обновляют разными релизами и в разное время. Возникают обе перекошенные ситуации: новый оркестратор поверх старых воркеров и старый оркестратор поверх новых. Каждая требует своей совместимости — прямой и обратной соответственно.