Протоколы агентов: A2A, ACP и AP2
Открытые стандарты, делающие агентов любого вендора совместимыми
Проблема: У вас есть research-агент от Google, аналитический агент собственной разработки и агент-отчётчик от стартапа. Каждый говорит на своём диалекте API, поэтому соединить их — значит писать кастомный клей для каждой пары: N агентов требуют N² адаптеров, а смена формата одним вендором ломает всё. И ни один из них не может заплатить другому за услугу.
Решение: Открытые протоколы: A2A, ACP и AP2
По мере роста мультиагентных систем и маркетплейсов агентов агенты от разных вендоров должны обнаруживать друг друга, общаться и даже проводить транзакции. Три открытых протокола стандартизируют это, делая агентов plug-and-play:
- A2A (Agent-to-Agent) — обнаружение capabilities через agent cards плюс жизненный цикл задачи для делегирования. Начат Google, запущен с 50+ партнёрами (апрель 2025), передан в Linux Foundation и растёт с тех пор.
- ACP (Agent Communication Protocol) — открытая спецификация коммуникации агентов от IBM, стандартный слой обмена сообщениями для диалога между агентами. Сейчас она со-управляется под Linux Foundation наряду с A2A — они взаимодействуют, а не заменяют друг друга.
- AP2 (Agent Payments Protocol) — формирующийся черновой стандарт 2026 года для подписанных мандатов (mandates) и расчёта (settlement), чтобы агенты могли безопасно платить друг другу с проверяемыми лимитами.
Ключевое различие: MCP соединяет агента с его инструментами, тогда как A2A соединяет агента с агентами-партнёрами. Это дополняющие слои одного стека.
Представьте это как стандарты HTTP и email для интернета:
- 1. Обнаружение: Агент публикует agent card — JSON-документ с описанием того, кто он, какие навыки предлагает, его endpoint и как аутентифицироваться. Клиенты (или реестр) читают его, чтобы найти нужного агента.
- 2. Делегирование: Клиент-агент назначает задачу через жизненный цикл A2A: submitted → working → input-required → completed/failed. Обе стороны могут отслеживать прогресс в любой момент.
- 3. Коммуникация: Агенты обмениваются сообщениями по ACP — стандартному слою обмена сообщениями. Структурированные ходы переносят текст, структурированные данные и артефакты туда-обратно, пока задача не выполнена.
- 4. Транзакция: Когда задача требует оплаты, AP2 переносит подписанный мандат (разрешить трату до лимита) и выполняет расчёт, чтобы зафиксировать перевод — делая автономную агентскую коммерцию безопасной и проверяемой.
Обнаружение и делегирование дают A2A, диалог идёт по ACP, а деньги движутся через AP2 — всё стандартизировано, поэтому любые два агента совместимы из коробки.
Где используются протоколы агентов
- Мультивендорная оркестрация: Соберите workflow из research-агента Google, вашего аналитического агента и агента-отчётчика стартапа — без кастомного клея для каждой пары, потому что все трое говорят на A2A.
- Маркетплейсы агентов: Реестр agent cards превращается в «магазин приложений» для агентов: находите capabilities, сравнивайте и подключайте агента в свой пайплайн через стандартный интерфейс.
- Автономные покупки (агентская коммерция): С AP2 агент может купить услугу у другого агента в рамках подписанного мандата на трату — платёж авторизован, ограничен лимитом и проводится проверяемо.
- Частая ошибка: Считать A2A заменой MCP. MCP соединяет одного агента с его инструментами (базы данных, API); A2A соединяет агентов с агентами-партнёрами. Обычно нужны оба — на разных слоях.
Интересный факт: IBM создала свой Agent Communication Protocol (ACP) независимо — и вместо слияния с A2A он теперь со-управляется под Linux Foundation наряду с A2A, причём оба взаимодействуют. К годовщине A2A в апреле 2026 года MCP, A2A и ACP оказались под управлением Linux Foundation, а рядом формировался AP2 как черновой стандарт от коалиции платёжных организаций.
Попробуйте сами!
Исследуйте интерактивную визуализацию ниже: переключайтесь между вкладками A2A, ACP и AP2, чтобы увидеть форму каждого сообщения, затем запустите AP2-поток и проследите путь платёжного мандата от запроса до расчёта.
A2A: agent card объявляет capabilities, затем задача делегируется и выполняется.
{ "name": "ResearchAgent", "skills": ["web-search", "summarize"], "url": "/a2a", "auth": "OAuth2" }A2A находит и делегирует, ACP переносит диалог, AP2 двигает деньги. MCP при этом соединяет агента с инструментами — это разные слои, а не конкуренты. Вместе они делают агентов любого вендора plug-and-play.
Частые вопросы
В чём разница между A2A и MCP?
MCP соединяет одного агента с его инструментами — базами данных, API, файловыми системами — как USB для периферии. A2A соединяет агентов с другими агентами-партнёрами, позволяя им обнаруживать друг друга и делегировать задачи — как HTTP между веб-сервисами. Это дополняющие слои, а не конкуренты: агент использует MCP, чтобы дотянуться до своих инструментов, и A2A, чтобы сотрудничать с другими агентами.
Что AP2 добавляет к A2A?
A2A отвечает за обнаружение, делегирование и коммуникацию, но не переводит деньги. AP2 (Agent Payments Protocol) добавляет платёжный слой: криптографически подписанный мандат (mandate) разрешает агенту тратить до заданного лимита от имени пользователя, а шаг расчёта (settlement) фиксирует транзакцию. Именно AP2 делает автономную агентскую коммерцию — когда агенты покупают и продают — безопасной и проверяемой.
Зачем использовать открытые протоколы вместо кастомных интеграций агентов?
При ad-hoc интеграциях каждой паре агентов нужен свой адаптер, поэтому N агентов требуют N² коннекторов, и смена формата одним вендором ломает всё. Открытые протоколы вроде A2A, ACP и AP2 делают любых двух агентов совместимыми из коробки — как стандарты HTTP и email позволяют любому браузеру или почтовому клиенту общаться с любым сервером. A2A запущен с 50+ партнёрами (апрель 2025), теперь управляется Linux Foundation и вырос с тех пор.
Попробуй сам
Интерактивное демо этой техники
Соединить research-агента (вендор A) и аналитического агента (вендор B), чтобы они вместе сделали отчёт о рынке.
Готово: написан адаптер под точный формат запроса/ответа research-агента A (свои поля, своя авторизация по статическому токену, свой парсинг JSON). Аналитический агент жёстко завязан на этот формат.
Проблемы: 1) Через месяц вендор A поменял схему ответа — интеграция упала. 2) Появился ещё агент-отчётчик (вендор C) — пришлось писать ещё один адаптер с нуля. 3) Для 4 агентов уже нужно 6 кастомных коннекторов (N²/2), и каждый ломается независимо.
- Discovery: Аналитический агент читает agent card research-агента A по /.well-known/agent.json: skills=[web-search, summarize], endpoint, auth=OAuth2.
- Delegation: Шлёт A2A-задачу
tasks/send(«рынок AI-агентов 2026»). Состояния: submitted → working. - Communication (ACP): На шаге input-required research-агент уточняет диапазон лет; аналитик отвечает по ACP. Задача → working.
- Result: completed, возвращается artifact (данные о 15 вендорах).
Ключевое: когда вендор A меняет внутреннюю реализацию, agent card и A2A-контракт остаются прежними — интеграция не ломается. Добавить агента-отчётчика C — это +1 agent card, а не новый кастомный адаптер. Те же шаги работают с любым A2A-совместимым агентом.
Кастомная интеграция привязывает агента к чужому формату и ломается при каждом изменении; A2A с agent card делает агентов любого вендора совместимыми, а число коннекторов растёт линейно, а не как N².
Создайте бесплатный аккаунт для решения челленджей
3 челленджей с AI-проверкой для этого урока
Этот урок — часть структурированного курса по LLM.
Мой путь обучения