a2a-protocol

A2A Protocol — навык для создания Agent-to-Agent серверов и клиентов, которые обмениваются задачами между агентами разных фреймворков. Он описывает не вызов отдельного инструмента, а взаимодействие самостоятельных агентов: discovery, согласование возможностей, передача сообщений, длительное выполнение и возврат артефактов. В основе workflow лежит Agent Card — JSON-метаданные по стандартному адресу /.well-known/agent.json. Card описывает identity, endpoint, capabilities, skills и auth, чтобы другой агент мог понять, к кому он подключается и какие задачи этому endpoint можно делегировать. В модели протокола A2A Client инициирует запрос от имени пользователя или другого агента, а A2A Server принимает его и обрабатывает задачу. Task проходит жизненный цикл submitted, working, input-required, completed, failed, canceled или rejected. Message обозначает ход общения и содержит Parts: текст, файл или JSON. Artifact — созданный агентом результат, например документ, изображение или структурированное значение. Это полезное разделение позволяет отличать текущий статус работы от сообщения и от окончательного результата, а input-required оставляет место для human-in-the-loop вместо того, чтобы считать любую паузу ошибкой. Источник указывает несколько способов транспорта и SDK. Обмен может идти через JSON-RPC 2.0 по HTTP(S), streaming через Server-Sent Events, gRPC или асинхронные push notifications. Для Python описан a2a-sdk с базовой установкой и дополнительными вариантами для HTTP-сервера или gRPC; заявлена совместимость с Python 3.10+. Для Node.js используется пакет @a2a-js/sdk и Node.js 18+. В экосистеме также упомянуты Go и Java SDK. Версии нужно закреплять явно: источник предупреждает, что протокол развивается и на момент его написания указывает v0.3.0, поэтому пример нельзя воспринимать как вечный контракт без сверки с актуальным SDK. Базовый сервер публикует Agent Card, принимает контекст запроса и помещает события статуса в очередь. Python-пример отделяет AgentExecutor, RequestContext и EventQueue, а при завершении передаёт completed-событие с сообщением агента. Клиент может получить другой Agent Card по URL, отправить SendMessageRequest и разобрать статус. Для задач, которые занимают больше нескольких секунд, рекомендуется streaming; для работы, которая может длиться минуты или часы, нужны push notifications. Долгие операции должны поддерживать cancellation. Эти правила важны не только для удобства интерфейса: без явного состояния working или input-required клиент не понимает, ждать ли результат, запросить ли ввод или остановить задачу. Навык показывает два способа orchestration. В последовательном pipeline один агент исследует, второй пишет, третий проверяет; результат первого явно передаётся следующему. В fan-out несколько агентов могут параллельно анализировать рынок, код или обратную связь, после чего orchestrator собирает результаты. Для примеров из предметной области это означает, что каждый агент должен иметь узкий capability domain и понятную Agent Card, иначе downstream-агенты не смогут надёжно решить, кому делегировать запрос. A2A не следует смешивать с MCP. В таблице источника A2A предназначен для agent-to-agent collaboration, где участники могут вести stateful, долгие или асинхронные задачи. MCP описывает agent-to-tool связь для вызова конкретного инструмента или источника данных, часто как stateless function call внутри одного агента. Поэтому внешний research-agent, code-review pipeline или customer-support router относятся к A2A, а подключение одной модели к базе данных или функции — к MCP. Это различие помогает не строить сложный протокол там, где достаточно обычного tool call. Для production-совместимого Agent Card нужны описательные skills, объявленные input/output modes и схема authentication; auth следует реализовать на endpoint и отразить в Card. Structured JSON Parts удобны для машинного обмена между агентами, а text Parts — для человекочитаемого сообщения. Состояние input-required нельзя игнорировать, потому что в нём агент ожидает человеческое решение или дополнительные данные. Рекомендуется держать одного агента в одной области, объявлять discovery endpoint, проверять lifecycle-события и отдельно тестировать streaming, cancellation и push-путь. Сам навык даёт архитектурные и SDK-примеры, но не делает endpoint защищённым автоматически, не выбирает бизнес-границы агента и не отменяет проверку версии SDK, auth и реальной сетевой доступности.