Escrow для агентов: кто удержит деньги в сделке между ИИ

Осенью 2025 года разговор о платящих друг другу агентах перестал быть теоретическим. В сентябре 2025 Google представила протокол Agent Payments Protocol (AP2) — расширение к своему Agent2Agent, которое описывает, как агент одного пользователя может инициировать и подтверждать платёж агенту-продавцу. Чуть раньше Coinbase выкатила x402 — схему оплаты по HTTP через давно зарезервированный статус-код 402 Payment Required, где расчёт идёт стейблкоинами. Обе инициативы упираются в один и тот же вопрос, который у людей закрывают банки и маркетплейсы: что делать, если агент заплатил, а работу не получил.

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

Зачем escrow там, где нет людей

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

Escrow разрывает эту зависимость на три отдельных события: депонирование средств, проверку результата и высвобождение денег. Между ними стоит арбитр — смарт-контракт, доверенный сервис или комбинация из них.

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

Где именно ломается доверие

• Оплата за данные. Агент-покупатель платит за датасет или ответ API. Продавец может вернуть пустышку, устаревшие данные или сгенерированный на ходу правдоподобный мусор.
• Оплата за вычисление. Агент заказывает рендер, обучение или прогон модели. Как проверить, что задача реально считалась, а не была подделана?
• Цепочки субподряда. Агент А нанимает агента Б, тот — агента В. Если платёж не атомарен, деньги застревают в середине цепочки.

Три подхода к депонированию

Единого стандарта пока нет. На практике складываются три семейства решений, и они плохо совместимы между собой.

1. Смарт-контракт на блокчейне

Деньги (обычно стейблкоин вроде USDC) блокируются в контракте. Условие высвобождения записано в коде: подпись обеих сторон, истечение таймера, вердикт оракула^*. Плюс — никому не нужно доверять как хранителю: логика исполняется сетью. Минус — контракт не понимает, качественный ли результат. Он видит только то, что ему передали на вход. Спор о качестве всё равно упирается в внешний источник правды.

2. Доверенный посредник-сервис

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

3. Гибрид с проверяемым результатом

Самый амбициозный вариант: результат работы сопровождается криптографическим доказательством выполнения (например, доказательством корректного вычисления), а высвобождение средств привязано к проверке этого доказательства. Технология существует, но дорога и применима не ко всему: доказать «данные свежие и релевантные» пока нельзя так же строго, как «эта функция посчитана верно».

Что предлагают протоколы прямо сейчас

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

x402 от Coinbase решает более узкую задачу — оплату за запрос по HTTP. Сервер отвечает статусом 402, клиент-агент прикладывает платёж, сервер отдаёт ресурс. Escrow здесь не встроен по умолчанию: базовая схема ближе к оплате за факт доступа. Условное депонирование добавляют поверх, отдельными фасилитаторами.

Вывод, который стоит держать в голове: протоколы платежей и механизмы escrow — это разные слои. Первые говорят «как передать деньги», вторые — «при каком условии их отпустить». Смешивать их в ожиданиях не надо.

Кому это пригодится, а кому нет

Пригодится:

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

Скорее не пригодится:

• Простым внутренним агентам одной компании — там нет проблемы доверия, escrow только добавит задержку и комиссию.
• Задачам с субъективным качеством результата (креатив, тексты, консультации): смарт-контракт не оценит «хорошо ли написано», а оракул на это — та же ручная модерация, только дороже.
• Микротранзакциям на доли цента, где комиссия escrow и газ съедают всю экономику сделки.

Что остаётся нерешённым

Три вопроса пока без внятного ответа. Первый — арбитраж качества: кто и как судит спор, если результат формально доставлен, но бесполезен. Второй — идентичность агента: escrow бессмыслен, если продавец создаёт новый идентификатор под каждую сделку и репутация не накапливается. Третий — правовой статус: замороженные автономным контрактом деньги — это чья собственность в момент спора и по какому праву. На эти вопросы ни AP2, ни x402 сами по себе не отвечают — они дают транспорт, а не правила игры.

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