Ранас Мукминов – Оркестрация ИИ-агентов. Claude Opus 4.7 (страница 93)
Чем богаче диалоговая машина, тем выше выразительность протокола и тем выше стоимость его корректной реализации обеими сторонами. Это тот же компромисс между мощностью и хрупкостью, что и везде в книге: протокол с одним состоянием (запрос-ответ) тривиально интероперабелен, но не выражает долгих задач; протокол с богатой машиной состояний выражает многое, но создаёт много способов разойтись в её трактовке.
Зачем вообще нужны протоколы как стандарты, а не как двусторонние договорённости — видно из простого подсчёта. Пусть в системе $N$ типов агентов, и каждый может потребоваться состыковать с каждым. Без общего протокола каждая пара стыкуется индивидуально: своя семантика, своя диалоговая машина, свой способ узнать возможности. Число пар растёт как $N^2$. Если к этому добавить $M$ типов внешних ресурсов и инструментов, к которым агентам нужен доступ, число интеграций «агент-ресурс» растёт как $N \times M$: каждый агент учится говорить с каждым ресурсом отдельно.
Это и есть классическая $N \times M$-проблема интеграции, известная задолго до агентов. Её стоимость не только в первоначальном написании $N \times M$ адаптеров, но и в их сопровождении: изменение одного ресурса требует правки во всех агентах, которые с ним работают; добавление одного агента требует написать его интеграцию с каждым нужным ресурсом заново. Координационный налог (см. главу 5) здесь растёт квадратично с размером системы.
Общий протокол сводит $N \times M$ к $N + M$: каждый агент реализует протокол один раз, каждый ресурс реализует протокол один раз, и любой агент работает с любым ресурсом без индивидуальной интеграции. Это и есть главная выгода стандартизации — превращение квадратичной стоимости в линейную. Именно эту выгоду преследуют протоколы доступа к инструментам и контексту: они стандартизируют стык «агент-ресурс», чтобы инструмент, реализованный однажды, был доступен любому совместимому агенту.
«Совместимы» — слишком грубое слово, и его огрубление само по себе источник отказов. Полезно различать уровни интероперабельности, потому что система может быть совместима на одном уровне и несовместима на следующем, создавая ложное впечатление готовности.
Уровень | Что согласовано | Что ещё может разойтись
Транспортная | Стороны могут установить связь и доставить байты | Всё остальное
Синтаксическая | Сообщения парсятся, схема валидна | Смысл полей, последовательности
Семантическая | Стороны одинаково понимают смысл сообщений | Грамматика обмена, состояния
Поведенческая | Диалоговые машины совместимы, переходы согласованы | Качество исполнения, соблюдение содержательных постусловий
Организационная | Согласованы права, ответственность, политика на стыке | —
Подъём по этой лестнице — это рост глубины согласования. Транспортная интероперабельность достигается легко и проверяется тривиально (связь есть). Синтаксическая проверяется валидатором схемы. Семантическая уже не проверяется автоматически — она требует, чтобы обе стороны вкладывали один смысл в одинаковую структуру, а это нельзя установить парсером. Поведенческая требует совместимости диалоговых машин. Организационная — это уже не свойство протокола, а свойство соглашения между владельцами агентов: кто отвечает за вред, кто платит за ресурс, чьи права действуют на стыке.
Практический вывод: стандарт протокола обычно гарантирует интероперабельность до синтаксического, иногда до семантического уровня, и почти никогда — до поведенческого и организационного. Две реализации одного стандарта могут пройти проверку соответствия на нижних уровнях и разойтись на верхних. Это центральная причина, по которой «оба поддерживают протокол X» не означает «они будут работать вместе» — и об этом подробнее в разделе о failure modes.
Существует устойчивая путаница: межагентные протоколы воспринимают как единый класс и спрашивают, какой из них «победит». На деле это два разных семейства, решающих разные задачи на разных уровнях, и в зрелой системе они сосуществуют, а не конкурируют. Различить их — необходимое условие трезвого проектирования.
Первое семейство стандартизирует стык между агентом и ресурсом: инструментом, источником данных, внешней системой. Условно назовём их MCP-подобными — по архитектурной роли стандартизированного протокола доступа к контексту и инструментам, получившего распространение в этот период.
Архитектурно это асимметричный протокол клиент-сервер. Агент (точнее, его контур — предмет другой книги) выступает клиентом: он обнаруживает доступные инструменты и ресурсы, узнаёт их сигнатуры, вызывает их и получает результат. Ресурс выступает сервером: он объявляет, что умеет, и исполняет вызовы. Стороны неравноправны по роли: одна потребляет возможности, другая предоставляет.
Что стандартизирует такой протокол:
— Обнаружение возможностей. Клиент узнаёт у сервера список доступных инструментов и ресурсов, их описания и сигнатуры, без предварительного знания. Это снимает необходимость зашивать знание об инструментах в агента.
— Сигнатуру вызова. Как описывается инструмент (его имя, параметры, схема результата) так, чтобы агент мог сформировать корректный вызов, не будучи написанным под конкретный инструмент.
— Семантику результата. Как возвращается результат, как кодируется ошибка, как отличается «инструмент отработал и вернул отрицательный результат» от «инструмент недоступен».
— Доступ к контексту и ресурсам. Не только вызов действий, но и получение данных: чтение источников, на которые агент должен опираться.
Ключевое свойство этого семейства — оно решает $N \times M$-проблему для пары «агент-ресурс». Инструмент, реализованный как совместимый сервер, становится доступен любому совместимому агенту без отдельной интеграции. Именно это делает такие протоколы ценными: они превращают инструменты в переиспользуемые компоненты с единым стыком.
Важная оговорка о границах: этот класс протоколов стандартизирует доступ агента к ресурсу, а не делегирование работы другому агенту. Сервер в такой модели — это пассивный поставщик возможностей, а не автономный исполнитель с собственными целями, состоянием и недетерминизмом. Когда «сервером» оказывается обёртка вокруг другого агента, протокол доступа к инструментам начинает использоваться не по назначению — для межагентного делегирования, — и его асимметричная клиент-серверная модель плохо ложится на симметричное взаимодействие двух автономных исполнителей. Это естественный мост ко второму семейству.
Второе семейство стандартизирует стык между двумя агентами как автономными исполнителями. Условно назовём их A2A-подобными.
Архитектурно это симметричный (или способный быть симметричным) протокол: обе стороны — автономные агенты, каждый со своими целями, состоянием, недетерминизмом и возможностью отказать. Один агент делегирует задачу другому не как вызов инструмента, а как поручение независимому исполнителю, который сам решит, как его выполнять, может вести долгую работу, присылать промежуточные результаты, запрашивать уточнения и честно отказываться (частичный контракт, см. главу 18).
Что стандартизирует такой протокол сверх первого семейства:
— Делегирование задачи, а не вызов функции. Единица обмена — задача с целью и контекстом, а не вызов с фиксированными аргументами. Исполнитель имеет свободу в том, как достичь цели.
— Долгие взаимодействия с состоянием. Задача может выполняться долго; протокол поддерживает приём, промежуточные обновления, финальный результат, отмену — то есть богатую диалоговую машину, которой у вызова инструмента нет.
— Объявление о себе как об агенте. Агент публикует не список функций, а описание своих компетенций, ролей и контракта (что он умеет делать как исполнитель), чтобы другие агенты могли решить, кому делегировать.
— Согласование на равных. Поскольку обе стороны автономны, протокол должен поддерживать переговоры: уточнение задачи, отказ, встречное предложение, эскалацию.
Различие между семействами удобно свести в таблицу — оно определяет, какой класс протокола уместен на данном стыке.
Свойство | Протокол доступа к инструментам (MCP-подобный) | Протокол агент-агент (A2A-подобный)
Что на другом конце | Пассивный ресурс, инструмент, источник | Автономный агент-исполнитель
Симметрия ролей | Асимметричный (клиент-сервер) | Симметричный (агент-агент)
Единица обмена | Вызов с аргументами | Задача с целью и контекстом
Недетерминизм другой стороны | Низкий (инструмент детерминирован) | Высокий (исполнитель недетерминирован)
Диалоговая машина | Обычно запрос-ответ | Богатая, с состоянием и долгой работой
Что объявляет другая сторона | Список инструментов и сигнатур | Компетенции, роли, контракт исполнителя
Право отказать | Обычно нет (инструмент исполняет) | Есть (исполнитель автономен)
Главная решаемая проблема | $N \times M$ доступа к ресурсам | Интероперабельность делегирования между агентами
Эти два семейства не конкурируют — они дополняют друг друга и образуют разные уровни одной системы. Внутри роя агенты делегируют друг другу задачи по A2A-подобному протоколу; каждый отдельный агент, выполняя свою задачу, обращается к инструментам и ресурсам по MCP-подобному протоколу. Один стандартизирует горизонтальный стык (агент-агент), другой — вертикальный (агент-ресурс). Зрелая система использует оба, и вопрос «какой протокол выбрать» в большинстве случаев неверно поставлен: выбирать нужно класс протокола под класс стыка, а не один протокол на всё.