Агентная коммерция. Как подготовить бизнес к покупателю, который… не человек. Практическое руководство для тимлидов и маркетинговых директоров

Момент, который стоит увидеть своими глазами

Прежде чем читать дальше, проведите короткий эксперимент. Откройте ChatGPT и попросите его купить конкретный товар из вашей категории — не найти, не порекомендовать, а именно подобрать, оформить заказ и довести покупку до максимально возможного этапа.

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

Это уже не гипотетический сценарий «через несколько лет». По состоянию на середину 2026 года покупательские сценарии внутри ChatGPT доступны многомиллионной аудитории, а число запросов, связанных с выбором и покупкой товаров, исчисляется десятками миллионов в день. Параллельно Google и отраслевые партнёры развивают открытые протоколы, позволяющие ИИ-агентам взаимодействовать с каталогами, оформлением заказов и другими коммерческими системами.

Вопрос о том, будут ли ИИ-агенты совершать покупки от имени людей, уже практически снят. Теперь главный вопрос звучит иначе: готов ли ваш бизнес к покупателю, который приходит не через браузер, а через агента?

Три типа покупателя, который больше не человек

Термин «агентная коммерция» часто используют как единое понятие, хотя на практике он объединяет три принципиально разных сценария. Для бизнеса это важно: требования к данным, интеграциям и процессам в каждом случае отличаются.

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

Корпоративные агенты работают от имени организации. Их задача — автоматизировать повторяющиеся закупки: пополнение расходных материалов, продление программных подписок, закупку типовых услуг или оплату согласованных счетов. Здесь решения принимаются не в свободном диалоге, а по заранее установленным правилам, бюджетам и политикам компании.

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

В этой книге мы сосредоточимся прежде всего на потребительских и корпоративных агентах, поскольку именно они уже начинают менять розничную торговлю и B2B-продажи.

Почему это не то же самое, что видимость в ИИ

Термин «агентная коммерция» часто используют как единое понятие, хотя на практике он объединяет три принципиально разных сценария. Это важно, потому что требования к данным, интеграциям и бизнес-процессам в каждом случае различаются.

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

Корпоративные агенты работают от имени организации. Их задача — автоматизировать повторяющиеся закупки: пополнение расходных материалов, продление подписок на программное обеспечение, закупку типовых услуг и оплату согласованных счетов. Здесь решения принимаются не в свободном диалоге, а по заранее установленным правилам, бюджетам и политикам компании.

Машинные агенты взаимодействуют друг с другом без участия человека. Они оплачивают обращения к API, вычислительные ресурсы, доступ к данным и другие цифровые сервисы, используя инфраструктуру, рассчитанную на автоматические микроплатежи.

Для большинства компаний именно первые два сценария станут предметом этой книги. Они уже начинают менять розничную торговлю и B2B-продажи, тогда как машинные агенты пока остаются скорее инфраструктурным направлением, чем массовым коммерческим каналом.

Масштаб, который нельзя игнорировать

Данные, появившиеся с середины 2025 года, показывают не постепенный, а очень быстрый переход к новому типу покупательского поведения. По оценкам независимых аналитических платформ, трафик на сайты ритейлеров из генеративных ИИ-систем за период с середины 2024 по середину 2025 года вырос на тысячи процентов год к году. Одновременно крупные игроки электронной коммерции сообщают о кратном росте числа заказов, инициированных через ИИ-интерфейсы и поиск.

Прогнозы также указывают на значительный экономический потенциал этого рынка. Ряд консалтинговых компаний оценивает, что к концу десятилетия агентная коммерция сможет обеспечивать сотни миллиардов долларов розничных продаж в США, а глобальный рынок — существенно больший объём.

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

Что вы получите к концу этой книги

каждая глава завершается практическим инструментом: протоколом, чек-листом или готовым шаблоном.

К концу книги у вас будут:

— ясная карта основных протоколов агентной коммерции и понимание, с какого из них начать;

— протокол аудита, который позволяет проверить, может ли ИИ-агент найти, оценить и оформить покупку вашего продукта;

— практический подход к адаптации каталога, ценообразования и логистики под требования агентных систем;

— система измерения агентских транзакций и оценки готовности бизнеса;

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

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

Первая проверка

Прежде чем двигаться дальше, проведите тот самый эксперимент, с которого началась глава, — но теперь зафиксируйте результат по простой схеме.

Попросите доступный вам ИИ-ассистент найти и, если это поддерживается, оформить покупку одного конкретного товара вашей компании. Затем ответьте на три вопроса:

— Нашёл ли агент товар и корректно ли его описал?

— Были ли цена и наличие точными на момент запроса?

— Если оформление заказа поддерживалось, удалось ли пройти этот процесс без ошибки?

Не воспринимайте отрицательный результат как неудачу. Он не означает, что ваш бизнес «не готов к ИИ», а лишь показывает, на каком этапе возникает разрыв: в данных, обнаружении товара, оформлении заказа или платёжной инфраструктуре.

Именно эти этапы мы разберём в следующей главе, где перейдём от общего представления об агентной коммерции к карте протоколов, лежащих в её основе.

Честное признание: единого стандарта пока не существует

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

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

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

Именно поэтому в этой главе мы будем изучать не отдельные бренды, а архитектуру. Если позже появятся новые протоколы, вам будет гораздо проще понять, какое место они занимают в общей системе.

Слой данных: MCP

В основании этой архитектуры лежит Model Context Protocol (MCP) — открытый протокол, разработанный для подключения ИИ-моделей к внешним источникам данных и инструментам. Изначально он создавался не как коммерческий стандарт, а как универсальный способ безопасно предоставлять модели актуальный контекст.

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

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

Слой полного цикла: UCP

Универсальный протокол коммерции (Universal Commerce Protocol, UCP) — это формирующийся открытый протокол, предназначенный для полного цикла агентной коммерции. Его цель — описать единый способ, которым ИИ-агенты могут обнаруживать товары, работать с корзиной, оформлять заказ, получать статус доставки и инициировать возвраты.

В отличие от MCP, который отвечает прежде всего за доступ к данным, UCP описывает коммерческие действия. Магазин публикует машиночитаемый манифест, в котором объявляет, какие возможности он поддерживает: поиск товаров, управление корзиной, оформление заказа, работу с заказами и другие функции. Агент читает этот манифест и понимает, как взаимодействовать с конкретным магазином без индивидуальной интеграции.

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

Слой оформления заказа: ACP

Протокол агентской коммерции (Agentic Commerce Protocol, ACP) — открытый протокол, разработанный OpenAI совместно со Stripe. Он решает более узкую, но критически важную задачу: позволяет ИИ-агенту взаимодействовать с продавцом для оформления и завершения покупки.

В отличие от Универсального протокола коммерции (UCP), который описывает более широкий набор коммерческих возможностей, ACP сосредоточен на транзакционном сценарии: агент, определившись с выбором, инициирует оформление заказа и передаёт продавцу необходимые данные для его завершения.

Практически важная деталь: ACP рассчитан на подключение к существующей коммерческой инфраструктуре. Поэтому продавцу не нужно создавать отдельный магазин или полностью новую платёжную систему специально для ИИ-агентов. Если компания уже работает с поддерживаемой платёжной или торговой платформой, часть необходимой инфраструктуры может быть предоставлена на уровне этой платформы.

Слой платёжного доверия: AP2

Протокол платежей для агентной коммерции (Agent Payments Protocol, AP2), разработанный и продвигаемый Google, решает задачу, которая становится критически важной по мере распространения агентных транзакций: как убедиться, что конкретный платёж действительно санкционирован пользователем, а не стал результатом ошибки или неправомерного действия агента.

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

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

Слой делегирования между агентами: A2A

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

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

Для большинства компаний, которые на первом этапе просто готовят существующий магазин к взаимодействию с ИИ-агентами, A2A не является приоритетом для немедленной интеграции. На него стоит обратить особое внимание, если компания сама создаёт экосистему агентов или планирует, что её агенты будут взаимодействовать с агентами других организаций.

Слой машинных микроплатежей: x402

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

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

Особый случай: платформы вне открытых стандартов

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

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

Что происходит, даже если вы ничего не делаете

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

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

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

Приоритизация протоколов

Ответьте на три вопроса, чтобы определить, с какого протокола начинать.

1. На какой платформе электронной коммерции построен ваш магазин?

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

2. Где сосредоточен трафик вашей аудитории из ИИ-систем?

Если аналитика уже показывает заметный трафик из конкретного ИИ-ассистента, это веский аргумент в пользу того, чтобы в первую очередь изучить протокол или интеграционный механизм, через который этот ассистент взаимодействует с продавцами.

3. Есть ли у вас значимая доля продаж на платформе с собственной экосистемой агентов?

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

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

Следующая глава переводит эту карту в конкретный пошаговый протокол диагностики: как проверить, на каком уровне готовности к каждому из этих слоёв реально находится ваш бизнес сегодня, а не в теории.

От разового теста к полной картине

Быстрая проверка из первой главы — попросить ассистента найти и, если это поддерживается, оформить покупку конкретного товара — даёт полезный, но неполный сигнал. Она показывает, работает ли весь путь в одном конкретном сценарии, но не позволяет понять, какой именно слой из карты второй главы стал точкой сбоя, если покупка не удалась.

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

Шаг 1. Проверка данных

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

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

Цель проверки — не добиться абстрактного «реального времени», а убедиться, что данные остаются достаточно актуальными на каждом этапе агентного сценария.

Шаг 2. Проверка манифеста и обнаружения

Если Если ваш магазин работает на платформе со встроенной поддержкой протокола полного цикла, проверьте, что соответствующий манифест действительно опубликован, доступен по предусмотренному протоколом адресу и проходит валидацию. Даже при корректно настроенной остальной инфраструктуре ошибка в манифесте может привести к тому, что агент не обнаружит магазин или неверно определит доступные ему возможности.

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

В результате проверки у вас должно быть чётко зафиксировано: существует ли манифест, корректен ли он, какие возможности магазина в нём заявлены и может ли агент обнаружить магазин и понять, какие действия ему доступны.

Шаг 3. Сквозная проверка оформления заказа

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

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

Поэтому для каждого сбоя фиксируйте не только этап, но и наблюдаемое поведение: что запросил агент, какой ответ получил, какие данные передал дальше и на каком шаге возникла ошибка. Такая запись позволит технической команде воспроизвести проблему и проверить её уже на соответствующем уровне инфраструктуры.

Шаг 4. Проверка платёжного слоя