UCP от Google добавляет четыре заголовка к каждой оплате. Три из них — для спора, который случится потом

11 января 2026 года Google опубликовала Universal Commerce Protocol — открытый стандарт, позволяющий ИИ-агентам совершать покупки. Он разработан совместно с Shopify и поддержан более чем 20 партнёрами, среди которых Etsy, Wayfair, Target, Walmart, Adyen, American Express, Mastercard, Stripe, Visa и Zalando.

Последовавшие публикации были о покупках. Агенты, которые ищут за вас, агенты, которые платят за вас, конец корзины и так далее.

А потом вы читаете спецификацию — и выясняется, что покупки в ней самое неинтересное. То, что UCP стандартизирует с необычной тщательностью, — это не покупка. Это доказательство того, что покупка произошла именно так, как утверждают обе стороны.

Коротко:

• Каждый изменяющий состояние запрос UCP несёт четыре заголовка, и три из них — request-signature, idempotency-key, request-id — для самой транзакции не делают ничего. Они существуют, чтобы потом кто-то смог доказать, что именно было запрошено, что запрошено ровно один раз, и найти эту запись снова.
• Неотказуемость — это функция с собственным именем. В необязательном расширении мандатов AP2 (dev.ucp.shopping.ap2_mandate) продавец криптографически подписывает условия оплаты, а платформа предоставляет криптографические мандаты, доказывающие, что пользователь их санкционировал. Заявленная в спецификации цель — «существенно снизить риски подмены и споров».
• Число поддержавших — это не число внедрений. «Более 20 глобальных партнёров» — формулировка Google, и она описывает поддержку. На момент написания мы не нашли ни одного первичного источника, который называл бы количество продавцов, работающих на UCP в продакшене.

Набор заголовков взят из собственного пошагового руководства Google, опубликованного в день запуска. Источники — в конце.

Что такое UCP, минимумом слов, которые остаются правдой

Перед аргументом — проверяемые факты. Они взяты из спецификации, опубликованной на ucp.dev, и из блога Google для разработчиков; оба источника получены 5 сентября 2026 года.

На двух строках этой таблицы стоит задержаться, потому что большинство обзоров пропускает обе.

Первая — строка транспортов. UCP не про MCP и не про REST. Одни и те же объявленные данные предлагаются по REST, MCP, A2A и через встроенную привязку, а выбирает продавец. Это осознанный отказ делать ставку на то, какая агентская «сантехника» победит.

Вторая — версионирование по дате. 2026-04-08 — это не семантическая версия, а день. Спецификация объясняет это хронологическим порядком и однозначностью сравнения, но практический эффект другой: каждая согласованная сессия фиксирует дату правил, по которым она проходила. Это архивное решение, переодетое в решение о версионировании, и оно задаёт тон всему остальному документу.

Узкое место, ради которого он построен

Формулировка Google — задача N×N. Каждая компания, желающая появиться внутри разговорной поверхности, должна строить отдельную интеграцию под каждую; каждая поверхность должна отдельно подключать каждую компанию; в итоге не выходит ничего.

Инженерная заметка Shopify, опубликованная в тот же день Ильёй Григориком (distinguished engineer), подступается к той же проблеме снизу. После двадцати с лишним лет, миллиардов транзакций и миллионов продавцов вывод такой: торговля отказывается нормализоваться. «Платёжные опции и правила различаются в зависимости от свойств корзины, покупателя и рынка; у скидок правила суммирования и комбинирования соперничают с налоговым кодексом; варианты доставки взрываются неуправляемыми перестановками». А затем следует фраза, которую стоит запомнить: «Эта сложность — не баг, это эмерджентное свойство разнообразия ретейлеров».

Одна эта строчка объясняет всю архитектуру. Если признать, что продавцы неустранимо разные, поведение стандартизировать нельзя. Стандартизировать можно только то, как продавец объявляет своё поведение, и то, как агент узнаёт, на что он только что согласился.

Структура, которую компания публикует по адресу /.well-known/ucp. Источник: спецификация UCP 2026-04-08, Overview.

Обнаружение происходит до того, как начнётся разговор

Вот последовательность, как её описывают спецификация и руководство Google. Её стоит пройти буквально, потому что сам порядок и есть аргумент.

1. Компания публикует профиль по адресу /.well-known/ucp. В нём объявляются версия протокола, один или несколько сервисов (dev.ucp.shopping), содержащиеся в них capability, транспорты и эндпоинты, доступные платёжные обработчики и — это пригодится дальше — открытые signing_keys.
2. Агент называет собственный профиль в каждом запросе через заголовок UCP-Agent в синтаксисе словаря RFC 8941: UCP-Agent: profile="https://agent.example/profiles/shopping-agent.json". В транспорте MCP та же информация едет в объекте meta.
3. Компания вычисляет пересечение. Из своих capability она оставляет те, что объявила и платформа; для каждой уцелевшей выбирает наивысшую версию, присутствующую в обоих массивах; если общей версии нет, capability выпадает целиком.
4. Осиротевшие расширения отсекаются. Расширение с extends: "dev.ucp.shopping.checkout" исчезает, если checkout не уцелел. Отсечение повторяется, пока ничего больше не отпадает, что покрывает транзитивные цепочки.
5. Выбирает компания. UCP использует архитектуру, где выбирает сервер: что активно в сессии, решает продавец, а не агент, и он возвращает реестр активных capability в ответе.

Именование — не соглашение, а предмет управления. Каждая capability записывается как {обратный-домен}.{сервис}.{capability}: dev.ucp.shopping.checkout для стандартной, com.example.payments.installments для собственной у продавца. Ретейлер может изобрести capability, которой нет ни у кого, не спрашивая разрешения и ни с кем не сталкиваясь, потому что обратный домен и есть источник полномочий.

У сбоев тоже есть своя таксономия, и это разделение показательно. Спецификация отделяет сбои обнаружения (транспортные ошибки: invalid_profile_url возвращает 400, profile_unreachable — 424, profile_malformed — 422) от сбоев согласования, которые являются бизнес-результатом и возвращаются обычным 200 с capabilities_incompatible в теле. «Я до вас не достучался» и «у нас нет ничего общего» — разные события, и UCP отказывается смешивать их в один 400.

Четыре заголовка едут на каждом изменяющем запросе

Посмотрим на реальный вызов. Это собственный пример Google из дня запуска: создание сессии оплаты у демонстрационного цветочного магазина.

POST /checkout-sessions
UCP-Agent: profile="https://agent.example/profile"
request-signature: test
idempotency-key: 0b50cc6b-19b2-42cd-afee-6a98e71eea87
request-id: 6d08ae4b-e7ea-44f4-846f-d7381919d4f2
Content-Type: application/json

Четыре заголовка. Спросите, зачем нужен каждый, и проступит закономерность.

Три из четырёх нужны не транзакции. Они нужны спору о транзакции.

Это не побочный продукт хорошей API-гигиены. Ключи идемпотентности и идентификаторы запросов — обычная хорошая практика в платежах, да, но спецификация идёт заметно дальше, и чем дальше она идёт, тем яснее становится замысел.

Неотказуемость — цель проектирования, а не отписка ради комплаенса

UCP перечисляет четыре механизма аутентификации, которые может принимать компания: API-ключи, OAuth 2.0, mTLS и подписи HTTP-сообщений по RFC 9421. Первые три обыкновенны. Четвёртый делает нечто особенное.

При подписях сообщений обе стороны публикуют открытые ключи в массиве signing_keys ровно того же документа профиля, который объявляет их capability. Проверяющий извлекает keyid из заголовка Signature-Input, сопоставляет его с kid в опубликованном наборе ключей подписанта и проверяет подпись. Никакого общего секрета, никакой регистрации, никакой учётной записи. Спецификация называет этот результат безразрешительным подключением: «любая платформа с обнаруживаемым профилем может взаимодействовать с любой компанией без предварительной регистрации».

Очевидную дыру закрывает привязка личности. Независимо от механизма, проверяющие обязаны убедиться, что аутентифицированный субъект действительно уполномочен действовать от имени профиля, указанного в UCP-Agent, и отклонить запрос при расхождении. Нельзя аутентифицироваться как ты сам, а затем объявить себя чужим агентом.

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

Источник: спецификация UCP 2026-04-08, разделы Identity & Authentication и Transaction Integrity.

И есть вершина лестницы. Для автономных агентов и сделок с высокой стоимостью UCP определяет необязательное расширение dev.ucp.shopping.ap2_mandate. Когда обе стороны его согласуют:

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

Агент подписывает объекты мандата приватным ключом пользователя на неагентской поверхности — то есть человек санкционирует операцию на экране, который контролирует он, а не внутри агентского цикла, который вот-вот потратит его деньги. Формулировку цели из самой спецификации стоит привести дословно, потому что это не дежурная фраза про безопасность: механизм «обеспечивает надёжные сквозные криптографические гарантии в отношении деталей транзакции и согласия участников, существенно снижая риски подмены и споров».

Вот в чём суть. Протоколу, задуманному лишь для того, чтобы агенты делали покупки, ничего этого не понадобилось бы. Подписанные условия со стороны продавца и подписанные мандаты со стороны пользователя — это не функции покупки. Это функции спора о покупке, шесть недель спустя, перед тем, кому предстоит решить, кто был прав.

Где рассказ обгоняет доказательства

Три вещи об UCP повторяются в том виде, в каком первичные источники их не подтверждают.

«20+ партнёров» — это число поддержавших. Формулировка Google: UCP «совместно разработан и поддержан более чем 20 партнёрами». Поддержка — это публичное заявление о поддержке. Это не выпущенная интеграция и тем более не работающий продавец. Мы искали первичный источник с числом продавцов, проводящих операции через UCP, и не нашли.

«Открытый стандарт» и «стандарт Google» верны оба, и напряжение здесь настоящее. Спецификация открыта, репозиторий на GitHub принимает пул-реквесты, а соглашение об именовании намеренно позволяет любому заявить своё пространство имён. При этом первую эталонную реализацию построила Google, и чтобы участвовать именно в ней, компании нужен активный аккаунт Google Merchant Center с товарами, пригодными для оформления заказа. Нейтральный протокол — и первая площадка с турникетом.

UCP не убирает продавца. Это искажают достаточно часто, чтобы сказать прямо: под UCP компания сохраняет собственную бизнес-логику и остаётся Merchant of Record. Embedded Checkout Protocol от Shopify даёт то же обязательство с другой стороны: когда в потоке нужен человек, агент загружает continue_url, и настоящая страница оплаты продавца отрисовывается внутри поверхности агента по каналу JSON-RPC 2.0, а завершает транзакцию продавец. Агент — это поверхность, а не замена.

Четыре вещи, которые мы не смогли проверить, — так и помечаем

Спецификация, опубликованная на ucp.dev на момент обращения, имеет версию 2026-04-08, и её список стандартных capability — Cart, Checkout, Identity Linking, Order — отличается от руководства от 11 января, примеры в котором работают на версии 2026-01-11 и показывают checkout, discount и fulfillment. Между этими датами что-то добавили. Мы не нашли первичного журнала изменений, указывающего, когда именно, и датированных примечаний к промежуточным версиям, поэтому сообщаем о различии, а не о событии релиза.

Мы не нашли опубликованного числа продавцов, работающих на UCP, ни у Google, ни у Shopify, ни у кого-либо из поддержавших партнёров. Отсутствие числа не доказывает, что число мало́, но именно поэтому мы никакого не приводим.

Google заявляет, что построила первую эталонную реализацию, обеспечивающую покупки внутри AI Mode в поиске и в приложении Gemini. Доступность, географию и масштаб этого развёртывания мы независимо не проверяли.

Станет ли UCP тем самым стандартом агентной коммерции — на момент написания знать невозможно, и любая статья, утверждающая обратное, гадает. Честное прочтение уже: спецификация существует, она публична, она необычно тщательна в вопросах доказательства, и несколько очень крупных компаний подписались под анонсом.

Неподписанная половина

Отступим от коммерции, потому что интересная часть обобщается.

UCP описывает мир, в котором машина действует от вашего имени, и каждый шаг этого действия оставляет след: кто попросил — подписано; на каких условиях — подписано; сколько раз — ключом; в каком порядке — корреляцией. Через шесть недель, когда списание оспорят, останется артефакт. Никому не нужно помнить.

А теперь подумайте, откуда на самом деле берутся полномочия для этих действий. Агент покупает 400 единиц, потому что было принято закупочное решение. Договор продлевается, потому что кто-то согласился с условием. Объём работ меняется, потому что двое обсудили это в четверг и один из них сказал «да».

Эти разговоры и есть неподписанная половина того же процесса. Машинная половина строится на криптографических квитанциях и на спецификации, для которой споры — сценарий первого класса. Человеческая половина в большинстве организаций — это чья-то память, другая память кого-то ещё и резюме, написанное по обеим.

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

Авторы UCP поняли это на уровне протокола и записали: храните подписанный оригинал, выводите из него что угодно и следите, чтобы вывод всегда можно было сверить с тем, что не сдвигалось. Это дисциплина, а не технология, и к часу человеческого разговора она применима ровно так же, как к POST /checkout-sessions.

Итог: агентная коммерция — это стандарт квитанций в костюме шопинга

Universal Commerce Protocol обычно описывают как способ для ИИ-агентов покупать вещи. Прочитанный целиком, он лучше описывается как попытка ответить на вопрос, с которым всё агентное вот-вот начнёт сталкиваться постоянно: когда машина действовала за меня, что именно можно доказать о том, на что я согласился?

Ответ UCP хорош: объявляйте свои capability публично, подписывайте условия, подписывайте согласие, снабжайте повтор ключом, коррелируйте вызов и подписывайте вебхук, который потом сообщает, что произошло. Победит ли протокол — вопрос по-настоящему открытый. Вопрос, вокруг которого он построен, никуда не денется, кто бы ни победил.

Остаётся вопрос, с которым стоит посидеть. Ваши агенты вот-вот получат более качественные записи о том, на что согласились они, чем те, что есть у вас о том, на что согласились вы. Чем это кончится?

---

Где здесь Telli.sh: мы строим ту самую неподписанную половину. Telli.sh записывает разговор, разделяет говорящих, переводит вживую на 15 языков и хранит исходную запись и полную расшифровку рядом с каждым созданным резюме — чтобы производный артефакт никогда не оказался единственным. Telli.sh не реализует UCP и не утверждает обратного; мы занимаемся другим концом той же задачи: решения, санкционирующие поведение агентов, чаще всего принимаются вслух и нигде не сохраняются.

Записать вашу следующую встречу с решениями

Источники

• Спецификация Universal Commerce Protocol, Overview, версия 2026-04-08 — модель сервисов, capability и расширений, соглашение об именовании, версионирование по дате, алгоритм пересечения capability, коды ошибок согласования и подписи, стандартные capability (Cart, Checkout, Identity Linking, Order), транспорты, заголовок UCP-Agent и синтаксис RFC 8941, механизмы аутентификации и безразрешительное подключение, обнаружение ключей через signing_keys, привязка личности, обязательная подпись вебхуков и раздел Transaction Integrity and Non-Repudiation; получено 5 сентября 2026 года
• Google Developers Blog, «Under the Hood: Universal Commerce Protocol (UCP)», 11 января 2026 — список партнёров и цифра более 20 поддержавших, совместимость с AP2, A2A и MCP, постановка N×N, манифест /.well-known/ucp, руководство из пяти шагов и набор заголовков POST /checkout-sessions, Merchant of Record и встроенный вариант, эталонная реализация Google в AI Mode и Gemini, требование Merchant Center; получено 5 сентября 2026 года
• Shopify Engineering, Илья Григорик, «Building the Universal Commerce Protocol», 11 января 2026 — рамка «20+ лет, миллиарды транзакций, миллионы продавцов», тезис «не баг, а эмерджентное свойство», четыре принципа проектирования и передача управления в Embedded Checkout Protocol по JSON-RPC 2.0 через continue_url; получено 5 сентября 2026 года
• Agent Payments Protocol (AP2) — платёжный протокол, совместимость с которым объявляет UCP
• Universal Commerce Protocol на GitHub — открытый репозиторий, названный в обоих анонсах
• Наш разбор GPT-6 Astra и того, что по-прежнему решает слой захвата — тот же аргумент со стороны модели: качество рассуждения ограничено сверху тем, что породило запись, о которой оно рассуждает