[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"portal-settings:stajic:ru":3,"public-menus:all":38,"post:mcp-vs-a2a-vs-ucp-vs-ap2-vs-a2ui-the-agent-protocol-stack-explained:ru":205,"related:post:mcp-vs-a2a-vs-ucp-vs-ap2-vs-a2ui-the-agent-protocol-stack-explained:ru:1":1827},{"statusCode":4,"data":5,"message":37},200,{"tenantId":6,"lang":7,"defaultLang":8,"siteUrl":9,"contactEmail":10,"brandName":11,"logoUrl":12,"siteName":11,"siteDescription":13,"ogImage":10,"robotsIndex":14,"socialLinks":10,"reservedSlugs":10,"seoPolicy":15},"stajic","ru","de","https:\u002F\u002Fstajic.de",null,"Stajic Platform","\u002FLogo_Planet.svg","Stajic Portal",true,{"branding":16,"relatedContent":17,"crossDomainLinks":18},{"logoUrl":12},{"enabled":14},[19,22,25,28,31,34],{"url":20,"label":21,"isActive":14,"showInFooter":14,"includeInSameAs":14},"https:\u002F\u002Ffigure.rocks","figure.rocks",{"url":23,"label":24,"isActive":14,"showInFooter":14,"includeInSameAs":14},"https:\u002F\u002Floving.rocks","loving.rocks",{"url":26,"label":27,"isActive":14,"showInFooter":14,"includeInSameAs":14},"https:\u002F\u002Fbazify.com","bazify.com",{"url":29,"label":30,"isActive":14,"showInFooter":14,"includeInSameAs":14},"https:\u002F\u002Fbazify.de","bazify.de",{"url":32,"label":33,"isActive":14,"showInFooter":14,"includeInSameAs":14},"https:\u002F\u002Fbazify.at","bazify.at",{"url":35,"label":36,"isActive":14,"showInFooter":14,"includeInSameAs":14},"https:\u002F\u002Fbazify.ba","bazify.ba","Portal settings resolved",[39,45],{"id":40,"name":41,"location":42,"isActive":14,"isDefault":43,"items":44},1,"main-navigation","header",false,[],{"id":46,"name":47,"location":48,"isActive":14,"isDefault":14,"items":49},4,"main-menu","sidebar",[50,66,79,93,103,118,133],{"id":51,"title":52,"url":60,"target":61,"icon":62,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":64,"portfolioId":10,"children":65},"item-18",{"de":53,"en":54,"es":55,"fr":56,"it":54,"ru":57,"sr":58,"zh":59},"Startseite","Home","Inicio","Accueil","Главная","Почетна","首页","\u002Ffull-stack-web-developer-munich-performance-seo-and-maintainable-builds","_self","i-lucide-home","page",111,[],{"id":67,"title":68,"url":75,"target":61,"icon":76,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":77,"portfolioId":10,"children":78},"item-22",{"de":69,"en":69,"es":70,"fr":69,"it":71,"ru":72,"sr":73,"zh":74},"Vision","Visión","Visione","Видение","Визија","想象","\u002Fueber-uns-webdesign-muenchen-webaplikation","i-lucide-eye",113,[],{"id":80,"title":81,"url":89,"target":61,"icon":90,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":91,"portfolioId":10,"children":92},"item-19",{"de":82,"en":83,"es":84,"fr":83,"it":85,"ru":86,"sr":87,"zh":88},"Leistungen","Services","Servicios","Servizi","Услуги","Услуге","服务","\u002Fservices-dienstleistungen-muenchen","i-lucide-wrench",116,[],{"id":94,"title":95,"url":99,"target":61,"icon":100,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":101,"portfolioId":10,"children":102},"item-23",{"de":96,"en":96,"es":96,"fr":96,"it":96,"ru":97,"sr":97,"zh":98},"Blog","Блог","博客","\u002Fblog","i-lucide-book-open",112,[],{"id":104,"title":105,"url":114,"target":61,"icon":115,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":116,"portfolioId":10,"children":117},"item-32",{"de":106,"en":107,"es":108,"fr":109,"it":110,"ru":111,"sr":112,"zh":113},"Neue Technologien","New Technologies","Nuevas tecnologías","Nouvelles technologies","Nuove tecnologie","Новые технологии","Нове технологије","新技术！","\u002Fneue-webtechnologien","i-lucide-sparkles",122,[],{"id":119,"title":120,"url":129,"target":61,"icon":130,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":131,"portfolioId":10,"children":132},"item-20",{"de":121,"en":122,"es":123,"fr":124,"it":125,"ru":126,"sr":127,"zh":128},"Kontakt","Contact us!","Contacto","Contact","Contatto","Контакт","Контактирајте нас","联系我们！","\u002Fcontact","i-lucide-mail",115,[],{"id":134,"title":135,"url":144,"target":61,"icon":145,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":146,"portfolioId":10,"children":147},"item-21",{"de":136,"en":137,"es":138,"fr":139,"it":140,"ru":141,"sr":142,"zh":143},"Unsere Arbeit","Our Work","Nuestro trabajo","Nos réalisations","I nostri lavori","Наши работы","Наши радови","文件夹","\u002Fportfolio","i-lucide-briefcase",114,[148,161,175,181,193],{"id":149,"title":150,"url":144,"target":61,"icon":159,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":146,"portfolioId":10,"children":160},"item-24",{"de":151,"en":152,"es":153,"fr":154,"it":155,"ru":156,"sr":157,"zh":158},"Alle Projekte","All Projects","Todos los proyectos","Tous les projets","Tutti i progetti","Все проекты","Сви пројекти","所有项目","i-lucide-grid-3x3",[],{"id":162,"title":163,"url":171,"target":61,"icon":172,"isActive":14,"type":173,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":10,"portfolioId":10,"children":174},"item-29",{"de":164,"en":165,"es":166,"fr":167,"it":168,"ru":169,"sr":170,"zh":143},"Local Roots, Global Reach","Local Roots - Global Reach","Empresa local ","Entreprise locale","Azienda locale","Местная компания","Локално предузеће глобално тржиште","\u002Fportfolio\u002Flocal-roots-global-reach-communication-media-systems-for-modern-business","i-lucide-folder","custom",[],{"id":176,"title":177,"url":179,"target":61,"icon":172,"isActive":14,"type":173,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":10,"portfolioId":10,"children":180},"item-28",{"de":178,"en":178,"es":178,"fr":178,"it":178,"ru":178,"sr":178,"zh":178},"Solr Suggester","\u002Fportfolio\u002Fsolr-fuzzy-suggester-und-solr-infix-suggester-abfrage-ueber-ajax-und-filterung",[],{"id":182,"title":183,"url":191,"target":61,"icon":172,"isActive":14,"type":173,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":10,"portfolioId":10,"children":192},"item-27",{"de":184,"en":185,"es":186,"fr":187,"it":188,"ru":189,"sr":190,"zh":185},"Firmenwebseite SEO","Company Website SEO","Sitio web corporativo SEO","Site web d’entreprise SEO","Sito web aziendale SEO","Корпоративный сайт SEO","Пословна веб-страница SEO","\u002Fportfolio\u002Fseo-sem-branding-mobile-webseite-muenchen",[],{"id":194,"title":195,"url":203,"target":61,"icon":172,"isActive":14,"type":173,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":10,"portfolioId":10,"children":204},"item-31",{"de":196,"en":197,"es":198,"fr":199,"it":200,"ru":201,"sr":202,"zh":197},"Digitalisierungsportal","Digitalization Portal","Portal de digitalización","Portail de numérisation","Portale di digitalizzazione","Портал цифровизации","Портал за дигитализацију","\u002Fportfolio\u002Fdigitalisierungsportal-archiv-museum-bibliothek-ead-lido-mets-mods",[],{"statusCode":4,"data":206,"message":1826},{"id":207,"title":208,"slug":209,"content":210,"contentJson":211,"excerpt":896,"featuredImage":897,"featuredImageAlt":898,"featuredImageCaption":10,"featuredImageTitle":10,"featuredImageCopyright":10,"featuredImageAuthor":10,"featuredImageSourceUrl":10,"featuredImageLicense":10,"featuredImageIsAiGenerated":43,"status":899,"publishedAt":900,"createdAt":901,"updatedAt":902,"seoLocalePaths":903,"categories":912,"author":925,"translations":930},"476","MCP vs A2A vs UCP vs AP2 vs A2UI: разбор стека протоколов агентов","mcp-vs-a2a-vs-ucp-vs-ap2-vs-a2ui-the-agent-protocol-stack-explained","\u003Cnav class=\"editorjs-toc\" data-editorjs-toc=\"true\" aria-label=\"Содержание\">\u003Cstrong class=\"editorjs-toc__title\">Содержание\u003C\u002Fstrong>\u003Col class=\"editorjs-toc__list editorjs-toc__list--depth-0\">\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-6\" class=\"editorjs-toc__link\">Главная ошибка: сравнение протоколов, находящихся на разных уровнях взаимодействия\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-9\" class=\"editorjs-toc__link\">Стек зон ответственности протоколов\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-12\" class=\"editorjs-toc__link\">1. MCP: подключение агента к возможностям\u003C\u002Fa>\u003Col class=\"editorjs-toc__list editorjs-toc__list--depth-1\">\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-15\" class=\"editorjs-toc__link\">Используйте MCP, когда\u003C\u002Fa>\u003C\u002Fli>\u003C\u002Fol>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-18\" class=\"editorjs-toc__link\">2. A2A: подключение независимых агентов\u003C\u002Fa>\u003Col class=\"editorjs-toc__list editorjs-toc__list--depth-1\">\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-22\" class=\"editorjs-toc__link\">Используйте A2A, когда\u003C\u002Fa>\u003C\u002Fli>\u003C\u002Fol>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-24\" class=\"editorjs-toc__link\">MCP против A2A: вертикальная интеграция против горизонтального сотрудничества\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-27\" class=\"editorjs-toc__link\">3. UCP: стандартизация агентской коммерции\u003C\u002Fa>\u003Col class=\"editorjs-toc__list editorjs-toc__list--depth-1\">\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-31\" class=\"editorjs-toc__link\">Используйте UCP, когда\u003C\u002Fa>\u003C\u002Fli>\u003C\u002Fol>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-33\" class=\"editorjs-toc__link\">4. AP2: подтверждение права агента совершать траты\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-37\" class=\"editorjs-toc__link\">UCP против AP2: семантика транзакций против полномочий\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-39\" class=\"editorjs-toc__link\">5. A2UI: позвольте агентам описывать интерфейсы, не отдавая им контроль над вашим фронтендом\u003C\u002Fa>\u003Col class=\"editorjs-toc__list editorjs-toc__list--depth-1\">\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-43\" class=\"editorjs-toc__link\">Используйте A2UI, когда\u003C\u002Fa>\u003C\u002Fli>\u003C\u002Fol>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-45\" class=\"editorjs-toc__link\">Тест для выбора протокола\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-48\" class=\"editorjs-toc__link\">Реалистичный мультипротокольный рабочий процесс\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-50\" class=\"editorjs-toc__link\">Почему один универсальный агентный протокол вряд ли заменит их все\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-54\" class=\"editorjs-toc__link\">Композиция протоколов создает новые сценарии сбоев\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-56\" class=\"editorjs-toc__link\">Выбор протокола не заменяет архитектуру приложения\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-60\" class=\"editorjs-toc__link\">Что может изменить этот расклад?\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-63\" class=\"editorjs-toc__link\">Ограничения\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-66\" class=\"editorjs-toc__link\">Заключение\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-69\" class=\"editorjs-toc__link\">Часто задаваемые вопросы\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-71\" class=\"editorjs-toc__link\">Глоссарий\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-73\" class=\"editorjs-toc__link\">Основные источники и материалы для дальнейшего чтения\u003C\u002Fa>\u003C\u002Fli>\u003C\u002Fol>\u003C\u002Fnav>\n\u003Cp>Протоколы для ИИ-агентов стремительно множатся: MCP, A2A, UCP, AP2, A2UI и смежные стандарты все чаще появляются на одних и тех же архитектурных схемах. Их нередко описывают как конкурирующие протоколы. На практике большинство из них решает различные задачи интероперабельности на разных уровнях взаимодействия. Правильный вопрос заключается не в том, «Какой протокол победит?», а в том, «Какую связь в системе необходимо стандартизировать?»\u003C\u002Fp>\n\u003Caside class=\"editorjs-callout editorjs-callout--info my-6 rounded-xl border p-5 border-blue-300 bg-blue-50 dark:border-blue-900 dark:bg-blue-950\u002F20\" role=\"note\">\u003Cstrong class=\"block mb-2 text-gray-900 dark:text-gray-100\">Прямой ответ\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">&lt;strong&gt;MCP, A2A, UCP, AP2 и A2UI в основном дополняют друг друга, а не заменяют.&lt;\u002Fstrong&gt; MCP подключает ИИ-приложение к инструментам, данным и ресурсам. A2A связывает независимых агентов друг с другом. UCP стандартизирует коммерческие взаимодействия между пользовательскими интерфейсами, бизнесом и платежными экосистемами. AP2 добавляет проверяемую авторизацию и платежные намерения в транзакции под управлением агентов. A2UI позволяет агенту описывать интерактивный пользовательский интерфейс без отправки произвольного кода приложения. Промышленная система может вполне обоснованно использовать несколько из них в рамках одного рабочего процесса.\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Caside class=\"editorjs-callout editorjs-callout--warning my-6 rounded-xl border p-5 border-amber-300 bg-amber-50 dark:border-amber-900 dark:bg-amber-950\u002F20\" role=\"note\">\u003Cstrong class=\"block mb-2 text-gray-900 dark:text-gray-100\">Быстро меняющиеся стандарты\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">В этой статье отражено состояние экосистемы протоколов на &lt;strong&gt;25 сентября 2026 года&lt;\u002Fstrong&gt;. A2A достиг версии 1.0, текущая линейка MCP TypeScript v2 реализует спецификацию от 28.07.2026, UCP уже добавил более новые версии протокола 2026 года, а A2UI продолжает развиваться. Всегда проверяйте актуальную спецификацию перед внедрением.\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Caside class=\"editorjs-callout editorjs-callout--note my-6 rounded-xl border p-5 border-gray-300 bg-gray-50 dark:border-gray-700 dark:bg-gray-900\u002F40\" role=\"note\">\u003Cstrong class=\"block mb-2 text-gray-900 dark:text-gray-100\">Модель, используемая в этой статье\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">Стек зон ответственности протоколов (Protocol Responsibility Stack) и тест выбора протокола (Protocol Selection Test) ниже представляют собой практические архитектурные модели, предложенные здесь. Они не являются официальной терминологией проектов протоколов.\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Ch2 id=\"section-6\">Главная ошибка: сравнение протоколов, находящихся на разных уровнях взаимодействия\u003C\u002Fh2>\n\u003Cp>Протокол полезен потому, что двум независимо реализованным системам необходим стабильный контракт. Контракт имеет смысл только тогда, когда четко определены границы взаимодействия. Агент, обращающийся к базе данных, решает принципиально иную задачу интероперабельности, чем агент, делегирующий работу другому агенту, покупатель, подтверждающий покупку, или удаленный агент, запрашивающий у нативного приложения отрисовку формы.\u003C\u002Fp>\n\u003Cp>В руководстве для разработчиков от Google за 2026 год MCP, A2A, UCP, AP2, A2UI и связанные с ними протоколы пользовательского интерфейса прямо представлены как стек взаимодополняющих стандартов. В одном и том же примере рабочего процесса несколько из них могут использоваться совместно: инструменты для учета запасов, удаленные агенты для поставщиков, коммерция для оформления заказа, авторизация платежей для списания средств и протоколы пользовательского интерфейса для взаимодействия.\u003C\u002Fp>\n\u003Ch2 id=\"section-9\">Стек зон ответственности протоколов\u003C\u002Fh2>\n\u003Cdiv class=\"overflow-x-auto\">\u003Ctable class=\"w-full border-collapse\">\u003Cthead>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Протокол\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Какую связь стандартизирует?\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Основная абстракция\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">В первую очередь не предназначен для\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">MCP\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">ИИ-приложение ↔ инструменты, ресурсы и данные\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Инструменты, ресурсы, промпты и обмен возможностями между хостом и сервером\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Сотрудничества независимых агентов или семантики электронной коммерции\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">A2A\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Агент ↔ независимый агент\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Обнаружение агентов, сообщения, задачи, артефакты и длительное сотрудничество\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Прямой интеграции баз данных\u002Fинструментов\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">UCP\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Интерфейс пользователя\u002Fагента ↔ коммерческая система продавца\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Возможности управления товарами\u002Fкорзиной\u002Fоформлением заказа\u002Fдоставкой\u002Fзаказами\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Общей коммуникации между агентами общего назначения\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">AP2\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Намерение пользователя\u002Fагента ↔ авторизация платежа\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Мандаты, ограничения на утверждение и проверяемые полномочия на проведение платежей агентами\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Поиска товаров или общего транспорта для оформления заказа\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">A2UI\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Агент ↔ хост пользовательского интерфейса\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Декларативное намерение интерфейса, отрисовываемое доверенными нативными компонентами\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Произвольного удаленного кода фронтенда или делегирования задач между агентами\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Caside class=\"editorjs-callout editorjs-callout--success my-6 rounded-xl border p-5 border-emerald-300 bg-emerald-50 dark:border-emerald-900 dark:bg-emerald-950\u002F20\" role=\"note\">\u003Cstrong class=\"block mb-2 text-gray-900 dark:text-gray-100\">Один рабочий процесс может использовать все пять\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">Агент может использовать &lt;strong&gt;MCP&lt;\u002Fstrong&gt; для проверки складских запасов, &lt;strong&gt;A2A&lt;\u002Fstrong&gt; для запроса доступности у агента поставщика, &lt;strong&gt;UCP&lt;\u002Fstrong&gt; для формирования коммерческой транзакции, &lt;strong&gt;AP2&lt;\u002Fstrong&gt; для подтверждения полномочий на оплату и &lt;strong&gt;A2UI&lt;\u002Fstrong&gt; для отображения пользователю нативного интерфейса подтверждения.\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Ch2 id=\"section-12\">1. MCP: подключение агента к возможностям\u003C\u002Fh2>\n\u003Cp>Model Context Protocol — это открытый стандарт для подключения ИИ-приложений к внешним системам, где находятся инструменты, данные и переиспользуемые ресурсы. Сервер предоставляет возможности; MCP-хост подключается к этому серверу и делает эти возможности доступными модели или приложению.\u003C\u002Fp>\n\u003Cp>Текущая документация MCP TypeScript v2 описывает протокол именно в таких терминах: серверы предоставляют инструменты, ресурсы и промпты, в то время как хосты, такие как среды разработки или пользовательские приложения, подключаются к ним. Это делает MCP в первую очередь протоколом интеграции возможностей.\u003C\u002Fp>\n\u003Ch3 id=\"section-15\">Используйте MCP, когда\u003C\u002Fh3>\n\u003Cul>\u003Cli>ИИ-приложению требуется стандартизированный доступ к инструментам или API.\u003C\u002Fli>\u003Cli>Вам нужно, чтобы один сервер возможностей работал с несколькими совместимыми ИИ-хостами.\u003C\u002Fli>\u003Cli>Вам необходим структурированный доступ к данным или ресурсам без жесткого кодирования каждой интеграции в каждого агента.\u003C\u002Fli>\u003Cli>Внешняя система является поставщиком возможностей, а не автономным одноранговым агентом.\u003C\u002Fli>\u003C\u002Ful>\n\u003Caside class=\"editorjs-callout editorjs-callout--warning my-6 rounded-xl border p-5 border-amber-300 bg-amber-50 dark:border-amber-900 dark:bg-amber-950\u002F20\" role=\"note\">\u003Cstrong class=\"block mb-2 text-gray-900 dark:text-gray-100\">MCP автоматически не является A2A\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">MCP-сервер может предоставлять мощные функции, но это не делает его независимым агентом с собственным жизненным циклом задач, семантикой обнаружения и непрозрачной внутренней логикой рассуждений. Вызов инструментов и сотрудничество агентов — это разные контракты.\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Ch2 id=\"section-18\">2. A2A: подключение независимых агентов\u003C\u002Fh2>\n\u003Cp>Agent2Agent (A2A) разработан для взаимодействия между независимыми, потенциально непрозрачными агентскими системами. Его текущая спецификация v1.0 сосредоточена на обнаружении возможностей, обмене сообщениями, задачах, артефактах, мультимодальном контенте и длительном сотрудничестве без необходимости раскрывать внутренние инструменты, память или реализацию одного агента другому.\u003C\u002Fp>\n\u003Cp>Эта непрозрачность является важной границей. Вызывающему агенту не нужно знать, использует ли удаленный агент внутри себя MCP, кастомные инструменты, проприетарный планировщик, модель другого поставщика или эскалацию на человека. Ему необходим контракт для обнаружения возможностей и делегирования работы.\u003C\u002Fp>\n\u003Cp>A2A v1.0 также стандартизирует согласование версий и поддерживает различные привязки вокруг общей модели данных. Опубликованный механизм Agent Card предоставляет клиентам стандартную точку обнаружения возможностей агента, поддерживаемых протоколов, требований к аутентификации и навыков.\u003C\u002Fp>\n\u003Ch3 id=\"section-22\">Используйте A2A, когда\u003C\u002Fh3>\n\u003Cul>\u003Cli>Одному автономному агенту необходимо делегировать работу другому автономному агенту.\u003C\u002Fli>\u003Cli>Удаленная система должна оставаться непрозрачной за контрактом возможностей.\u003C\u002Fli>\u003Cli>Задачи могут быть длительными, асинхронными или требовать участия человека (human-in-the-loop).\u003C\u002Fli>\u003Cli>Агенты построены на базе различных фреймворков, языков, решений разных вендоров или принадлежат разным организациям.\u003C\u002Fli>\u003C\u002Ful>\n\u003Ch2 id=\"section-24\">MCP против A2A: вертикальная интеграция против горизонтального сотрудничества\u003C\u002Fh2>\n\u003Csection class=\"editorjs-comparison my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">MCP и A2A решают различные проблемы интероперабельности\u003C\u002Fh3>\u003Cdiv class=\"overflow-x-auto\">\u003Ctable class=\"w-full border-collapse\">\u003Cthead>\u003Ctr>\u003Cth class=\"border border-gray-300 bg-gray-50 px-4 py-3 text-left dark:border-gray-700 dark:bg-gray-900\">\u003C\u002Fth>\u003Cth class=\"border border-gray-300 bg-gray-50 px-4 py-3 text-left font-semibold dark:border-gray-700 dark:bg-gray-900\">Критерий\u003C\u002Fth>\u003Cth class=\"border border-gray-300 bg-gray-50 px-4 py-3 text-left font-semibold dark:border-gray-700 dark:bg-gray-900\">MCP\u003C\u002Fth>\u003Cth class=\"border border-gray-300 bg-gray-50 px-4 py-3 text-left font-semibold dark:border-gray-700 dark:bg-gray-900\">A2A\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">Взаимосвязь\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">Абстракция\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">Внутренняя непрозрачность\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">Длительные задачи\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Cp>Сам проект A2A сейчас описывает это различие как горизонтальное против вертикального: MCP подключает агентов к внутренним инструментам и базам данных, тогда как A2A обеспечивает одноранговое (peer-to-peer) сотрудничество между агентскими системами.\u003C\u002Fp>\n\u003Ch2 id=\"section-27\">3. UCP: стандартизация агентской коммерции\u003C\u002Fh2>\n\u003Cp>Universal Commerce Protocol не является универсальным протоколом для агентов общего назначения. Он стандартизирует коммерческие сценарии между клиентскими интерфейсами, продавцами и платежными провайдерами. Реализация от Google уже поддерживает такие возможности, как создание корзины, оформление заказа, исполнение и жизненный цикл заказа с помощью версионированных профилей и API.\u003C\u002Fp>\n\u003Cp>Продавец может опубликовать UCP-профиль по адресу \u002F.well-known\u002Fucp с описанием сервисов, версий протокола и возможностей. Этот паттерн обнаружения важен, поскольку агентскому интерфейсу не должен требоваться индивидуальный контракт на оформление заказа для каждого продавца.\u003C\u002Fp>\n\u003Cp>UCP также намеренно сделан компонуемым. В техническом обзоре Google говорится, что он может интегрироваться через API, A2A и MCP, а также совместим с AP2 для авторизации платежей агентами.\u003C\u002Fp>\n\u003Ch3 id=\"section-31\">Используйте UCP, когда\u003C\u002Fh3>\n\u003Cul>\u003Cli>Рабочий процесс включает товары продавца, корзины, оформление заказа, исполнение или жизненный цикл заказа.\u003C\u002Fli>\u003Cli>Вы создаете интерфейс продавца, который должен работать с агентскими сценариями покупок.\u003C\u002Fli>\u003Cli>Интеграции требуется семантика, специфичная для электронной коммерции, а не стандартные вызовы инструментов.\u003C\u002Fli>\u003Cli>Вам нужен совместимый коммерческий контракт, который может сосуществовать с MCP, A2A и платежными протоколами.\u003C\u002Fli>\u003C\u002Ful>\n\u003Ch2 id=\"section-33\">4. AP2: подтверждение права агента совершать траты\u003C\u002Fh2>\n\u003Cp>Агентская коммерция порождает проблему, с которой обычные сценарии оформления заказа не сталкивались напрямую: агент может совершать транзакции без непосредственного нажатия финальной кнопки человеком в реальном времени. Agent Payments Protocol (AP2) решает вопросы авторизации, подлинности и подотчетности для платежей, инициируемых агентами.\u003C\u002Fp>\n\u003Cp>В руководстве по протоколу Google за 2026 год AP2 описывается через типизированные мандаты, фиксирующие намерения пользователя, ограничения на расходы и конкретную авторизуемую транзакцию. AP2 может работать как расширение вместе с UCP: UCP описывает коммерческую транзакцию, а AP2 подтверждает полномочия агента на проведение платежа.\u003C\u002Fp>\n\u003Cp>Это различие принципиально. Протокол оформления заказа может сообщить продавцу, что именно необходимо приобрести. Однако сам по себе он не подтверждает, кто уполномочил агента тратить средства, в каких пределах, у какого продавца, на какой срок и оставалась ли итоговая корзина в рамках этих полномочий.\u003C\u002Fp>\n\u003Ch2 id=\"section-37\">UCP против AP2: семантика транзакций против полномочий\u003C\u002Fh2>\n\u003Cdiv class=\"overflow-x-auto\">\u003Ctable class=\"w-full border-collapse\">\u003Cthead>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Вопрос\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">UCP\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">AP2\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Что покупается?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Товары, корзина, семантика оформления заказа и исполнения\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Ссылается на авторизованный контекст транзакции\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Кто может это авторизовать?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Не является основной зоной ответственности протокола\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Явная модель полномочий и мандатов агента\u002Fпользователя\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Какие ограничения на расходы применяются?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Торговый сценарий может содержать итоговые суммы и данные оформления заказа\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Ограничения авторизации и лимиты намерений\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Как проводится аудит транзакции?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Жизненный цикл заказа и торговли\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Криптографический \u002F проверяемый след авторизации через мандаты и квитанции\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Могут ли они работать вместе?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Да\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Да — AP2 может расширять сценарии коммерции с участием агентов\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Ch2 id=\"section-39\">5. A2UI: позвольте агентам описывать интерфейсы, не отдавая им контроль над вашим фронтендом\u003C\u002Fh2>\n\u003Cp>Agent-to-User Interface (A2UI) решает задачу другой границы: как удаленный или локальный агент передает насыщенный интерактивный интерфейс хост-приложению. Вместо отправки произвольного HTML, CSS и JavaScript, A2UI использует декларативные данные, которые хост отрисовывает через собственный доверенный каталог компонентов.\u003C\u002Fp>\n\u003Cp>Это сохраняет дизайн-систему и модель безопасности хост-приложения, позволяя агенту запрашивать динамические интерфейсы. A2UI v0.9 особо акцентирует внимание на независимых от фреймворков намерениях UI и потоковых обновлениях для веба, мобильных и других клиентов.\u003C\u002Fp>\n\u003Cp>Последующая работа Google над связкой A2UI + MCP Apps также демонстрирует, что эти модели UI не обязательно исключают друг друга. Декларативный нативный UI и более богатый опыт встроенных приложений могут сосуществовать в зависимости от задачи.\u003C\u002Fp>\n\u003Ch3 id=\"section-43\">Используйте A2UI, когда\u003C\u002Fh3>\n\u003Cul>\u003Cli>Удаленному агенту необходимо запрашивать формы, карточки, элементы управления или другой интерактивный UI.\u003C\u002Fli>\u003Cli>Хост должен сохранять свои нативные компоненты, стилизацию и периметр безопасности.\u003C\u002Fli>\u003Cli>Вы не хотите, чтобы удаленные агенты передавали произвольный исполняемый код фронтенда.\u003C\u002Fli>\u003Cli>Одно и то же определенное агентом намерение UI должно работать в различных клиентских фреймворках.\u003C\u002Fli>\u003C\u002Ful>\n\u003Ch2 id=\"section-45\">Тест для выбора протокола\u003C\u002Fh2>\n\u003Cp>Отталкивайтесь не от аббревиатуры. Отталкивайтесь от взаимодействия, требующего интероперабельности.\u003C\u002Fp>\n\u003Csection class=\"editorjs-process my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">Выбирайте протокол по границе взаимодействия\u003C\u002Fh3>\u003Cdiv class=\"grid grid-cols-1 md:grid-cols-2 xl:grid-cols-3 gap-4\">\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">1\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">1. Определите две независимые стороны\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Это взаимодействие ИИ с инструментом, агента с агентом, агента с продавцом, агента с органом авторизации платежей или агента с пользовательским интерфейсом?\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">2\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">2. Определите разделяемый объект\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Является ли контракт вызовом инструмента, задачей, корзиной, платежным мандатом, артефактом или описанием UI?\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">3\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">3. Проверьте, существует ли уже доменный протокол\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Отдавайте предпочтение семантике коммерции или платежей, если задача связана с коммерцией или авторизацией, вместо кодирования всего подряд в виде универсальных инструментов.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">4\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">4. Оставляйте внутренние детали локальными\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Не раскрывайте всего агента как MCP-инструменты, если удаленной стороне требуется лишь возможность A2A, и не возлагайте на удаленного агента ответственность за среду выполнения вашего UI.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">5\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">5. Комбинируйте протоколы, когда рабочий процесс пересекает границы\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Один рабочий процесс может правомерно пересекать контракты инструментов, агентов, коммерции, платежей и UI.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">6\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">6. Версионируйте каждый контракт независимо\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Версии протоколов развиваются с разной скоростью; не привязывайте каждую интеграцию к одной монолитной версии приложения.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">7\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">7. Сохраняйте авторизацию на каждой границе\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Интероперабельность не заменяет продуктовые права доступа, авторизацию инструментов, платежные полномочия или политики доступа к данным.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Ch2 id=\"section-48\">Реалистичный мультипротокольный рабочий процесс\u003C\u002Fh2>\n\u003Csection class=\"editorjs-process my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">Пример: рабочий процесс автономных закупок\u003C\u002Fh3>\u003Cdiv class=\"grid grid-cols-1 md:grid-cols-2 xl:grid-cols-3 gap-4\">\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">1\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">1. Проверка внутренних запасов с помощью MCP\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Агент по закупкам вызывает функции складского учета и прогнозирования, предоставляемые внутренними MCP-серверами.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">2\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">2. Поиск агента поставщика с помощью A2A\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Агент считывает Agent Card поставщика и делегирует задачу по проверке доступности и сроков поставки.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">3\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">3. Согласование объекта коммерции с помощью UCP\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Интерфейс поставщика или продавца возвращает структурированную информацию о корзине, оформлении заказа и исполнении.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">4\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">4. Проверка полномочий на расходы с помощью AP2\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Покупка сопоставляется с подписанным мандатом пользователя или организации, ограничениями продавца и лимитами расходов.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">5\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">5. Запрос одобрения через A2UI\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Если требуется одобрение человека, агент отправляет декларативное намерение UI, а хост отрисовывает интерфейс утверждения с использованием доверенных нативных компонентов.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">6\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">6. Завершение и аудит\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Состояние коммерции, авторизация платежа, подтверждения выполнения задач агентом и записи аудита приложения остаются отслеживаемыми в рамках соответствующих границ.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Ch2 id=\"section-50\">Почему один универсальный агентный протокол вряд ли заменит их все\u003C\u002Fh2>\n\u003Cp>Универсальный протокол кажется более простым решением ровно до тех пор, пока ему не потребуется описывать семантику каждой предметной области. Обнаружение инструментов, длительное взаимодействие агентов, оформление заказов, авторизация платежей и нативный UI имеют совершенно разные требования к жизненному циклу, безопасности и корректности.\u003C\u002Fp>\n\u003Cp>Сам веб развивался за счет многоуровневых протоколов, а не единого формата сообщений для всех задач. Формирующийся стек для агентов движется в том же направлении: общие горизонтальные примитивы, специализированные доменные контракты и явные механизмы обнаружения и версионирования.\u003C\u002Fp>\n\u003Cp>Таким образом, архитектурная задача смещается с вопроса «какой протокол победит?» к вопросу о том, насколько органично протоколы сочетаются между собой без дублирования семантики идентификации, авторизации, состояния и аудита.\u003C\u002Fp>\n\u003Ch2 id=\"section-54\">Композиция протоколов создает новые сценарии сбоев\u003C\u002Fh2>\n\u003Cdiv class=\"overflow-x-auto\">\u003Ctable class=\"w-full border-collapse\">\u003Cthead>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Режим сбоя\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Что происходит\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Архитектурный контроль\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Утечка полномочий\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Допустимый инструмент или возможность агента воспринимаются как разрешение на выполнение бизнес-действия\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Обеспечьте независимость авторизации на уровне продукта от обнаружения возможностей протокола\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Несоответствие идентификаторов\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Идентификатор хоста MCP, идентификатор агента A2A и идентификатор коммерции\u002Fплатежей относятся к разным субъектам\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Определите явное сопоставление субъектов (principals) через границы протоколов\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Дрейф версий\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Один протокол обновляется, в то время как зависимые адаптеры предполагают старую семантику\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Согласовывайте и фиксируйте версии протоколов независимо\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Дублирование состояния\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Одно и то же состояние корзины, задачи или утверждения копируется на несколько уровней протокола\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Определите одного авторитетного владельца для каждого доменного объекта\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Фрагментация аудита\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Трассировки инструментов, задачи агентов, подтверждения оформления заказа и платежей не могут быть объединены\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Передавайте корреляционные идентификаторы и стабильные доменные идентификаторы через границы протоколов\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Семантическое туннелирование\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Все принудительно прогоняется через универсальный протокол в виде непрозрачного JSON\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Используйте доменные протоколы там, где их семантика существенно повышает корректность\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Ch2 id=\"section-56\">Выбор протокола не заменяет архитектуру приложения\u003C\u002Fh2>\n\u003Cp>Открытые стандарты снижают связность интеграции, но они не определяют вашу доменную модель, политику авторизации, источник истины, стратегию повторных попыток или критерии приемки. Инструмент MCP все еще может предоставить не ту возможность. Агент A2A все еще может вернуть некорректный артефакт. Оформление заказа UCP все еще может содержать устаревшие данные продавца. Мандат AP2 все еще может быть неверно применен логикой приложения.\u003C\u002Fp>\n\u003Cp>Относитесь к протоколам как к контрактам между независимо развивающимися компонентами. Сохраняйте доменную истину и определяющие политики на уровне приложения, которому они принадлежат, а затем используйте протоколы для обеспечения интероперабельности границ.\u003C\u002Fp>\n\u003Caside class=\"editorjs-referral my-6\">\u003Ca href=\"https:\u002F\u002Fstajic.de\u002Fru\u002Fblog\u002Fmanaged-agent-harness-vs-self-hosted-agent-loop-what-you-gain-what-you-lose\" class=\"flex flex-col sm:flex-row gap-4 rounded-xl border border-gray-200 dark:border-gray-700 p-4 transition hover:border-primary-500\">\u003Cdiv class=\"min-w-0 flex-1\">\u003Cstrong class=\"block text-lg text-gray-900 dark:text-gray-100\">Управляемая обвязка агентов против автономного цикла: что вы получаете и что теряете\u003C\u002Fstrong>\u003Cp class=\"mt-2 text-sm text-gray-600 dark:text-gray-300\">Границы протоколов решают вопросы интероперабельности. Границы среды выполнения определяют, кто управляет обвязкой, средой выполнения и плоскостью управления приложением.\u003C\u002Fp>\u003Cspan class=\"mt-3 inline-flex text-sm font-medium text-primary-600 dark:text-primary-400\">Читать руководство по архитектуре среды выполнения →\u003C\u002Fspan>\u003C\u002Fdiv>\u003C\u002Fa>\u003C\u002Faside>\n\u003Ch2 id=\"section-60\">Что может изменить этот расклад?\u003C\u002Fh2>\n\u003Cp>Стек изменится, если протоколы сойдутся воедино, один стандарт формально поглотит другой или поставщики стандартизируют общий уровень идентификации и авторизации для нескольких границ. UCP уже демонстрирует композицию, поддерживая API, A2A и MCP, а также интегрируясь с AP2 вместо их вытеснения.\u003C\u002Fp>\n\u003Cp>Ответ также зависит от масштаба приложения. Небольшому внутреннему агенту может потребоваться только MCP. Мультикорпоративному рабочему процессу может понадобиться A2A. Продавцу может потребоваться UCP без A2UI. Делегированному агенту по закупкам могут потребоваться все эти стандарты. Используйте минимальный набор протоколов, который отражает реальные границы, не упрощая доменную семантику.\u003C\u002Fp>\n\u003Ch2 id=\"section-63\">Ограничения\u003C\u002Fh2>\n\u003Cp>Обсуждаемые здесь протоколы находятся на разных уровнях зрелости и имеют разные модели управления. A2A достиг стабильной спецификации версии 1.0, тогда как другие стандарты продолжают быстро развиваться. Внедрение в экосистему также распределено неравномерно среди поставщиков и фреймворков.\u003C\u002Fp>\n\u003Cp>Эта статья сосредоточена на архитектурной ответственности, а не на полноте реализации. Конкретные методы аутентификации, транспортные привязки, схемы и механизмы расширения следует брать из текущей спецификации каждого протокола.\u003C\u002Fp>\n\u003Ch2 id=\"section-66\">Заключение\u003C\u002Fh2>\n\u003Cp>MCP, A2A, UCP, AP2 и A2UI становятся более понятными, если рассматривать их как протоколы для различных типов взаимодействия, а не как пять конкурирующих попыток стандартизировать «агентов».\u003C\u002Fp>\n\u003Cp>MCP открывает доступ к возможностям. A2A координирует независимых агентов. UCP дает коммерции собственный машиночитаемый контракт. AP2 добавляет верифицируемые полномочия для платежей. A2UI предоставляет агентам безопасный декларативный способ взаимодействия с пользовательскими интерфейсами. Таким образом, формирующийся агентный веб не заменяет протоколы искусственным интеллектом — он создает новый стек протоколов вокруг ИИ.\u003C\u002Fp>\n\u003Ch2 id=\"section-69\">Часто задаваемые вопросы\u003C\u002Fh2>\n\u003Csection class=\"editorjs-faq my-6 rounded-xl border border-gray-200 p-5 dark:border-gray-700\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">MCP, A2A, UCP, AP2 и A2UI\u003C\u002Fh3>\u003Cdiv id=\"faq1\" class=\"border-t border-gray-200 py-4 first:border-t-0 dark:border-gray-700\">\u003Ch4 class=\"font-semibold text-gray-900 dark:text-gray-100\">Является ли A2A заменой MCP?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Нет. MCP в первую очередь стандартизирует то, как приложения ИИ получают доступ к инструментам, ресурсам и данным. A2A стандартизирует взаимодействие между независимыми агентными системами. Удаленный агент может внутри себя использовать MCP, предоставляя наружу интерфейс A2A.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv id=\"faq2\" class=\"border-t border-gray-200 py-4 first:border-t-0 dark:border-gray-700\">\u003Ch4 class=\"font-semibold text-gray-900 dark:text-gray-100\">Является ли UCP заменой MCP для торговых агентов?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">В целом нет. UCP предоставляет специфичную для коммерции семантику, такую как корзина, оформление заказа и исполнение. MCP по-прежнему может открывать доступ к инструментам или данным продавца, и UCP спроектирован для сосуществования с MCP и A2A.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv id=\"faq3\" class=\"border-t border-gray-200 py-4 first:border-t-0 dark:border-gray-700\">\u003Ch4 class=\"font-semibold text-gray-900 dark:text-gray-100\">В чем разница между UCP и AP2?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">UCP стандартизирует коммерческие взаимодействия и жизненный цикл транзакций. AP2 фокусируется на подтверждении того, что агент обладал полномочиями совершить платеж в рамках установленных пользовательских или организационных ограничений.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv id=\"faq4\" class=\"border-t border-gray-200 py-4 first:border-t-0 dark:border-gray-700\">\u003Ch4 class=\"font-semibold text-gray-900 dark:text-gray-100\">Какую проблему решает A2UI?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">A2UI позволяет агентам отправлять декларативное описание намерений по интерфейсу хост-приложению, которое отрисовывает его с помощью доверенных нативных компонентов вместо выполнения произвольного удаленного фронтенд-кода.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv id=\"faq5\" class=\"border-t border-gray-200 py-4 first:border-t-0 dark:border-gray-700\">\u003Ch4 class=\"font-semibold text-gray-900 dark:text-gray-100\">Может ли одно агентное приложение использовать все эти протоколы?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Да. Рабочий процесс может использовать MCP для внутренних инструментов, A2A для делегирования задач удаленным агентам, UCP для коммерции, AP2 для авторизации платежей и A2UI для взаимодействия с человеком.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv id=\"faq6\" class=\"border-t border-gray-200 py-4 first:border-t-0 dark:border-gray-700\">\u003Ch4 class=\"font-semibold text-gray-900 dark:text-gray-100\">Какой протокол следует внедрить первым?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Отталкивайтесь от границы интероперабельности. Если задача — доступ к инструментам, оцените MCP. Если взаимодействие независимых агентов — оцените A2A. Если коммерция — UCP. Если делегированные полномочия на платежи — AP2. Если переносимый агентный UI — A2UI.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Ch2 id=\"section-71\">Глоссарий\u003C\u002Fh2>\n\u003Csection class=\"editorjs-glossary my-6 rounded-xl border border-gray-200 dark:border-gray-700 p-5\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">Ключевые термины протоколов агентов\u003C\u002Fh3>\u003Cdl>\u003Cdiv id=\"mcp\" class=\"border-t border-gray-200 dark:border-gray-700 py-3 first:border-t-0\">\u003Cdt class=\"font-semibold text-gray-900 dark:text-gray-100\">MCP\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Model Context Protocol — открытый стандарт для предоставления инструментов, ресурсов и промптов из внешних систем совместимым хостам ИИ.\u003C\u002Fdd>\u003C\u002Fdiv>\u003Cdiv id=\"a2a\" class=\"border-t border-gray-200 dark:border-gray-700 py-3 first:border-t-0\">\u003Cdt class=\"font-semibold text-gray-900 dark:text-gray-100\">A2A\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Agent2Agent Protocol — открытый стандарт для обнаружения независимых агентных систем и взаимодействия с ними посредством сообщений, задач и артефактов.\u003C\u002Fdd>\u003C\u002Fdiv>\u003Cdiv id=\"ucp\" class=\"border-t border-gray-200 dark:border-gray-700 py-3 first:border-t-0\">\u003Cdt class=\"font-semibold text-gray-900 dark:text-gray-100\">UCP\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Universal Commerce Protocol — открытый стандарт для интероперабельных сценариев агентной коммерции между интерфейсами потребителей, бизнесом и платежными провайдерами.\u003C\u002Fdd>\u003C\u002Fdiv>\u003Cdiv id=\"ap2\" class=\"border-t border-gray-200 dark:border-gray-700 py-3 first:border-t-0\">\u003Cdt class=\"font-semibold text-gray-900 dark:text-gray-100\">AP2\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Agent Payments Protocol — открытый стандарт для представления и проверки полномочий, намерений и подотчетности в платежах, управляемых агентами.\u003C\u002Fdd>\u003C\u002Fdiv>\u003Cdiv id=\"a2ui\" class=\"border-t border-gray-200 dark:border-gray-700 py-3 first:border-t-0\">\u003Cdt class=\"font-semibold text-gray-900 dark:text-gray-100\">A2UI\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Agent-to-User Interface — декларативный протокол, позволяющий агентам запрашивать интерфейс, который отрисовывается с использованием доверенных компонентов хост-приложения.\u003C\u002Fdd>\u003C\u002Fdiv>\u003Cdiv id=\"protocol-composition\" class=\"border-t border-gray-200 dark:border-gray-700 py-3 first:border-t-0\">\u003Cdt class=\"font-semibold text-gray-900 dark:text-gray-100\">Композиция протоколов\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Использование нескольких протоколов в одном рабочем процессе, где каждый отвечает за отдельную границу интероперабельности, вместо принудительного пропуска всей семантики через один контракт.\u003C\u002Fdd>\u003C\u002Fdiv>\u003C\u002Fdl>\u003C\u002Fsection>\n\u003Ch2 id=\"section-73\">Основные источники и материалы для дальнейшего чтения\u003C\u002Fh2>\n\u003Ca href=\"https:\u002F\u002Fdevelopers.googleblog.com\u002Fdevelopers-guide-to-ai-agent-protocols\u002F\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">Google Developers — Руководство разработчика по протоколам ИИ-агентов\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Практический обзор совместной работы MCP, A2A, UCP, AP2, A2UI и связанных протоколов в рамках единого многоэтапного рабочего процесса агентов.\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fts.sdk.modelcontextprotocol.io\u002Fv2\u002F\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">Model Context Protocol — TypeScript SDK v2\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Текущая стабильная документация SDK, реализующая спецификацию MCP от 28.07.2026 и определяющая инструменты, ресурсы, промпты и интеграцию с хостом и сервером.\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fa2a-protocol.org\u002Fdev\u002Fspecification\u002F\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">Протокол A2A — Спецификация v1.0\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Текущая спецификация протокола A2A, охватывающая карточки агентов (Agent Cards), сообщения, задачи, артефакты, привязки и согласование версий.\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fa2a-protocol.org\u002Flatest\u002Fblog\u002F2026\u002F08\u002F27\u002Fa-new-chapter-for-a2a-joining-the-agentic-ai-foundation\u002F\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">A2A — Присоединение к Agentic AI Foundation\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Текущее позиционирование проекта A2A в качестве горизонтального уровня взаимодействия агентов наряду с MCP как вертикальной интеграцией инструментов и данных.\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fdevelopers.googleblog.com\u002Funder-the-hood-universal-commerce-protocol-ucp\u002F\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">Google Developers — Под капотом: Universal Commerce Protocol\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Технический обзор UCP, его коммерческих примитивов и возможностей композиции с API, A2A, MCP и AP2.\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fdevelopers.google.com\u002Fmerchant\u002Fucp\u002Fimplementation\u002F2026-04-08\u002Fpublish-profile\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">Google Universal Commerce Protocol — Профиль UCP\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Текущий версионированный механизм профилей для публикации сервисов UCP и коммерческих возможностей продавцов.\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fcloud.google.com\u002Fblog\u002Fproducts\u002Fai-machine-learning\u002Fannouncing-agents-to-payments-ap2-protocol\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">Google Cloud — Протокол платежей агентов (AP2)\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Анонс и обоснование открытого протокола, охватывающего авторизацию, подлинность и подотчетность в платежах, совершаемых агентами.\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fdevelopers.googleblog.com\u002Fa2ui-v0-9-generative-ui\u002F\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">Google Developers — A2UI v0.9\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Фреймворко-независимая декларативная модель A2UI для переносимых интерфейсов под управлением агентов, отображаемых нативными компонентами хоста.\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fdevelopers.googleblog.com\u002Fa2ui-and-mcp-apps\u002F\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">Google Developers — A2UI + MCP Apps\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Как декларативный подход A2UI и более богатый функционал MCP App могут сосуществовать, не выступая взаимоисключающими моделями интерфейса.\u003C\u002Fp>\u003C\u002Fa>",{"time":212,"blocks":213,"version":895},1790364406714,[214,222,228,236,243,250,255,260,265,270,306,313,318,323,328,333,345,351,356,361,366,371,376,386,391,423,428,433,438,443,448,453,463,468,473,478,483,488,515,520,525,530,535,540,550,555,560,589,594,618,623,628,633,638,643,676,681,686,691,700,705,710,715,720,725,730,735,740,745,750,780,785,808,813,823,832,841,850,859,868,877,886],{"id":215,"data":216,"type":220,"tunes":221},"_z4yTl5Fh-",{"title":217,"maxLevel":218,"minLevel":219},"Содержание",3,2,"tableOfContents",{},{"id":223,"data":224,"type":226,"tunes":227},"intro",{"text":225},"Протоколы для ИИ-агентов стремительно множатся: MCP, A2A, UCP, AP2, A2UI и смежные стандарты все чаще появляются на одних и тех же архитектурных схемах. Их нередко описывают как конкурирующие протоколы. На практике большинство из них решает различные задачи интероперабельности на разных уровнях взаимодействия. Правильный вопрос заключается не в том, «Какой протокол победит?», а в том, «Какую связь в системе необходимо стандартизировать?»","paragraph",{},{"id":229,"data":230,"type":234,"tunes":235},"direct",{"body":231,"title":232,"variant":233},"\u003Cstrong>MCP, A2A, UCP, AP2 и A2UI в основном дополняют друг друга, а не заменяют.\u003C\u002Fstrong> MCP подключает ИИ-приложение к инструментам, данным и ресурсам. A2A связывает независимых агентов друг с другом. UCP стандартизирует коммерческие взаимодействия между пользовательскими интерфейсами, бизнесом и платежными экосистемами. AP2 добавляет проверяемую авторизацию и платежные намерения в транзакции под управлением агентов. A2UI позволяет агенту описывать интерактивный пользовательский интерфейс без отправки произвольного кода приложения. Промышленная система может вполне обоснованно использовать несколько из них в рамках одного рабочего процесса.","Прямой ответ","info","callout",{},{"id":237,"data":238,"type":234,"tunes":242},"freshness",{"body":239,"title":240,"variant":241},"В этой статье отражено состояние экосистемы протоколов на \u003Cstrong>25 сентября 2026 года\u003C\u002Fstrong>. A2A достиг версии 1.0, текущая линейка MCP TypeScript v2 реализует спецификацию от 28.07.2026, UCP уже добавил более новые версии протокола 2026 года, а A2UI продолжает развиваться. Всегда проверяйте актуальную спецификацию перед внедрением.","Быстро меняющиеся стандарты","warning",{},{"id":244,"data":245,"type":234,"tunes":249},"model-note",{"body":246,"title":247,"variant":248},"Стек зон ответственности протоколов (Protocol Responsibility Stack) и тест выбора протокола (Protocol Selection Test) ниже представляют собой практические архитектурные модели, предложенные здесь. Они не являются официальной терминологией проектов протоколов.","Модель, используемая в этой статье","note",{},{"id":251,"data":252,"type":42,"tunes":254},"h-core",{"text":253,"level":219},"Главная ошибка: сравнение протоколов, находящихся на разных уровнях взаимодействия",{},{"id":256,"data":257,"type":226,"tunes":259},"p-core-1",{"text":258},"Протокол полезен потому, что двум независимо реализованным системам необходим стабильный контракт. Контракт имеет смысл только тогда, когда четко определены границы взаимодействия. Агент, обращающийся к базе данных, решает принципиально иную задачу интероперабельности, чем агент, делегирующий работу другому агенту, покупатель, подтверждающий покупку, или удаленный агент, запрашивающий у нативного приложения отрисовку формы.",{},{"id":261,"data":262,"type":226,"tunes":264},"p-core-2",{"text":263},"В руководстве для разработчиков от Google за 2026 год MCP, A2A, UCP, AP2, A2UI и связанные с ними протоколы пользовательского интерфейса прямо представлены как стек взаимодополняющих стандартов. В одном и том же примере рабочего процесса несколько из них могут использоваться совместно: инструменты для учета запасов, удаленные агенты для поставщиков, коммерция для оформления заказа, авторизация платежей для списания средств и протоколы пользовательского интерфейса для взаимодействия.",{},{"id":266,"data":267,"type":42,"tunes":269},"h-stack",{"text":268,"level":219},"Стек зон ответственности протоколов",{},{"id":271,"data":272,"type":304,"tunes":305},"stack-table",{"content":273,"stretched":43,"withHeadings":14},[274,279,284,289,294,299],[275,276,277,278],"Протокол","Какую связь стандартизирует?","Основная абстракция","В первую очередь не предназначен для",[280,281,282,283],"MCP","ИИ-приложение ↔ инструменты, ресурсы и данные","Инструменты, ресурсы, промпты и обмен возможностями между хостом и сервером","Сотрудничества независимых агентов или семантики электронной коммерции",[285,286,287,288],"A2A","Агент ↔ независимый агент","Обнаружение агентов, сообщения, задачи, артефакты и длительное сотрудничество","Прямой интеграции баз данных\u002Fинструментов",[290,291,292,293],"UCP","Интерфейс пользователя\u002Fагента ↔ коммерческая система продавца","Возможности управления товарами\u002Fкорзиной\u002Fоформлением заказа\u002Fдоставкой\u002Fзаказами","Общей коммуникации между агентами общего назначения",[295,296,297,298],"AP2","Намерение пользователя\u002Fагента ↔ авторизация платежа","Мандаты, ограничения на утверждение и проверяемые полномочия на проведение платежей агентами","Поиска товаров или общего транспорта для оформления заказа",[300,301,302,303],"A2UI","Агент ↔ хост пользовательского интерфейса","Декларативное намерение интерфейса, отрисовываемое доверенными нативными компонентами","Произвольного удаленного кода фронтенда или делегирования задач между агентами","table",{},{"id":307,"data":308,"type":234,"tunes":312},"all-five",{"body":309,"title":310,"variant":311},"Агент может использовать \u003Cstrong>MCP\u003C\u002Fstrong> для проверки складских запасов, \u003Cstrong>A2A\u003C\u002Fstrong> для запроса доступности у агента поставщика, \u003Cstrong>UCP\u003C\u002Fstrong> для формирования коммерческой транзакции, \u003Cstrong>AP2\u003C\u002Fstrong> для подтверждения полномочий на оплату и \u003Cstrong>A2UI\u003C\u002Fstrong> для отображения пользователю нативного интерфейса подтверждения.","Один рабочий процесс может использовать все пять","success",{},{"id":314,"data":315,"type":42,"tunes":317},"h-mcp",{"text":316,"level":219},"1. MCP: подключение агента к возможностям",{},{"id":319,"data":320,"type":226,"tunes":322},"p-mcp-1",{"text":321},"Model Context Protocol — это открытый стандарт для подключения ИИ-приложений к внешним системам, где находятся инструменты, данные и переиспользуемые ресурсы. Сервер предоставляет возможности; MCP-хост подключается к этому серверу и делает эти возможности доступными модели или приложению.",{},{"id":324,"data":325,"type":226,"tunes":327},"p-mcp-2",{"text":326},"Текущая документация MCP TypeScript v2 описывает протокол именно в таких терминах: серверы предоставляют инструменты, ресурсы и промпты, в то время как хосты, такие как среды разработки или пользовательские приложения, подключаются к ним. Это делает MCP в первую очередь протоколом интеграции возможностей.",{},{"id":329,"data":330,"type":42,"tunes":332},"h-mcp-use",{"text":331,"level":218},"Используйте MCP, когда",{},{"id":334,"data":335,"type":343,"tunes":344},"mcp-list",{"meta":336,"items":337,"style":342},{},[338,339,340,341],"ИИ-приложению требуется стандартизированный доступ к инструментам или API.","Вам нужно, чтобы один сервер возможностей работал с несколькими совместимыми ИИ-хостами.","Вам необходим структурированный доступ к данным или ресурсам без жесткого кодирования каждой интеграции в каждого агента.","Внешняя система является поставщиком возможностей, а не автономным одноранговым агентом.","unordered","list",{},{"id":346,"data":347,"type":234,"tunes":350},"mcp-warning",{"body":348,"title":349,"variant":241},"MCP-сервер может предоставлять мощные функции, но это не делает его независимым агентом с собственным жизненным циклом задач, семантикой обнаружения и непрозрачной внутренней логикой рассуждений. Вызов инструментов и сотрудничество агентов — это разные контракты.","MCP автоматически не является A2A",{},{"id":352,"data":353,"type":42,"tunes":355},"h-a2a",{"text":354,"level":219},"2. A2A: подключение независимых агентов",{},{"id":357,"data":358,"type":226,"tunes":360},"p-a2a-1",{"text":359},"Agent2Agent (A2A) разработан для взаимодействия между независимыми, потенциально непрозрачными агентскими системами. Его текущая спецификация v1.0 сосредоточена на обнаружении возможностей, обмене сообщениями, задачах, артефактах, мультимодальном контенте и длительном сотрудничестве без необходимости раскрывать внутренние инструменты, память или реализацию одного агента другому.",{},{"id":362,"data":363,"type":226,"tunes":365},"p-a2a-2",{"text":364},"Эта непрозрачность является важной границей. Вызывающему агенту не нужно знать, использует ли удаленный агент внутри себя MCP, кастомные инструменты, проприетарный планировщик, модель другого поставщика или эскалацию на человека. Ему необходим контракт для обнаружения возможностей и делегирования работы.",{},{"id":367,"data":368,"type":226,"tunes":370},"p-a2a-3",{"text":369},"A2A v1.0 также стандартизирует согласование версий и поддерживает различные привязки вокруг общей модели данных. Опубликованный механизм Agent Card предоставляет клиентам стандартную точку обнаружения возможностей агента, поддерживаемых протоколов, требований к аутентификации и навыков.",{},{"id":372,"data":373,"type":42,"tunes":375},"h-a2a-use",{"text":374,"level":218},"Используйте A2A, когда",{},{"id":377,"data":378,"type":343,"tunes":385},"a2a-list",{"meta":379,"items":380,"style":342},{},[381,382,383,384],"Одному автономному агенту необходимо делегировать работу другому автономному агенту.","Удаленная система должна оставаться непрозрачной за контрактом возможностей.","Задачи могут быть длительными, асинхронными или требовать участия человека (human-in-the-loop).","Агенты построены на базе различных фреймворков, языков, решений разных вендоров или принадлежат разным организациям.",{},{"id":387,"data":388,"type":42,"tunes":390},"h-mcp-a2a",{"text":389,"level":219},"MCP против A2A: вертикальная интеграция против горизонтального сотрудничества",{},{"id":392,"data":393,"type":421,"tunes":422},"mcp-a2a-comparison",{"rows":394,"title":412,"layout":304,"columns":413},[395,400,404,408],{"id":396,"label":397,"values":398},"relationship","Взаимосвязь",[399,399,399],"",{"id":401,"label":402,"values":403},"abstraction","Абстракция",[399,399,399],{"id":405,"label":406,"values":407},"opacity","Внутренняя непрозрачность",[399,399,399],{"id":409,"label":410,"values":411},"long","Длительные задачи",[399,399,399],"MCP и A2A решают различные проблемы интероперабельности",[414,417,419],{"id":415,"label":416},"dimension","Критерий",{"id":418,"label":280},"mcp",{"id":420,"label":285},"a2a","comparison",{},{"id":424,"data":425,"type":226,"tunes":427},"p-mcp-a2a-1",{"text":426},"Сам проект A2A сейчас описывает это различие как горизонтальное против вертикального: MCP подключает агентов к внутренним инструментам и базам данных, тогда как A2A обеспечивает одноранговое (peer-to-peer) сотрудничество между агентскими системами.",{},{"id":429,"data":430,"type":42,"tunes":432},"h-ucp",{"text":431,"level":219},"3. UCP: стандартизация агентской коммерции",{},{"id":434,"data":435,"type":226,"tunes":437},"p-ucp-1",{"text":436},"Universal Commerce Protocol не является универсальным протоколом для агентов общего назначения. Он стандартизирует коммерческие сценарии между клиентскими интерфейсами, продавцами и платежными провайдерами. Реализация от Google уже поддерживает такие возможности, как создание корзины, оформление заказа, исполнение и жизненный цикл заказа с помощью версионированных профилей и API.",{},{"id":439,"data":440,"type":226,"tunes":442},"p-ucp-2",{"text":441},"Продавец может опубликовать UCP-профиль по адресу \u002F.well-known\u002Fucp с описанием сервисов, версий протокола и возможностей. Этот паттерн обнаружения важен, поскольку агентскому интерфейсу не должен требоваться индивидуальный контракт на оформление заказа для каждого продавца.",{},{"id":444,"data":445,"type":226,"tunes":447},"p-ucp-3",{"text":446},"UCP также намеренно сделан компонуемым. В техническом обзоре Google говорится, что он может интегрироваться через API, A2A и MCP, а также совместим с AP2 для авторизации платежей агентами.",{},{"id":449,"data":450,"type":42,"tunes":452},"h-ucp-use",{"text":451,"level":218},"Используйте UCP, когда",{},{"id":454,"data":455,"type":343,"tunes":462},"ucp-list",{"meta":456,"items":457,"style":342},{},[458,459,460,461],"Рабочий процесс включает товары продавца, корзины, оформление заказа, исполнение или жизненный цикл заказа.","Вы создаете интерфейс продавца, который должен работать с агентскими сценариями покупок.","Интеграции требуется семантика, специфичная для электронной коммерции, а не стандартные вызовы инструментов.","Вам нужен совместимый коммерческий контракт, который может сосуществовать с MCP, A2A и платежными протоколами.",{},{"id":464,"data":465,"type":42,"tunes":467},"h-ap2",{"text":466,"level":219},"4. AP2: подтверждение права агента совершать траты",{},{"id":469,"data":470,"type":226,"tunes":472},"p-ap2-1",{"text":471},"Агентская коммерция порождает проблему, с которой обычные сценарии оформления заказа не сталкивались напрямую: агент может совершать транзакции без непосредственного нажатия финальной кнопки человеком в реальном времени. Agent Payments Protocol (AP2) решает вопросы авторизации, подлинности и подотчетности для платежей, инициируемых агентами.",{},{"id":474,"data":475,"type":226,"tunes":477},"p-ap2-2",{"text":476},"В руководстве по протоколу Google за 2026 год AP2 описывается через типизированные мандаты, фиксирующие намерения пользователя, ограничения на расходы и конкретную авторизуемую транзакцию. AP2 может работать как расширение вместе с UCP: UCP описывает коммерческую транзакцию, а AP2 подтверждает полномочия агента на проведение платежа.",{},{"id":479,"data":480,"type":226,"tunes":482},"p-ap2-3",{"text":481},"Это различие принципиально. Протокол оформления заказа может сообщить продавцу, что именно необходимо приобрести. Однако сам по себе он не подтверждает, кто уполномочил агента тратить средства, в каких пределах, у какого продавца, на какой срок и оставалась ли итоговая корзина в рамках этих полномочий.",{},{"id":484,"data":485,"type":42,"tunes":487},"h-ucp-ap2",{"text":486,"level":219},"UCP против AP2: семантика транзакций против полномочий",{},{"id":489,"data":490,"type":304,"tunes":514},"ucp-ap2-table",{"content":491,"stretched":43,"withHeadings":14},[492,494,498,502,506,510],[493,290,295],"Вопрос",[495,496,497],"Что покупается?","Товары, корзина, семантика оформления заказа и исполнения","Ссылается на авторизованный контекст транзакции",[499,500,501],"Кто может это авторизовать?","Не является основной зоной ответственности протокола","Явная модель полномочий и мандатов агента\u002Fпользователя",[503,504,505],"Какие ограничения на расходы применяются?","Торговый сценарий может содержать итоговые суммы и данные оформления заказа","Ограничения авторизации и лимиты намерений",[507,508,509],"Как проводится аудит транзакции?","Жизненный цикл заказа и торговли","Криптографический \u002F проверяемый след авторизации через мандаты и квитанции",[511,512,513],"Могут ли они работать вместе?","Да","Да — AP2 может расширять сценарии коммерции с участием агентов",{},{"id":516,"data":517,"type":42,"tunes":519},"h-a2ui",{"text":518,"level":219},"5. A2UI: позвольте агентам описывать интерфейсы, не отдавая им контроль над вашим фронтендом",{},{"id":521,"data":522,"type":226,"tunes":524},"p-a2ui-1",{"text":523},"Agent-to-User Interface (A2UI) решает задачу другой границы: как удаленный или локальный агент передает насыщенный интерактивный интерфейс хост-приложению. Вместо отправки произвольного HTML, CSS и JavaScript, A2UI использует декларативные данные, которые хост отрисовывает через собственный доверенный каталог компонентов.",{},{"id":526,"data":527,"type":226,"tunes":529},"p-a2ui-2",{"text":528},"Это сохраняет дизайн-систему и модель безопасности хост-приложения, позволяя агенту запрашивать динамические интерфейсы. A2UI v0.9 особо акцентирует внимание на независимых от фреймворков намерениях UI и потоковых обновлениях для веба, мобильных и других клиентов.",{},{"id":531,"data":532,"type":226,"tunes":534},"p-a2ui-3",{"text":533},"Последующая работа Google над связкой A2UI + MCP Apps также демонстрирует, что эти модели UI не обязательно исключают друг друга. Декларативный нативный UI и более богатый опыт встроенных приложений могут сосуществовать в зависимости от задачи.",{},{"id":536,"data":537,"type":42,"tunes":539},"h-a2ui-use",{"text":538,"level":218},"Используйте A2UI, когда",{},{"id":541,"data":542,"type":343,"tunes":549},"a2ui-list",{"meta":543,"items":544,"style":342},{},[545,546,547,548],"Удаленному агенту необходимо запрашивать формы, карточки, элементы управления или другой интерактивный UI.","Хост должен сохранять свои нативные компоненты, стилизацию и периметр безопасности.","Вы не хотите, чтобы удаленные агенты передавали произвольный исполняемый код фронтенда.","Одно и то же определенное агентом намерение UI должно работать в различных клиентских фреймворках.",{},{"id":551,"data":552,"type":42,"tunes":554},"h-selection",{"text":553,"level":219},"Тест для выбора протокола",{},{"id":556,"data":557,"type":226,"tunes":559},"p-selection-intro",{"text":558},"Отталкивайтесь не от аббревиатуры. Отталкивайтесь от взаимодействия, требующего интероперабельности.",{},{"id":561,"data":562,"type":587,"tunes":588},"selection-flow",{"steps":563,"title":585,"orientation":586},[564,567,570,573,576,579,582],{"label":565,"description":566},"1. Определите две независимые стороны","Это взаимодействие ИИ с инструментом, агента с агентом, агента с продавцом, агента с органом авторизации платежей или агента с пользовательским интерфейсом?",{"label":568,"description":569},"2. Определите разделяемый объект","Является ли контракт вызовом инструмента, задачей, корзиной, платежным мандатом, артефактом или описанием UI?",{"label":571,"description":572},"3. Проверьте, существует ли уже доменный протокол","Отдавайте предпочтение семантике коммерции или платежей, если задача связана с коммерцией или авторизацией, вместо кодирования всего подряд в виде универсальных инструментов.",{"label":574,"description":575},"4. Оставляйте внутренние детали локальными","Не раскрывайте всего агента как MCP-инструменты, если удаленной стороне требуется лишь возможность A2A, и не возлагайте на удаленного агента ответственность за среду выполнения вашего UI.",{"label":577,"description":578},"5. Комбинируйте протоколы, когда рабочий процесс пересекает границы","Один рабочий процесс может правомерно пересекать контракты инструментов, агентов, коммерции, платежей и UI.",{"label":580,"description":581},"6. Версионируйте каждый контракт независимо","Версии протоколов развиваются с разной скоростью; не привязывайте каждую интеграцию к одной монолитной версии приложения.",{"label":583,"description":584},"7. Сохраняйте авторизацию на каждой границе","Интероперабельность не заменяет продуктовые права доступа, авторизацию инструментов, платежные полномочия или политики доступа к данным.","Выбирайте протокол по границе взаимодействия","auto","processFlow",{},{"id":590,"data":591,"type":42,"tunes":593},"h-workflow",{"text":592,"level":219},"Реалистичный мультипротокольный рабочий процесс",{},{"id":595,"data":596,"type":587,"tunes":617},"workflow-flow",{"steps":597,"title":616,"orientation":586},[598,601,604,607,610,613],{"label":599,"description":600},"1. Проверка внутренних запасов с помощью MCP","Агент по закупкам вызывает функции складского учета и прогнозирования, предоставляемые внутренними MCP-серверами.",{"label":602,"description":603},"2. Поиск агента поставщика с помощью A2A","Агент считывает Agent Card поставщика и делегирует задачу по проверке доступности и сроков поставки.",{"label":605,"description":606},"3. Согласование объекта коммерции с помощью UCP","Интерфейс поставщика или продавца возвращает структурированную информацию о корзине, оформлении заказа и исполнении.",{"label":608,"description":609},"4. Проверка полномочий на расходы с помощью AP2","Покупка сопоставляется с подписанным мандатом пользователя или организации, ограничениями продавца и лимитами расходов.",{"label":611,"description":612},"5. Запрос одобрения через A2UI","Если требуется одобрение человека, агент отправляет декларативное намерение UI, а хост отрисовывает интерфейс утверждения с использованием доверенных нативных компонентов.",{"label":614,"description":615},"6. Завершение и аудит","Состояние коммерции, авторизация платежа, подтверждения выполнения задач агентом и записи аудита приложения остаются отслеживаемыми в рамках соответствующих границ.","Пример: рабочий процесс автономных закупок",{},{"id":619,"data":620,"type":42,"tunes":622},"h-universal",{"text":621,"level":219},"Почему один универсальный агентный протокол вряд ли заменит их все",{},{"id":624,"data":625,"type":226,"tunes":627},"p-universal-1",{"text":626},"Универсальный протокол кажется более простым решением ровно до тех пор, пока ему не потребуется описывать семантику каждой предметной области. Обнаружение инструментов, длительное взаимодействие агентов, оформление заказов, авторизация платежей и нативный UI имеют совершенно разные требования к жизненному циклу, безопасности и корректности.",{},{"id":629,"data":630,"type":226,"tunes":632},"p-universal-2",{"text":631},"Сам веб развивался за счет многоуровневых протоколов, а не единого формата сообщений для всех задач. Формирующийся стек для агентов движется в том же направлении: общие горизонтальные примитивы, специализированные доменные контракты и явные механизмы обнаружения и версионирования.",{},{"id":634,"data":635,"type":226,"tunes":637},"p-universal-3",{"text":636},"Таким образом, архитектурная задача смещается с вопроса «какой протокол победит?» к вопросу о том, насколько органично протоколы сочетаются между собой без дублирования семантики идентификации, авторизации, состояния и аудита.",{},{"id":639,"data":640,"type":42,"tunes":642},"h-failures",{"text":641,"level":219},"Композиция протоколов создает новые сценарии сбоев",{},{"id":644,"data":645,"type":304,"tunes":675},"failure-table",{"content":646,"stretched":43,"withHeadings":14},[647,651,655,659,663,667,671],[648,649,650],"Режим сбоя","Что происходит","Архитектурный контроль",[652,653,654],"Утечка полномочий","Допустимый инструмент или возможность агента воспринимаются как разрешение на выполнение бизнес-действия","Обеспечьте независимость авторизации на уровне продукта от обнаружения возможностей протокола",[656,657,658],"Несоответствие идентификаторов","Идентификатор хоста MCP, идентификатор агента A2A и идентификатор коммерции\u002Fплатежей относятся к разным субъектам","Определите явное сопоставление субъектов (principals) через границы протоколов",[660,661,662],"Дрейф версий","Один протокол обновляется, в то время как зависимые адаптеры предполагают старую семантику","Согласовывайте и фиксируйте версии протоколов независимо",[664,665,666],"Дублирование состояния","Одно и то же состояние корзины, задачи или утверждения копируется на несколько уровней протокола","Определите одного авторитетного владельца для каждого доменного объекта",[668,669,670],"Фрагментация аудита","Трассировки инструментов, задачи агентов, подтверждения оформления заказа и платежей не могут быть объединены","Передавайте корреляционные идентификаторы и стабильные доменные идентификаторы через границы протоколов",[672,673,674],"Семантическое туннелирование","Все принудительно прогоняется через универсальный протокол в виде непрозрачного JSON","Используйте доменные протоколы там, где их семантика существенно повышает корректность",{},{"id":677,"data":678,"type":42,"tunes":680},"h-app-arch",{"text":679,"level":219},"Выбор протокола не заменяет архитектуру приложения",{},{"id":682,"data":683,"type":226,"tunes":685},"p-app-1",{"text":684},"Открытые стандарты снижают связность интеграции, но они не определяют вашу доменную модель, политику авторизации, источник истины, стратегию повторных попыток или критерии приемки. Инструмент MCP все еще может предоставить не ту возможность. Агент A2A все еще может вернуть некорректный артефакт. Оформление заказа UCP все еще может содержать устаревшие данные продавца. Мандат AP2 все еще может быть неверно применен логикой приложения.",{},{"id":687,"data":688,"type":226,"tunes":690},"p-app-2",{"text":689},"Относитесь к протоколам как к контрактам между независимо развивающимися компонентами. Сохраняйте доменную истину и определяющие политики на уровне приложения, которому они принадлежат, а затем используйте протоколы для обеспечения интероперабельности границ.",{},{"id":692,"data":693,"type":698,"tunes":699},"ref-harness",{"url":694,"title":695,"excerpt":696,"ctaLabel":697},"https:\u002F\u002Fstajic.de\u002Fru\u002Fblog\u002Fmanaged-agent-harness-vs-self-hosted-agent-loop-what-you-gain-what-you-lose","Управляемая обвязка агентов против автономного цикла: что вы получаете и что теряете","Границы протоколов решают вопросы интероперабельности. Границы среды выполнения определяют, кто управляет обвязкой, средой выполнения и плоскостью управления приложением.","Читать руководство по архитектуре среды выполнения","referralArticle",{},{"id":701,"data":702,"type":42,"tunes":704},"h-change",{"text":703,"level":219},"Что может изменить этот расклад?",{},{"id":706,"data":707,"type":226,"tunes":709},"p-change-1",{"text":708},"Стек изменится, если протоколы сойдутся воедино, один стандарт формально поглотит другой или поставщики стандартизируют общий уровень идентификации и авторизации для нескольких границ. UCP уже демонстрирует композицию, поддерживая API, A2A и MCP, а также интегрируясь с AP2 вместо их вытеснения.",{},{"id":711,"data":712,"type":226,"tunes":714},"p-change-2",{"text":713},"Ответ также зависит от масштаба приложения. Небольшому внутреннему агенту может потребоваться только MCP. Мультикорпоративному рабочему процессу может понадобиться A2A. Продавцу может потребоваться UCP без A2UI. Делегированному агенту по закупкам могут потребоваться все эти стандарты. Используйте минимальный набор протоколов, который отражает реальные границы, не упрощая доменную семантику.",{},{"id":716,"data":717,"type":42,"tunes":719},"h-limitations",{"text":718,"level":219},"Ограничения",{},{"id":721,"data":722,"type":226,"tunes":724},"p-limit-1",{"text":723},"Обсуждаемые здесь протоколы находятся на разных уровнях зрелости и имеют разные модели управления. A2A достиг стабильной спецификации версии 1.0, тогда как другие стандарты продолжают быстро развиваться. Внедрение в экосистему также распределено неравномерно среди поставщиков и фреймворков.",{},{"id":726,"data":727,"type":226,"tunes":729},"p-limit-2",{"text":728},"Эта статья сосредоточена на архитектурной ответственности, а не на полноте реализации. Конкретные методы аутентификации, транспортные привязки, схемы и механизмы расширения следует брать из текущей спецификации каждого протокола.",{},{"id":731,"data":732,"type":42,"tunes":734},"h-conclusion",{"text":733,"level":219},"Заключение",{},{"id":736,"data":737,"type":226,"tunes":739},"p-conclusion-1",{"text":738},"MCP, A2A, UCP, AP2 и A2UI становятся более понятными, если рассматривать их как протоколы для различных типов взаимодействия, а не как пять конкурирующих попыток стандартизировать «агентов».",{},{"id":741,"data":742,"type":226,"tunes":744},"p-conclusion-2",{"text":743},"MCP открывает доступ к возможностям. A2A координирует независимых агентов. UCP дает коммерции собственный машиночитаемый контракт. AP2 добавляет верифицируемые полномочия для платежей. A2UI предоставляет агентам безопасный декларативный способ взаимодействия с пользовательскими интерфейсами. Таким образом, формирующийся агентный веб не заменяет протоколы искусственным интеллектом — он создает новый стек протоколов вокруг ИИ.",{},{"id":746,"data":747,"type":42,"tunes":749},"h-faq",{"text":748,"level":219},"Часто задаваемые вопросы",{},{"id":751,"data":752,"type":751,"tunes":779},"faq",{"items":753,"title":778},[754,758,762,766,770,774],{"id":755,"answer":756,"question":757},"faq1","Нет. MCP в первую очередь стандартизирует то, как приложения ИИ получают доступ к инструментам, ресурсам и данным. A2A стандартизирует взаимодействие между независимыми агентными системами. Удаленный агент может внутри себя использовать MCP, предоставляя наружу интерфейс A2A.","Является ли A2A заменой MCP?",{"id":759,"answer":760,"question":761},"faq2","В целом нет. UCP предоставляет специфичную для коммерции семантику, такую как корзина, оформление заказа и исполнение. MCP по-прежнему может открывать доступ к инструментам или данным продавца, и UCP спроектирован для сосуществования с MCP и A2A.","Является ли UCP заменой MCP для торговых агентов?",{"id":763,"answer":764,"question":765},"faq3","UCP стандартизирует коммерческие взаимодействия и жизненный цикл транзакций. AP2 фокусируется на подтверждении того, что агент обладал полномочиями совершить платеж в рамках установленных пользовательских или организационных ограничений.","В чем разница между UCP и AP2?",{"id":767,"answer":768,"question":769},"faq4","A2UI позволяет агентам отправлять декларативное описание намерений по интерфейсу хост-приложению, которое отрисовывает его с помощью доверенных нативных компонентов вместо выполнения произвольного удаленного фронтенд-кода.","Какую проблему решает A2UI?",{"id":771,"answer":772,"question":773},"faq5","Да. Рабочий процесс может использовать MCP для внутренних инструментов, A2A для делегирования задач удаленным агентам, UCP для коммерции, AP2 для авторизации платежей и A2UI для взаимодействия с человеком.","Может ли одно агентное приложение использовать все эти протоколы?",{"id":775,"answer":776,"question":777},"faq6","Отталкивайтесь от границы интероперабельности. Если задача — доступ к инструментам, оцените MCP. Если взаимодействие независимых агентов — оцените A2A. Если коммерция — UCP. Если делегированные полномочия на платежи — AP2. Если переносимый агентный UI — A2UI.","Какой протокол следует внедрить первым?","MCP, A2A, UCP, AP2 и A2UI",{},{"id":781,"data":782,"type":42,"tunes":784},"h-glossary",{"text":783,"level":219},"Глоссарий",{},{"id":786,"data":787,"type":786,"tunes":807},"glossary",{"title":788,"entries":789},"Ключевые термины протоколов агентов",[790,792,794,797,800,803],{"term":280,"anchor":418,"definition":791},"Model Context Protocol — открытый стандарт для предоставления инструментов, ресурсов и промптов из внешних систем совместимым хостам ИИ.",{"term":285,"anchor":420,"definition":793},"Agent2Agent Protocol — открытый стандарт для обнаружения независимых агентных систем и взаимодействия с ними посредством сообщений, задач и артефактов.",{"term":290,"anchor":795,"definition":796},"ucp","Universal Commerce Protocol — открытый стандарт для интероперабельных сценариев агентной коммерции между интерфейсами потребителей, бизнесом и платежными провайдерами.",{"term":295,"anchor":798,"definition":799},"ap2","Agent Payments Protocol — открытый стандарт для представления и проверки полномочий, намерений и подотчетности в платежах, управляемых агентами.",{"term":300,"anchor":801,"definition":802},"a2ui","Agent-to-User Interface — декларативный протокол, позволяющий агентам запрашивать интерфейс, который отрисовывается с использованием доверенных компонентов хост-приложения.",{"term":804,"anchor":805,"definition":806},"Композиция протоколов","protocol-composition","Использование нескольких протоколов в одном рабочем процессе, где каждый отвечает за отдельную границу интероперабельности, вместо принудительного пропуска всей семантики через один контракт.",{},{"id":809,"data":810,"type":42,"tunes":812},"h-sources",{"text":811,"level":219},"Основные источники и материалы для дальнейшего чтения",{},{"id":814,"data":815,"type":821,"tunes":822},"src-google-guide",{"link":816,"meta":817},"https:\u002F\u002Fdevelopers.googleblog.com\u002Fdevelopers-guide-to-ai-agent-protocols\u002F",{"image":818,"title":819,"description":820},{"url":399},"Google Developers — Руководство разработчика по протоколам ИИ-агентов","Практический обзор совместной работы MCP, A2A, UCP, AP2, A2UI и связанных протоколов в рамках единого многоэтапного рабочего процесса агентов.","linkTool",{},{"id":824,"data":825,"type":821,"tunes":831},"src-mcp",{"link":826,"meta":827},"https:\u002F\u002Fts.sdk.modelcontextprotocol.io\u002Fv2\u002F",{"image":828,"title":829,"description":830},{"url":399},"Model Context Protocol — TypeScript SDK v2","Текущая стабильная документация SDK, реализующая спецификацию MCP от 28.07.2026 и определяющая инструменты, ресурсы, промпты и интеграцию с хостом и сервером.",{},{"id":833,"data":834,"type":821,"tunes":840},"src-a2a-spec",{"link":835,"meta":836},"https:\u002F\u002Fa2a-protocol.org\u002Fdev\u002Fspecification\u002F",{"image":837,"title":838,"description":839},{"url":399},"Протокол A2A — Спецификация v1.0","Текущая спецификация протокола A2A, охватывающая карточки агентов (Agent Cards), сообщения, задачи, артефакты, привязки и согласование версий.",{},{"id":842,"data":843,"type":821,"tunes":849},"src-a2a-aaif",{"link":844,"meta":845},"https:\u002F\u002Fa2a-protocol.org\u002Flatest\u002Fblog\u002F2026\u002F08\u002F27\u002Fa-new-chapter-for-a2a-joining-the-agentic-ai-foundation\u002F",{"image":846,"title":847,"description":848},{"url":399},"A2A — Присоединение к Agentic AI Foundation","Текущее позиционирование проекта A2A в качестве горизонтального уровня взаимодействия агентов наряду с MCP как вертикальной интеграцией инструментов и данных.",{},{"id":851,"data":852,"type":821,"tunes":858},"src-ucp",{"link":853,"meta":854},"https:\u002F\u002Fdevelopers.googleblog.com\u002Funder-the-hood-universal-commerce-protocol-ucp\u002F",{"image":855,"title":856,"description":857},{"url":399},"Google Developers — Под капотом: Universal Commerce Protocol","Технический обзор UCP, его коммерческих примитивов и возможностей композиции с API, A2A, MCP и AP2.",{},{"id":860,"data":861,"type":821,"tunes":867},"src-ucp-profile",{"link":862,"meta":863},"https:\u002F\u002Fdevelopers.google.com\u002Fmerchant\u002Fucp\u002Fimplementation\u002F2026-04-08\u002Fpublish-profile",{"image":864,"title":865,"description":866},{"url":399},"Google Universal Commerce Protocol — Профиль UCP","Текущий версионированный механизм профилей для публикации сервисов UCP и коммерческих возможностей продавцов.",{},{"id":869,"data":870,"type":821,"tunes":876},"src-ap2",{"link":871,"meta":872},"https:\u002F\u002Fcloud.google.com\u002Fblog\u002Fproducts\u002Fai-machine-learning\u002Fannouncing-agents-to-payments-ap2-protocol",{"image":873,"title":874,"description":875},{"url":399},"Google Cloud — Протокол платежей агентов (AP2)","Анонс и обоснование открытого протокола, охватывающего авторизацию, подлинность и подотчетность в платежах, совершаемых агентами.",{},{"id":878,"data":879,"type":821,"tunes":885},"src-a2ui",{"link":880,"meta":881},"https:\u002F\u002Fdevelopers.googleblog.com\u002Fa2ui-v0-9-generative-ui\u002F",{"image":882,"title":883,"description":884},{"url":399},"Google Developers — A2UI v0.9","Фреймворко-независимая декларативная модель A2UI для переносимых интерфейсов под управлением агентов, отображаемых нативными компонентами хоста.",{},{"id":887,"data":888,"type":821,"tunes":894},"src-a2ui-mcp",{"link":889,"meta":890},"https:\u002F\u002Fdevelopers.googleblog.com\u002Fa2ui-and-mcp-apps\u002F",{"image":891,"title":892,"description":893},{"url":399},"Google Developers — A2UI + MCP Apps","Как декларативный подход A2UI и более богатый функционал MCP App могут сосуществовать, не выступая взаимоисключающими моделями интерфейса.",{},"2.31","MCP, A2A, UCP, AP2 и A2UI часто представляют как конкурирующие агентские стандарты. В основном они решают разные проблемы интероперабельности. Это руководство сопоставляет каждый протокол с границей, которую он фактически стандартизирует,—и показывает, как они могут работать вместе в одной промышленной системе.","\u002Fuploads\u002F2026\u002F09\u002Fmcp-vs-a2a-vs-ucp-vs-ap2-vs-a2ui-the-agent-protocol-stack-explained-1790352625869-2ezle0.webp","mcp-vs-a2a-vs-ucp-vs-ap2-vs-a2ui-the-agent-protocol-stack-explained-1790352625869-2ezle0","PUBLISHED","2026-09-25T12:09:00.000Z","2026-09-25T16:09:26.909Z","2026-09-25T19:27:42.182Z",{"en":904,"de":905,"sr":906,"es":907,"fr":908,"it":909,"ru":910,"zh":911},"\u002Fblog\u002Fmcp-vs-a2a-vs-ucp-vs-ap2-vs-a2ui-the-agent-protocol-stack-explained","\u002Fde\u002Fblog\u002Fmcp-vs-a2a-vs-ucp-vs-ap2-vs-a2ui-the-agent-protocol-stack-explained","\u002Fsr\u002Fblog\u002Fmcp-vs-a2a-vs-ucp-vs-ap2-vs-a2ui-the-agent-protocol-stack-explained","\u002Fes\u002Fblog\u002Fmcp-vs-a2a-vs-ucp-vs-ap2-vs-a2ui-the-agent-protocol-stack-explained","\u002Ffr\u002Fblog\u002Fmcp-vs-a2a-vs-ucp-vs-ap2-vs-a2ui-the-agent-protocol-stack-explained","\u002Fit\u002Fblog\u002Fmcp-vs-a2a-vs-ucp-vs-ap2-vs-a2ui-the-agent-protocol-stack-explained","\u002Fru\u002Fblog\u002Fmcp-vs-a2a-vs-ucp-vs-ap2-vs-a2ui-the-agent-protocol-stack-explained","\u002Fzh\u002Fblog\u002Fmcp-vs-a2a-vs-ucp-vs-ap2-vs-a2ui-the-agent-protocol-stack-explained",[913,917,921],{"id":914,"name":915,"slug":916},57,"Границы данных","data-boundaries",{"id":918,"name":919,"slug":920},84,"Политики и границы данных","policy-and-data",{"id":922,"name":923,"slug":924},46,"Обзор","overview",{"id":926,"login":927,"email":928,"displayName":929},"20","rooth8233","aleksandar@stajic.de","Aleksandar Stajić",[931,1487],{"lang":932,"title":933,"content":934,"contentJson":935,"excerpt":1486},"en","MCP vs A2A vs UCP vs AP2 vs A2UI: The Agent Protocol Stack Explained","{\"time\":1790352626854,\"blocks\":[{\"id\":\"_z4yTl5Fh-\",\"type\":\"tableOfContents\",\"data\":{\"title\":\"Contents\",\"minLevel\":2,\"maxLevel\":3},\"tunes\":{}},{\"id\":\"intro\",\"type\":\"paragraph\",\"data\":{\"text\":\"AI agent protocols are multiplying quickly: MCP, A2A, UCP, AP2, A2UI and adjacent standards increasingly appear in the same architecture diagrams. They are often described as competing protocols. In practice, most of them solve different interoperability problems at different boundaries. The useful question is not “Which protocol wins?” but “Which relationship in the system needs to be standardized?”\"},\"tunes\":{}},{\"id\":\"direct\",\"type\":\"callout\",\"data\":{\"variant\":\"info\",\"title\":\"Direct answer\",\"body\":\"\u003Cstrong>MCP, A2A, UCP, AP2 and A2UI are mostly complementary, not substitutes.\u003C\u002Fstrong> MCP connects an AI application to tools, data and resources. A2A connects independent agents to one another. UCP standardizes commerce interactions between consumer surfaces, businesses and payment ecosystems. AP2 adds verifiable authorization and payment intent to agent-led transactions. A2UI lets an agent describe interactive UI without sending arbitrary application code. A production system may legitimately use several of them in one workflow.\"},\"tunes\":{}},{\"id\":\"freshness\",\"type\":\"callout\",\"data\":{\"variant\":\"warning\",\"title\":\"Fast-moving standards\",\"body\":\"This article reflects the protocol landscape on \u003Cstrong>25 September 2026\u003C\u002Fstrong>. A2A has reached v1.0, MCP's current TypeScript v2 line implements the 2026-07-28 specification, UCP has already added newer 2026 protocol versions, and A2UI continues to evolve. Always verify the current specification before implementation.\"},\"tunes\":{}},{\"id\":\"model-note\",\"type\":\"callout\",\"data\":{\"variant\":\"note\",\"title\":\"The model used in this article\",\"body\":\"The Protocol Responsibility Stack and Protocol Selection Test below are practical architecture models proposed here. They are not official terminology from the protocol projects.\"},\"tunes\":{}},{\"id\":\"h-core\",\"type\":\"header\",\"data\":{\"text\":\"The core mistake: comparing protocols that sit at different boundaries\",\"level\":2},\"tunes\":{}},{\"id\":\"p-core-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"A protocol is useful because two independently implemented systems need a stable contract. The contract only makes sense if the boundary is clear. An agent talking to a database has a different interoperability problem from one agent delegating work to another, a shopper authorizing a purchase, or a remote agent asking a native application to render a form.\"},\"tunes\":{}},{\"id\":\"p-core-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"Google's 2026 developer guide explicitly presents MCP, A2A, UCP, AP2, A2UI and related UI protocols as a stack of complementary standards. The same example workflow can use several of them together: tools for inventory, remote agents for suppliers, commerce for ordering, payment authorization for spending and UI protocols for interaction.\"},\"tunes\":{}},{\"id\":\"h-stack\",\"type\":\"header\",\"data\":{\"text\":\"The Protocol Responsibility Stack\",\"level\":2},\"tunes\":{}},{\"id\":\"stack-table\",\"type\":\"table\",\"data\":{\"withHeadings\":true,\"stretched\":false,\"content\":[[\"Protocol\",\"Standardizes which relationship?\",\"Primary abstraction\",\"Not primarily for\"],[\"MCP\",\"AI application ↔ tools, resources and data\",\"Tools, resources, prompts and host\u002Fserver capability exchange\",\"Independent agent collaboration or commerce semantics\"],[\"A2A\",\"Agent ↔ independent agent\",\"Agent discovery, messages, tasks, artifacts and long-running collaboration\",\"Direct database\u002Ftool integration\"],[\"UCP\",\"Consumer\u002Fagent surface ↔ merchant commerce system\",\"Product\u002Fcart\u002Fcheckout\u002Ffulfillment\u002Forder capabilities\",\"General-purpose agent communication\"],[\"AP2\",\"User\u002Fagent intent ↔ payment authorization\",\"Mandates, approval constraints and auditable agent-led payment authority\",\"Product discovery or generic checkout transport\"],[\"A2UI\",\"Agent ↔ user interface host\",\"Declarative UI intent rendered by trusted native components\",\"Arbitrary remote frontend code or agent-to-agent task delegation\"]]},\"tunes\":{}},{\"id\":\"all-five\",\"type\":\"callout\",\"data\":{\"variant\":\"success\",\"title\":\"One workflow can use all five\",\"body\":\"An agent may use \u003Cstrong>MCP\u003C\u002Fstrong> to inspect inventory, \u003Cstrong>A2A\u003C\u002Fstrong> to ask a supplier agent for availability, \u003Cstrong>UCP\u003C\u002Fstrong> to build a commerce transaction, \u003Cstrong>AP2\u003C\u002Fstrong> to prove spending authority, and \u003Cstrong>A2UI\u003C\u002Fstrong> to render a native approval interface to the user.\"},\"tunes\":{}},{\"id\":\"h-mcp\",\"type\":\"header\",\"data\":{\"text\":\"1. MCP: connect the agent to capabilities\",\"level\":2},\"tunes\":{}},{\"id\":\"p-mcp-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"The Model Context Protocol is an open standard for connecting AI applications to external systems where tools, data and reusable resources live. A server exposes capabilities; an MCP host connects to that server and makes those capabilities available to the model or application.\"},\"tunes\":{}},{\"id\":\"p-mcp-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"The current MCP TypeScript v2 documentation describes the protocol in exactly those terms: servers expose tools, resources and prompts, while hosts such as development environments or custom applications connect to them. This makes MCP primarily a capability integration protocol.\"},\"tunes\":{}},{\"id\":\"h-mcp-use\",\"type\":\"header\",\"data\":{\"text\":\"Use MCP when\",\"level\":3},\"tunes\":{}},{\"id\":\"mcp-list\",\"type\":\"list\",\"data\":{\"style\":\"unordered\",\"meta\":{},\"items\":[\"An AI application needs standardized access to tools or APIs.\",\"You want one capability server to work with multiple compatible AI hosts.\",\"You need structured access to data or resources without hard-coding every integration into each agent.\",\"The external system is a capability provider, not an autonomous peer agent.\"]},\"tunes\":{}},{\"id\":\"mcp-warning\",\"type\":\"callout\",\"data\":{\"variant\":\"warning\",\"title\":\"MCP is not automatically A2A\",\"body\":\"An MCP server can expose powerful functions, but that does not make it an independent agent with its own task lifecycle, discovery semantics and opaque internal reasoning. Tool invocation and agent collaboration are different contracts.\"},\"tunes\":{}},{\"id\":\"h-a2a\",\"type\":\"header\",\"data\":{\"text\":\"2. A2A: connect independent agents\",\"level\":2},\"tunes\":{}},{\"id\":\"p-a2a-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"Agent2Agent (A2A) is designed for communication between independent, potentially opaque agent systems. Its current v1.0 specification focuses on capability discovery, messaging, tasks, artifacts, multimodal content and long-running collaboration without requiring one agent to expose its internal tools, memory or implementation to another.\"},\"tunes\":{}},{\"id\":\"p-a2a-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"That opacity is the important boundary. The calling agent does not need to know whether the remote agent uses MCP, custom tools, a proprietary planner, another model vendor, or human escalation internally. It needs a contract for discovering capabilities and delegating work.\"},\"tunes\":{}},{\"id\":\"p-a2a-3\",\"type\":\"paragraph\",\"data\":{\"text\":\"A2A v1.0 also standardizes version negotiation and supports multiple bindings around a common data model. Its published Agent Card mechanism gives clients a standard discovery point for an agent's capabilities, supported protocols, authentication requirements and skills.\"},\"tunes\":{}},{\"id\":\"h-a2a-use\",\"type\":\"header\",\"data\":{\"text\":\"Use A2A when\",\"level\":3},\"tunes\":{}},{\"id\":\"a2a-list\",\"type\":\"list\",\"data\":{\"style\":\"unordered\",\"meta\":{},\"items\":[\"One autonomous agent needs to delegate work to another autonomous agent.\",\"The remote system should remain opaque behind a capability contract.\",\"Tasks may be long-running, asynchronous or require human-in-the-loop interaction.\",\"Agents are built with different frameworks, languages, vendors or organizational ownership.\"]},\"tunes\":{}},{\"id\":\"h-mcp-a2a\",\"type\":\"header\",\"data\":{\"text\":\"MCP vs A2A: vertical integration vs horizontal collaboration\",\"level\":2},\"tunes\":{}},{\"id\":\"mcp-a2a-comparison\",\"type\":\"comparison\",\"data\":{\"title\":\"MCP and A2A solve different interoperability problems\",\"layout\":\"table\",\"columns\":[{\"id\":\"dimension\",\"label\":\"Dimension\"},{\"id\":\"mcp\",\"label\":\"MCP\"},{\"id\":\"a2a\",\"label\":\"A2A\"}],\"rows\":[{\"id\":\"relationship\",\"label\":\"Relationship\",\"values\":[\"\",\"\",\"\"]},{\"id\":\"abstraction\",\"label\":\"Abstraction\",\"values\":[\"\",\"\",\"\"]},{\"id\":\"opacity\",\"label\":\"Internal opacity\",\"values\":[\"\",\"\",\"\"]},{\"id\":\"long\",\"label\":\"Long-running work\",\"values\":[\"\",\"\",\"\"]}]},\"tunes\":{}},{\"id\":\"p-mcp-a2a-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"The A2A project itself now describes the distinction as horizontal versus vertical: MCP connects agents to internal tools and databases, while A2A enables peer-to-peer collaboration across agent systems.\"},\"tunes\":{}},{\"id\":\"h-ucp\",\"type\":\"header\",\"data\":{\"text\":\"3. UCP: standardize agentic commerce\",\"level\":2},\"tunes\":{}},{\"id\":\"p-ucp-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"The Universal Commerce Protocol is not a generic agent protocol. It standardizes commerce journeys between consumer surfaces, merchants and payment providers. Google's implementation already supports capabilities such as cart creation, checkout, fulfillment and order lifecycle through versioned profiles and APIs.\"},\"tunes\":{}},{\"id\":\"p-ucp-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"A merchant can publish a UCP profile under \u002F.well-known\u002Fucp describing services, protocol versions and capabilities. That discovery pattern matters because an agentic surface should not need a bespoke checkout contract for every merchant.\"},\"tunes\":{}},{\"id\":\"p-ucp-3\",\"type\":\"paragraph\",\"data\":{\"text\":\"UCP is also intentionally composable. Google's technical overview says it can integrate through APIs, A2A and MCP and is compatible with AP2 for agentic payment authorization.\"},\"tunes\":{}},{\"id\":\"h-ucp-use\",\"type\":\"header\",\"data\":{\"text\":\"Use UCP when\",\"level\":3},\"tunes\":{}},{\"id\":\"ucp-list\",\"type\":\"list\",\"data\":{\"style\":\"unordered\",\"meta\":{},\"items\":[\"The workflow involves merchant products, carts, checkout, fulfillment or order lifecycle.\",\"You are building a merchant surface that should work with agentic shopping experiences.\",\"The integration needs commerce-specific semantics rather than generic tool calls.\",\"You want an interoperable commerce contract that can coexist with MCP, A2A and payment protocols.\"]},\"tunes\":{}},{\"id\":\"h-ap2\",\"type\":\"header\",\"data\":{\"text\":\"4. AP2: prove that the agent was allowed to spend\",\"level\":2},\"tunes\":{}},{\"id\":\"p-ap2-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"Agentic commerce introduces a problem that ordinary checkout flows did not have to solve in the same way: an agent may transact when the human is not clicking the final button in real time. The Agent Payments Protocol (AP2) addresses authorization, authenticity and accountability for agent-led payments.\"},\"tunes\":{}},{\"id\":\"p-ap2-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"Google's 2026 protocol guide describes AP2 through typed mandates that capture user intent, spending constraints and the specific transaction being authorized. AP2 can work as an extension alongside UCP: UCP describes the commerce transaction, while AP2 provides evidence that the agent had authority to perform the payment.\"},\"tunes\":{}},{\"id\":\"p-ap2-3\",\"type\":\"paragraph\",\"data\":{\"text\":\"This distinction is important. A checkout protocol can tell a merchant what should be purchased. It does not by itself prove who authorized the agent to spend, under what limit, for which merchant, for how long, or whether the final cart remained inside that authority.\"},\"tunes\":{}},{\"id\":\"h-ucp-ap2\",\"type\":\"header\",\"data\":{\"text\":\"UCP vs AP2: transaction semantics vs authority\",\"level\":2},\"tunes\":{}},{\"id\":\"ucp-ap2-table\",\"type\":\"table\",\"data\":{\"withHeadings\":true,\"stretched\":false,\"content\":[[\"Question\",\"UCP\",\"AP2\"],[\"What is being bought?\",\"Commerce items, cart, checkout and fulfillment semantics\",\"References the authorized transaction context\"],[\"Who may authorize it?\",\"Not the primary protocol responsibility\",\"Explicit agent\u002Fuser authority and mandate model\"],[\"What spending constraints apply?\",\"Commerce flow can contain totals and checkout data\",\"Authorization guardrails and intent limits\"],[\"How is the transaction audited?\",\"Order and commerce lifecycle\",\"Cryptographic \u002F verifiable authorization trail through mandates and receipts\"],[\"Can they work together?\",\"Yes\",\"Yes — AP2 can extend agentic commerce flows\"]]},\"tunes\":{}},{\"id\":\"h-a2ui\",\"type\":\"header\",\"data\":{\"text\":\"5. A2UI: let agents describe interfaces without owning your frontend\",\"level\":2},\"tunes\":{}},{\"id\":\"p-a2ui-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"Agent-to-User Interface (A2UI) tackles another boundary: how a remote or local agent communicates a rich interactive interface to a host application. Instead of sending arbitrary HTML, CSS and JavaScript, A2UI uses declarative data that the host renders through its own trusted component catalog.\"},\"tunes\":{}},{\"id\":\"p-a2ui-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"This preserves the host application's design system and security model while still allowing an agent to request dynamic interfaces. A2UI v0.9 specifically emphasizes framework-agnostic UI intent and streaming updates across web, mobile and other clients.\"},\"tunes\":{}},{\"id\":\"p-a2ui-3\",\"type\":\"paragraph\",\"data\":{\"text\":\"Google's later A2UI + MCP Apps work also demonstrates that these UI models are not necessarily mutually exclusive. Declarative native UI and richer embedded application experiences can coexist depending on the task.\"},\"tunes\":{}},{\"id\":\"h-a2ui-use\",\"type\":\"header\",\"data\":{\"text\":\"Use A2UI when\",\"level\":3},\"tunes\":{}},{\"id\":\"a2ui-list\",\"type\":\"list\",\"data\":{\"style\":\"unordered\",\"meta\":{},\"items\":[\"A remote agent needs to request forms, cards, controls or other interactive UI.\",\"The host should preserve its native components, styling and security boundary.\",\"You do not want remote agents shipping arbitrary executable frontend code.\",\"The same agent-defined UI intent should work across different client frameworks.\"]},\"tunes\":{}},{\"id\":\"h-selection\",\"type\":\"header\",\"data\":{\"text\":\"The Protocol Selection Test\",\"level\":2},\"tunes\":{}},{\"id\":\"p-selection-intro\",\"type\":\"paragraph\",\"data\":{\"text\":\"Do not start from the acronym. Start from the relationship that needs interoperability.\"},\"tunes\":{}},{\"id\":\"selection-flow\",\"type\":\"processFlow\",\"data\":{\"title\":\"Choose the protocol by the boundary\",\"orientation\":\"auto\",\"steps\":[{\"label\":\"1. Identify the two independent parties\",\"description\":\"Is this AI-to-tool, agent-to-agent, agent-to-merchant, agent-to-payment authority, or agent-to-user-interface?\"},{\"label\":\"2. Identify the shared object\",\"description\":\"Is the contract about a tool call, task, cart, payment mandate, artifact, or UI description?\"},{\"label\":\"3. Check whether a domain protocol already exists\",\"description\":\"Prefer commerce or payment semantics when the problem is commerce or authorization instead of encoding everything as generic tools.\"},{\"label\":\"4. Keep local internals local\",\"description\":\"Do not expose an entire agent as MCP tools if the remote party only needs an A2A capability, and do not make a remote agent responsible for your UI runtime.\"},{\"label\":\"5. Compose protocols when the workflow crosses boundaries\",\"description\":\"One workflow can legitimately cross tool, agent, commerce, payment and UI contracts.\"},{\"label\":\"6. Version each contract independently\",\"description\":\"Protocol versions evolve at different speeds; do not tie every integration to one monolithic application version.\"},{\"label\":\"7. Preserve authorization at every boundary\",\"description\":\"Interoperability does not replace product permissions, tool authorization, payment authority or data-access policy.\"}]},\"tunes\":{}},{\"id\":\"h-workflow\",\"type\":\"header\",\"data\":{\"text\":\"A realistic multi-protocol workflow\",\"level\":2},\"tunes\":{}},{\"id\":\"workflow-flow\",\"type\":\"processFlow\",\"data\":{\"title\":\"Example: an autonomous procurement workflow\",\"orientation\":\"auto\",\"steps\":[{\"label\":\"1. Inspect internal stock with MCP\",\"description\":\"The purchasing agent calls inventory and forecasting capabilities exposed by internal MCP servers.\"},{\"label\":\"2. Discover a supplier agent with A2A\",\"description\":\"The agent reads the supplier's Agent Card and delegates an availability and lead-time task.\"},{\"label\":\"3. Negotiate the commerce object with UCP\",\"description\":\"The supplier or merchant surface returns structured cart, checkout and fulfillment information.\"},{\"label\":\"4. Check spending authority with AP2\",\"description\":\"The purchase is compared with the user's or organization's signed mandate, merchant constraints and spending limits.\"},{\"label\":\"5. Ask for approval through A2UI\",\"description\":\"If human approval is required, the agent sends declarative UI intent and the host renders the approval experience using trusted native components.\"},{\"label\":\"6. Complete and audit\",\"description\":\"Commerce state, payment authorization, agent task evidence and application audit records remain traceable across their respective boundaries.\"}]},\"tunes\":{}},{\"id\":\"h-universal\",\"type\":\"header\",\"data\":{\"text\":\"Why one universal agent protocol is unlikely to replace all of them\",\"level\":2},\"tunes\":{}},{\"id\":\"p-universal-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"A universal protocol sounds simpler until it must encode every domain's semantics. Tool discovery, long-running agent collaboration, checkout, payment authorization and native UI all have different lifecycle, security and correctness requirements.\"},\"tunes\":{}},{\"id\":\"p-universal-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"The web itself evolved through layered protocols rather than one message format for every problem. The emerging agentic stack appears to be moving in the same direction: common horizontal primitives, specialized domain contracts and explicit discovery\u002Fversioning.\"},\"tunes\":{}},{\"id\":\"p-universal-3\",\"type\":\"paragraph\",\"data\":{\"text\":\"The architecture challenge therefore shifts from “which protocol wins?” to how cleanly protocols compose without duplicating identity, authorization, state and audit semantics.\"},\"tunes\":{}},{\"id\":\"h-failures\",\"type\":\"header\",\"data\":{\"text\":\"Protocol composition creates new failure modes\",\"level\":2},\"tunes\":{}},{\"id\":\"failure-table\",\"type\":\"table\",\"data\":{\"withHeadings\":true,\"stretched\":false,\"content\":[[\"Failure mode\",\"What happens\",\"Architecture control\"],[\"Authority leakage\",\"A valid tool or agent capability is treated as permission to perform a business action\",\"Keep product authorization independent from protocol capability discovery\"],[\"Identity mismatch\",\"MCP host identity, A2A agent identity and commerce\u002Fpayment identity refer to different principals\",\"Define explicit principal mapping across boundaries\"],[\"Version drift\",\"One protocol upgrades while dependent adapters assume older semantics\",\"Negotiate and pin protocol versions independently\"],[\"State duplication\",\"The same cart, task or approval state is copied into several protocol layers\",\"Define one authoritative owner per domain object\"],[\"Audit fragmentation\",\"Tool traces, agent tasks, checkout and payment evidence cannot be joined\",\"Carry correlation IDs and stable domain identifiers across protocol boundaries\"],[\"Semantic tunneling\",\"Everything is forced through a generic protocol as opaque JSON\",\"Use domain protocols where their semantics materially improve correctness\"]]},\"tunes\":{}},{\"id\":\"h-app-arch\",\"type\":\"header\",\"data\":{\"text\":\"Protocol choice does not replace application architecture\",\"level\":2},\"tunes\":{}},{\"id\":\"p-app-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"Open standards reduce integration coupling, but they do not decide your domain model, authorization policy, source of truth, retry strategy or acceptance criteria. An MCP tool can still expose the wrong capability. An A2A agent can still return a bad artifact. A UCP checkout can still contain stale merchant data. An AP2 mandate can still be misapplied by application logic.\"},\"tunes\":{}},{\"id\":\"p-app-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"Treat protocols as contracts between independently evolving components. Keep domain truth and consequential policy in the application layer that owns them, then use protocols to make the boundaries interoperable.\"},\"tunes\":{}},{\"id\":\"ref-harness\",\"type\":\"referralArticle\",\"data\":{\"url\":\"https:\u002F\u002Fstajic.de\u002Fblog\u002Fmanaged-agent-harness-vs-self-hosted-agent-loop-what-you-gain-what-you-lose\",\"title\":\"Managed Agent Harness vs Self-Hosted Agent Loop: What You Gain, What You Lose\",\"excerpt\":\"Protocol boundaries solve interoperability. Runtime boundaries solve who operates the harness, execution environment and application control plane.\",\"ctaLabel\":\"Read the runtime architecture guide\"},\"tunes\":{}},{\"id\":\"h-change\",\"type\":\"header\",\"data\":{\"text\":\"What would change this answer?\",\"level\":2},\"tunes\":{}},{\"id\":\"p-change-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"The stack changes if protocols converge, one standard formally absorbs another, or vendors standardize a shared identity and authorization layer across several boundaries. UCP already demonstrates composition by supporting APIs, A2A and MCP and by integrating with AP2 rather than replacing them.\"},\"tunes\":{}},{\"id\":\"p-change-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"The answer also changes by application scope. A small internal agent may need only MCP. A multi-company workflow may need A2A. A merchant may need UCP without A2UI. A delegated purchasing agent may need all of them. Use the smallest protocol set that represents the real boundaries without flattening domain semantics.\"},\"tunes\":{}},{\"id\":\"h-limitations\",\"type\":\"header\",\"data\":{\"text\":\"Limitations\",\"level\":2},\"tunes\":{}},{\"id\":\"p-limit-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"The protocols discussed here are at different maturity levels and have different governance models. A2A has reached a stable v1.0 specification, while other standards continue to evolve rapidly. Ecosystem adoption is also uneven across vendors and frameworks.\"},\"tunes\":{}},{\"id\":\"p-limit-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"This article focuses on architecture responsibility rather than implementation completeness. Specific authentication methods, transport bindings, schemas and extension mechanisms must be taken from each protocol's current specification.\"},\"tunes\":{}},{\"id\":\"h-conclusion\",\"type\":\"header\",\"data\":{\"text\":\"Conclusion\",\"level\":2},\"tunes\":{}},{\"id\":\"p-conclusion-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"MCP, A2A, UCP, AP2 and A2UI make more sense when viewed as protocols for different relationships, not five competing attempts to standardize “agents.”\"},\"tunes\":{}},{\"id\":\"p-conclusion-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"MCP exposes capabilities. A2A coordinates independent agents. UCP gives commerce its own machine-readable contract. AP2 adds verifiable payment authority. A2UI gives agents a safe declarative path into user interfaces. The emerging agentic web is therefore not replacing protocols with AI; it is creating a new protocol stack around AI.\"},\"tunes\":{}},{\"id\":\"h-faq\",\"type\":\"header\",\"data\":{\"text\":\"FAQ\",\"level\":2},\"tunes\":{}},{\"id\":\"faq\",\"type\":\"faq\",\"data\":{\"title\":\"MCP, A2A, UCP, AP2 and A2UI\",\"items\":[{\"id\":\"faq1\",\"question\":\"Is A2A a replacement for MCP?\",\"answer\":\"No. MCP primarily standardizes how AI applications access tools, resources and data. A2A standardizes collaboration between independent agent systems. A remote agent can internally use MCP while exposing an A2A interface.\"},{\"id\":\"faq2\",\"question\":\"Is UCP a replacement for MCP in shopping agents?\",\"answer\":\"Not generally. UCP provides commerce-specific semantics such as cart, checkout and fulfillment. MCP can still expose merchant tools or data, and UCP is designed to coexist with MCP and A2A.\"},{\"id\":\"faq3\",\"question\":\"What is the difference between UCP and AP2?\",\"answer\":\"UCP standardizes commerce interactions and transaction lifecycle. AP2 focuses on proving that an agent had authority to perform a payment under defined user or organizational constraints.\"},{\"id\":\"faq4\",\"question\":\"What problem does A2UI solve?\",\"answer\":\"A2UI lets agents send declarative UI intent to a host application, which renders the experience through trusted native components instead of executing arbitrary remote frontend code.\"},{\"id\":\"faq5\",\"question\":\"Can one agent application use all of these protocols?\",\"answer\":\"Yes. A workflow can use MCP for internal tools, A2A for remote-agent delegation, UCP for commerce, AP2 for payment authorization and A2UI for human interaction.\"},{\"id\":\"faq6\",\"question\":\"Which protocol should I implement first?\",\"answer\":\"Start from the interoperability boundary. If the problem is tool access, evaluate MCP. If it is independent-agent collaboration, evaluate A2A. If it is commerce, UCP. If it is delegated payment authority, AP2. If it is portable agent-driven UI, A2UI.\"}]},\"tunes\":{}},{\"id\":\"h-glossary\",\"type\":\"header\",\"data\":{\"text\":\"Glossary\",\"level\":2},\"tunes\":{}},{\"id\":\"glossary\",\"type\":\"glossary\",\"data\":{\"title\":\"Key agent-protocol terms\",\"entries\":[{\"term\":\"MCP\",\"definition\":\"Model Context Protocol, an open standard for exposing tools, resources and prompts from external systems to compatible AI hosts.\",\"anchor\":\"mcp\"},{\"term\":\"A2A\",\"definition\":\"Agent2Agent Protocol, an open standard for discovering and collaborating with independent agent systems through messages, tasks and artifacts.\",\"anchor\":\"a2a\"},{\"term\":\"UCP\",\"definition\":\"Universal Commerce Protocol, an open standard for interoperable agentic commerce journeys between consumer surfaces, businesses and payment providers.\",\"anchor\":\"ucp\"},{\"term\":\"AP2\",\"definition\":\"Agent Payments Protocol, an open standard for representing and verifying authority, intent and accountability in agent-led payments.\",\"anchor\":\"ap2\"},{\"term\":\"A2UI\",\"definition\":\"Agent-to-User Interface, a declarative protocol for allowing agents to request UI that is rendered using the host application's trusted components.\",\"anchor\":\"a2ui\"},{\"term\":\"Protocol composition\",\"definition\":\"Using multiple protocols in one workflow, each responsible for a distinct interoperability boundary rather than forcing all semantics through one contract.\",\"anchor\":\"protocol-composition\"}]},\"tunes\":{}},{\"id\":\"h-sources\",\"type\":\"header\",\"data\":{\"text\":\"Primary sources and further reading\",\"level\":2},\"tunes\":{}},{\"id\":\"src-google-guide\",\"type\":\"linkTool\",\"data\":{\"link\":\"https:\u002F\u002Fdevelopers.googleblog.com\u002Fdevelopers-guide-to-ai-agent-protocols\u002F\",\"meta\":{\"image\":{\"url\":\"\"},\"title\":\"Google Developers — Developer's Guide to AI Agent Protocols\",\"description\":\"A practical overview showing MCP, A2A, UCP, AP2, A2UI and related protocols working together in one multi-step agent workflow.\"}},\"tunes\":{}},{\"id\":\"src-mcp\",\"type\":\"linkTool\",\"data\":{\"link\":\"https:\u002F\u002Fts.sdk.modelcontextprotocol.io\u002Fv2\u002F\",\"meta\":{\"image\":{\"url\":\"\"},\"title\":\"Model Context Protocol — TypeScript SDK v2\",\"description\":\"Current stable SDK documentation implementing the 2026-07-28 MCP specification and defining tools, resources, prompts and host\u002Fserver integration.\"}},\"tunes\":{}},{\"id\":\"src-a2a-spec\",\"type\":\"linkTool\",\"data\":{\"link\":\"https:\u002F\u002Fa2a-protocol.org\u002Fdev\u002Fspecification\u002F\",\"meta\":{\"image\":{\"url\":\"\"},\"title\":\"A2A Protocol — v1.0 Specification\",\"description\":\"Current A2A protocol specification covering Agent Cards, messages, tasks, artifacts, bindings and version negotiation.\"}},\"tunes\":{}},{\"id\":\"src-a2a-aaif\",\"type\":\"linkTool\",\"data\":{\"link\":\"https:\u002F\u002Fa2a-protocol.org\u002Flatest\u002Fblog\u002F2026\u002F08\u002F27\u002Fa-new-chapter-for-a2a-joining-the-agentic-ai-foundation\u002F\",\"meta\":{\"image\":{\"url\":\"\"},\"title\":\"A2A — Joining the Agentic AI Foundation\",\"description\":\"Current project framing of A2A as the horizontal agent-collaboration layer alongside MCP as vertical tool\u002Fdata integration.\"}},\"tunes\":{}},{\"id\":\"src-ucp\",\"type\":\"linkTool\",\"data\":{\"link\":\"https:\u002F\u002Fdevelopers.googleblog.com\u002Funder-the-hood-universal-commerce-protocol-ucp\u002F\",\"meta\":{\"image\":{\"url\":\"\"},\"title\":\"Google Developers — Under the Hood: Universal Commerce Protocol\",\"description\":\"Technical overview of UCP, its commerce primitives and its ability to compose with APIs, A2A, MCP and AP2.\"}},\"tunes\":{}},{\"id\":\"src-ucp-profile\",\"type\":\"linkTool\",\"data\":{\"link\":\"https:\u002F\u002Fdevelopers.google.com\u002Fmerchant\u002Fucp\u002Fimplementation\u002F2026-04-08\u002Fpublish-profile\",\"meta\":{\"image\":{\"url\":\"\"},\"title\":\"Google Universal Commerce Protocol — UCP Profile\",\"description\":\"Current versioned profile mechanism for publishing UCP services and merchant commerce capabilities.\"}},\"tunes\":{}},{\"id\":\"src-ap2\",\"type\":\"linkTool\",\"data\":{\"link\":\"https:\u002F\u002Fcloud.google.com\u002Fblog\u002Fproducts\u002Fai-machine-learning\u002Fannouncing-agents-to-payments-ap2-protocol\",\"meta\":{\"image\":{\"url\":\"\"},\"title\":\"Google Cloud — Agent Payments Protocol (AP2)\",\"description\":\"Announcement and rationale for an open protocol covering authorization, authenticity and accountability in agent-led payments.\"}},\"tunes\":{}},{\"id\":\"src-a2ui\",\"type\":\"linkTool\",\"data\":{\"link\":\"https:\u002F\u002Fdevelopers.googleblog.com\u002Fa2ui-v0-9-generative-ui\u002F\",\"meta\":{\"image\":{\"url\":\"\"},\"title\":\"Google Developers — A2UI v0.9\",\"description\":\"A2UI's framework-agnostic declarative model for portable agent-driven interfaces rendered by host-native components.\"}},\"tunes\":{}},{\"id\":\"src-a2ui-mcp\",\"type\":\"linkTool\",\"data\":{\"link\":\"https:\u002F\u002Fdevelopers.googleblog.com\u002Fa2ui-and-mcp-apps\u002F\",\"meta\":{\"image\":{\"url\":\"\"},\"title\":\"Google Developers — A2UI + MCP Apps\",\"description\":\"How declarative A2UI and richer MCP App experiences can coexist rather than being treated as mutually exclusive UI models.\"}},\"tunes\":{}}],\"version\":\"2.31.6\"}",{"time":936,"blocks":937,"version":1485},1790352626854,[938,942,946,951,956,961,965,969,973,977,1006,1011,1015,1019,1023,1027,1036,1041,1045,1049,1053,1057,1061,1070,1074,1096,1100,1104,1108,1112,1116,1120,1129,1133,1137,1141,1145,1149,1175,1179,1183,1187,1191,1195,1204,1208,1212,1238,1242,1265,1269,1273,1277,1281,1285,1317,1321,1325,1329,1336,1340,1344,1348,1352,1356,1360,1364,1368,1372,1376,1399,1403,1421,1425,1432,1438,1445,1452,1459,1466,1473,1479],{"id":215,"data":939,"type":220,"tunes":941},{"title":940,"maxLevel":218,"minLevel":219},"Contents",{},{"id":223,"data":943,"type":226,"tunes":945},{"text":944},"AI agent protocols are multiplying quickly: MCP, A2A, UCP, AP2, A2UI and adjacent standards increasingly appear in the same architecture diagrams. They are often described as competing protocols. In practice, most of them solve different interoperability problems at different boundaries. The useful question is not “Which protocol wins?” but “Which relationship in the system needs to be standardized?”",{},{"id":229,"data":947,"type":234,"tunes":950},{"body":948,"title":949,"variant":233},"\u003Cstrong>MCP, A2A, UCP, AP2 and A2UI are mostly complementary, not substitutes.\u003C\u002Fstrong> MCP connects an AI application to tools, data and resources. A2A connects independent agents to one another. UCP standardizes commerce interactions between consumer surfaces, businesses and payment ecosystems. AP2 adds verifiable authorization and payment intent to agent-led transactions. A2UI lets an agent describe interactive UI without sending arbitrary application code. A production system may legitimately use several of them in one workflow.","Direct answer",{},{"id":237,"data":952,"type":234,"tunes":955},{"body":953,"title":954,"variant":241},"This article reflects the protocol landscape on \u003Cstrong>25 September 2026\u003C\u002Fstrong>. A2A has reached v1.0, MCP's current TypeScript v2 line implements the 2026-07-28 specification, UCP has already added newer 2026 protocol versions, and A2UI continues to evolve. Always verify the current specification before implementation.","Fast-moving standards",{},{"id":244,"data":957,"type":234,"tunes":960},{"body":958,"title":959,"variant":248},"The Protocol Responsibility Stack and Protocol Selection Test below are practical architecture models proposed here. They are not official terminology from the protocol projects.","The model used in this article",{},{"id":251,"data":962,"type":42,"tunes":964},{"text":963,"level":219},"The core mistake: comparing protocols that sit at different boundaries",{},{"id":256,"data":966,"type":226,"tunes":968},{"text":967},"A protocol is useful because two independently implemented systems need a stable contract. The contract only makes sense if the boundary is clear. An agent talking to a database has a different interoperability problem from one agent delegating work to another, a shopper authorizing a purchase, or a remote agent asking a native application to render a form.",{},{"id":261,"data":970,"type":226,"tunes":972},{"text":971},"Google's 2026 developer guide explicitly presents MCP, A2A, UCP, AP2, A2UI and related UI protocols as a stack of complementary standards. The same example workflow can use several of them together: tools for inventory, remote agents for suppliers, commerce for ordering, payment authorization for spending and UI protocols for interaction.",{},{"id":266,"data":974,"type":42,"tunes":976},{"text":975,"level":219},"The Protocol Responsibility Stack",{},{"id":271,"data":978,"type":304,"tunes":1005},{"content":979,"stretched":43,"withHeadings":14},[980,985,989,993,997,1001],[981,982,983,984],"Protocol","Standardizes which relationship?","Primary abstraction","Not primarily for",[280,986,987,988],"AI application ↔ tools, resources and data","Tools, resources, prompts and host\u002Fserver capability exchange","Independent agent collaboration or commerce semantics",[285,990,991,992],"Agent ↔ independent agent","Agent discovery, messages, tasks, artifacts and long-running collaboration","Direct database\u002Ftool integration",[290,994,995,996],"Consumer\u002Fagent surface ↔ merchant commerce system","Product\u002Fcart\u002Fcheckout\u002Ffulfillment\u002Forder capabilities","General-purpose agent communication",[295,998,999,1000],"User\u002Fagent intent ↔ payment authorization","Mandates, approval constraints and auditable agent-led payment authority","Product discovery or generic checkout transport",[300,1002,1003,1004],"Agent ↔ user interface host","Declarative UI intent rendered by trusted native components","Arbitrary remote frontend code or agent-to-agent task delegation",{},{"id":307,"data":1007,"type":234,"tunes":1010},{"body":1008,"title":1009,"variant":311},"An agent may use \u003Cstrong>MCP\u003C\u002Fstrong> to inspect inventory, \u003Cstrong>A2A\u003C\u002Fstrong> to ask a supplier agent for availability, \u003Cstrong>UCP\u003C\u002Fstrong> to build a commerce transaction, \u003Cstrong>AP2\u003C\u002Fstrong> to prove spending authority, and \u003Cstrong>A2UI\u003C\u002Fstrong> to render a native approval interface to the user.","One workflow can use all five",{},{"id":314,"data":1012,"type":42,"tunes":1014},{"text":1013,"level":219},"1. MCP: connect the agent to capabilities",{},{"id":319,"data":1016,"type":226,"tunes":1018},{"text":1017},"The Model Context Protocol is an open standard for connecting AI applications to external systems where tools, data and reusable resources live. A server exposes capabilities; an MCP host connects to that server and makes those capabilities available to the model or application.",{},{"id":324,"data":1020,"type":226,"tunes":1022},{"text":1021},"The current MCP TypeScript v2 documentation describes the protocol in exactly those terms: servers expose tools, resources and prompts, while hosts such as development environments or custom applications connect to them. This makes MCP primarily a capability integration protocol.",{},{"id":329,"data":1024,"type":42,"tunes":1026},{"text":1025,"level":218},"Use MCP when",{},{"id":334,"data":1028,"type":343,"tunes":1035},{"meta":1029,"items":1030,"style":342},{},[1031,1032,1033,1034],"An AI application needs standardized access to tools or APIs.","You want one capability server to work with multiple compatible AI hosts.","You need structured access to data or resources without hard-coding every integration into each agent.","The external system is a capability provider, not an autonomous peer agent.",{},{"id":346,"data":1037,"type":234,"tunes":1040},{"body":1038,"title":1039,"variant":241},"An MCP server can expose powerful functions, but that does not make it an independent agent with its own task lifecycle, discovery semantics and opaque internal reasoning. Tool invocation and agent collaboration are different contracts.","MCP is not automatically A2A",{},{"id":352,"data":1042,"type":42,"tunes":1044},{"text":1043,"level":219},"2. A2A: connect independent agents",{},{"id":357,"data":1046,"type":226,"tunes":1048},{"text":1047},"Agent2Agent (A2A) is designed for communication between independent, potentially opaque agent systems. Its current v1.0 specification focuses on capability discovery, messaging, tasks, artifacts, multimodal content and long-running collaboration without requiring one agent to expose its internal tools, memory or implementation to another.",{},{"id":362,"data":1050,"type":226,"tunes":1052},{"text":1051},"That opacity is the important boundary. The calling agent does not need to know whether the remote agent uses MCP, custom tools, a proprietary planner, another model vendor, or human escalation internally. It needs a contract for discovering capabilities and delegating work.",{},{"id":367,"data":1054,"type":226,"tunes":1056},{"text":1055},"A2A v1.0 also standardizes version negotiation and supports multiple bindings around a common data model. Its published Agent Card mechanism gives clients a standard discovery point for an agent's capabilities, supported protocols, authentication requirements and skills.",{},{"id":372,"data":1058,"type":42,"tunes":1060},{"text":1059,"level":218},"Use A2A when",{},{"id":377,"data":1062,"type":343,"tunes":1069},{"meta":1063,"items":1064,"style":342},{},[1065,1066,1067,1068],"One autonomous agent needs to delegate work to another autonomous agent.","The remote system should remain opaque behind a capability contract.","Tasks may be long-running, asynchronous or require human-in-the-loop interaction.","Agents are built with different frameworks, languages, vendors or organizational ownership.",{},{"id":387,"data":1071,"type":42,"tunes":1073},{"text":1072,"level":219},"MCP vs A2A: vertical integration vs horizontal collaboration",{},{"id":392,"data":1075,"type":421,"tunes":1095},{"rows":1076,"title":1089,"layout":304,"columns":1090},[1077,1080,1083,1086],{"id":396,"label":1078,"values":1079},"Relationship",[399,399,399],{"id":401,"label":1081,"values":1082},"Abstraction",[399,399,399],{"id":405,"label":1084,"values":1085},"Internal opacity",[399,399,399],{"id":409,"label":1087,"values":1088},"Long-running work",[399,399,399],"MCP and A2A solve different interoperability problems",[1091,1093,1094],{"id":415,"label":1092},"Dimension",{"id":418,"label":280},{"id":420,"label":285},{},{"id":424,"data":1097,"type":226,"tunes":1099},{"text":1098},"The A2A project itself now describes the distinction as horizontal versus vertical: MCP connects agents to internal tools and databases, while A2A enables peer-to-peer collaboration across agent systems.",{},{"id":429,"data":1101,"type":42,"tunes":1103},{"text":1102,"level":219},"3. UCP: standardize agentic commerce",{},{"id":434,"data":1105,"type":226,"tunes":1107},{"text":1106},"The Universal Commerce Protocol is not a generic agent protocol. It standardizes commerce journeys between consumer surfaces, merchants and payment providers. Google's implementation already supports capabilities such as cart creation, checkout, fulfillment and order lifecycle through versioned profiles and APIs.",{},{"id":439,"data":1109,"type":226,"tunes":1111},{"text":1110},"A merchant can publish a UCP profile under \u002F.well-known\u002Fucp describing services, protocol versions and capabilities. That discovery pattern matters because an agentic surface should not need a bespoke checkout contract for every merchant.",{},{"id":444,"data":1113,"type":226,"tunes":1115},{"text":1114},"UCP is also intentionally composable. Google's technical overview says it can integrate through APIs, A2A and MCP and is compatible with AP2 for agentic payment authorization.",{},{"id":449,"data":1117,"type":42,"tunes":1119},{"text":1118,"level":218},"Use UCP when",{},{"id":454,"data":1121,"type":343,"tunes":1128},{"meta":1122,"items":1123,"style":342},{},[1124,1125,1126,1127],"The workflow involves merchant products, carts, checkout, fulfillment or order lifecycle.","You are building a merchant surface that should work with agentic shopping experiences.","The integration needs commerce-specific semantics rather than generic tool calls.","You want an interoperable commerce contract that can coexist with MCP, A2A and payment protocols.",{},{"id":464,"data":1130,"type":42,"tunes":1132},{"text":1131,"level":219},"4. AP2: prove that the agent was allowed to spend",{},{"id":469,"data":1134,"type":226,"tunes":1136},{"text":1135},"Agentic commerce introduces a problem that ordinary checkout flows did not have to solve in the same way: an agent may transact when the human is not clicking the final button in real time. The Agent Payments Protocol (AP2) addresses authorization, authenticity and accountability for agent-led payments.",{},{"id":474,"data":1138,"type":226,"tunes":1140},{"text":1139},"Google's 2026 protocol guide describes AP2 through typed mandates that capture user intent, spending constraints and the specific transaction being authorized. AP2 can work as an extension alongside UCP: UCP describes the commerce transaction, while AP2 provides evidence that the agent had authority to perform the payment.",{},{"id":479,"data":1142,"type":226,"tunes":1144},{"text":1143},"This distinction is important. A checkout protocol can tell a merchant what should be purchased. It does not by itself prove who authorized the agent to spend, under what limit, for which merchant, for how long, or whether the final cart remained inside that authority.",{},{"id":484,"data":1146,"type":42,"tunes":1148},{"text":1147,"level":219},"UCP vs AP2: transaction semantics vs authority",{},{"id":489,"data":1150,"type":304,"tunes":1174},{"content":1151,"stretched":43,"withHeadings":14},[1152,1154,1158,1162,1166,1170],[1153,290,295],"Question",[1155,1156,1157],"What is being bought?","Commerce items, cart, checkout and fulfillment semantics","References the authorized transaction context",[1159,1160,1161],"Who may authorize it?","Not the primary protocol responsibility","Explicit agent\u002Fuser authority and mandate model",[1163,1164,1165],"What spending constraints apply?","Commerce flow can contain totals and checkout data","Authorization guardrails and intent limits",[1167,1168,1169],"How is the transaction audited?","Order and commerce lifecycle","Cryptographic \u002F verifiable authorization trail through mandates and receipts",[1171,1172,1173],"Can they work together?","Yes","Yes — AP2 can extend agentic commerce flows",{},{"id":516,"data":1176,"type":42,"tunes":1178},{"text":1177,"level":219},"5. A2UI: let agents describe interfaces without owning your frontend",{},{"id":521,"data":1180,"type":226,"tunes":1182},{"text":1181},"Agent-to-User Interface (A2UI) tackles another boundary: how a remote or local agent communicates a rich interactive interface to a host application. Instead of sending arbitrary HTML, CSS and JavaScript, A2UI uses declarative data that the host renders through its own trusted component catalog.",{},{"id":526,"data":1184,"type":226,"tunes":1186},{"text":1185},"This preserves the host application's design system and security model while still allowing an agent to request dynamic interfaces. A2UI v0.9 specifically emphasizes framework-agnostic UI intent and streaming updates across web, mobile and other clients.",{},{"id":531,"data":1188,"type":226,"tunes":1190},{"text":1189},"Google's later A2UI + MCP Apps work also demonstrates that these UI models are not necessarily mutually exclusive. Declarative native UI and richer embedded application experiences can coexist depending on the task.",{},{"id":536,"data":1192,"type":42,"tunes":1194},{"text":1193,"level":218},"Use A2UI when",{},{"id":541,"data":1196,"type":343,"tunes":1203},{"meta":1197,"items":1198,"style":342},{},[1199,1200,1201,1202],"A remote agent needs to request forms, cards, controls or other interactive UI.","The host should preserve its native components, styling and security boundary.","You do not want remote agents shipping arbitrary executable frontend code.","The same agent-defined UI intent should work across different client frameworks.",{},{"id":551,"data":1205,"type":42,"tunes":1207},{"text":1206,"level":219},"The Protocol Selection Test",{},{"id":556,"data":1209,"type":226,"tunes":1211},{"text":1210},"Do not start from the acronym. Start from the relationship that needs interoperability.",{},{"id":561,"data":1213,"type":587,"tunes":1237},{"steps":1214,"title":1236,"orientation":586},[1215,1218,1221,1224,1227,1230,1233],{"label":1216,"description":1217},"1. Identify the two independent parties","Is this AI-to-tool, agent-to-agent, agent-to-merchant, agent-to-payment authority, or agent-to-user-interface?",{"label":1219,"description":1220},"2. Identify the shared object","Is the contract about a tool call, task, cart, payment mandate, artifact, or UI description?",{"label":1222,"description":1223},"3. Check whether a domain protocol already exists","Prefer commerce or payment semantics when the problem is commerce or authorization instead of encoding everything as generic tools.",{"label":1225,"description":1226},"4. Keep local internals local","Do not expose an entire agent as MCP tools if the remote party only needs an A2A capability, and do not make a remote agent responsible for your UI runtime.",{"label":1228,"description":1229},"5. Compose protocols when the workflow crosses boundaries","One workflow can legitimately cross tool, agent, commerce, payment and UI contracts.",{"label":1231,"description":1232},"6. Version each contract independently","Protocol versions evolve at different speeds; do not tie every integration to one monolithic application version.",{"label":1234,"description":1235},"7. Preserve authorization at every boundary","Interoperability does not replace product permissions, tool authorization, payment authority or data-access policy.","Choose the protocol by the boundary",{},{"id":590,"data":1239,"type":42,"tunes":1241},{"text":1240,"level":219},"A realistic multi-protocol workflow",{},{"id":595,"data":1243,"type":587,"tunes":1264},{"steps":1244,"title":1263,"orientation":586},[1245,1248,1251,1254,1257,1260],{"label":1246,"description":1247},"1. Inspect internal stock with MCP","The purchasing agent calls inventory and forecasting capabilities exposed by internal MCP servers.",{"label":1249,"description":1250},"2. Discover a supplier agent with A2A","The agent reads the supplier's Agent Card and delegates an availability and lead-time task.",{"label":1252,"description":1253},"3. Negotiate the commerce object with UCP","The supplier or merchant surface returns structured cart, checkout and fulfillment information.",{"label":1255,"description":1256},"4. Check spending authority with AP2","The purchase is compared with the user's or organization's signed mandate, merchant constraints and spending limits.",{"label":1258,"description":1259},"5. Ask for approval through A2UI","If human approval is required, the agent sends declarative UI intent and the host renders the approval experience using trusted native components.",{"label":1261,"description":1262},"6. Complete and audit","Commerce state, payment authorization, agent task evidence and application audit records remain traceable across their respective boundaries.","Example: an autonomous procurement workflow",{},{"id":619,"data":1266,"type":42,"tunes":1268},{"text":1267,"level":219},"Why one universal agent protocol is unlikely to replace all of them",{},{"id":624,"data":1270,"type":226,"tunes":1272},{"text":1271},"A universal protocol sounds simpler until it must encode every domain's semantics. Tool discovery, long-running agent collaboration, checkout, payment authorization and native UI all have different lifecycle, security and correctness requirements.",{},{"id":629,"data":1274,"type":226,"tunes":1276},{"text":1275},"The web itself evolved through layered protocols rather than one message format for every problem. The emerging agentic stack appears to be moving in the same direction: common horizontal primitives, specialized domain contracts and explicit discovery\u002Fversioning.",{},{"id":634,"data":1278,"type":226,"tunes":1280},{"text":1279},"The architecture challenge therefore shifts from “which protocol wins?” to how cleanly protocols compose without duplicating identity, authorization, state and audit semantics.",{},{"id":639,"data":1282,"type":42,"tunes":1284},{"text":1283,"level":219},"Protocol composition creates new failure modes",{},{"id":644,"data":1286,"type":304,"tunes":1316},{"content":1287,"stretched":43,"withHeadings":14},[1288,1292,1296,1300,1304,1308,1312],[1289,1290,1291],"Failure mode","What happens","Architecture control",[1293,1294,1295],"Authority leakage","A valid tool or agent capability is treated as permission to perform a business action","Keep product authorization independent from protocol capability discovery",[1297,1298,1299],"Identity mismatch","MCP host identity, A2A agent identity and commerce\u002Fpayment identity refer to different principals","Define explicit principal mapping across boundaries",[1301,1302,1303],"Version drift","One protocol upgrades while dependent adapters assume older semantics","Negotiate and pin protocol versions independently",[1305,1306,1307],"State duplication","The same cart, task or approval state is copied into several protocol layers","Define one authoritative owner per domain object",[1309,1310,1311],"Audit fragmentation","Tool traces, agent tasks, checkout and payment evidence cannot be joined","Carry correlation IDs and stable domain identifiers across protocol boundaries",[1313,1314,1315],"Semantic tunneling","Everything is forced through a generic protocol as opaque JSON","Use domain protocols where their semantics materially improve correctness",{},{"id":677,"data":1318,"type":42,"tunes":1320},{"text":1319,"level":219},"Protocol choice does not replace application architecture",{},{"id":682,"data":1322,"type":226,"tunes":1324},{"text":1323},"Open standards reduce integration coupling, but they do not decide your domain model, authorization policy, source of truth, retry strategy or acceptance criteria. An MCP tool can still expose the wrong capability. An A2A agent can still return a bad artifact. A UCP checkout can still contain stale merchant data. An AP2 mandate can still be misapplied by application logic.",{},{"id":687,"data":1326,"type":226,"tunes":1328},{"text":1327},"Treat protocols as contracts between independently evolving components. Keep domain truth and consequential policy in the application layer that owns them, then use protocols to make the boundaries interoperable.",{},{"id":692,"data":1330,"type":698,"tunes":1335},{"url":1331,"title":1332,"excerpt":1333,"ctaLabel":1334},"https:\u002F\u002Fstajic.de\u002Fblog\u002Fmanaged-agent-harness-vs-self-hosted-agent-loop-what-you-gain-what-you-lose","Managed Agent Harness vs Self-Hosted Agent Loop: What You Gain, What You Lose","Protocol boundaries solve interoperability. Runtime boundaries solve who operates the harness, execution environment and application control plane.","Read the runtime architecture guide",{},{"id":701,"data":1337,"type":42,"tunes":1339},{"text":1338,"level":219},"What would change this answer?",{},{"id":706,"data":1341,"type":226,"tunes":1343},{"text":1342},"The stack changes if protocols converge, one standard formally absorbs another, or vendors standardize a shared identity and authorization layer across several boundaries. UCP already demonstrates composition by supporting APIs, A2A and MCP and by integrating with AP2 rather than replacing them.",{},{"id":711,"data":1345,"type":226,"tunes":1347},{"text":1346},"The answer also changes by application scope. A small internal agent may need only MCP. A multi-company workflow may need A2A. A merchant may need UCP without A2UI. A delegated purchasing agent may need all of them. Use the smallest protocol set that represents the real boundaries without flattening domain semantics.",{},{"id":716,"data":1349,"type":42,"tunes":1351},{"text":1350,"level":219},"Limitations",{},{"id":721,"data":1353,"type":226,"tunes":1355},{"text":1354},"The protocols discussed here are at different maturity levels and have different governance models. A2A has reached a stable v1.0 specification, while other standards continue to evolve rapidly. Ecosystem adoption is also uneven across vendors and frameworks.",{},{"id":726,"data":1357,"type":226,"tunes":1359},{"text":1358},"This article focuses on architecture responsibility rather than implementation completeness. Specific authentication methods, transport bindings, schemas and extension mechanisms must be taken from each protocol's current specification.",{},{"id":731,"data":1361,"type":42,"tunes":1363},{"text":1362,"level":219},"Conclusion",{},{"id":736,"data":1365,"type":226,"tunes":1367},{"text":1366},"MCP, A2A, UCP, AP2 and A2UI make more sense when viewed as protocols for different relationships, not five competing attempts to standardize “agents.”",{},{"id":741,"data":1369,"type":226,"tunes":1371},{"text":1370},"MCP exposes capabilities. A2A coordinates independent agents. UCP gives commerce its own machine-readable contract. AP2 adds verifiable payment authority. A2UI gives agents a safe declarative path into user interfaces. The emerging agentic web is therefore not replacing protocols with AI; it is creating a new protocol stack around AI.",{},{"id":746,"data":1373,"type":42,"tunes":1375},{"text":1374,"level":219},"FAQ",{},{"id":751,"data":1377,"type":751,"tunes":1398},{"items":1378,"title":1397},[1379,1382,1385,1388,1391,1394],{"id":755,"answer":1380,"question":1381},"No. MCP primarily standardizes how AI applications access tools, resources and data. A2A standardizes collaboration between independent agent systems. A remote agent can internally use MCP while exposing an A2A interface.","Is A2A a replacement for MCP?",{"id":759,"answer":1383,"question":1384},"Not generally. UCP provides commerce-specific semantics such as cart, checkout and fulfillment. MCP can still expose merchant tools or data, and UCP is designed to coexist with MCP and A2A.","Is UCP a replacement for MCP in shopping agents?",{"id":763,"answer":1386,"question":1387},"UCP standardizes commerce interactions and transaction lifecycle. AP2 focuses on proving that an agent had authority to perform a payment under defined user or organizational constraints.","What is the difference between UCP and AP2?",{"id":767,"answer":1389,"question":1390},"A2UI lets agents send declarative UI intent to a host application, which renders the experience through trusted native components instead of executing arbitrary remote frontend code.","What problem does A2UI solve?",{"id":771,"answer":1392,"question":1393},"Yes. A workflow can use MCP for internal tools, A2A for remote-agent delegation, UCP for commerce, AP2 for payment authorization and A2UI for human interaction.","Can one agent application use all of these protocols?",{"id":775,"answer":1395,"question":1396},"Start from the interoperability boundary. If the problem is tool access, evaluate MCP. If it is independent-agent collaboration, evaluate A2A. If it is commerce, UCP. If it is delegated payment authority, AP2. If it is portable agent-driven UI, A2UI.","Which protocol should I implement first?","MCP, A2A, UCP, AP2 and A2UI",{},{"id":781,"data":1400,"type":42,"tunes":1402},{"text":1401,"level":219},"Glossary",{},{"id":786,"data":1404,"type":786,"tunes":1420},{"title":1405,"entries":1406},"Key agent-protocol terms",[1407,1409,1411,1413,1415,1417],{"term":280,"anchor":418,"definition":1408},"Model Context Protocol, an open standard for exposing tools, resources and prompts from external systems to compatible AI hosts.",{"term":285,"anchor":420,"definition":1410},"Agent2Agent Protocol, an open standard for discovering and collaborating with independent agent systems through messages, tasks and artifacts.",{"term":290,"anchor":795,"definition":1412},"Universal Commerce Protocol, an open standard for interoperable agentic commerce journeys between consumer surfaces, businesses and payment providers.",{"term":295,"anchor":798,"definition":1414},"Agent Payments Protocol, an open standard for representing and verifying authority, intent and accountability in agent-led payments.",{"term":300,"anchor":801,"definition":1416},"Agent-to-User Interface, a declarative protocol for allowing agents to request UI that is rendered using the host application's trusted components.",{"term":1418,"anchor":805,"definition":1419},"Protocol composition","Using multiple protocols in one workflow, each responsible for a distinct interoperability boundary rather than forcing all semantics through one contract.",{},{"id":809,"data":1422,"type":42,"tunes":1424},{"text":1423,"level":219},"Primary sources and further reading",{},{"id":814,"data":1426,"type":821,"tunes":1431},{"link":816,"meta":1427},{"image":1428,"title":1429,"description":1430},{"url":399},"Google Developers — Developer's Guide to AI Agent Protocols","A practical overview showing MCP, A2A, UCP, AP2, A2UI and related protocols working together in one multi-step agent workflow.",{},{"id":824,"data":1433,"type":821,"tunes":1437},{"link":826,"meta":1434},{"image":1435,"title":829,"description":1436},{"url":399},"Current stable SDK documentation implementing the 2026-07-28 MCP specification and defining tools, resources, prompts and host\u002Fserver integration.",{},{"id":833,"data":1439,"type":821,"tunes":1444},{"link":835,"meta":1440},{"image":1441,"title":1442,"description":1443},{"url":399},"A2A Protocol — v1.0 Specification","Current A2A protocol specification covering Agent Cards, messages, tasks, artifacts, bindings and version negotiation.",{},{"id":842,"data":1446,"type":821,"tunes":1451},{"link":844,"meta":1447},{"image":1448,"title":1449,"description":1450},{"url":399},"A2A — Joining the Agentic AI Foundation","Current project framing of A2A as the horizontal agent-collaboration layer alongside MCP as vertical tool\u002Fdata integration.",{},{"id":851,"data":1453,"type":821,"tunes":1458},{"link":853,"meta":1454},{"image":1455,"title":1456,"description":1457},{"url":399},"Google Developers — Under the Hood: Universal Commerce Protocol","Technical overview of UCP, its commerce primitives and its ability to compose with APIs, A2A, MCP and AP2.",{},{"id":860,"data":1460,"type":821,"tunes":1465},{"link":862,"meta":1461},{"image":1462,"title":1463,"description":1464},{"url":399},"Google Universal Commerce Protocol — UCP Profile","Current versioned profile mechanism for publishing UCP services and merchant commerce capabilities.",{},{"id":869,"data":1467,"type":821,"tunes":1472},{"link":871,"meta":1468},{"image":1469,"title":1470,"description":1471},{"url":399},"Google Cloud — Agent Payments Protocol (AP2)","Announcement and rationale for an open protocol covering authorization, authenticity and accountability in agent-led payments.",{},{"id":878,"data":1474,"type":821,"tunes":1478},{"link":880,"meta":1475},{"image":1476,"title":883,"description":1477},{"url":399},"A2UI's framework-agnostic declarative model for portable agent-driven interfaces rendered by host-native components.",{},{"id":887,"data":1480,"type":821,"tunes":1484},{"link":889,"meta":1481},{"image":1482,"title":892,"description":1483},{"url":399},"How declarative A2UI and richer MCP App experiences can coexist rather than being treated as mutually exclusive UI models.",{},"2.31.6","MCP, A2A, UCP, AP2 and A2UI are often presented as competing agent standards. They mostly solve different interoperability problems. This guide maps each protocol to the boundary it actually standardizes—and shows how they can work together in one production system.",{"lang":7,"title":208,"content":210,"contentJson":1488,"excerpt":896},{"time":212,"blocks":1489,"version":895},[1490,1493,1496,1499,1502,1505,1508,1511,1514,1517,1527,1530,1533,1536,1539,1542,1547,1550,1553,1556,1559,1562,1565,1570,1573,1589,1592,1595,1598,1601,1604,1607,1612,1615,1618,1621,1624,1627,1637,1640,1643,1646,1649,1652,1657,1660,1663,1674,1677,1687,1690,1693,1696,1699,1702,1713,1716,1719,1722,1725,1728,1731,1734,1737,1740,1743,1746,1749,1752,1755,1765,1768,1778,1781,1786,1791,1796,1801,1806,1811,1816,1821],{"id":215,"data":1491,"type":220,"tunes":1492},{"title":217,"maxLevel":218,"minLevel":219},{},{"id":223,"data":1494,"type":226,"tunes":1495},{"text":225},{},{"id":229,"data":1497,"type":234,"tunes":1498},{"body":231,"title":232,"variant":233},{},{"id":237,"data":1500,"type":234,"tunes":1501},{"body":239,"title":240,"variant":241},{},{"id":244,"data":1503,"type":234,"tunes":1504},{"body":246,"title":247,"variant":248},{},{"id":251,"data":1506,"type":42,"tunes":1507},{"text":253,"level":219},{},{"id":256,"data":1509,"type":226,"tunes":1510},{"text":258},{},{"id":261,"data":1512,"type":226,"tunes":1513},{"text":263},{},{"id":266,"data":1515,"type":42,"tunes":1516},{"text":268,"level":219},{},{"id":271,"data":1518,"type":304,"tunes":1526},{"content":1519,"stretched":43,"withHeadings":14},[1520,1521,1522,1523,1524,1525],[275,276,277,278],[280,281,282,283],[285,286,287,288],[290,291,292,293],[295,296,297,298],[300,301,302,303],{},{"id":307,"data":1528,"type":234,"tunes":1529},{"body":309,"title":310,"variant":311},{},{"id":314,"data":1531,"type":42,"tunes":1532},{"text":316,"level":219},{},{"id":319,"data":1534,"type":226,"tunes":1535},{"text":321},{},{"id":324,"data":1537,"type":226,"tunes":1538},{"text":326},{},{"id":329,"data":1540,"type":42,"tunes":1541},{"text":331,"level":218},{},{"id":334,"data":1543,"type":343,"tunes":1546},{"meta":1544,"items":1545,"style":342},{},[338,339,340,341],{},{"id":346,"data":1548,"type":234,"tunes":1549},{"body":348,"title":349,"variant":241},{},{"id":352,"data":1551,"type":42,"tunes":1552},{"text":354,"level":219},{},{"id":357,"data":1554,"type":226,"tunes":1555},{"text":359},{},{"id":362,"data":1557,"type":226,"tunes":1558},{"text":364},{},{"id":367,"data":1560,"type":226,"tunes":1561},{"text":369},{},{"id":372,"data":1563,"type":42,"tunes":1564},{"text":374,"level":218},{},{"id":377,"data":1566,"type":343,"tunes":1569},{"meta":1567,"items":1568,"style":342},{},[381,382,383,384],{},{"id":387,"data":1571,"type":42,"tunes":1572},{"text":389,"level":219},{},{"id":392,"data":1574,"type":421,"tunes":1588},{"rows":1575,"title":412,"layout":304,"columns":1584},[1576,1578,1580,1582],{"id":396,"label":397,"values":1577},[399,399,399],{"id":401,"label":402,"values":1579},[399,399,399],{"id":405,"label":406,"values":1581},[399,399,399],{"id":409,"label":410,"values":1583},[399,399,399],[1585,1586,1587],{"id":415,"label":416},{"id":418,"label":280},{"id":420,"label":285},{},{"id":424,"data":1590,"type":226,"tunes":1591},{"text":426},{},{"id":429,"data":1593,"type":42,"tunes":1594},{"text":431,"level":219},{},{"id":434,"data":1596,"type":226,"tunes":1597},{"text":436},{},{"id":439,"data":1599,"type":226,"tunes":1600},{"text":441},{},{"id":444,"data":1602,"type":226,"tunes":1603},{"text":446},{},{"id":449,"data":1605,"type":42,"tunes":1606},{"text":451,"level":218},{},{"id":454,"data":1608,"type":343,"tunes":1611},{"meta":1609,"items":1610,"style":342},{},[458,459,460,461],{},{"id":464,"data":1613,"type":42,"tunes":1614},{"text":466,"level":219},{},{"id":469,"data":1616,"type":226,"tunes":1617},{"text":471},{},{"id":474,"data":1619,"type":226,"tunes":1620},{"text":476},{},{"id":479,"data":1622,"type":226,"tunes":1623},{"text":481},{},{"id":484,"data":1625,"type":42,"tunes":1626},{"text":486,"level":219},{},{"id":489,"data":1628,"type":304,"tunes":1636},{"content":1629,"stretched":43,"withHeadings":14},[1630,1631,1632,1633,1634,1635],[493,290,295],[495,496,497],[499,500,501],[503,504,505],[507,508,509],[511,512,513],{},{"id":516,"data":1638,"type":42,"tunes":1639},{"text":518,"level":219},{},{"id":521,"data":1641,"type":226,"tunes":1642},{"text":523},{},{"id":526,"data":1644,"type":226,"tunes":1645},{"text":528},{},{"id":531,"data":1647,"type":226,"tunes":1648},{"text":533},{},{"id":536,"data":1650,"type":42,"tunes":1651},{"text":538,"level":218},{},{"id":541,"data":1653,"type":343,"tunes":1656},{"meta":1654,"items":1655,"style":342},{},[545,546,547,548],{},{"id":551,"data":1658,"type":42,"tunes":1659},{"text":553,"level":219},{},{"id":556,"data":1661,"type":226,"tunes":1662},{"text":558},{},{"id":561,"data":1664,"type":587,"tunes":1673},{"steps":1665,"title":585,"orientation":586},[1666,1667,1668,1669,1670,1671,1672],{"label":565,"description":566},{"label":568,"description":569},{"label":571,"description":572},{"label":574,"description":575},{"label":577,"description":578},{"label":580,"description":581},{"label":583,"description":584},{},{"id":590,"data":1675,"type":42,"tunes":1676},{"text":592,"level":219},{},{"id":595,"data":1678,"type":587,"tunes":1686},{"steps":1679,"title":616,"orientation":586},[1680,1681,1682,1683,1684,1685],{"label":599,"description":600},{"label":602,"description":603},{"label":605,"description":606},{"label":608,"description":609},{"label":611,"description":612},{"label":614,"description":615},{},{"id":619,"data":1688,"type":42,"tunes":1689},{"text":621,"level":219},{},{"id":624,"data":1691,"type":226,"tunes":1692},{"text":626},{},{"id":629,"data":1694,"type":226,"tunes":1695},{"text":631},{},{"id":634,"data":1697,"type":226,"tunes":1698},{"text":636},{},{"id":639,"data":1700,"type":42,"tunes":1701},{"text":641,"level":219},{},{"id":644,"data":1703,"type":304,"tunes":1712},{"content":1704,"stretched":43,"withHeadings":14},[1705,1706,1707,1708,1709,1710,1711],[648,649,650],[652,653,654],[656,657,658],[660,661,662],[664,665,666],[668,669,670],[672,673,674],{},{"id":677,"data":1714,"type":42,"tunes":1715},{"text":679,"level":219},{},{"id":682,"data":1717,"type":226,"tunes":1718},{"text":684},{},{"id":687,"data":1720,"type":226,"tunes":1721},{"text":689},{},{"id":692,"data":1723,"type":698,"tunes":1724},{"url":694,"title":695,"excerpt":696,"ctaLabel":697},{},{"id":701,"data":1726,"type":42,"tunes":1727},{"text":703,"level":219},{},{"id":706,"data":1729,"type":226,"tunes":1730},{"text":708},{},{"id":711,"data":1732,"type":226,"tunes":1733},{"text":713},{},{"id":716,"data":1735,"type":42,"tunes":1736},{"text":718,"level":219},{},{"id":721,"data":1738,"type":226,"tunes":1739},{"text":723},{},{"id":726,"data":1741,"type":226,"tunes":1742},{"text":728},{},{"id":731,"data":1744,"type":42,"tunes":1745},{"text":733,"level":219},{},{"id":736,"data":1747,"type":226,"tunes":1748},{"text":738},{},{"id":741,"data":1750,"type":226,"tunes":1751},{"text":743},{},{"id":746,"data":1753,"type":42,"tunes":1754},{"text":748,"level":219},{},{"id":751,"data":1756,"type":751,"tunes":1764},{"items":1757,"title":778},[1758,1759,1760,1761,1762,1763],{"id":755,"answer":756,"question":757},{"id":759,"answer":760,"question":761},{"id":763,"answer":764,"question":765},{"id":767,"answer":768,"question":769},{"id":771,"answer":772,"question":773},{"id":775,"answer":776,"question":777},{},{"id":781,"data":1766,"type":42,"tunes":1767},{"text":783,"level":219},{},{"id":786,"data":1769,"type":786,"tunes":1777},{"title":788,"entries":1770},[1771,1772,1773,1774,1775,1776],{"term":280,"anchor":418,"definition":791},{"term":285,"anchor":420,"definition":793},{"term":290,"anchor":795,"definition":796},{"term":295,"anchor":798,"definition":799},{"term":300,"anchor":801,"definition":802},{"term":804,"anchor":805,"definition":806},{},{"id":809,"data":1779,"type":42,"tunes":1780},{"text":811,"level":219},{},{"id":814,"data":1782,"type":821,"tunes":1785},{"link":816,"meta":1783},{"image":1784,"title":819,"description":820},{"url":399},{},{"id":824,"data":1787,"type":821,"tunes":1790},{"link":826,"meta":1788},{"image":1789,"title":829,"description":830},{"url":399},{},{"id":833,"data":1792,"type":821,"tunes":1795},{"link":835,"meta":1793},{"image":1794,"title":838,"description":839},{"url":399},{},{"id":842,"data":1797,"type":821,"tunes":1800},{"link":844,"meta":1798},{"image":1799,"title":847,"description":848},{"url":399},{},{"id":851,"data":1802,"type":821,"tunes":1805},{"link":853,"meta":1803},{"image":1804,"title":856,"description":857},{"url":399},{},{"id":860,"data":1807,"type":821,"tunes":1810},{"link":862,"meta":1808},{"image":1809,"title":865,"description":866},{"url":399},{},{"id":869,"data":1812,"type":821,"tunes":1815},{"link":871,"meta":1813},{"image":1814,"title":874,"description":875},{"url":399},{},{"id":878,"data":1817,"type":821,"tunes":1820},{"link":880,"meta":1818},{"image":1819,"title":883,"description":884},{"url":399},{},{"id":887,"data":1822,"type":821,"tunes":1825},{"link":889,"meta":1823},{"image":1824,"title":892,"description":893},{"url":399},{},"Post erfolgreich abgerufen",{"items":1828,"source":1878,"manualIds":1879,"manualMatchedIds":1880},[1829,1836,1843,1850,1857,1864,1871],{"id":1830,"slug":1831,"title":1832,"excerpt":1833,"featuredImage":1834,"publishedAt":1835},"478","what-is-rag-the-simplest-explanation-of-how-it-works","Что такое RAG? Самое простое объяснение того, как это работает","RAG звучит сложно, но идея проста: прежде чем ИИ ответит, он сначала находит полезную информацию из источника знаний и передаёт эту информацию языковой модели. В этом руководстве объясняются RAG, LLM, состояние, память и инструменты с помощью одной простой ментальной модели.","\u002Fuploads\u002F2026\u002F09\u002Fwhat-is-rag-the-simplest-explanation-of-how-it-works-1790377492124-khjagt.webp","2026-09-25T19:03:00.000Z",{"id":1837,"slug":1838,"title":1839,"excerpt":1840,"featuredImage":1841,"publishedAt":1842},"466","the-gpu-is-not-the-product-future-proof-private-ai-architecture","GPU — не продукт: перспективная архитектура приватного ИИ","Инфраструктура приватного ИИ не должна проектироваться вокруг одного GPU или одной модели. Более устойчивый подход объединяет быстрые GPU для инференса, ИИ-системы с большим объемом памяти, узлы физического ИИ и опциональные передовые облачные модели за уровнем маршрутизации, учитывающим возможности.","\u002Fuploads\u002F2026\u002F09\u002Fthe-gpu-is-not-the-product-future-proof-private-ai-architecture-1790140878812-8hsl39.webp","2026-09-23T01:19:00.000Z",{"id":1844,"slug":1845,"title":1846,"excerpt":1847,"featuredImage":1848,"publishedAt":1849},"470","what-should-an-ai-agent-remember-forget-recompute-or-retrieve-again","Что ИИ-агент должен помнить, забывать, перевычислять или извлекать повторно?","Долгоживущие агенты не должны помнить всё. В этой статье представлена практическая модель жизненного цикла для определения того, что относится к долговременной памяти, что следует извлекать повторно, что безопаснее пересчитать, а что должно истечь по сроку действия или быть заменено.","\u002Fuploads\u002F2026\u002F09\u002Fwhat-should-an-ai-agent-remember-forget-recompute-or-retrieve-again-1790351131087-iehz28.webp","2026-09-25T09:43:00.000Z",{"id":1851,"slug":1852,"title":1853,"excerpt":1854,"featuredImage":1855,"publishedAt":1856},"471","how-to-know-whether-an-ai-agent-actually-used-the-right-evidence","Как узнать, действительно ли ИИ-агент использовал правильные доказательства","ИИ-агент может ссылаться на источники и при этом использовать неверные доказательства. В этой статье представлен практический метод проверки обоснованности утверждений, авторитетности источников, применимости, происхождения и того, действительно ли доказательства повлияли на ответ.","\u002Fuploads\u002F2026\u002F09\u002Fhow-to-know-whether-an-ai-agent-actually-used-the-right-evidence-1790351317188-o5z9ve.webp","2026-09-25T11:47:00.000Z",{"id":1858,"slug":1859,"title":1860,"excerpt":1861,"featuredImage":1862,"publishedAt":1863},"468","ai-agent-memory-is-not-rag-how-to-separate-memory-retrieval-state-and-context","Память ИИ-агента — это не RAG: как разграничить память, извлечение, состояние и контекст","Память агента, RAG, состояние и контекст часто используются так, будто они взаимозаменяемы. Это не так. Эта практическая архитектурная модель разделяет четыре уровня, показывает, где место каждого из них, и объясняет, что ломается, когда системы объединяют их в одно целое.","\u002Fuploads\u002F2026\u002F09\u002Fai-agent-memory-is-not-rag-how-to-separate-memory-retrieval-state-and-context-1790350560308-np0xy6.webp","2026-09-25T11:34:00.000Z",{"id":1865,"slug":1866,"title":1867,"excerpt":1868,"featuredImage":1869,"publishedAt":1870},"467","the-answer-validity-boundary-the-missing-layer-between-relevance-and-reliable-ai-answers","Граница достоверности ответа: недостающий слой между релевантностью и надёжными ответами ИИ","Источник может быть релевантным, авторитетным и при этом неверным для задаваемого вопроса. Недостающий слой — применимость: условия, при которых ответ остаётся в силе, и изменения, вынуждающие пересмотреть его. В этой статье вводится понятие «Граница действительности ответа» как паттерн проектирования источников для людей, ИИ-поиска и RAG-систем.","\u002Fuploads\u002F2026\u002F09\u002Fthe-answer-validity-boundary-the-missing-layer-between-relevance-and-reliable-ai-answers-1790272901306-1g5jly.webp","2026-09-24T11:59:00.000Z",{"id":1872,"slug":1873,"title":1874,"excerpt":1875,"featuredImage":1876,"publishedAt":1877},"473","openai-agents-api-vs-agents-sdk-vs-responses-api-what-should-you-build-on-in-2026","OpenAI Agents API против Agents SDK против Responses API: на чем вам стоит разрабатывать в 2026 году?","Стек агентов OpenAI изменился в сентябре 2026 года. Это архитектурное руководство разделяет Agents API, Agents SDK, Responses API и Codex SDK по владению средой выполнения — чтобы команды могли выбрать правильную границу контроля вместо сравнения названий продуктов.","\u002Fuploads\u002F2026\u002F09\u002Fopenai-agents-api-vs-agents-sdk-vs-responses-api-what-should-you-build-on-in-2026-1790351846714-zi7lus.webp","2026-09-25T11:56:00.000Z","fallback",[],[]]