Agent Cards: как агенты договариваются друг с другом

В апреле 2025 года Google представил протокол Agent2Agent (A2A) — способ для ИИ-агентов от разных вендоров находить друг друга и обмениваться задачами. Ключевой элемент протокола — Agent Card: JSON-файл, который агент публикует по стандартному адресу и в котором описывает, что он умеет, как к нему обращаться и какая авторизация нужна. К проекту заявили о поддержке более 50 партнёров, среди них Atlassian, Salesforce, SAP и MongoDB. Позже Google передал спецификацию A2A в Linux Foundation, чтобы протокол развивался как нейтральный открытый стандарт.

Идея простая: если один агент бронирует переговорку, а другой ведёт календарь, им нужен общий язык, чтобы договориться без человека-посредника. Agent Card — это визитка, по которой первый агент понимает, к кому вообще стоит обращаться.

Что такое Agent Card на самом деле

Agent Card — это структурированный документ (по спецификации A2A он отдаётся в формате JSON). Внутри перечислены имя агента, описание, версия, endpoint для обращения, поддерживаемые способы аутентификации и список навыков (skills) — по сути, каталог того, что агент готов делать.

По задумке карточка публикуется по предсказуемому адресу вида /.well-known/agent-card.json на домене сервиса. Другой агент или оркестратор запрашивает этот файл, читает список навыков и решает, стоит ли делегировать задачу. Дальше идёт уже сам обмен сообщениями по A2A: задача ставится, агент-исполнитель возвращает результат или промежуточные статусы.

Пока у агентов нет общего способа сказать «вот что я умею и вот как со мной говорить», любая мультиагентная система — это набор ручных интеграций, которые ломаются при каждом обновлении.

Открытый реестр — это следующий шаг

Одна карточка описывает одного агента. Реестр — это каталог, где такие карточки собраны и доступны для поиска. Логика та же, что у реестров пакетов вроде npm или PyPI: вместо того чтобы вручную прописывать адрес каждого агента, оркестратор обращается к реестру и находит подходящего исполнителя по нужному навыку.

На момент выхода материала единого общепризнанного публичного реестра агентов уровня npm ещё не сложилось — это направление на ранней стадии. Спецификация A2A описывает механику карточек и обмена, но вопрос, кто и как будет вести доверенные реестры, проверять подлинность карточек и модерировать их, во многом остаётся открытым.

A2A против MCP: это не конкуренты

Здесь часто возникает путаница. MCP^* (Model Context Protocol) от Anthropic и A2A от Google решают разные задачи, и сами компании это подчёркивают.

Проще говоря, MCP отвечает на вопрос «как модель дотянется до инструмента», а A2A — «как один агент найдёт и попросит другого». Их можно использовать вместе: агент внутри себя ходит в инструменты через MCP, а с внешними агентами общается через A2A.

Кому это пригодится, а кому нет

Технология адресована в первую очередь тем, кто строит системы из нескольких агентов, а не одного чат-бота.

• Пригодится: командам, которые собирают внутренние оркестраторы задач — например, агент-координатор раздаёт подзадачи агентам по кадрам, финансам и логистике внутри одной компании.
• Пригодится: вендорам SaaS, которые хотят, чтобы их продукт умел выступать исполнителем в чужих агентных сценариях без ручной интеграции под каждого клиента.
• Пригодится: платформам-маркетплейсам агентов, где сторонние разработчики публикуют своих агентов, а пользователи их подключают.
• Скорее нет: тем, у кого один ассистент с парой инструментов — здесь достаточно прямых вызовов API или MCP, а накладные расходы на межагентный протокол не окупятся.
• Скорее нет: проектам, где все агенты живут внутри одного фреймворка и уже общаются его штатными средствами.

Что вызывает вопросы

Открытые реестры и машиночитаемые визитки удобны, но с ними приходит и цена вопроса. Первое — доверие: если агент публикует карточку с навыками, кто гарантирует, что он делает именно то, что заявил, и не сливает данные. Второе — безопасность: endpoint агента становится точкой входа, которую нужно защищать так же серьёзно, как обычный API. Третье — фрагментация: пока стандартов несколько (A2A, MCP, форматы отдельных фреймворков), совместимость приходится проверять руками.

Спецификация A2A предусматривает описание схем аутентификации прямо в карточке, но выбор конкретного механизма и его настройка остаются на стороне разработчика.

Что делать сейчас

1. Определитесь, есть ли у вас вообще мультиагентный сценарий — если агент один, протокол между агентами не нужен.
2. Разведите ответственность: доступ к инструментам — это про MCP, общение между агентами — про A2A.
3. Прочитайте актуальную спецификацию A2A в репозитории Linux Foundation, а не пересказы: формат карточки и адреса well-known уточняются по мере развития стандарта.
4. Заложите аутентификацию и логирование обращений к вашему агенту с самого начала, а не после первого инцидента.

^* MCP (Model Context Protocol) — открытый протокол Anthropic, стандартизирующий, как языковая модель обращается к внешним инструментам, файлам и источникам данных через единый интерфейс.