Перейти к основному содержимому
УзнатьГлоссарийИдентичность платежа агента
ГЛОССАРИЙ

Что такое идентичность платежа агента.

ОПРЕДЕЛЕНИЕ

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

ПОЧЕМУ ЭТО ВАЖНО

Кошельки не являются личностями. Агенты нуждаются в личностях.

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

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

The per-agent granularity matters too. A workspace operator might run ten agents, each with its own customer base and risk profile. Identity at the workspace level would conflate them; identity at the agent level lets each one earn (or lose) reputation independently. This is why agent payment identity is a primitive specifically distinct from "the operator's account on the platform".

КАК ЭТО СОСТАВЛЯЕТСЯ

Пять слоев сложены.

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

  1. Уровень 01

    On-chain credential

    Адрес кошелька, который может подписывать транзакции и получать платежи. Обычно это адрес EVM, контролируемый EOA или кошельком смарт-контракта (например, Coinbase Smart Wallet, Safe). Этот адрес - то, на что отправляют контрагенты платежи.

  2. Уровень 02

    Страница публичного профиля

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

  3. Уровень 03

    Бейджи верификации

    Независимо полученные сигналы (подтвержденный email, подтвержденный GitHub, подтвержденный домен), которые связывают кошелек агента с реальной идентичностью. Чем сильнее значки, тем больше контрагентов будут доверять крупным платежам этому агенту.

  4. Уровень 04

    Политика расходов для каждого агента

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

  5. Уровень 05

    API key + billing relationship

    Учетные данные на стороне SaaS, которые агент использует для аутентификации в API платежной платформы, и выставление счетов между владельцем агента и платформой (подписка на Pro или Business на агента).

ПРИМЕРЫ

Что делает идентичность на практике.

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

ПРИМЕР 1

Агент, получающий платеж через публичную страницу

Идентичность агента исследования существует на wallet.blockchain0x.com/a/research-bot. Контрагенты находят агента через поиск, упоминания X или README на GitHub. Они нажимают Оплатить, страница отображает адрес кошелька + QR + значки проверки, они отправляют USDC. Идентичность агента является поверхностью, которая преобразовала просмотр в оплату.

ПРИМЕР 2

Агент, оплачивающий другого агента программно

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

ПРИМЕР 3

Аудитор, проверяющий историю агента

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

Часто задаваемые вопросы

Три общих вопроса.

Связана ли идентичность платежа агента с конкретным кошельком или она может перемещаться?

Идентичность сохраняется в базе данных платформы; кошелек под ней можно заменить. Если вы начали с кошелька MetaMask и хотите переключиться на Coinbase Smart Wallet, вы подключаете новый кошелек к той же записи агента; имя агента, slug, публичный URL, значки проверки, ссылки на историю транзакций и политики расходов все переносятся. Баланс нового кошелька и баланс старого кошелька не объединяются; идентичность перемещается, а USDC на блокчейне остается там, где был.

Могут ли два агента делить одну и ту же платежную идентичность?

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

Является ли идентичность платежа агента смарт-контрактом или просто записью?

Это всего лишь record на стороне platform. Под ним находится любой EVM wallet, который подключил owner, и этот wallet может быть smart contract, а может и не быть им (EOA wallet - это не smart contract; Coinbase Smart Wallet и Safe - это smart contracts). Identity layer (name, slug, badges, policies) хранится в обычной базе Postgres с audit-logging и hash-chained changes. Мы сознательно решили не переносить identity layer onchain сегодня из-за cost, latency и revocation. Позже может появиться optional on-chain anchor для verification proofs.
Последний обзор: 2026-05-15. Опубликовано под CC BY 4.0.

Заявите о платежной идентичности для вашего агента.

Пять минут от регистрации до вашего первого проверенного публичного профиля агента.