Долгое время основным способом взаимодействия людей с ИИ был диалог. Мы задавали вопросы, получали ответы, создавали контент и использовали результаты, чтобы самостоятельно принимать решения.
С развитием ИИ-агентов эти отношения начинают меняться.
ИИ-агенты созданы не только для ответов. В зависимости от своих возможностей и доступных инструментов они могут планировать задачи, взаимодействовать с внешними сервисами, использовать программное обеспечение и выполнять действия при ограниченном участии человека.
Эта перемена важна, потому что ИИ-система, способная действовать в реальном мире, ставит перед нами иные вопросы, чем система, которая просто генерирует текст.
Если ИИ-помощник даст неудачную рекомендацию, человек может её проигнорировать. Но если ИИ-агент совершит покупку, оплатит услугу или выполнит транзакцию от имени человека, последствия уже не ограничатся беседой.
Экономика агентов строится вокруг этого перехода. Агенты могут всё чаще выступать и потребителями, и поставщиками цифровых услуг, взаимодействуя с другими агентами, приложениями и платёжными системами.
Но одного интеллекта недостаточно.
Агент должен уметь действовать. Другим сторонам необходимо иметь возможность установить, что это за агент, что ему разрешено делать и можно ли доверять его действиям.
И вот здесь начинается настоящая сложность.
Проблема не только в доверии. Она в контролируемой автономности.
В основе автономного ИИ лежит важное противоречие.
Если предоставить агенту слишком мало полномочий, он станет не более чем помощником, который постоянно просит разрешения. Он может уметь спланировать выполнение целой задачи, но всё равно будет зависеть от человека, который должен одобрять каждый мелкий шаг.
Если предоставить агенту слишком много полномочий, последствия ошибки будет сложнее ограничить. Взломанный агент, плохо составленная инструкция или неожиданное решение могут привести к действиям, на которые пользователь никогда не намеревался давать разрешение.
Ни одна из крайностей не особенно полезна.
Цель не в том, чтобы сделать агентов полностью независимыми, и не в том, чтобы навсегда привязать их к одобрению человека. Им нужно предоставить достаточно свободы для выполнения задачи, но удерживать её в чётко установленных границах.
В традиционной цифровой экономике человек обычно инициирует платёж или подтверждает транзакцию. В экономике, управляемой агентами, человек может задать цель, а агент — решить, какие действия необходимы для её достижения.
Это создаёт новое требование: делегированные полномочия должны быть ограниченными, понятными и отзывными.
Агенту не нужен неограниченный доступ лишь потому, что ему требуется выполнить одну задачу. Его разрешения должны соответствовать тому, что пользователь намерен ему поручить, возможной стоимости задачи и времени, в течение которого агенту нужно действовать самостоятельно.
Именно поэтому стоит изучить инфраструктуру для идентификации агентов, авторизации и платежей.
Какое место занимает Kite AI
Kite AI создаёт инфраструктуру для экономики, в которой ИИ-агенты смогут взаимодействовать с сервисами и совершать транзакции.
Вместо того чтобы рассматривать агентов только как программные инструменты, которыми управляют люди, подход Kite охватывает инфраструктуру, необходимую агентам для участия в цифровых транзакциях. К ней относятся идентификация агентов, делегированные разрешения и механизмы оплаты.
Это важное различие.
Интеллектуальный агент может знать, как выполнить задачу, но понимание того, что нужно сделать, само по себе не даёт безопасного и надёжного способа это сделать. Агенту всё равно нужно идентифицировать себя, получить соответствующую авторизацию, взаимодействовать с сервисами и при необходимости совершать платежи.
Это разные задачи, и решение одной из них не означает автоматического решения остальных.
Kite Passport особенно интересен тем, что, согласно описанию, позволяет агенту оплачивать поддерживаемые сервисы от имени пользователя в пределах одобренного им лимита расходов. Задокументированный процесс связывает настройку аккаунта, пополнение кошелька, разрешения на расходы в рамках сессии и оплату сервисов.
Здесь широкое видение Kite обретает конкретную форму. Вместо того чтобы предоставлять агенту неограниченный финансовый доступ, пользователь может разрешить ему действовать в течение определённого периода и в рамках заданного бюджета.
Интересна не просто возможность агентов совершать платежи. Важно то, что способность агента проводить транзакции можно связать с полномочиями, которые пользователь явно ему предоставил.
Чтобы понять, почему это важно, стоит рассмотреть, как, согласно документации, устроен процесс работы Kite Passport.
Иерархическая идентификация: связь агентов с их владельцами
Важная составляющая инфраструктуры агентов — не только идентификация агента, но и установление его связи с субъектом, который его уполномочил.
В документации Kite описана трёхуровневая модель идентификации: пользовательская, или корневая, идентичность; идентичность агента с делегированными полномочиями; и идентичность сессии, действующая в течение определённого периода. Отдельная идентичность агента указывает, какой агент взаимодействует с сервисом. Иерархия добавляет контекст: она связывает агента с уполномочившим его пользователем и с ограниченной сессией, в рамках которой агент действует.
Это может быть полезно, когда один человек или организация управляет несколькими агентами, каждый из которых отвечает за разные задачи. Вместо того чтобы считать каждого агента совершенно отдельной сущностью с не связанными друг с другом разрешениями, иерархия позволяет отразить связь владельца с агентами, действующими от его имени. В документации Kite также описаны адреса агентов, производные от кошелька пользователя, и ключи сессий, рассчитанные на короткий срок действия. Это особенности описанной архитектуры, а не гарантия того, что любой взлом или ошибка реализации будут безвредны.
Это похоже на различие между тем, кто действует, и тем, чьими полномочиями он пользуется. Оба вопроса важны, когда программное обеспечение начинает самостоятельно принимать решения и совершать транзакции.
Например, компания может использовать отдельных агентов для исследований, доступа к данным и закупок. Каждому агенту могут требоваться разные разрешения, но в конечном счёте его полномочия исходят от организации, которая его запустила. Иерархическая структура идентификации помогает явно показать эти связи, а не оставлять их неявными в логике приложения.
Такая структура также имеет важные последствия для безопасности. Если взломан отдельный агент или сессия, хорошо спроектированная система должна ограничить потенциальный ущерб разрешениями и ресурсами, доступными этому агенту или сессии. Взлом одного агента не должен автоматически предоставлять неограниченный доступ к базовым полномочиям пользователя или ко всем остальным агентам в той же экосистеме.
Когда агенты начинают поручать задачи другим агентам, ещё важнее становится поддерживать чёткие связи между идентичностями и границы делегированных полномочий. Без них взлом на одном уровне может повлечь последствия, выходящие за рамки исходной задачи. Цель — сделать полномочия отслеживаемыми и разделёнными на изолированные области, чтобы каждый агент получал лишь необходимый доступ, а не наследовал неограниченный контроль от вышестоящей идентичности.
Это цель в области безопасности, а не гарантия защиты от любых возможных сбоев. Эффективность зависит от реализации, безопасности базовых ключей и правильного применения соответствующих средств контроля.
В конечном счёте иерархическая идентификация нужна не только для упорядочивания множества агентов. Она помогает сохранить чёткую связь между агентом, выполняющим действие, полномочиями, на основании которых он действует, и пределами этих полномочий. По мере того как автономные системы становятся всё более взаимосвязанными, такое разграничение может стать важной основой для повышения безопасности взаимодействий с агентами и упрощения управления ими.
Kite Passport: от настройки до автономных платежей
Kite Passport создан, чтобы ИИ-агент мог оплачивать поддерживаемые сервисы от имени пользователя, не требуя от него вручную подтверждать каждую транзакцию. Сначала пользователь настраивает Passport, пополняет его кошелёк и одобряет платёжную сессию. После этого агент может находить сервисы, совершать платежи и получать результаты в пределах ограничений сессии.
Этот процесс важен, потому что разделяет три понятия, которые часто смешивают: предоставление агенту доступа к платёжной системе, выделение ему средств и разрешение тратить эти средства.
Это разные разрешения.
1. Установка Passport и подключение агента
Согласно документации, процесс начинается с командной строки Kite Passport (CLI) и навыков агента, благодаря которым совместимый ИИ-агент может взаимодействовать с Passport.
В документации Kite описана работа как с программирующими агентами на компьютере пользователя, так и с облачными агентами на удалённых компьютерах. Способ установки различается, но общий порядок входа в аккаунт одинаков.
Для поддерживаемых конфигураций с программирующими агентами, например Claude Desktop или Codex, описанный процесс включает запуск команды установки Passport через среду разработки агента и выполнение инструкций по регистрации в Passport и настройке необходимых навыков.
Для поддерживаемых конфигураций с облачными агентами пользователь выполняет соответствующие инструкции по подключению размещённого в облаке агента к Passport.
После установки и регистрации пользователь получает два электронных письма: ссылку для подтверждения, которая открывает панель управления Passport, и восьмизначный код, который нужно передать агенту. Пользователь переходит по ссылке подтверждения, создаёт ключ доступа одним из поддерживаемых способов — например, с помощью Touch ID, Face ID, Windows Hello или аппаратного ключа безопасности — и затем вводит код, чтобы завершить вход.
Ключ доступа играет важную роль в этом процессе, поскольку одобрение платёжной сессии не должно молча и без ограничений оставаться на усмотрение агента. Прежде чем агент получит запрошенные полномочия на расходование средств, пользователь должен явно подтвердить запрос.
При использовании облачного агента важно учитывать и практический аспект: подключение к Passport предоставляет этому агенту доступ к аккаунту Passport пользователя. В документации Kite пользователям прямо рекомендуется проверять лимиты сессии перед одобрением. Удобство не должно означать слепое доверие к любым разрешениям, которые запрашивает агент.
После подключения аккаунта и агента следующий шаг — пополнение средств.
2. Пополнение кошелька Passport
Прежде чем агент сможет отправлять платные запросы, на Passport должны быть средства. Согласно документации Kite, в процессе оплаты услуг используется USDC.e в сети Kite Chain.
В панели управления доступно несколько способов пополнения — в зависимости от того, с чего начинает пользователь.
Покупка с карты: Пользователи, у которых ещё нет криптовалюты, могут купить USDC в сети Base через раздел Add funds в панели управления Passport. Они выбирают сумму и способ оплаты, совершают покупку и ждут обновления баланса после завершения расчётов.
Внесение стейблкоинов: Пользователи, у которых уже есть поддерживаемые стейблкоины, могут открыть вкладку Crypto и получить нужный адрес для пополнения. В документации перечислены поддерживаемые варианты пополнения в разных сетях и активах, включая USDC в сетях Base, Polygon, Avalanche, Tempo, Solana, Arc и других указанных сетях. Пользователям необходимо отправить на адрес соответствующей сети правильный стейблкоин. Если отправить не тот актив или воспользоваться не той сетью, средства могут не отобразиться должным образом.
Использование Kite Bridge: Пользователи также могут перевести USDC в Kite Chain через Kite Bridge. Они подключают кошелёк со средствами, выбирают исходную сеть и токен, указывают Kite в качестве сети назначения и вводят адрес кошелька Passport в качестве адреса получателя. После подтверждения транзакций и завершения перевода баланс Passport должен обновиться.
Перевод из кошелька, уже подключённого к Kite: Если у пользователя уже есть USDC.e в сети Kite Chain, он может напрямую отправить его из внешнего кошелька на адрес кошелька Passport. В документации Kite указано, что для оплаты комиссии за газ при таком переводе внешнему кошельку нужны $KITE токены.
Пользователь может проверить баланс в панели управления или с помощью команды kpass wallet balance. По запросу агент также может проверить баланс.
Эти способы пополнения дают пользователям несколько вариантов подготовки кошелька, однако наличие средств не означает, что у агента есть неограниченное право их расходовать.
Это различие лежит в основе модели Passport. В кошельке хранятся средства, а платёжная сессия определяет полномочия, которые агент получает для их использования.
3. Создание платёжной сессии
Вероятно, это самый важный этап всего процесса.
После пополнения кошелька агент может запросить платёжную сессию. Вместо того чтобы просить общий доступ к кошельку, он указывает задачу и ограничения, в рамках которых ему разрешено расходовать средства.
Параметры сессии, указанные в документации Kite, включают:
Краткое описание задачи: описание того, чего агент пытается достичь.
Максимальная сумма одной транзакции: верхний предел для отдельного платежа.
Общая максимальная сумма: бюджет, доступный на протяжении сессии.
Срок действия (TTL): время, в течение которого сессия остаётся действительной.
Разрешённые активы: активы, которые можно использовать в рамках сессии.
Например, представим агента, которому нужно отправить один платный запрос к погодному API. Пользователь может одобрить сессию с максимальной суммой $2 за транзакцию, общим бюджетом $10 и сроком действия 24 часа.
Агент запрашивает сессию и получает ссылку для одобрения. Пользователь открывает её на устройстве, где доступен его ключ доступа, и явно одобряет запрос.
Сессия становится активной только после этого одобрения.
Разделение лимита на одну транзакцию и общего бюджета особенно полезно. Максимальная сумма одной транзакции ограничивает размер отдельного платежа, а общий бюджет ограничивает совокупные расходы за время сессии. Срок действия задаёт временные рамки и не позволяет сессии оставаться действительной бесконечно.
После одобрения агент может совершать соответствующие требованиям платежи в пределах ограничений сессии, не запрашивая нового разрешения для каждого отдельного платежа. Сессия завершается по истечении срока действия или исчерпании бюджета.
Таков главный компромисс, которым управляет Passport: пользователь сохраняет контроль над объёмом разрешённых полномочий, а агент получает достаточно самостоятельности для выполнения задачи.
Без такого разделения автономность могла бы означать предоставление агенту широкого финансового доступа. Разрешения на основе сессий призваны предоставлять только те полномочия, которые нужны для определённого периода работы.
Разумеется, система разрешений полезна лишь настолько, насколько качественно она реализована. Пользователь должен понимать, что именно он одобряет, а система — правильно применять ограничения. Сессия не гарантирует, что агент выберет подходящий сервис или примет верное решение. Она лишь ограничивает действия, которые ему разрешено совершать.
4. Поиск сервисов и совершение платежей
Когда кошелёк пополнен, а платёжная сессия одобрена, агент может найти подходящий платный сервис в каталоге Kite.
Согласно документации, CLI поддерживает поиск сервисов с помощью команды ksearch. Пользователь также может попросить совместимого агента найти доступные сервисы для выполнения задачи, например погодный API.
Найдя подходящий сервис, агент может отправить платный запрос с помощью поддерживаемого платёжного процесса.
Один из описанных Kite механизмов — x402, платёжный протокол, основанный на ответе HTTP 402 Payment Required. Суть в том, что сервис может сообщить о необходимости оплаты запроса и предоставить условия, необходимые для продолжения.
Взаимодействие можно представить как последовательность действий:
Агент запрашивает ресурс у сервиса.
Если требуется оплата, сервис возвращает платёжный запрос с описанием условий.
Агент Passport получает разрешение на оплату в рамках одобренной пользователем платёжной сессии.
Агент повторно отправляет запрос с необходимой платёжной информацией.
Сервис проверяет и проводит платёж через поддерживаемую платёжную инфраструктуру.
После подтверждения оплаты сервис предоставляет запрошенный ресурс или ответ.
Затем агент может использовать этот ответ в рамках более масштабной задачи, которую он выполняет.
Это важно, потому что платёж может стать частью самого взаимодействия программ. Агенту не обязательно останавливаться, перенаправлять пользователя на обычную страницу оплаты и ждать, пока тот вручную совершит каждую небольшую покупку.
Сервис задаёт требования к оплате, Passport применяет одобренные пользователем полномочия на расходование средств, а после обработки платежа сервис предоставляет ресурс.
В документации Kite для поставщиков услуг также описана поддержка Machine Payments Protocol (MPP) — ещё одного способа принимать платежи от агентов Passport. Детали протоколов различаются, но общая цель схожа: дать сервисам возможность указывать требования к оплате в формате, с которым могут работать программные агенты.
В документации Passport также указана поддержка прямых переводов USDC, инициируемых агентом в пределах одобренных ограничений сессии. Это отличается от оплаты услуги запросом через протокол, хотя в обоих случаях всё зависит от разрешений, предоставленных агенту.
Важно точно понимать, что это означает, а что нет. Не каждый сайт или API автоматически становится доступен агентам Passport. Сервис должен поддерживать совместимый платёжный процесс, а агент — правильно с ним взаимодействовать. Система позволяет связать авторизацию с оплатой, но не отменяет необходимости интеграции с сервисом.
5. Отслеживание действий и сохранение контроля
Автономность не должна означать утрату контроля.
Когда агент начинает расходовать средства, пользователи могут просматривать совершённые платежи и активность сессии в панели управления Passport. В CLI также есть команды для просмотра активных сессий и последних действий.
Это важно, потому что делегированные полномочия должны оставаться понятными и после их предоставления. Пользователям нужно иметь возможность проверить, что сделали их агенты, сколько было потрачено и остаётся ли сессия активной.
Бюджет сессии и срок её действия заранее задают границы. Записи о действиях обеспечивают прозрачность после их совершения. Важно и то и другое, но эти меры выполняют разные задачи.
Лимиты расходов ограничивают то, что агенту разрешено делать. История действий помогает пользователю понять, что агент фактически сделал.
Ни то ни другое не гарантирует, что каждая транзакция была разумной, а каждый сервис — добросовестным. Мониторинг не заменяет безопасность, а запись о транзакции сама по себе не подтверждает, что базовое программное обеспечение работало правильно.
И всё же это сочетание полезнее, чем просто предоставить агенту кошелёк и надеяться, что он будет вести себя как положено.
Общий принцип таков: делегированная автономность требует и ограничений, и прозрачности. Пользователям не следует выбирать между подтверждением каждого мелкого действия и утратой реального контроля над процессом.
6. Отзыв разрешений: возможность, которую стоит проверить
Делегирование полномочий — лишь половина задачи. Надёжная модель разрешений также должна объяснять, как пользователь может отозвать полномочия, если обстоятельства изменятся. Задача может быть выполнена, агент может больше не понадобиться, или его поведение может заставить пользователя остановить его.
В контексте авторизации агентов отзыв означает аннулирование ранее предоставленных полномочий, а не ожидание естественного истечения срока их действия. Сессии с ограниченным сроком задают автоматическую границу, но она может наступить слишком поздно, если пользователь захочет остановить задачу раньше.
Лимит бюджета и механизм отзыва решают разные задачи. Бюджет ограничивает возможные расходы, а отзыв определяет, следует ли агенту и дальше разрешать действовать. При оценке делегированной автономности важны оба вопроса.
В конечном счёте для реального контроля недостаточно задать границы в самом начале. Пользователям нужна чёткая информация как о существующих средствах контроля, так и о тех, которые ещё необходимо проверить.
Автономности проще доверять, когда объём делегированных полномочий чётко определён, ограничен по времени и, если это поддерживается, может быть отозван.
Что на самом деле меняет этот процесс
В совокупности процесс Passport задаёт чёткий путь от разрешения пользователя к платежу, совершаемому агентом.
Пользователь подключает агента, пополняет кошелёк, одобряет сессию с явными параметрами расходов и позволяет агенту взаимодействовать с поддерживаемыми платными сервисами. Затем пользователь может проверить действия, совершённые в рамках сессии.
Это более конкретный подход к автономности агентов, чем простое предоставление ИИ-системе доступа к способу оплаты.
При этом становится понятно, какие сложные вопросы остаются открытыми. Насколько легко пользователям понять одобряемые ими разрешения? Насколько надёжно применяются эти ограничения? Что произойдёт, если агент примет неверное решение в рамках одобренного бюджета? Насколько защищены среда агента, кошелёк и получающий оплату сервис?
Passport решает часть проблем авторизации и платежей, но не может устранить все риски, связанные с автономным программным обеспечением.
Это не повод отвергать такой подход. Это повод оценивать его исходя из того, что он действительно обеспечивает.
Другая сторона: сервисы должны принимать платежи от агентов
Есть ещё одна сторона этой системы, которую легко упустить из виду.
У агента могут быть кошелёк, идентичность и одобренные разрешения на расходование средств, но ему всё равно нужно место, где их можно потратить. Чтобы экономика агентов работала, поставщики услуг должны иметь возможность принимать платежи не только от людей, но и от агентов.
Поэтому документация Kite для поставщиков услуг важна для понимания общей картины.
Kite описывает для поставщиков два способа интеграции платежей: x402 и MPP. При использовании x402 поставщик может вернуть ответ HTTP 402 Payment Required с условиями оплаты. Затем агент Passport получает необходимое разрешение в рамках одобренной пользователем сессии и повторно отправляет запрос с платёжной информацией. Прежде чем предоставить услугу, поставщик проверяет и проводит платёж через совместимый сервис-посредник.
MPP работает по схожей общей схеме: запрос ресурса, предоставление условий оплаты, получение платёжных данных, проверка платежа и выдача ресурса. Однако этот протокол поддерживает другой набор платёжных механизмов и моделей взаимодействия.
Важно то, что система предназначена не только для помощи агентам в расходовании денег. Она также делает сервисы доступными для агентов посредством платёжных процессов, разработанных для программного обеспечения.
Представим разработчика, который предлагает доступ к специализированному API. Если агент может найти этот сервис, понять требования к оплате, получить разрешение в рамках бюджета пользователя и получить ответ API после оплаты, у разработчика появляется возможность обслуживать автоматизированных клиентов без создания отдельного процесса оформления заказа вручную.
Это не гарантирует спрос и не делает интеграцию простой. Поставщикам всё равно нужно внедрить соответствующий протокол, настроить платёжную инфраструктуру и обеспечить безопасную обработку запросов сервисом. Агентам также нужен надёжный способ находить сервисы и понимать, как ими пользоваться.
Однако эта двусторонняя структура имеет значение. Система платежей агентов становится полезнее по мере того, как всё больше подходящих сервисов начинают принимать такие платежи. А у сервисов появляется больше причин поддерживать платежи от агентов, если уже есть полезные агенты и готовые ими пользоваться клиенты.
Иными словами, инфраструктура должна объединять обе стороны транзакции.
Почему платежи важны для экономики агентов
Автономность приносит больше пользы, когда агенты могут оплачивать необходимые им ресурсы.
Агенту может понадобиться доступ к API, источнику данных, вычислительному сервису или возможностям другого агента. Если для каждого взаимодействия человеку приходится вручную договариваться об оплате и совершать её, автоматизация быстро становится обременительной.
Поэтому платёжная инфраструктура важна для формирующейся экономики агентов.
Стейблкоины полезны в таких ситуациях, потому что их стоимость привязана к эталонной валюте, благодаря чему проще оценивать сумму транзакции, чем в случае активов со значительными колебаниями цены. В описанном платёжном процессе Kite Passport для пополнения кошелька Passport требуется USDC.e в сети Kite Chain.
Потенциальная польза не в том, что за каждое взаимодействие с ИИ нужно платить. В большинстве случаев это не так. Польза в том, что если агенту действительно нужно приобрести ресурс, оплату можно встроить в его рабочий процесс, а не прерывать его для ручного вмешательства.
Однако технически успешная транзакция не обязательно полезна. Сетевые комиссии, стоимость услуг, неудачные запросы, риски безопасности и сложность авторизации — всё это влияет на практическую целесообразность автоматических платежей.
Экономике агентов недостаточно одной лишь возможности перемещать деньги. Ей нужны такие платёжные системы, как Kite Passport, которыми удобно пользоваться программам и которым люди могут безопасно делегировать полномочия.
Полезная система оценки инфраструктуры для агентов
Оценивая проекты, создающие инфраструктуру для экономики агентов, я считаю пять вопросов полезнее, чем простой вопрос о поддержке ИИ-агентов.
1. Платежи на основе стейблкоинов
Могут ли агенты оплачивать услуги с помощью активов и платёжных механизмов, подходящих для цифровых транзакций? Важно то, полезен ли платёжный процесс на практике, а не просто наличие токена или кошелька.
2. Программируемые разрешения
Могут ли пользователи определять полномочия, которые получает агент? Лимиты расходов, ограничения на действия и разрешения с ограниченным сроком могут помочь обеспечить соразмерность делегированного доступа поставленной задаче.
3. Аутентификация с учётом потребностей агентов
Может ли агент идентифицировать себя и взаимодействовать с сервисом посредством процесса, разработанного для программного обеспечения, соблюдая при этом полномочия, предоставленные владельцем?
4. Проверяемая история действий
Могут ли пользователи просматривать соответствующие действия и транзакции? Прозрачность важна, когда агент действует от чьего-либо имени, хотя одной истории транзакций недостаточно, чтобы доказать правильность каждого решения или безопасность каждого базового процесса.
5. Экономическая целесообразность транзакций
Позволяет ли система совершать транзакции с такой стоимостью и скоростью, которые подходят для соответствующих сервисов? Если небольшие платежи обходятся слишком дорого или их сложно выполнить, многие потенциальные сценарии использования могут так и остаться непрактичными.
В совокупности эти вопросы дают полезную основу для оценки инфраструктуры автономных агентов. Они также показывают, почему ни одну отдельную функцию нельзя считать полноценным решением.
Кошелёк не решает проблему авторизации. Система идентификации не гарантирует правильных решений. Журнал действий не устраняет уязвимости безопасности. А платёжный протокол сам по себе не создаёт устойчивого спроса.
Чтобы эти компоненты работали, они должны быть согласованы между собой. Kite описывает свой подход с помощью связанной системы принципов под названием SPACE: платежи на основе стейблкоинов (Stablecoin-native payments), программируемые ограничения (Programmable constraints), аутентификация с учётом потребностей агентов (Agent-first authentication), инфраструктура, готовая к требованиям нормативного соответствия (Compliance-ready infrastructure), и экономически целесообразные микроплатежи (Economically viable micropayments). Эта система принципов полезно описывает цели проекта, но не доказывает, что все задачи в каждой из этих областей уже решены. На практике всё будет зависеть от того, насколько слаженно эти элементы работают вместе при реальном внедрении.
Что это может сделать возможным?
Если идентификация агентов, разрешения и платежи станут достаточно надёжными, некоторые виды взаимодействия будет проще автоматизировать.
Агенты смогут покупать доступ к API и данным, оплачивать вычислительные ресурсы и взаимодействовать со специализированными агентами, предоставляющими возможности, которых им самим не хватает. Компании также смогут внедрять агентов, выполняющих части рабочего процесса сразу в нескольких сервисах без необходимости подтверждать вручную каждое отдельное взаимодействие.
Это правдоподобные направления развития экономики агентов, а не доказательство того, что все такие сценарии уже работают в большом масштабе.
Их успех будет зависеть не только от наличия инфраструктуры. Разработчикам нужно создавать полезные сервисы, пользователям — иметь причины делегировать задачи, а компаниям — доверять системам, которым они поручают свои ресурсы.
Технологии могут уменьшить трение, но сами по себе не способны создать спрос.
Роль токена KITE
У Kite также есть собственный токен $KITE , который следует рассматривать отдельно от стейблкоинов, используемых для оплаты услуг через Passport. В описанном процессе пополнения USDC.e используется для платежей агентов в сети Kite Chain, а для оплаты газа при переводе средств из внешнего кошелька, уже подключённого к Kite Chain, требуется $KITE .
Эту описанную роль токена в оплате газа не следует путать с полным описанием его более широкого применения. Любые дополнительные функции следует оценивать по актуальной документации проекта, различая уже действующие возможности и запланированные. Нельзя делать выводы о полезности токена, основываясь лишь на широком видении проекта.
Настоящая проверка — сможем ли мы безопасно делегировать полномочия
Потенциал ИИ-агентов понятен. Они могли бы взять на себя большую часть работы между определением того, чего мы хотим, и фактическим достижением результата.
Но чем больше полномочий мы им предоставляем, тем важнее определить, где эти полномочия заканчиваются.
Я считаю это одной из главных проблем экономики агентов. Разработчики стремятся не просто создавать системы, способные действовать самостоятельно. Они пытаются создать системы, которым люди смогут с достаточным основанием доверять действия от своего имени.
Внимание Kite к идентификации агентов, делегированным разрешениям и платёжной инфраструктуре помогает решить часть этой задачи. Passport делает эту идею особенно наглядной: он связывает лимиты расходов пользователя с действиями, которые агент может выполнять в рамках одобренной сессии. Его значение в долгосрочной перспективе будет зависеть от надёжности этих средств контроля, простоты интеграции сервисов с платёжными процессами и того, сочтут ли пользователи этот опыт достаточно полезным, чтобы начать им пользоваться.
Остаются открытыми вопросы безопасности, подотчётности, удобства использования и внедрения. Их нельзя отмахнувшись игнорировать только потому, что технология выглядит многообещающе. Именно ответы на эти вопросы определят, станет ли этот потенциал полезным на практике.
Агент, способный выполнить задачу, полезен. Агент, способный выполнить её в чётко определённых пределах, полезнее. А агенту, действия которого можно понимать, контролировать и останавливать с помощью действительно работающих средств, проще доверять. Именно к этому в более широком смысле стремится Kite, хотя настоящей проверкой станет то, как эти средства контроля покажут себя на практике.
Будущее автономного ИИ следует оценивать не по тому, сколько свободы мы даём агентам, а по тому, насколько разумно мы определяем, какая свобода им нужна.