Что выпустили A2A Extensions 9 сентября? Механизм расширений AI Agent и JSON-протокол (2026)

Кратко перед чтением

Аспект	Пояснение
Официальный релиз	2025-09-09 Google Developers Blog «A2A Extensions: Empowering Custom Agent Functionality»
Главный результат	Необязательные расширения протокола с URI: новые данные, ограничения, RPC, автоматы состояний
Носитель JSON	capabilities.extensions[] в Agent Card
Согласование	HTTP-заголовок A2A-Extensions, по умолчанию выключен
Роль в 2026	A2A отвечает за интероперабельность агентов; Extensions — за предметную настройку; это не замена MCP или Function Calling

Что выпустили 9 сентября?

A2A (Agent2Agent) уже описывает, как агенты находят друг друга, отправляют задачи и потоково возвращают результат. Ядро протокола обязано оставаться общим — голосовая задержка, сквозная трассировка или рукопожатие нулевого доверия в него не входят. 9 сентября 2025 года инженеры Google в официальном блоге дали ответ: Extensions.

В тот день появился не один новый RPC, а целый открытый механизм расширений:

• Любой может определить, опубликовать и реализовать расширение, помеченное уникальным URI (лучше с номером версии, например https://example.com/ext/my-extension/v1).
• Агент в Agent Card (JSON с описанием возможностей) объявляет, какие расширения он поддерживает.
• Клиент по необходимости активирует их HTTP-заголовком на одном запросе; клиент без такого объявления остаётся на ядре протокола и не ломается.
• Одновременно вышел вводный пример: проставить метку времени в metadata у Message и Artifact.

К 2026 году правило записано в тематическом разделе A2A Extensions; появилась рамка управления (официальные расширения используют префикс https://a2a-protocol.org/extensions/). Ниже разбираем механизм по JSON-протоколу.

Протокол A2A и JSON Agent Card

Agent Card — машиночитаемая визитка агента: имя, описание, входной URL, MIME входа и выхода, список навыков и capabilities. Extensions висят на capabilities, а не в отдельном файле.

Карточка с расширением выглядит примерно так (структура из официального примера, имена полей — по действующей спецификации):

{
  "name": "Magic 8-ball",
  "description": "An agent that can tell your future... maybe.",
  "version": "0.1.0",
  "url": "https://example.com/agents/eightball",
  "capabilities": {
    "streaming": true,
    "extensions": [
      {
        "uri": "https://example.com/ext/konami-code/v1",
        "description": "Provide cheat codes to unlock new fortunes",
        "required": false,
        "params": {
          "hints": [
            "When your sims need extra cash fast"
          ]
        }
      }
    ]
  },
  "defaultInputModes": ["text/plain"],
  "defaultOutputModes": ["text/plain"],
  "skills": [
    {
      "id": "fortune",
      "name": "Fortune teller",
      "description": "Seek advice from the mystical magic 8-ball",
      "tags": ["mystical"]
    }
  ]
}

Отлаживая этот JSON, сначала проверьте скобки и запятые в форматировщике JSONSort, затем сверьте со схемой, не пропущены ли поля в extensions[]. Agent Card публикуется в сети — секреты в params класть нельзя.

Механизм расширений: объявить, по умолчанию выключить, активировать на запрос

Extensions задуманы так, чтобы расширять A2A, не разрывая ядро стандарта. Спецификация проводит несколько границ:

1. По умолчанию не активно. Клиент, который не знает расширение, по-прежнему вызывает методы ядра и получает базовое поведение.
2. Клиент включает расширение явно. В HTTP-запросе есть A2A-Extensions, значение — список URI через запятую.
3. Агент игнорирует неподдерживаемые URI и в заголовке ответа повторяет фактически включённые расширения.
4. required: true — жёсткая зависимость. Если клиент не активировал расширение или не соблюдает его, агент должен отклонить запрос. Расширения только для показа данных required не ставят.

Расширение может зависеть от других (обязательно или по желанию). Спецификация требует описать зависимости в документе расширения; при активации клиент передаёт и URI зависимостей. Номер версии входит в URI: несовместимое изменение требует нового URI. Агент не вправе тихо откатиться на другую версию.

Поля JSON AgentExtension

Спецификация проводит красную черту, чтобы расширения не ломали проверку типов ядра: не добавляйте и не снимайте обязательные поля у уже определённых структур — свои свойства кладите в существующую карту metadata; не добавляйте значения в перечисления, дополнительную семантику тоже пишите в metadata. Эти два правила напрямую задают вид JSON.

Согласование запроса: HTTP-заголовок и сообщение JSON-RPC

Активация действует на каждый HTTP-запрос, а не «подключились — и навсегда». Типичный запрос (в духе официального вводного примера):

POST /agents/eightball HTTP/1.1
Host: example.com
Content-Type: application/json
A2A-Extensions: https://example.com/ext/konami-code/v1

{
  "jsonrpc": "2.0",
  "method": "SendMessage",
  "id": "1",
  "params": {
    "message": {
      "messageId": "1",
      "role": "ROLE_USER",
      "parts": [{"text": "Oh magic 8-ball, will it rain today?"}]
    },
    "metadata": {
      "https://example.com/ext/konami-code/v1/code": "motherlode"
    }
  }
}

Ответ должен повторить успешно активированное расширение:

HTTP/1.1 200 OK
Content-Type: application/json
A2A-Extensions: https://example.com/ext/konami-code/v1

{
  "jsonrpc": "2.0",
  "id": "1",
  "result": {
    "message": {
      "messageId": "2",
      "role": "ROLE_AGENT",
      "parts": [{"text": "That's a bingo!"}]
    }
  }
}

Ключ в params.metadata — это URI расширения плюс суффикс пути, а не произвольно короткое имя. Так несколько расширений одновременно кладут данные в один JSON-RPC, не сталкиваясь именами. Если расширение «не сработало», сначала проверьте, есть ли URI в заголовке запроса, затем сравните JSON запроса и ответа — JSON Diff удобен, чтобы сопоставить metadata до и после активации.

Четыре типа расширений: данные, Profile, методы, автомат состояний

Спецификация нарочно широко формулирует «что умеет расширение». Предсказуемые к 2026 году применения укладываются в четыре типа:

• Данные (Data-only): только дополнительные структурированные сведения в Agent Card, без изменения потока запрос–ответ. Например, поля соответствия GDPR. Такой тип не помечают required: true.
• Profile: более жёсткие структурные или статусные ограничения поверх сообщений ядра — словно профиль над A2A. Например, все parts должны быть DataPart по заданной схеме; или при TaskStatus.state === "working" через metadata["generating-image"] показать подсостояние.
• Методы (Extended Skills): RPC вне ядра. Расширение task-history добавляет tasks/search и даёт агенту навык «искать исторические задачи».
• Автомат состояний: новые состояния или переходы в автомате задач. Здесь красную черту проще всего переступить: новую семантику кладут в metadata, а не в перечисление ядра.

Кейсы, названные в день публикации

Блог Google не ограничился абстракцией: там перечислили уже работающие расширения, чтобы было видно, какой JSON они несут.

Traceability (прослеживаемость): центральное сообщение — ResponseTrace, структурированный журнал вне основного протокола, где фиксируются шаги агента. Каждый Step — либо ToolInvocation (вызов инструмента или API), либо AgentInvocation (вызов другого агента). Шаги могут быть вложенными: если нижестоящий агент тоже поддерживает расширение, его trace вешается на шаг выше и складывается в дерево вызовов от края до края. Это критично для оценки совместной работы нескольких агентов и поиска ошибок — и при этом не должно жить в ядре A2A.

Twilio Latency Extension: голосовому агенту (ConversationRelay) нужно объявлять задержку, чтобы выбрать подходящую нижестоящую модель или корректно деградировать. Задержка — не поле ядра Agent Card; Twilio дополняет её расширением. Это типичный пример того, что предметные данные не должны засорять ядро протокола.

Identity Machines: расширение для рукопожатия нулевого доверия между агентами. Перед делегированием задачи фильтр политик проверяет цель, бюджет, возможности, модель, статус PII и другие свои условия. JSON здесь несёт контекст политики, а не текст чата.

В статье также упомянуто направление ERC-8004 Ethereum: ончейн-реестры личности, репутации и проверки как слой доверия между организациями. Это не обязательно выходит в виде A2A Extension, но показывает то же разделение — ядро протокола отвечает на «как говорить», расширения и внешние стандарты — на «почему доверять».

Как это соотносится с MCP и Function Calling?

Все три дают JSON, но на разных уровнях; в 2026 году их не стоит подменять друг другом:

Обычная архитектура слоями: MCP-сервер даёт инструменты → хост проецирует их в Function Calling модели → несколько агентов раздают задачи через A2A и Extensions несут трассировку, задержку и личность между агентами. Сравнение JSON первых двух слоёв — в предыдущей статье MCP Tool Schema vs Function Calling.

Ограничить данные расширения через JSON Schema

В спецификации расширения стоит как минимум описать: список URI, схему params, дополнительные структуры между клиентом и агентом, новые потоки запрос–ответ. На практике:

• Вести отдельную JSON Schema для AgentExtension.params и для ключей metadata.
• В CI проверять примерные полезные нагрузки; считать Agent Card публичным контрактом API.
• Любой ввод, связанный с расширением, считать недоверенным: сначала разобрать, потом проверить.

Как писать JSON Schema — в полном учебнике JSON Schema на этом сайте. Локальное форматирование, проверка синтаксиса и Diff версий — в JSONSort, без загрузки карточки с политикой или личностью на чужой сайт.

Частые ошибки

• Считать Extension правом «добавить любое поле». Структуру ядра не меняют; новые данные идут в metadata.
• Ставить required на расширение типа «данные». Так без нужды отсекают массу клиентов.
• URI без версии. При несовместимом изменении некуда отступить, согласование ломается.
• При несовпадении версий откатываться на старую реализацию. Спецификация требует игнорировать такую активацию, а не тихо «быть совместимым».
• Обходить существующую аутентификацию новым RPC. Методы расширения проходят ту же проверку подлинности и прав, что и методы ядра.
• Смешивать со списком инструментов MCP. MCP отвечает на «какие есть инструменты»; A2A Extension — на «как двум агентам говорить по правилам предметной области».

Частые вопросы (FAQ)

A2A Extensions вышли 9 сентября 2026 года?

Дата официального поста — 9 сентября 2025. В 2026 году по этой дате по-прежнему ищут «что выпустили»; сам механизм уже в действующей спецификации A2A, плюс управление и примеры расширений (Traceability, Timestamp, Secure Passport и другие).

Нужно ли реализовывать расширения, чтобы пользоваться A2A?

Нет. Расширения по умолчанию выключены. Только если чужая Agent Card помечает расширение как required, его нужно активировать и соблюдать по спецификации.

Куда класть JSON расширения — в тело сообщения или в HTTP-заголовок?

Список активации — в заголовке A2A-Extensions; предметные данные расширения — в JSON-RPC params.metadata (или в другом месте, указанном спецификацией). Заголовок согласует, JSON несёт нагрузку.

Как отладить Agent Card и metadata расширения?

Локально отформатируйте карточку в JSONSort, проверьте схему и сравните две версии массива extensions. JSON с личностью или политикой не вставляйте в онлайн-инструменты.

Выводы

9 сентября вышла не ещё одна закрытая API вендора, а открытый слой расширений A2A: возможности именуют URI, объявляют в JSON Agent Card, активируют на запрос через A2A-Extensions, предметные данные несут в metadata. Собирая систему из нескольких агентов в 2026 году: диалог ядра — через A2A, поставка инструментов — через MCP, намерение модели — через Function Calling, вертикальные нужды — через Extensions. У каждого слоя своя зона, JSON Schema — единственный источник правды для параметров и данных расширения.

Дальше по теме

• Google: пост о выпуске A2A Extensions Оригинал и кейсы от 2025-09-09
• Тематический раздел спецификации A2A Extensions Объявление, активация, управление и ограничения
• MCP Tool Schema vs Function Calling Сравнение JSON на слое инструментов
• Локальный набор JSON-инструментов JSONSort Форматирование, проверка синтаксиса, Diff

Журнал изменений: 2026-08-28 первая публикация