Почему агенты не договариваются: где ломается Agent-to-Agent Protocol
Пока агентов два, связка держится на договорённостях внутри инструкций. Как только в цепочке пять-семь участников, ломается не модель, а обмен: каждый уверен, что передал задачу корректно, а следующий видит уже другую формулировку. Часть условий — ограничения, сроки, идентификаторы сущностей — теряется при пересказе, и ошибка всплывает через два-три шага.
Второе узкое место — несогласованный обмен задачами. Если ответ не пришёл вовремя, вызывающий агент отправляет задачу повторно, а исполнитель не отличает повтор от новой работы и выполняет её дважды. Так появляются дубли: две записи, два письма, двойное подтверждение — при полной уверенности обеих сторон, что они сделали ровно то, что просили.
Третье — потеря контекста между агентами. Результат возвращается в ветку диалога, которая уже закрыта или переиспользована под другую задачу, и ответ оседает «в никуда». Вызывающая сторона не получает ни результата, ни ошибки: агент просто ждёт, а сбой в цепочке агентов выявляется по косвенным признакам — зависшей очереди или пустому отчёту.
Отсюда зависшие цепочки: без явных подтверждений и предельного времени ожидания никто не знает, работает исполнитель или уже упал. Чем длиннее связка, тем дороже диагностика — состояния задач живут в разных журналах, и восстановить причину постфактум почти невозможно.
Agent-to-Agent Protocol закрывает именно этот слой: у каждого агента появляется объявленная роль и контракт сообщения, задача получает идентификатор и состояние, ответ — подтверждение доставки. Разбираем, из чего складывается интеграция AI-агентов, которая не рассыпается на третьем шаге.
Что даёт управляемое взаимодействие агентов в рабочем контуре
В управляемом контуре агент не вызывает другого агента напрямую — он регистрирует в реестре агентов карточку с описанием умений, форматов входа и выхода и границ ответственности. Диспетчеризация задач сопоставляет карточку с конкретным запросом и маршрутизирует вызов, поэтому связи между участниками становятся данными, а не жёстко зашитым кодом.
Практический эффект виден на подключении нового агента: регистрация карточки и прогон по контрольному набору задач занимают часы вместо недель переписывания интеграций, а на каждой стыковке высвобождаются дни работы инженеров. Доля задач, доходящих до конца без ручного вмешательства, растёт с ~70% до 95% — за счёт повторов с сохранением промежуточного состояния и явных проверок результата на каждом шаге.
Отдельно закрывается восстановление после сбоя агента: незавершённый шаг возвращается в очередь вместе с контекстом и повторяется на резервном исполнителе, а не начинается с нуля. Диспетчер при этом сам является единой точкой отказа, поэтому его разворачивают в нескольких экземплярах, а состояние задачи держат в общем журнале, доступном каждому узлу.
Такой контур описывает открытая спецификация Agent-to-Agent, развитие которой курирует Linux Foundation: заказчик не привязывается к одному поставщику агентов и меняет исполнителя, не перестраивая оркестрацию целиком.
Режимы работы Agent-to-Agent Protocol и их ограничения
Режим обмена в Agent-to-Agent Protocol — не вкусовой выбор, а решение о том, какие отказы вы получите первыми и насколько дёшево их диагностировать. Прямой вызов агента даёт минимальную задержку, но жёстко связывает участников: недоступность одного останавливает всю цепочку.
Асинхронные схемы снимают связность, зато переносят сложность в другое место. Шина событий требует идемпотентных обработчиков и дедупликации — иначе повторы и потерянные задачи. Централизованный оркестратор держит маршруты в одном узле: отладка проще, но это и единая точка отказа. У федерации нет посредника, зато согласование схем и прав доступа расходится по командам.
Четыре режима обмена
| Режим | Когда подходит | Ограничения |
|---|---|---|
| Прямой вызов агента | Синхронный сценарий, 2-3 участника | Жёсткая связность, нет истории обмена |
| Шина событий | Много независимых агентов, длинные задачи | Нужны дедупликация и подтверждения, порядок не гарантирован |
| Централизованный оркестратор | Регламент, аудит, права по шагам | Единая точка отказа, потолок по нагрузке |
| Федерация агентов | Кросс-доменные сценарии, разные владельцы | Согласование схем и доверия, распределённая диагностика |
На практике режимы комбинируют: федерация на периметре, оркестратор внутри контура, шина — для длинных задач. Мы начинаем с матрицы совместимости: какие агенты уже есть, какие версии а2а-протокола и форматы описаний они поддерживают, что происходит при недоступности соседа. Опишите задачу — вернёмся с оценкой и планом.
Этапы внедрения: от аудита схемы до передачи в эксплуатацию
Порядок работ фиксируем до старта: каждый этап заканчивается артефактом, который заказчик видит и может проверить. Это убирает главную причину срывов — интеграцию, которую собирают сразу в рабочем контуре и потом месяцами отлаживают.
- Аудит агентной схемы. Разбираем существующих агентов, их зоны ответственности и текущие способы обмена. На выходе — карта: кто к кому обращается, какие данные передаёт и где сейчас теряется контекст.
- Проектирование обмена. Фиксируем структуры сообщений, правила идентификации задач и поведение при недоступности соседа. Обмен строим на Agent-to-Agent Protocol — открытом стандарте, поэтому схему не придётся переписывать при смене моделей или поставщиков.
- Настройка маршрутизации и прав. Определяем, кто кому может делегировать задачу, какие вызовы запрещены и на каких лимитах агент останавливается сам, не вытягивая ресурсы у остальных.
- Сборка в тестовом контуре. Соединяем агентов на копии реальных данных и прогоняем штатные и аварийные сценарии: обрывы связи, дубли, повторную доставку.
- Приёмка интеграции под нагрузкой. Смотрим, как схема держится на пиковом потоке и что происходит при отказе одного узла. Критерии измеримые: доля успешных обменов, время ответа, доля задач, дошедших до результата.
- Передача в эксплуатацию. Отдаём регламенты, схемы маршрутов, панели мониторинга и порядок разбора инцидентов. Команда заказчика меняет маршруты и добавляет агентов без нас.
Артефакты проекта: реестр агентов, схемы и политики доступа
Проект по интеграции агентов заканчивается не показом сценария, а набором артефактов в вашем репозитории. Мы передаём не «работающий сервис как есть», а конфигурации, схемы и регламенты, по которым ваша команда сама меняет связи между агентами и права доступа — без нас и без пересборки интеграции по Agent-to-Agent Protocol. Ниже — перечень того, что физически остаётся у заказчика.
- Реестр агентов: назначение, владелец, входные и выходные форматы сообщений, ограничения по нагрузке, версия карточки.
- Схема взаимодействия агентов: кто с кем общается, какие вызовы синхронные, где стоят очереди, таймауты и точки отказа.
- Политики доступа агентов: матрица «агент — ресурс — действие», срок жизни учётных данных, порядок отзыва прав при выводе агента.
- Регламент эскалации: какие классы задач агент не берёт, кому передаёт диалог и по какому признаку понимает, что нужен человек.
- Конфигурации: параметры запуска, лимиты, повторные попытки, правила маршрутизации запросов между моделями.
- Документация по агентам: как подключить нового агента, изменить политику и прогнать контрольные примеры перед выкатом.
- Передача знаний: пакет онбординга для команды, разбор спорных сценариев, совместная правка регламентов.
Всё это версионируется вместе с кодом: при следующем изменении видно, какая политика или схема к нему привела. Если хотите сверить состав таких артефактов со своей задачей — опишите её, вернёмся с оценкой и планом.
Кейс: цепочка из семи агентов — метрики до и после
Цепочка из семи агентов — сбор, нормализация, извлечение, валидация, обогащение, маршрутизация, отчётность — работала на самописных связках, где выход одного этапа передавался следующему прямым вызовом. Обрыв в середине разрушал весь контур: контекст терялся, часть данных обрабатывалась повторно, инженер вручную перезапускал этапы и сверял состояние. Перевели взаимодействие на Agent2Agent — открытую спецификацию обмена, где каждый агент публикует карточку своих возможностей, а задача живёт как объект с идентификатором и статусом.
Что изменили
Каждый переход получил идемпотентность и ограниченное число повторов, состояние задачи фиксируется на каждом шаге, а трассировка по идентификатору показывает, где именно встала цепочка. Агент, выпавший из строя, подменяется резервным без остановки остальных шести — очередь продолжает двигаться.
| Метрика | До | После |
|---|---|---|
| Время восстановления цепочки | 40–60 минут ручной пересборки | 3–5 минут автоматического повтора |
| Доля успешных задач | 71% | 96% |
| Ручные доработки | около 15 в неделю | 2 в неделю |
| Класс отказов | потеря контекста при обрыве середины | устранён |
Через месяц эксплуатации цепочка перестала требовать постоянного присмотра: семь агентов стали управляемым контуром с наблюдаемым состоянием, а не набором вызовов, где любой сбой означает ручной разбор.
Что делать, если агенты уже развёрнуты в разных контурах
Если агенты уже работают в разных контурах, переписывать их не нужно. Соединение делается снаружи — через посредника между контурами, который держит исходящее соединение с закрытой средой. Внутренняя логика агента остаётся нетронутой: меняется только то, как он получает задачи и отдаёт результат.
Подключение существующего агента начинается с описания его возможностей: какие задачи решает, что принимает на вход, что возвращает и когда отказывает. Описание попадает в каталог — по нему посредник понимает, кому адресовать вызов. Сам агент получает лёгкую обвязку-адаптер, которая переводит его внутренний формат в общий формат Agent-to-Agent обмена и обратно.
Закрытый контур наружу не открывается: соединение всегда инициирует внутренняя сторона, входящие порты остаются закрытыми, а посредник лишь маршрутизирует уже установленный поток. Каждый вызов подписан и привязан к конкретному агенту и навыку, права выдаются не на контур целиком, а на отдельные операции. Журнал обмена фиксирует, кто запросил действие, что вернулось и сколько это заняло.
Если контур недоступен, посредник ставит вызовы в очередь и повторяет их, а вызывающая сторона получает понятный отказ вместо зависания — деградирует отдельный навык, а не вся цепочка. Так агенты из разных сред начинают обмениваться задачами без переписывания и без расширения периметра.
Частые технические сомнения перед интеграцией агентов
Агенты уже работают по отдельности, и перед объединением в общую цепочку у инженерных команд возникают одни и те же вопросы: кто чем управляет, что происходит при отказе узла и как восстановить ход задачи. Обмен и карточки агентов задаёт открытая спецификация Agent2Agent — ниже короткие ответы по эксплуатации.
Как разграничиваются права агентов?
Каждый агент публикует карточку с объявленными навыками, а вызывает других не от своего имени, а от отдельной сервисной учётной записи с узким набором областей доступа. Прав инициатора запроса агент не наследует: компрометация одного узла не открывает доступ ко всей цепочке.
Что будет, если агент в цепочке недоступен?
Вызов идёт с таймаутом и повторными попытками по нарастающей паузе, при этом задача не теряется — она остаётся в очереди с сохранённым состоянием. Дальше цепочка уходит на резервный маршрут либо останавливается на последнем успешном шаге.
Как понять, на каком шаге сломалась цепочка?
Каждый вызов получает идентификатор задачи, а журнал фиксирует, кто вызвал агента, какой навык сработал и какой артефакт вернулся. По идентификатору поднимается вся история, включая промежуточные сообщения, — сбой локализуется за минуты, без сверки логов разных сервисов вручную.
Можно ли оставить обмен в закрытом контуре и переиспользовать существующих агентов?
Да: обмен разворачиваем внутри периметра, наружу трафик не уходит, доступы выдаются внутри вашей службы каталогов. Уже внедрённые агенты подключаются через адаптер и публикуют карточку — дальше они используются новыми сценариями без переписывания.
Обсудим задачу и вернёмся с оценкой и планом работ
Чтобы вернуться с оценкой интеграции и планом этапов, нам достаточно нескольких вводных от вас. Чем точнее описан сценарий, тем меньше допущений в оценке и тем раньше мы называем срок и состав работ. Присылать готовое техническое задание не нужно — хватит описания процесса и ограничений.
- Какие системы и сервисы должны обмениваться данными и кто в них отвечает за изменения.
- Роли агентов: что каждый решает самостоятельно, а что требует подтверждения человека.
- Формат обмена между сторонами и требования совместимости с уже работающими интеграциями.
- Ограничения по доступам: какие данные нельзя выводить за периметр, какие журналы обязательны.
- Нештатные ситуации: поведение при недоступности агента, конфликте ответов, повторной доставке запроса.
- Режим нагрузки: пиковые периоды, доля ручных операций, допустимая задержка ответа.
- Кто со стороны заказчика принимает результат и по каким критериям считает задачу закрытой.
На созвоне мы уточняем границы ответственности агентов, схему согласования действий, требования к журналированию и откату. Затем собираем тестовый контур на ваших сценариях: несколько агентов и замена одного из них без остановки остальных. По результатам даём оценку сроков, поэтапный план и точки приёмки — вы видите, что и в каком порядке проверяете.
Опишите задачу в свободной форме — вернёмся с оценкой и планом работ.
