Google Agent Registry 2026: что такое Agent Card и как A2A-агент описывает возможности, tools и skills в JSON

Каталог, а не третий протокол

Agent Registry звучит так, будто Google придумал ещё один разговорный протокол. Нет. A2A по-прежнему говорит, как агент описывает себя и как принимает Task. Registry — каталог обнаруживаемых компонентов в Google Cloud: уже существующие агенты становятся ресурсами, которые можно искать. После регистрации оркестраторы, Gemini Enterprise и Agent Gateway в том же проекте находят их по ключевым словам навыков. Протокол всё ещё A2A. Меняется тот, кто помнит карточку за вас. Без каталога URL зашиты в конфиг оркестратора — это записная книжка 2025-го, не обнаружение 2026-го.

Регистрация бывает автоматической и ручной. Agent Runtime того же проекта, GKE с меткой AI-агента и аннотацией карточки, Cloud Run с функциональным типом и собственные агенты Google Workspace / Gemini могут попасть в каталог сами. Авторегистрация смотрит только этот проект. Кросс-проект, on-prem или рантаймы без автообнаружения требуют рукописный Service, из него получается read-only Agent. Центральный governance-проект, которому нужно видеть агентов в spoke, идёт ручной кросс-проектной регистрацией, а не магическим сканом всей орг. Страница Register agents обновлена 2026-09-22.

Тот же каталог принимает MCP-серверы. Файл называется toolspec.json, формой как ответ tools/list, потолок тоже 10 КБ. Поэтому в Registry рядом лежат боковые коллеги и руки вниз. Не пишите один общий валидатор на оба типа записей. Как hop вызова проверяет аргументы — в MCP и JSON Schema. Сегодня только о том, как каталог их запоминает.

Agent Card: исходный JSON, который индексируют

Agent Card — цифровая визитка A2A-сервера. Путь в спецификации по-прежнему /.well-known/agent-card.json — см. что нового в A2A v1.0. Для A2A-совместимой записи Registry забирает карточку и индексирует skills для поиска по словам. Сама карточка должна пройти официальную схему A2A. Форма 1.0 кладёт транспорты в supportedInterfaces, у каждого url, protocolBinding и protocolVersion. Верхнеуровневые url и protocolVersion — контракт 0.3. Клиент 1.0 не должен читать их как главные поля.

Человеческая идентичность — name, description и version: версия самого агента, не протокола. Версия протокола едет с интерфейсом. У каждого элемента skills[] нужны id, name, description; Registry ищет по tags. examples — подсказки людям, не схема аргументов. Полная таблица полей — следующая статья. Сегодня: без валидной карточки автоизвлечение типа A2A не случится. Больше 10 КБ — Registry отвергает файл, оркестратор вас не найдёт.

Ниже карточка 1.0, которую можно класть в репозиторий. Сначала parse, потом официальная схема. Залить весь runbook в description — первым ударитесь о потолок. Поверхность открытия — короткий текст плюс tags, а не справочник, втиснутый в визитку.

{
  "name": "Invoice Specialist",
  "description": "Finds and summarizes invoices for finance. Does not post payments.",
  "version": "1.2.0",
  "supportedInterfaces": [
    {
      "url": "https://agents.example.com/invoice/a2a",
      "protocolBinding": "JSONRPC",
      "protocolVersion": "1.0"
    }
  ],
  "capabilities": {
    "streaming": true,
    "pushNotifications": true,
    "extendedAgentCard": false
  },
  "defaultInputModes": ["text/plain"],
  "defaultOutputModes": ["text/plain"],
  "skills": [
    {
      "id": "search-invoices",
      "name": "Search invoices",
      "description": "Look up invoices by week, status, or counterparty.",
      "tags": ["invoices", "finance", "search"],
      "examples": ["Find overdue invoices for last week"]
    }
  ]
}

После регистрации: как выглядит запись каталога

Спека не заставляет Google выгружать локальный «снимок каталога». Ревью всё равно нужно видеть, что проиндексировали. Сложите результат в фикстуру: displayName, specType (A2A_AGENT_CARD или NO_SPEC), cardVersion, извлечённые id навыков, interfaces, searchKeywords. Этот снимок не экземпляр схемы A2A — не валидируйте его схемой карточки. Это CI-утверждение: зарегистрирован не значит находимый.

{
  "registry": "google-cloud-agent-registry",
  "displayName": "Invoice Specialist",
  "specType": "A2A_AGENT_CARD",
  "cardVersion": "1.0",
  "skillsIndexed": ["search-invoices"],
  "searchKeywords": ["invoices", "finance", "search"],
  "interfaces": [
    {
      "url": "https://agents.example.com/invoice/a2a",
      "protocolBinding": "JSONRPC"
    }
  ]
}

Автоизвлечение бывает только у A2A-совместимых записей. Registry спрашивает /.well-known/agent-card.json и пишет заявленные навыки в каталог. REST-эндпоинт NO_SPEC попадает в каталог без навыков для поиска — оркестраторы видят, что агент есть, и не матчат «коллегу, который ищет счета». Чтобы вас находили, добавьте карточку или зарегистрируйте отдельные ресурсы навыков. Gemini Enterprise умеет регистрировать самостоятельные skills как верхнеуровневые ресурсы Skill. Это другая линия управления. Не смешивайте её в один файл с skills[] карточки.

Снимок и закоммиченную карточку положите рядом в diff. Ключевые слова не сходятся: забыли tags или индекс отстаёт. URL не сходятся: зарегистрировали старый эндпоинт. Карточка валидна, а skillsIndexed пуст: проверьте, не читал ли Registry карточку 0.3 правилами 1.0 — без supportedInterfaces извлечение молча худеет, а в тикете всё равно «не нашли».

skills на карточке — не MCP tools и не Plugin-навыки

Одно слово, три слоя. Skill на карточке — то, что агент заявляет уметь, для поиска в каталоге и выбора оркестратором. MCP tool — детерминированный вызов, контракт — inputSchema. SKILL.md Plugin / Agent Skills — бриф для модели того же агента. Registry индексирует первое. Скопировать имя MCP-инструмента в Card.skills[].id — поиск иногда попадёт; делегирование всё равно смотрит на непрозрачного агента, не на tools/call. Многоходовые уточнения и асинхронные колбэки рвут форму вызова функции.

Некоторые реализации карточки вешают inputSchema на skill. Это намёк на форму, не контракт исполнения MCP. Не валидируйте карточку через plugin.schema.json и не валидируйте tools/call карточкой. Три JSON говорят «возможность»; обработка отказа разная. Сломанная карточка — отказ обнаружения. Сломанный inputSchema — отказ вызова. Как один coding-агент растит навыки и руки — в практике Plugin Manifest. Сегодня только о том, как другой агент запоминается каталогом.

У записи NO_SPEC такого заявления нет. В каталоге она похожа на строку адресной книги с hostname. Оркестраторы не найдут её по ключевому слову, пока вы не зарегистрируете отдельные skills или не добавите карточку. Сначала решите, нужно ли быть найденными, потом — говорить ли на A2A. Пустая карточка «для каталога» индексирует пустой массив навыков — хуже, чем не регистрироваться.

0.3 и 1.0: два контракта не мешать

Registry принимает и 0.3, и 1.0; новые карточки должны быть 1.0. Версия 1.0 унесла версию протокола и основной URL в supportedInterfaces; extendedAgentCard сидит под capabilities; stateTransitionHistory из 0.3 больше не ядерная возможность. Смешать два набора полей — клиенты читают разные половины, индекс каталога теряет половину. Собственный breaking-список A2A — на странице изменений v1.0, не в частном форке Google.

В ревью оставьте минимум две карточки: легальную 1.0 выше и негатив, где url наверху, а регистрация как 1.0. Вторая должна провалить валидацию 1.0 или основной эндпоинт проигнорируют. Если CI сваливает обе схемы в одну «общую проверку агента», вы грязнее клиента. Registry выбирает правила по заявленной версии и не ходит за схемой при загрузке — та же дисциплина, что у Plugin Manifest.

Подписи, расширенные карточки и GetExtendedAgentCard — слой безопасности после auth, не въезд в каталог. Публичная карточка сначала должна отдать навыки; потом оркестратор решает, тянуть ли аутентифицированную вторую копию. Подписи сегодня за скобками. Сначала сделайте tags находимыми.

Фикстуры в JSONVue

Минимум три фикстуры ревью: карточка 1.0 выше, снимок каталога и смешанный негатив 0.3/1.0. Первая проходит схему A2A 1.0. Вторая — ваша схема снимка или assert на skillsIndexed и tags. Третья должна упасть. Скопировать закрытые поля Plugin в карточку или залить всю таблицу MCP inputSchema в skills[] видно сразу в diff.

Добавьте MCP-контраст: легальный toolspec.json, чтобы показать второй исходный файл каталога. Схему карточки на него не гоняйте. tools[].name — для рантайма; skills[].tags — для поиска. Секретов в закоммиченной фикстуре быть не должно. Карточка — публичная визитка: пишите так, будто её заберут.

В браузере:Форматтер JSON — парсятся ли карточка и снимок;Валидатор JSON Schema — проверить 1.0 supportedInterfaces и skills;JSON Diff — поймать дрейф tags / URL между закоммиченной карточкой и снимком. Данные не уходят с машины. Дальше:A2A vs MCP, проверка MCP и Plugin Manifest.

Рядом: A2A vs MCP, MCP и JSON Schema, практика Plugin Manifest.

FAQ

Итог и следующие шаги

В 2026 Google Agent Registry складывается в одну фразу: это каталог; карточка — индексируемый исходный JSON. Оркестраторы ищут tags и имена навыков, не топологию на слайдах.

Порядок поставки: легальная карточка 1.0; при регистрации смотреть specType; в снимке утвердить, что навыки реально легли; для MCP отдельный toolspec.json. Три контракта проверьте в JSONVue. Слои — статья A2A vs MCP. Поля — следующая. Прогулка — та, что после.