Sui Foundation представила фреймворк AI-агентов с упором на исполнимые разрешения и записи

3 мин

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

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

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

Инструкции и разрешения решают разные задачи

Заметка Foundation рекомендует границы, принудительно обеспечиваемые системами, которыми пользуется агент, в сочетании с общими условиями и верифицируемыми записями между организациями.

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

Атомарные транзакции снижают риск частичных результатов

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

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

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

Делегирование должно сохранять исходные границы

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

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

Верифицируемые записи помогают разобраться, что произошло

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

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

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