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

Из различия семейств следует конкретный антипаттерн: использовать протокол одного семейства для задач другого. Два направления ошибки симметричны.

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

Использование A2A-протокола для доступа к простому детерминированному инструменту. Обратная ошибка дешевле, но тоже вредна: оборачивать вызов детерминированной функции в тяжёлый протокол делегирования с машиной состояний, объявлением компетенций и переговорами — значит платить координационный налог (см. главу 5) без отдачи. Простой стык к инструменту не нуждается в богатой диалоговой машине; навязанная сложность увеличивает поверхность отказа без выгоды.

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

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

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

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

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

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

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

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

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

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

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

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

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

Ложная совместимость («оба поддерживают стандарт X»). Самый частый и самый дорогой режим. Две реализации заявляют поддержку одного стандарта, проходят проверку соответствия на нижних уровнях (транспорт, синтаксис) и расходятся на верхних (семантика, диалоговая машина). Одна сторона трактует «частично выполнено» как годный результат, другая — как ошибку; одна допускает отмену задачи в работе, другая не реализует это состояние. Структурно сообщения валидны, протокольно — несовместимы. Защита — не доверять заявлению о поддержке стандарта, а проверять поведенческую интероперабельность на репрезентативных сценариях (аналог контрактных тестов из главы 18, поднятый на уровень протокола).

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

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

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