Источник: Waterdrop Capital

Резюме

Крупные языковые модели эволюционируют из инструментов для ответов на вопросы в интеллектуальных агентов, способных планировать, вызывать инструменты и выдавать результаты. Одновременно устойчивые монеты для расчётов, протоколы оплаты, нативные для HTTP (HTTP 402), и «умные» кошельки начинают объединяться в платёжную инфраструктуру, предназначенную для машин. Программа может получить ценовое предложение во время выполнения, подписать разрешение и совершить микроплатёж — нечто, что ещё несколько лет назад было лишь концепцией, а сегодня стало реалистичным технологическим путём.

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

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

Введение: интеллектуальные агенты получают ограниченный «распорядительный бюджет»

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

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

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

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

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

1. Почему платёж для агентов станет самостоятельным направлением

1.1 От вызова инструментов к экономическим действиям

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

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

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

1.2 Микроплатежи, высокая частота и множественные продавцы меняют экономику платежей

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

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

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

1.3 Стабильные монеты переходят от средства обмена к инфраструктуре расчётов

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

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

Это не означает, что on-chain-платежи изначально превосходят все традиционные платежи. Вопросы защиты потребителей, механизмов возвратов, конфиденциальности, управления ключами и регуляторной ответственности всё ещё требуют решения. Однако в сценариях «машина–машина», микроплатежей по факту использования и глобальных закупок услуг программируемые стабильные монеты демонстрируют очевидную совместимость. Впервые они позволяют объединить «вызов интерфейса» и «оплату интерфейса» в едином сетевом взаимодействии.

2. Платёжные протоколы уже появились: x402, MPP и HTTP-нативные транзакции

2.1 От статус-кода 402 к коммерческому интерфейсу

HTTP давно зарезервировал статус-код 402 «Требуется оплата», однако почти 30 лет он не формировал общего рабочего процесса. Протоколы машинных платежей возобновили эту семантику: клиент запрашивает платный эндпоинт, сервер возвращает код 402 и машиночитаемые условия оплаты; клиент выбирает приемлемый вариант, завершает подписание или оплату и повторяет запрос с учётными данными.

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

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

2.2 Долгосрочный характер диверсификации платёжных протоколов

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

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

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

Рисунок 1: Матрица конфигураций платёжных протоколов в условиях фрагментации

Таким образом, фрагментация не обязательно исчезнет естественным путём по мере зрелости рынка. Рынок банковских карт не свёлся к единственной карточной организации даже после длительного развития, равно как и облачные вычисления не сошлись на одном поставщике. Зрелые рынки обычно не устраняют различия, а создают поверх них агрегационные, маршрутизационные и клиринговые слои. Скорее всего, платформа агентских платежей пройдёт тот же эволюционный путь. Эта фрагментация уже измерима. Данные двух публичных сканеров (x402scan и mppscan) за последние 30 дней (по состоянию на 3 сентября 2026 г.) показывают: протокол MPP имеет 65 591 активный кошелёк покупателя в сети Tempo, x402 — 19 472 в сети Base, а лишь 365 кошельков фигурируют в обеих системах — менее 0,6 % покупателей MPP и менее 2 % покупателей x402 в Base; среди них лишь 112 выполнили более десяти транзакций в каждой системе, причём значительная их часть — это агрегаторы двух систем, осуществляющие оплату от имени пользователей с одним и тем же ключом, а не сами покупатели, использующие вторую платёжную систему. Покупатели не переходят между системами; каждая система формирует собственную независимую базу покупателей.

2.3 Онбординг продавца — лишь половина транзакции

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

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

Реальное внедрение зависит от общей сложности транзакции, а не только от сложности этапа расчёта.

3. Настоящее узкое место отрасли: у транзакций нет замкнутого цикла

Рис. 2: Полный процесс машинной закупки

3.1 Первый барьер: поиск покупаемых услуг

Агентам нужны машиночитаемые каталоги услуг. Эффективный каталог должен содержать не только названия и URL-адреса, но и описания возможностей конечных точек, входных и выходных параметров, единиц ценообразования, поддерживаемых протоколов, задержек, географических ограничений и статуса обновлений. Также необходима привязка естественноязыковых намерений к параметрам API; иначе агент знает, что ему «нужны макроэкономические данные», но не может определить, какой эндпоинт решит задачу.

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

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

3.2 Второй барьер: понимание и сравнение расчётов

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

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

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

3.3 Третий барьер: распределение средств и ликвидность между сетями

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

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

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

3.4 Четвёртый барьер: авторизация на основе политик

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

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

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

3.5 Этап пять: успешное завершение расчётов ≠ доставка услуги

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

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

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

3.6 Этап шесть: единая сверка и определение ответственности

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

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

Когда оплата встроена в цепочку рассуждений, стоимость становится сигналом обратной связи для решений модели. Без единой сверки агенты могут оптимизировать лишь ответы, а не экономический процесс их получения. Значительная часть долгосрочной ценности Agent Payment как раз и основана на такой наблюдаемости.

4. От протокола оплаты к слою машинных закупок

4.1 Ключевая абстракция будущего — это не «оплатить», а «купить»

Оплата — это действие после определения объекта и цены, тогда как закупка охватывает весь процесс от возникновения потребности до принятия результата. Предоставление агенту функции pay() позволяет лишь перевести средства на известный адрес; возможность buy() означает, что система может принять запрос, найти сервисы, сравнить варианты, выполнить оплату и вернуть проверяемый результат.

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

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

4.2 Агрегация покупателей может быть важнее агрегации продавцов

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

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

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

4.3 Построение репутации на основе реальных транзакционных данных

Машинные покупатели принимают решения очень быстро и не могут полагаться на длительную проверку. Им нужны сигналы о контрагенте одновременно с появлением предложения. Традиционные рейтинги и отзывы могут служить ориентиром, но легко подделываются за счёт накрутки объёмов, учётных записей Сибилы и связанных сторон. Если для отзыва не требуется реальная оплата, стоимость атаки особенно мала. Недавние эмпирические исследования ERC-8004 — первого разрешённого в блокчейне доверительного слоя для агентов — подтверждают это [6]. В спецификации протокола прямо указано: «Оплаты не связаны с этим протоколом» — отзывы по умолчанию не привязаны к реальным оплаченным транзакциям, а подтверждение оплаты — лишь опциональное поле. Результат: на Ethereum, BSC и Base (по состоянию на 13 мая 2026 г.) 73,5 %, 59,2 % и 90,6 % рецензентов соответственно проявили координированное поведение Сибилы.

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

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

4.4 Стратегия бюджетирования станет важной компетенцией агентов

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

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

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

5. Возможные пути эволюции платёжных функций агентов

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

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

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

5.2 Этап второй: корпоративные бюджеты и совместная работа нескольких агентов

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

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

5.3 Этап третий: расширение от цифровых сервисов до реальной экономики

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

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

5.4 Этап четвёртый: от маршрутизации между протоколами к исполнению на кросс-рынках

В долгосрочной перспективе агенты покупают не просто ответ API, а результат. Пользователь может запросить «создать достоверный отчёт по отрасли», и система автономно объединит поиск, базы данных, перевод, модели и сервисы верификации. На нижнем уровне происходит множество транзакций, а пользователь видит лишь общий бюджет, источники доказательств и итоговую доставку.

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

6. Риски и открытые вопросы

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

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

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

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

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

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

7. SELAT: обеспечение стороны покупателя для машинной коммерции

«SELAT» происходит от малайского слова «пролив», как, например, Малаккский пролив (Selat Melaka). На протяжении веков основной поток восточно-западной торговли проходил через этот водный путь — вне зависимости от порта отправки грузов или рынка назначения. SELAT стремится стать таким же проливом в машинной коммерции: независимо от платформы, к которой подключён продавец, спрос агентов будет проходить через него.

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

Рисунок 3: Схема слоя стороны покупателя SELAT

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

• Один казначейский баланс с использованием N платёжных систем

Агенты хранят баланс USDC в самоуправляемом кошельке без необходимости предварительного пополнения по цепочкам или поддержки разных клиентов для разных протоколов.

• Агрегированный каталог конечных точек

CLI SELAT интегрирует четыре сторонних реестра сервисов — Circle, MPP, Apify и pay.sh — а также собственный каталог SELAT, позволяя агентам находить и сравнивать более 4000 конечных точек сервисов на основе актуальных запросов.

• Жёсткие лимиты расходов

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

• Отсутствие необходимости миграции продавцов

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

Со стороны финансирования SELAT совместима с любыми кошельками агентов, включая кошельки Circle и MetaMask. SELAT маршрутизирует каждую покупку через платёжные системы, такие как x402 и MPP, с учётом актуальных ценовых предложений.

7.1 ERC-8004: корректные примитивы, сомнительные сигналы

ERC-8004 определяет три типа реестров — идентификации, репутации и валидации — и позволяет покупателям оставлять отзывы о продавцах. Направление верное, но в нём явно разделяются оплата и репутация: отзывы могут поступать не только от реальных транзакций, а прикрепление доказательств оплаты является необязательным.

Эмпирическое исследование внедрённой экосистемы показывает, что на Base 93,8 % рецензентов никогда не совершали платежей x402, но предоставили 94,9 % всех отзывов; значительная часть отзывов также демонстрирует координированное сибил-поведение [6]. Реестры фиксируют заявления, но покупателям на самом деле нужны результаты.

7.2 Репутация, привязанная к данным реальных транзакций, — то, что нужно покупателям

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

Слой покупателей, выполняющий оплаты, лучше всего подходит для связывания обеих сторон транзакции: каждая покупка через SELAT фиксирует, какой эндпоинт получил оплату, какая сумма была списана и метаданные статуса доставки после оплаты (2xx, 4xx, 5xx). Эти записи накапливаются непрерывно по продавцам и платёжным инфраструктурам, формируя основу «графа расчётов–доставки».

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

7.3 Оценка надёжности контрагента до транзакции

В то время как в X обсуждали создание механизма доверия в духе Google PageRank для интернета четвёртого поколения, SELAT уже запустил «Индекс транзакционной способности» atop графа расчётов–доставки, чтобы обеспечить агентов данными о надёжности контрагентов на основе реальных результатов транзакций.

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

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

Рисунок 3: Сигналы транзакционной способности на этапе получения предложения

В настоящее время CLI SELAT адаптирован для сред выполнения агентов, включая Claude Code, Codex, Cursor, Gemini CLI, OpenClaw, Hermes и Grok Bot.

8. Резюме: экономике машин нужно больше, чем просто более быстрые платёжные инфраструктуры

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

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

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

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

Список литературы

[1] Circle, «Создание открытой агентной экономики», 2026 г. https://www.circle.com/blog/building-the-open-agentic-economy

[2] SELAT, «Риск контрагента в агентских платежах: незамеченная половина», 2026 г. https://selat.ai/insights/counterparty-risk-agentic-payments

[3] Google Cloud, «AI-коммерция с новым протоколом агентских платежей (AP2)», 2025 г. https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol

[4] Фонд x402, «x402: открытый интернет-нативный стандарт платежей». https://github.com/x402-foundation/x402

[5] Протокол машинных платежей, «MPP: протокол машинных платежей на основе HTTP 402». https://mpp.dev/

[6] Сюн и др., «Можно ли доверять бездоверительным агентам? Эмпирическое исследование децентрализованной экосистемы ИИ-агентов ERC-8004», arXiv, 2026 г. https://arxiv.org/abs/2606.26028

[7] Официальный сайт SELAT: https://www.selat.ai

Статья подготовлена внешним автором и не отражает точку зрения BlockBeats.