Торговля на уровне машин: текущее состояние и недостающая инфраструктура

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

Автор: Waterdrip Capital

Введение: Агенты получают ограниченный "дискреционный бюджет"

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

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

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

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

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

1. Почему платежи агентов станут независимой веткой

---

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

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

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

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

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

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

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

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

1.3 Стейблкоины переходят от средства транзакции к инфраструктуре расчетов

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

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

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

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

---

2.1 Превращение 402 из кода состояния в бизнес-интерфейс

HTTP давно зарезервировал код состояния 402 Payment Required, но на протяжении почти 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 Keys на кошельки и адаптеры протоколов.

Истинные показатели принятия зависят от общего трения транзакций, а не только от трения на этапе расчетов.

3. Реальная узкая горловина в отрасли: транзакции без замкнутого цикла

---

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

3.1 Первый барьер: обнаружение доступных услуг

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.5 Пятый барьер: успешный расчет не равен доставке услуги

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

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

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

3.6 Шестой барьер: единая сверка и определение ответственности

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

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

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

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

---

4.1 Основная абстракция будущего — это не "платить", а "покупать"

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

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

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

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

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

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

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

4.3 Создание доверия на основе реальных данных транзакций

Машинные покупатели принимают решения быстро и не могут полагаться на длительную проверку. Им нужно одновременно получать сигналы контрагента, когда появляются котировки. Традиционные рейтинги и отзывы пользователей могут служить ссылками, но легко манипулируются фальшивыми аккаунтами, ведьмами и заинтересованными сторонами. Если оценки не требуют реальных платежей, стоимость атак особенно низка. Недавние эмпирические исследования ERC-8004 — первого разрешенного на блокчейне слоя доверия для агентов — подтвердили это. Спецификация протокола гласит: "Платежи ортогональны этому протоколу" — оценки не должны быть связаны с какими-либо реальными оплачиваемыми транзакциями, а доказательство платежа является лишь необязательным полем. В результате на 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. Заключение: Машинной экономике нужно больше, чем просто более быстрые платежные треки

---

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

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

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

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

Ссылки
[1] Circle, "Создание открытой агентной экономики", 2026. https://www.circle.com/blog/building-the-open-agentic-economy
[2] Google Cloud, "Поддержка AI-коммерции с новым протоколом платежей агентов (AP2)", 2025. https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol
[3] Фонд x402, "x402: Открытый стандарт платежей, родной для интернета". https://github.com/x402-foundation/x402
[4] Протокол платежей машин, "MPP: Протокол машинных платежей на основе HTTP 402". https://mpp.dev/
[5] Сюн и др., "Могут ли доверительные агенты быть надежными? Эмпирическое исследование децентрализованной экосистемы AI-агентов ERC-8004", arXiv, 2026. https://arxiv.org/abs/2606.26028

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