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

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

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

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

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

— Валидация на входе потребителя — граница недоверия (zero trust), а не дублирование валидации на выходе: производитель защищает форму, потребитель защищает от опасного и несогласованного. Текстовые поля нагрузки, попадающие в контекст получателя-модели, — вектор инъекции; от него защищает изоляция данных от инструкций, а не схема.

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

Глава 26. Протоколы агент-агент (A2A) и стандартизация

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

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

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

Терминология здесь требует осторожности. Конкретные стандарты межагентного взаимодействия в 2026 году находятся в активном развитии, их версии и детали меняются, и привязка изложения к точным номерам версий или формулировкам спецификаций сделала бы текст недостоверным. Поэтому глава говорит о классах протоколов и их архитектурных свойствах, а конкретные стандарты упоминает как иллюстрации этих классов, а не как нормативные источники. «MCP-подобный» и «A2A-подобный» здесь — обозначения архитектурных ролей, а не конкретных спецификаций.

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

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

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

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

Слой | Что фиксирует | Пример вопроса, на который отвечает | Где разобрано подробно

Транспорт | Физический канал доставки | Блокирующий вызов или поток событий | Глава 24

Кадрирование | Границы сообщений в потоке | Где кончается одно сообщение и начинается следующее | Глава 25

Формат и схема | Структура одного сообщения | Какие поля и типы у запроса | Глава 25

Семантика сообщений | Смысл полей и типов сообщений | Что значит поле «статус: частично» | Эта глава

Диалоговая машина | Допустимые последовательности и состояния обмена | Можно ли отменить уже начатую задачу | Эта глава

Согласование возможностей | Как стороны узнают, что умеет собеседник | Поддерживает ли вторая сторона потоковый вывод | Эта глава

Согласование версий | Как стороны выбирают общую версию правил | По каким правилам говорить, если версии разные | Эта глава, глава 22

Идентичность и доверие | Кто собеседник и можно ли ему верить | Тот ли это агент, за которого себя выдаёт | Эта глава, часть XII

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

Два верхних слоя над форматом заслуживают отдельного внимания, потому что именно их чаще всего недопроектируют.

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

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