Протокол A2A (Agent2Agent) 2026: спецификация и безопасность

Официальная формулировка A2A о разделении ролей с MCP такова: «MCP вертикален и углубляет одного агента; A2A горизонтален и соединяет агентов через границы». В A2A вызываемая сторона — «непрозрачный» агент: он сам рассуждает и сам хранит состояние, вызывающая сторона не видит, какие модели или инструменты используются внутри, а взаимодействие идёт в несколько раундов только через жизненный цикл задачи (Task). A2A упоминается и в официальных документах Тайваня: в «Справочном руководстве по применению ИИ в государственном секторе» V1.0 Министерства цифровых дел Тайваня (дата предоставления, указанная в документе, — 115-01-28 по календарю Миньго) на странице 14 есть подраздел «A2A: протокол взаимодействия между ИИ-агентами», где поясняется, что он сосредоточен на коммуникации «Client — удалённая сторона».

Управление A2A прошло три этапа. 2025-06-23 Linux Foundation объявил о принятии проекта; учредителями стали AWS, Cisco, Google, Microsoft, Salesforce, SAP и ServiceNow; 2025-08-29 протокол ACP под руководством IBM был влит в A2A, а его разработка прекращена. Реальные полномочия принадлежат Техническому руководящему комитету (TSC) из 9 мест — по одному на компанию: Google, Microsoft, Cisco, AWS, Salesforce, ServiceNow, SAP, IBM, Bloomberg. Предложения голосуются через gitvote в GitHub issue с меткой TSC Review; например, #1942, объединивший 41 тему в восемь тем v1.1, был принят 2026-06-25: 5 голосов «за», 0 «против» (порог 51%).

В августе 2026 года A2A вошёл в Agentic AI Foundation (AAIF) как проект уровня Growth Stage, оказавшись в одном фонде с MCP. Даты вступления в разных источниках расходятся: блог AAIF и Axios указывают 2026-08-17, официальный блог A2A и страница спецификации — 2026-08-27, а публикация Forbes датирована 08-19. Возможно, 08-17 — дата объявления фонда, а 08-27 — дата публикации со стороны проекта, но ни один источник это объяснение не подтверждает; в статье приведены обе даты без выбора одной из них за читателя. Diginomica считает A2A пятым проектом под эгидой AAIF после MCP, goose, AGENTS.md и agentgateway; вторичные источники также подчёркивают, что речь идёт лишь об организационной перестройке и две спецификации не объединялись.

В документе об управлении A2A указано: «состав на стабильный период определяется через 18 месяцев после создания». Если считать с июня 2025 года, срок истекает примерно в декабре 2026 года, а в объявлении AAIF не сказано, будет ли TSC реорганизован. Это вывод: состав TSC может измениться в ближайшее время, и за этим стоит следить.

В A2A v1.0 переименованы все методы: message/send стал SendMessage, message/stream — SendStreamingMessage, tasks/resubscribe — SubscribeToTask, добавлен ListTasks. Пути REST переведены в стиль AIP, например POST /tasks/{id}:cancel, префикс /v1 убран. Формат HTTP-ошибок сменился с application/problem+json по RFC 9457 на google.rpc.Status; reason записывается заглавными буквами через подчёркивание (например, TASK_NOT_FOUND), а domain фиксирован как «a2a-protocol.org». В исследовательских заметках эта редакция расценивается как перевод A2A на стиль руководства по проектированию Google API; это вывод.

Самое разрушительное изменение модели данных — упрощение Part. Удалены TextPart, FilePart, DataPart и поле-дискриминатор kind; теперь один Part содержит только одно из полей text, raw (bytes), url или data, а тип определяется по наличию поля, а не по чтению kind; mimeType переименован в mediaType, file.fileWithUri — в url. По сообщениям сообщества, многие парсеры до сих пор читают part.kind, и это самая частая причина несовместимости 0.3 и 1.0. Agent Card теперь строится вокруг supportedInterfaces[]: каждый интерфейс несёт собственные url, protocolBinding, protocolVersion и необязательный tenant; клиент выбирает по порядку массива и SHOULD реализовать fallback.

У согласования версий есть малозаметное умолчание: пустой заголовок A2A-Version трактуется как 0.3. Клиент отправляет только Major.Minor, а сервер без поддержки возвращает −32009 VersionNotSupportedError; один агент может перечислить в supportedInterfaces интерфейсы с разными protocolVersion, чтобы 0.3 и 1.0 сосуществовали. Официальная миграция идёт в три этапа: сначала научиться разбирать оба формата, затем выдавать 1.0 и читать 0.3, наконец оставить только 1.0. Atlassian Forge и MuleSoft уже опубликовали руководства по миграции 0.3→1.0 — значит, ломающие изменения действительно кому-то стоят денег.

В семантике задач есть детали, которые обнаруживаются только при полном прочтении спецификации. taskId всегда генерирует сервер; если contextId передал клиент, агент может лишь принять или отклонить его, но не создать другой; при несоответствии taskId и contextId агент MUST отклонить запрос. Отправка сообщения в задачу, находящуюся в одном из четырёх конечных состояний — COMPLETED, FAILED, CANCELED, REJECTED, — вернёт UnsupportedOperationError; чтобы продолжить, нужно открыть новую задачу в том же context и связать её с исходной через referenceTaskIds. В конечном автомате есть два «прерывающих» состояния — TASK_STATE_INPUT_REQUIRED и TASK_STATE_AUTH_REQUIRED; блокирующий SendMessage при встрече с ними тоже возвращает управление.

Гарантии потоковой передачи и push-уведомлений слабее, чем многие думают. Флаг final в TaskStatusUpdateEvent в 1.0 удалён; конец потока теперь обозначается «закрытием соединения», поэтому обрыв посреди задачи и её завершение для клиента выглядят одинаково — различить их можно только повторным вызовом GetTask или SubscribeToTask; механизма возобновления по ID события в спецификации тоже нет, это вынесено в тему v1.1 #1986. Push-уведомление — это отправка StreamResponse методом HTTP POST на webhook клиента с Content-Type application/a2a+json; спецификация требует лишь, чтобы агент попытался отправить его хотя бы один раз, тайм-аут SHOULD составлять около 10–30 секунд, а получатель SHOULD обрабатывать уведомления идемпотентно и MUST сверять taskId. Иначе говоря, push — это «как минимум один раз, без гарантии порядка, payload без подписи»; это вывод из спецификации. Идемпотентность реализована лишь наполовину: SendMessage «может» устранять дубликаты по messageId, но не обязан.

По датам и количествам источники расходятся в двух местах. Дата выпуска v1.0: CHANGELOG указывает 2026-03-12, обзорная статья (arXiv:2507.10644 v4) — январь 2026 года, а пресс-релиз Linux Foundation к первой годовщине лишь называет v1.0 первой стабильной версией без даты; в статье используется CHANGELOG как первичный источник. Число SDK: Linux Foundation в 2026-04 говорит о 5 языках с готовностью «production-ready», официальное объявление A2A перечисляет 6 — Python, Go, Java, JS, .NET и Rust, — но подробно протестированный Rust SDK является общественным.

За последний год часто звучало: «В MCP добавили Tasks, значит, A2A больше не нужен», — но фактическое направление MCP версии 2026-07-28 противоположное. В версии MCP 2025-11-25 действительно появились экспериментальные Tasks (SEP-1686) для отслеживания долгих запросов, опроса и отложенного получения результатов, причём их состояния (working, input_required, completed, failed, cancelled) почти один к одному соответствуют A2A. Однако версия 2026-07-28 убрала session и рукопожатие initialize, сделав MCP протоколом без состояния (SEP-2567, SEP-2575), вынесла Tasks из ядра в официальное расширение io.modelcontextprotocol/tasks (SEP-2663), заменила запросы, инициируемые сервером, механизмом MRTR (InputRequiredResult плюс inputResponses, прикладываемые при повторной отправке) (SEP-2322) и пометила Sampling, Roots и Logging как deprecated (SEP-2577).

Смысл этих изменений в том, что мейнтейнеры MCP сознательно отказались от «агентного» пути, при котором сервер заимствует рассуждения LLM вызывающей стороны; это вывод. Если MCP-серверу нужно рассуждать самому, он должен иметь собственную модель — и тогда он по сути уже непрозрачный агент, лишь внешне похожий на инструмент. Task в MCP решает задачу «отложенного получения результата одного долгого вызова инструмента», а Task в A2A — «многораундового сотрудничества, в котором вопросы может задавать любая сторона», плюс обнаружение через Agent Card, объявление навыков и потоковая передача артефактов. Обратное направление тоже имеет сценарии неудачи: если детерминированные запросы вроде проверки цены или налоговой ставки насильно обернуть в жизненный цикл Task, Message и Artifact, вырастут задержки и стоимость реализации, а LLM вызывающей стороны не получит детальной schema инструмента; это тоже вывод. В исследовательских заметках не найдено реальных инцидентов вида «провал из-за использования MCP для связи агент–агент» или «провал из-за обёртывания инструмента в A2A».

Что касается внедрения, помимо числа topic на GitHub, несистематическое сравнение PyPI показывает около 10,9 млн загрузок SDK A2A и около 257 млн загрузок SDK MCP. По данным вторичных источников, эндпоинт UCP у Shopify использует MCP как транспортный уровень, то есть массовые торговые агенты подключаются через MCP. По облачным платформам: AWS AgentCore Runtime позволяет развернуть A2A-сервер (JSON-RPC, POST /, port 9000, OAuth 2.0 или SigV4); поддержка A2A в Microsoft Foundry вышла в public preview в июне 2026 года; Google Agent Registry читает well-known-карточки, но автоматическое обнаружение работает только в пределах одного проекта. Среди основных поставщиков моделей, изученных в исследовательских заметках, у Anthropic пока нет нативной поддержки A2A, а issue #104852, связанный с Claude Code, открыт лишь в конце октября 2026 года.

Практический выбор прост: если нужно, чтобы ИИ-ассистент вызывал ваши детерминированные функции (расчёт стоимости, проверка налоговой ставки, отслеживание отправления), используйте MCP; A2A нужен только тогда, когда два самостоятельно рассуждающих агента из разных организаций должны сотрудничать в несколько раундов. Публичный MCP HowBridge относится к первой категории; как его подключить, описано в руководстве по MCP для консолидированной доставки на нашем сайте.

Agent Card в A2A объявляет через securitySchemes одну из пяти схем аутентификации: API Key, HTTP Auth, OAuth2, OIDC, mTLS. В v1.0 убраны implicit flow и password flow OAuth, добавлен Device Code, а всем клиентам рекомендован PKCE. Спецификация требует, чтобы сервер «MUST authenticate every incoming request», но авторизация является implementation-specific, а учётные данные должны получаться по внеполосному (out-of-band) каналу; для перехода задачи в состояние AUTH_REQUIRED спецификация отдельно оговаривает: «Agents MUST NOT treat the state transition alone as authorization». Раздел 13 «Соображения безопасности» вовсе не упоминает prompt injection, делегирование или token exchange, OpenTelemetry, и в нём нет специальных требований к изоляции арендаторов. В обзоре Semgrep времён v0.3 отмечалось, что A2A «supports but does not enforce Agent Card signing», срок жизни и scope токенов протоколом не ограничены, а у одной задачи может быть несколько параллельных потоков, так что украденный токен сессии позволяет незаметно прослушивать поток жертвы.

Даже подписанная Agent Card пока не гарантирует проверку между разными SDK. Спецификация предписывает сначала канонизировать карточку по RFC 8785 (JCS) (без поля signatures), а затем формировать JWS; protected header MUST содержать alg и kid. В Issue #2122 (открыт 2026-08-10, по состоянию на 2026-10-31 не закрыт) зафиксированы расхождения на практике: a2a-python 1.1.2 и @a2a-js/sdk 1.0.1 дают разные канонические байты; Python экранирует не-ASCII-символы как \uXXXX, сортирует по code point, а не по единицам UTF-16, и выводит числа как 1e-06, тогда как ECMAScript выводит 0.000001; спецификация требует, чтобы поля REQUIRED присутствовали даже со значениями по умолчанию, но в proto3 нет понятия presence, поэтому description: "" и skills: [] отбрасываются; неоднозначен и typ. PR #2319 исправил примеры в спецификации, но вывод a2a-go всё равно отличается. Ещё одно ограничение: успешная проверка подписи доказывает лишь, что карточка не была изменена, но не подтверждает личность её издателя; сообщество также указывает, что в спецификации нет механизма привязки карточки к среде исполнения, фактически выполняющей вызов.

Некоторые атаки срабатывают даже при полном соответствии спецификации. A2ABreak (arXiv:2609.10871, v3 2026-10-24) с помощью LLM извлёк из спецификации на естественном языке 37 состояний, 76 переходов и 929 формальных утверждений и обнаружил 11 новых уязвимостей, все из которых «не требуют никаких дефектов реализации — ими может воспользоваться противник, соблюдающий спецификацию»: например, незащищённый context identifier позволяет внедрять context между клиентами, при многозвенном делегировании теряется идентичность, а агент может заявлять неподтверждённые возможности. Исследование коллизий имён (arXiv:2609.27624) показывает, что спецификация определяет name как «human-readable metadata, not as a stable identity» и не задаёт правил разрешения коллизий; из 7 открытых реализаций, изученных автором, 6 клиентских интеграций отправляли запросы на эндпоинт, контролируемый атакующим, и автор квалифицирует это как повторяющийся класс уязвимостей реализации, а не как общую уязвимость протокола. Подразделение Unit 42 компании Palo Alto Networks создало на Google ADK proof of concept атаки session smuggling: вредоносный агент с помощью «уточняющих вопросов» выведывает системные инструкции и вынуждает клиента вызвать buy_stock, без авторизации купив 10 акций; Unit 42 прямо указывает, что это не уязвимость протокола — затронут может быть любой многораундовый протокол с состоянием, — и эксплуатации в реальной среде не зафиксировано. Сообщество также сообщает, что вредоносный сервер может спрятать инструкции в полях description или skills Agent Card, и LLM хоста выполнит их как команды.

Эмпирические академические данные о межагентных атаках также подтверждают принцип «доверие между агентами нельзя предполагать по умолчанию». Triedman и соавт. (COLM 2025) показали, что вредоносное содержимое веб-страницы может перехватить поток управления мультиагентной системы; на примере GPT-4o выполнение произвольного кода удавалось в 58%–90% испытаний. Рецензируемый обзор Ferrag и соавт. в ICT Express (2026) систематизирует атаки от prompt injection до уровня протоколов, охватывая MCP и A2A.

Номера CVE в таблице ниже приведены в точности по исследовательским заметкам. В самих заметках отмечено, что номера необычны, а некоторые записи встречаются только в одной базе данных (например, у CVE-2026-90790 нет соответствующего GHSA в репозитории a2a-python, он есть только в OpenCVE). Запрос repo advisories для a2a-js, a2a-go и a2a-dotnet вернул пустой результат, но это может объясняться недостатком прав и не означает, что уязвимостей нет. Из таблицы можно извлечь три урока (далее — вывод): во-первых, Agent Card — это вход, контролируемый атакующим, вплоть до имён заголовков; во-вторых, спецификация лишь пишет «SHOULD проверять URL webhook», и SDK на двух языках получили SSRF; в-третьих, спецификация говорит, что «авторизацию определяет реализация», и самый популярный Java SDK по умолчанию авторизацию не выполнял, а исправление ещё и обходилось из-за особенностей платформы Android.

Проблема идентичности агентов за пределами A2A разделилась на три уровня. Первый — идентичность рабочей нагрузки, отвечающая на вопрос «что это за программа»: авторы draft-klrc-aiagent-auth представляют Amazon, Zscaler, Ping Identity, OpenAI и другие компании; черновик принят рабочей группой IETF WIMSE и заменён draft-ietf-wimse-aims, а подход состоит в применении существующих семейств WIMSE и OAuth 2.0 — «без изобретения нового протокола». Второй — авторизация и делегирование, отвечающие на вопрос «от чьего имени и что можно делать»: в примере Ping Identity весь путь делегирования записывается в act claim токена по RFC 8693, а следующий переход ограничивается через may_act; однако RFC 8693 изначально создавался для межсерверного обмена «после того, как согласие уже получено», и не охватывает нативно согласие пользователя на конкретного агента.

Третий уровень — внешне проверяемая идентичность, отвечающая на вопрос «как незнакомой стороне ему доверять». Cloudflare Web Bot Auth подписывает HTTP-запросы с помощью Ed25519 и RFC 9421, но Cloudflare пока не проверяет nonce, поэтому защита от повторного воспроизведения опирается в основном на короткий срок действия около 1 минуты; черновик ANS v2 проверяет домены через ACME и предусматривает три уровня: Bronze, Silver (плюс DANE) и Gold (плюс журнал прозрачности SCITT). A2A затрагивает на этом уровне лишь подпись карточки, и та необязательна. Коммерческие продукты появились раньше: Okta Agent SSO официально запущен 2026-08-24 и использует ID-JAG; Microsoft Entra Agent ID нативно не поддерживает ID-JAG, а дата его официального запуска в источниках различается (2026-04 или 2026-05). Поэтому при межкорпоративном A2A сторонам, скорее всего, придётся конвертировать токены на своих границах; это вывод.

На государственном уровне эту нишу тоже начинают заполнять. Центр CAISI при NIST (США) 2026-02-17 объявил AI Agent Standards Initiative с тремя опорами: отраслевые стандарты, открытые протоколы, развиваемые сообществом, и исследования безопасности и идентичности агентов; однако на странице инициативы используются лишь общие формулировки вроде «interoperable agent protocols», без упоминания A2A или MCP. Проект NIST NCCoE «Software and AI Agent Identity and Authorization» 2026-09-29 опубликовал сводку отзывов на концептуальный документ — откликнулись более 600 организаций и частных лиц. В блоге NIST от 2026-10-27 «Design Tenets for Agent Identity Management Systems» предложено 10 принципов проектирования, в том числе: у агента должна быть собственная идентичность, связанная с инициатором, а полномочия должны сужаться на каждом уровне делегирования; минимальные привилегии; кратковременная и отзываемая авторизация; вмешательство человека по риск-триггерам; подписанные мандаты, ограничивающие рамки действий; неизменяемые записи. Статус документа — запись в блоге, а не официальный стандарт.

Академические исследования движутся в том же направлении. South и соавт. предлагают расширить OAuth 2.0 / OIDC специализированными учётными данными агентов и строить проверяемые цепочки делегирования; позиционная версия той же работы включена в ICML 2025 Position Paper Track. Chan и соавт. (FAccT 2024) предлагают повышать видимость агентов с помощью трёх типов мер: идентификаторов агентов, мониторинга в реальном времени и журналов активности.

AP2 уже не тот, каким его запомнили в 2025 году. В v0.2.0 механизм переведён на Checkout Mandate и Payment Mandate, каждый из которых проходит две стадии — open и closed, реализован на SD-JWT, а open mandate хранит открытый ключ агента в cnf claim. Важное новшество — сценарий Human-Not-Present: пользователь сначала в доверенном интерфейсе подписывает open mandate своим ключом и задаёт ограничения, затем агент подписывает closed mandate ключом агента, и обе части связываются через sd_hash; продавец или поставщик учётных данных может вернуть unresolved_constraint и вернуть процесс в режим «человек присутствует». Спецификация также рекомендует продавцам при подписи Checkout JWT использовать недетерминированную подпись (ECDSA), а не Ed25519, чтобы защититься от атак с радужными таблицами. Самое главное: спецификация AP2 относит обработку споров, хранение и истребование доказательств к out of scope и обещает лишь неотрекаемый криптографический аудиторский след. В исследовательских заметках также отмечено, что спецификация AP2 рекомендует расширяться через extension points UCP, тогда как A2A в основном тексте спецификации даже не обсуждается; позиционирование AP2 смещается от «расширения A2A» к «уровню безопасности внутри торговых протоколов»; это вывод.

Платёжные расширения подключаются к A2A через собственный механизм extension: в AgentCapabilities объявляется AgentExtension (uri, description, required, params), а клиент запрашивает его активацию заголовком A2A-Extensions; расширения не могут менять базовые структуры данных или добавлять значения enum и работают только через metadata, ломающие изменения требуют нового URI, а при встрече с неподдерживаемой версией действует правило «MUST NOT fall back». a2a-x402 (spec v0.1) — именно такое расширение: продавец отправляет payment-required, клиент подписывает и отвечает payment-submitted, а продавец после расчёта в блокчейне отвечает payment-completed.

Число транзакций x402 в основном обеспечено накруткой. По данным Chainalysis, к первому кварталу 2026 года накопленное число транзакций x402 в сети Base превысило 100 млн, однако всплеск в четвёртом квартале 2025 года был «в основном вызван meme coin farming», а недельное удержание упало с 87% до 5%. Coinbase в конце апреля 2026 года заявила примерно о 165 млн транзакций и накопленном объёме около 50 млн долларов США — это заявление вендора; Artemis считает, что более 95% составляют сигналы протокола или тесты, а один сайт-трекер оценивает реальный торговый оборот примерно в 28 тыс. долларов США в день.

Карточные сети и платформы на практике действуют по принципу «принимать несколько протоколов, а строгую аутентификацию с участием человека использовать как предохранительный клапан». В марте 2026 года OpenAI вернула Instant Checkout в ChatGPT к модели Apps продавцов; по словам представителя компании, «Instant Checkout is moving to Apps». Visa 2026-07-02 объявила, что в Европе агенты уже совершили реальные покупки при участии более 30 банков-эмитентов, причём все транзакции использовали Payment Passkeys для выполнения требований строгой аутентификации клиента (SCA). Рамочная модель ответственности по-прежнему отсутствует: Chargebacks911 предупреждает, что инфраструктура споров и ответственности «largely unaddressed»; по анализу Taylor Wessing, в рамках ЕС покупка агентом, выходящая за установленные клиентом условия, в принципе будет признана несанкционированной операцией; Ant International, Visa и Mastercard лишь 2026-09-10 начали изучать рамочную модель совместимости Know-Your-Agent. PSD3 / PSR ЕС пока дошли только до позиции первого чтения, одобренной Советом 2026-10-29, в Official Journal не опубликованы, а поиск по ключевым словам в пояснительной записке Совета к PSR не выявил положений об ИИ или автономных агентах; у CFPB США также нет руководства по платежам агентов.

Научные работы указывают ещё на одну слепую зону. Debi и соавт. (IEEE IMNS 2026) провели red team-тестирование агентов для покупок на AP2: косвенная и прямая prompt injection позволяют манипулировать ранжированием товаров и извлекать конфиденциальные данные пользователя, то есть подписанный mandate не защищает процесс рассуждения, предшествующий подписи; Jiang и соавт. (arXiv:2609.00060) выполнили формальный анализ x402, MPP, ACP и AP2 в Tamarin и показали зависимости безопасности, возникающие из-за распределения намерения, полномочий делегирования и расчётов между несколькими сторонами. Агентизация в логистике сейчас идёт через MCP: MCP-сервер Flexport позволяет ИИ-ассистенту клиента бронировать перевозку по согласованным тарифам и получать booking ID. Примеров оплаты стоимости доставки через AP2 или x402 в исследовательских заметках не найдено.

В пресс-релизе Linux Foundation к первой годовщине от 2026-04-09 говорится о более чем 150 поддерживающих организациях и промышленных внедрениях A2A в цепочках поставок, финансах, страховании и ИТ-эксплуатации; это заявление вендора: пресс-релиз не называет ни одного пользователя и не приводит ни метрик процессов, ни результатов. Чаще всего в качестве примеров приводят статью о Microsoft Agent Framework для .NET и codelab Google о закупочном concierge — но это примеры кода, а не отчёты о внедрении. Tyson Foods часто подают как кейс A2A в цепочке поставок, однако apis.io оценивает её A2A Agent Card в 0/8, а для торговых партнёров компания по-прежнему предоставляет EDI и API.

Самое прямое опровержение — практические проверки. Один автор в апреле 2026 года выбрал из публичных реестров 50 агентов, заявляющих поддержку A2A: лишь примерно 0–2 отдавали валидную карточку по well-known-пути, а корректно ответили на task — 0. Тот же автор 2026-09-09 отправил 24 запроса в 12 организаций, а 2026-10-27 — 36 запросов в 18 организаций и оба раза получил 0 карточек. Выборка сформирована самим автором и не является сплошным обследованием, но тенденция последовательна. Реально работает взаимодействие внутри одной облачной платформы: AWS AgentCore, Microsoft Foundry, Google Agent Registry.

Эмпирические данные о самих мультиагентных архитектурах тоже не в пользу межорганизационного A2A. MAST (NeurIPS 2025 Datasets & Benchmarks Track) проанализировал 1 642 трассы выполнения и выделил 14 режимов отказа в трёх больших категориях: проектирование системы, рассогласование между агентами и проверка задач; доля отказов 7 передовых открытых мультиагентных систем в работе составила 41%–86,7% (авторы предупреждают, что разные бенчмарки напрямую не сравнимы). В работе «Towards a Science of Scaling Agent Systems» авторов из Google Research, MIT и других организаций в v1 / v2 и версии для блога Google протестировано 180 конфигураций: в независимых мультиагентных схемах ошибки усиливаются в 17,2 раза, в централизованно координируемых — в 4,4 раза, а на задачах последовательного рассуждения все мультиагентные варианты ухудшают результат на 39%–70%; в v3 от 2026-04-08 исследование расширено до 260 конфигураций и 6 бенчмарков с сохранением выводов о 17,2 и 4,4 раза. Инженерный блог Anthropic (не рецензируемая статья) сообщает, что его мультиагентная исследовательская система на 90,2% превосходит одиночного агента Claude Opus 4, но расходует примерно в 15 раз больше токенов, чем обычный диалог, и прямо называет неподходящими области, где «всем агентам нужен общий контекст или между агентами много зависимостей». Межорганизационный A2A как раз собирает все эти неблагоприятные условия: у сторон нет общего контекста, нет общего верификатора, а торговый процесс (проверка цены→заказ→оплата→отгрузка) последователен; это вывод.

Пробелов на инженерном уровне больше, чем на уровне спецификации. При делегировании следующему агенту в A2A трассировка обрывается: Python SDK создаёт лишь локальные span, а стандартного способа передавать W3C Trace Context между агентами нет (Issue #2103). Общественный Rust SDK сообщил о 7 сбоях TCK, которые после сверки были признаны дефектами самого тестового набора; в том же отчёте говорится, что SDK для JS, Go и Java проходят 21/21 на обеих привязках. Агентный трафик на стороне потребителей тоже пока невелик: по данным HUMAN Security, в 2025 году агентный трафик вырос на 7 851% за год, но лишь 2,3% приходится на страницы оформления заказа; вторичный источник со ссылкой на данные Cloudflare Radar за август 2026 года указывает, что ИИ-боты дают около 7% HTML-запросов, из которых на «действия в реальном времени от имени пользователя» приходится лишь 5,8%; произведение этих долей — около 0,4%, но это перемножение является выводом и не проверено на исходных данных. Akamai предупреждает, что сайты электронной торговли лишь наблюдают за более чем 90% ИИ-ботов, тогда как мошенническая агентная активность растёт. Доказательств того, что персональные агенты вроде ChatGPT, Gemini или Claude вызывают через A2A агентов обычных компаний, в исследовательских заметках не найдено, но это лишь отсутствие опровержения, а не официальное подтверждение.

Интервью, проведённые правительствами и международными организациями, показывают, что спрос реален. В OECD Artificial Intelligence Papers No. 65 на странице 16 зафиксировано, что опрошенные практики предпочитают открытые протоколы и считают протоколы связи «агент–агент», такие как A2A, важным двигателем мультиагентной координации, одновременно опасаясь привязки к экосистеме одного поставщика.

Тайвань: Базовый закон об искусственном интеллекте состоит из 20 статей; статья 3 определяет искусственный интеллект как «систему, способную функционировать автономно», что может охватывать ИИ-агентов, но слово «агент» в тексте закона не встречается; статья 4 перечисляет семь основных принципов, включая автономию и надзор человека, прозрачность и объяснимость, подотчётность; статья 16 поручает Министерству цифровых дел продвигать рамочную классификацию рисков, согласованную с международной практикой; статья 17 обязывает правительство определить распределение ответственности и условия её возложения для высокорисковых систем ИИ, а также создать механизмы защиты прав, компенсации или страхования; статья 18 обязывает ведомства в течение двух лет после вступления закона в силу привести профильное регулирование в соответствие. На основании статьи 16 Министерство цифровых дел 115-07-07 опубликовало «Рамочную модель классификации рисков ИИ» v1.0 (письмо по цифровой стратегии № 1150015933, вступает в силу немедленно), где для типа риска B6 «действия автономных ИИ-агентов за пределами полномочий» сказано: «В мультиагентных системах из-за взаимного запуска агентов выше вероятность цепных реакций, не предусмотренных ни разработчиками, ни пользователями, что затрудняет своевременное вмешательство и исправление со стороны человека». В руководстве по генеративному ИИ для медицинских учреждений, разосланном Министерством здравоохранения и социального обеспечения 115-05-29, прямо указано, что системы ИИ-агентов «пока не входят в сферу применения настоящего руководства».

Действующее законодательство Тайваня также применимо к агентным сценариям. Статья 4 Закона о защите персональных данных устанавливает, что лицо, которому поручены сбор, обработка или использование персональных данных, в пределах действия закона приравнивается к поручившему органу; поэтому передача персональных данных агенту на обработку не освобождает от ответственности под предлогом «это делает ИИ»; статья 21 регулирует ограничения на трансграничную передачу. Следует учитывать, что ряд статей, изменённых 114-11-11 (включая новую редакцию статьи 21 и добавленную статью 20-1), уже обнародован, но ещё не вступил в силу; дату вступления определяет Исполнительный юань. Закон об электронной подписи ИИ и агентов не упоминает; можно ли считать подпись, поставленную агентом от имени человека, подписью самого человека, законом прямо не урегулировано, и подтвердить это в статье невозможно.

Китай: Государственное управление по регулированию рынка и Управление по стандартизации КНР объявлением о национальных стандартах № 22 за 2026 год 2026-05-22 утвердили и выпустили серию GB/Z 185.1～185.7-2026 «Искусственный интеллект — взаимосвязь интеллектуальных агентов» из 7 руководящих технических документов (общая архитектура, идентификационный код, управление идентичностью, описание агентов, обнаружение агентов, взаимодействие агентов, вызов инструментов агентами); национальная публичная платформа информации о стандартах отмечает их статус как «действующий», полный текст опубликован 2026-06-18, а 2026-06-26 Государственное управление по регулированию рынка провело тематическую пресс-конференцию. В официальных документах используется название протокола AIP (протокол взаимосвязи интеллектуальных агентов), и на найденных официальных страницах ни A2A, ни MCP не упоминаются; совместимость не подтверждена. «Руководящее мнение о нормативном применении и инновационном развитии интеллектуальных агентов», совместно выпущенное 2026-05-08 Канцелярией по делам киберпространства КНР, Государственным комитетом по развитию и реформе и Министерством промышленности и информатизации, увязывает продвижение AIP, платформу регистрации агентов и цифровую идентичность агентов в единый пакет и требует, чтобы «операции, выполняемые агентами, не выходили за пределы полномочий, предоставленных пользователем». Этот путь отличается от позиции сообщества A2A, где «официального реестра нет».

Европейский союз: AI Act (Regulation (EU) 2024/1689) вступил в силу 2024-08-01; обязанности для моделей ИИ общего назначения применяются с 2025-08-02, общие положения и обязанности по прозрачности — с 2026-08-02; обязанности для высокорисковых систем отложены регламентом Regulation (EU) 2026/1744 (опубликован в Official Journal 2026-07-24): по приложению III — до 2027-12-02, по приложению I — до 2028-08-02. PSD3 и PSR находятся на стадии позиции первого чтения, одобренной Советом 2026-10-29, ожидают второго чтения в Европейском парламенте и в Official Journal не опубликованы.

США, Сингапур, Великобритания: CISA, NSA и другие ведомства «Пяти глаз» 2026-04-30 / 05-01 выпустили документ «Careful Adoption of Agentic AI Services» с рекомендацией ограничивать права доступа и начинать с низкорисковых и нечувствительных сценариев; у CFPB США нет руководства по платежам агентов, а соответствующий проект интерпретационного правила 2025 года был отозван 2025-05-15. В «Model AI Governance Framework for Agentic AI» v1.5 от IMDA Сингапура (опубликован 2026-05-20, обновлён 06-05) в разделе 1.1.1 прямо названы A2A — для связи между агентами — и MCP — для связи агентов с инструментами, а рекурсивное делегирование и межорганизационная идентичность указаны как текущие пробелы. В руководстве CMA Великобритании от 2026-03-09 (обновлено 10-30) сказано: «if an AI agent you use does something illegal, you are responsible», то есть компания несёт ответственность за противоправные действия используемого ею агента; публичные консультации ICO Великобритании по агентному ИИ завершаются 2026-11-20.

Issue #1942 объединил 41 тему в восемь тем v1.1, а межзадачная память агентов (#893) в рамки отслеживания не вошла. О направлении развития лучше списка тем говорят самые комментируемые обсуждения: #1672 о проверке идентичности агента в Agent Card (около 658 комментариев), #1829 о подписи сообщений через Ed25519 и RFC 9421, #2028 о делегировании actor-chain, #2121 о передаче затрат и бюджета и #1815 об использовании HTTP 402 для обозначения «требуется оплата». Всё это вопросы доверия и коммерции; учитывая новый процесс управления extension, в исследовательских заметках сделан вывод, что они скорее появятся в виде расширений, а не изменений базовой спецификации; это вывод.

На вопрос «как персональному агенту найти агента компании» внедрённого открытого ответа пока нет. Официальная документация A2A прямо указывает, что курируемые реестры выходят за рамки A2A; предложение Agent Registry в Discussion #741 долго не продвигается, а рецензенты ставят под сомнение исходную посылку, что «поставщики сами управляют своими записями». Для обнаружения агента по домену в IETF есть четыре конкурирующих индивидуальных черновика: DNS-AID (запись SVCB, указывающая на /.well-known/agent-card.json), AID (запрос TXT-записи _agent), ADP и DAN — ни один не принят рабочей группой; черновик landscape от июля 2026 года также отмечает необходимость координации пространства имён. Со стороны MCP реестр MCP Registry с сентября 2025 года по сей день остаётся в предварительной версии.

Для межорганизационного аудита и ответственности рамочной модели тоже нет. Спецификация A2A содержит лишь требования уровня SHOULD к журналированию сбоев аутентификации и ограничению частоты запросов, а сведения о стабильности семантических соглашений OpenTelemetry GenAI в разных источниках противоречат друг другу. С существующими инструментами минимальная единица аудита, которую можно сохранить, примерно такова: собственные taskId и contextId, отпечаток подписи Agent Card другой стороны и цепочка делегирования act из токена, предъявленного другой стороной; каждая сторона хранит их у себя для последующей сверки; это вывод. Эмпирических исследований атак denial-of-wallet, направленных на «исчерпание бюджета LLM другой стороны», в исследовательских заметках также не найдено.

Нынешнее состояние A2A напоминает ранний HTTP: формат уже стандартизирован, а уровень доверия каждому приходится достраивать самостоятельно; разница в том, что вызываемая сторона теперь рассуждает сама и может быть переубеждена другой стороной. Поэтому узкое место не в инженерии, а в вопросе «кто отвечает за действия агента», и этот вопрос сейчас распределён между IETF (идентичность), FIDO Alliance (платёжное намерение), карточными сетями (споры) и регуляторами разных стран — TSC A2A на это не влияет. Отсюда вывод: в ближайшие годы наиболее вероятной формой межкорпоративного взаимодействия агентов станет «оболочка A2A вокруг детерминированных вызовов инструментов»: вызываемая сторона снаружи выглядит как агент, а внутри это API, и настоящие рассуждения происходят только внутри собственного периметра доверия.

Направление государственных рекомендаций совпадает с этим. CISA, NSA и другие ведомства «Пяти глаз» советуют начинать с низкорисковых и нечувствительных сценариев и ограничивать права доступа; рамочная модель IMDA Сингапура выделяет «реальную ответственность человека» и технический контроль как ключевые аспекты; Министерство цифровых дел Тайваня относит цепные реакции от взаимного запуска агентов к риску B6; CMA Великобритании прямо заявляет, что компания отвечает за противоправные действия используемого ею агента.

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

Ключевые запросы трансграничной торговли и логистики — сколько стоит доставка, каковы налоги и сборы, какой код тарифной классификации и какие требования к ввозу у этого товара — по своей природе являются детерминированными расчётами, то есть именно тем типом услуг, который больше всего нужен внешним агентам и в котором меньше всего ошибок. По опыту инженерного блога Anthropic, переписывание описаний инструментов сократило время выполнения задач последующими агентами на 40%; опыт OpenAI, вернувшей Instant Checkout к Apps продавцов, показывает, что сделка в итоге всё равно возвращается в собственный процесс продавца. Поэтому порядок подготовки должен быть таким: сначала обеспечить машиночитаемость веб-страниц и структурированных данных, затем оформить детерминированные инструменты как MCP, добавлять в ответы инструментов URL продолжения, возвращающий сделку в собственный процесс, и лишь в последнюю очередь рассматривать A2A-заглушку.

A2A-карточка-заглушка — это публикация карточки в /.well-known/agent-card.json, навыки которой сопоставлены существующим детерминированным инструментам (расчёт стоимости, налоги, описание процесса), а бэкенд напрямую вызывает программный код без LLM. Это дёшево и имеет ценность «опциона», но измеренных кейсов, когда малый или средний бизнес получил бы благодаря этому трафик или выручку, пока нет; это вывод. Если всё же открывать эндпоинт A2A, нужно как минимум: открывать только навыки для чтения, не доверять ни одному полю карточки другой стороны, отклонять частные IP в URL push, журналировать taskId, contextId, идентичность вызывающей стороны и traceparent.

Текущий подход HowBridge (всё нижеперечисленное можно проверить на странице для разработчиков HowBridge): HowBridge предоставляет публичный MCP без ключа и без OAuth (https://0523.tw/mcp/public) с 8 инструментами только для чтения и идемпотентными: описание бренда и услуг HowBridge, расчёт стоимости консолидированной доставки Китай→Тайвань (Sea Express / авиадоставка), расчёт импортных налогов и сборов Тайваня, подбор кандидатов кода тарифной классификации CCC по названию товара, ставки по коду CCC и требования к ввозу, доплата за негабарит при доставке по Тайваню, а также процесс консолидированной доставки и правила упрощённого декларирования; лимит — 120 запросов в минуту на IP; сервис зарегистрирован в официальном MCP Registry (имя tw.0523/lucky-public); ответ расчёта стоимости доставки содержит URL продолжения (continue_url), чтобы пользователь вернулся на официальный сайт. MCP для участников (https://0523.tw/mcp) использует авторизацию OAuth 2.1 и предоставляет 6 инструментов только для чтения, которые позволяют читать лишь счета, посылки, предварительные уведомления, налоговые квитанции и импортные декларации самого авторизовавшего участника; лимиты по умолчанию — 60 запросов в минуту и 5 000 в день. Сейчас на странице для разработчиков HowBridge перечислены API данных участников, MCP для участников и публичный MCP; эндпоинта A2A нет; эта статья не означает, что HowBridge уже поддерживает A2A.

Если вы хотите, чтобы ИИ-ассистент помог оценить стоимость отправки из Китая на Тайвань, можно сразу воспользоваться веб-версиями калькулятора стоимости консолидированной доставки, калькулятора импортных пошлин и поиска тарифной классификации; эти инструменты и публичный MCP используют одну и ту же логику расчёта. Расчёт носит справочный характер: стоимость доставки определяется по счёту после замеров на складе, а налоги — по решению таможни.