Суть
Когда MCP стандартизировал «агент ↔ инструмент», осталась незакрытой следующая проблема — «агент ↔ агент» (разные команды, разные фреймворки, разные вендоры). A2A даёт общий язык: как агенту объявить свои способности, как поставить другому задачу и получить результат.
Как работает
- Agent Card — JSON-объект, которым агент публикует свои возможности, аутентификацию, типы контента, endpoints. Размещается по стандартному пути
/.well-known/agent.json— обнаружение предсказуемо, по аналогии сrobots.txt. Клиент черезA2ACardResolverнаходит подходящего удалённого агента. - Task — центральная единица работы со своим жизненным циклом:
submitted → working → input-required → completed / failed / canceled. Запускается черезtasks/sendилиtasks/sendSubscribe. - Message / Part / Artifact — сообщения (role: user/agent) состоят из частей; результат успешной задачи возвращается как Artifact (файлы, структурированные данные).
- Транспорт: HTTP (базовый запрос/ответ), JSON-RPC 2.0 (структурированные вызовы методов), SSE (Server-Sent Events — стриминг статусов длинных задач без поллинга:
TaskStatusUpdateEvent/TaskArtifactUpdateEvent).
A2A на MCP. Отдельная инженерная идея (статья kts.tech): сам MCP можно дотянуть до межагентного взаимодействия, если у MCP-инструментов есть streaming, resumability (EventStore), durability и многошаговость — тогда «инструмент» становится полноценным агентом. То есть граница MCP/A2A на практике размывается.
Связано с
- Multi Agent Systems — A2A как протокольный слой координации команды
- MCP — «агент ↔ инструмент»; A2A — «агент ↔ агент» (дополняют друг друга)
- MAS Frameworks — фреймворки могут говорить между собой через A2A
Открытые вопросы
- насколько A2A примут вендоры на практике (или останется «ещё один стандарт»)
- где проходит реальная граница A2A vs «MCP с агентными расширениями»