Galaxy Report: Структурные трения затрудняют работу AI-агентов на блокчейне

Автор: Зак Покорни

Перевод: Chopper, Foresight News

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

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

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

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

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

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

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

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

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

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

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

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

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

• Интерпретируйте расплывчатые или неполные цели. Такие инструкции, как «максимизировать доход, но избегать чрезмерного риска», требуют семантической интерпретации. Что считать чрезмерным риском? Как соотносить доход и риск? Традиционные алгоритмы должны заранее точно определить эти условия. А агенты способны интерпретировать намерения, принимать решения и улучшать свое понимание на основе обратной связи.
• Способен обобщать и адаптироваться к неизвестным интерфейсам. Агент может читать неизвестный код контракта, анализировать документацию или изучать бинарные интерфейсы приложений, с которыми ранее не сталкивался, и выводить экономические функции системы. Ему не нужно заранее создавать парсеры для каждого типа протокола. Хотя эта способность пока несовершенна и агент может неправильно интерпретировать увиденное, он способен взаимодействовать с системами, которых не предвидели на этапе создания.
• Рассуждайте в условиях неопределенности в отношении доверия и нормативности. Когда сигналы доверия нечетки или неполны, базовая модель может вероятностно взвешивать сигналы, а не просто применять бинарные правила. Является ли этот смарт-контракт стандартным? На основании имеющихся данных, является ли этот токен законным? Традиционные алгоритмы либо следуют правилам, либо не могут ничего сделать; а агенты могут рассуждать о степени уверенности.
• Объясните ошибку и внесите корректировки. При возникновении нештатных ситуаций агент может анализировать причины проблемы и принимать решение о реакции. В отличие от этого, традиционные алгоритмы выполняют только модуль обработки исключений, перенаправляя информацию об ошибке без её интерпретации.

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

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

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

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

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

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

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

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

Обнаружено трение

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

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

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

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

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

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

Контроль трения

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

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

Механический турок 1789 года — это шахматная машина, которая внешне казалась автономной, но на самом деле управлялась скрытым человеческим оператором.

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

На цепочке уже появились реальные последствия слабой оценки доверия со стороны интеллектуальных агентов. В случае с криптовалютным блогером-инфлюенсером Orangie предполагается, что агент перевел средства в «медовый» контракт. В другом случае интеллектуальный агент по имени Lobstar Wilde из-за сбоя в состоянии или контексте неверно определил статус адреса и перевел крупный баланс токенов онлайн-«просителю». Эти примеры не являются основными аргументами, но достаточно наглядно демонстрируют, как ошибки в оценке доверия, интерпретации состояния и стратегии выполнения могут непосредственно привести к потере средств.

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

Люди решают эту проблему с помощью документов, пользовательских интерфейсов и социальных сетей. Агенты должны определить это, проверив следующее:

• Модель агента и ключевые моменты реализации
• Управление правами и таймлок
• Модуль обновления параметров управления
• Известно, что байт-код / интерфейс двоичного приложения совпадают между развертываниями

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

Токен-аутентичность и метаданные — это одна и та же проблема. Токены кажутся самодостаточными, но их метаданные не являются авторитетными — это просто байтовые данные, возвращаемые кодом. Классический пример — обернутый Эфириум (WETH). В широко используемом коде контракта WETH четко определены имя, символ и точность.

Это выглядит как идентификатор личности, но на самом деле нет. Любой контракт может быть настроен:

• symbol() = WETH
• decimals() = 18
• Wrapped Ether

И реализуют тот же интерфейс стандарта ERC-20. Функции name(), symbol() и decimals() являются открытыми только для чтения и возвращают произвольные значения, заданные развертывающим. На самом деле, в Ethereum существует почти 200 токенов с названием «Wrapped Ether», символом «WETH» и точностью 18 знаков. Не обращаясь к CoinGecko или Etherscan, сможете ли вы определить, какой «WETH» является стандартной версией?

Агенты сталкиваются именно с такой ситуацией. Блокчейн не проверяет уникальность, не сверяется с каким-либо реестром и не накладывает никаких ограничений. Сегодня вы можете развернуть 500 контрактов, все из которых возвращают абсолютно одинаковые метаданные. На цепочке существуют некоторые экспериментальные методы определения (например, проверка соответствия баланса Ethereum и общего предложения, запрос глубины ликвидности на основных децентрализованных биржах, проверка, используется ли он в качестве залога в кредитных протоколах), но ни один из них не предоставляет абсолютного доказательства. Каждый метод либо опирается на пороговые предположения, либо рекурсивно зависит от проверки стандартности других контрактов.

Как и в лабиринте, где для поиска «истинного» пути требуется внешнее руководство, в блокчейне нет нативных стандартных сигналов.

Вот почему списки токенов и реестры существуют как оффчейн-слой фильтрации. Они обеспечивают способ сопоставления концепции «WETH» с конкретным адресом, что объясняет, почему кошельки и интерфейсы поддерживают белые списки или полагаются на доверенные агрегаторы. Для агентов ключевая проблема заключается не только в низкой надежности метаданных, но и в том, что стандартные идентификаторы обычно устанавливаются на социальном или институциональном уровне, а не нативно на уровне протокола. Надежным ончейн-идентификатором является адрес контракта, однако сопоставление человеческих намерений, таких как «обменять на USDC», с правильным адресом все еще сильно зависит от оффчейн-фильтрации, реестров, белых списков или других уровней доверия.

Фрикция данных

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

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

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

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

Кредитный рынок: поиск фрагментированных типовых примеров

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

В Aave v3 получение перечня рынков и состояния резервов — это два отдельных шага. Типичный процесс выглядит следующим образом:

Перечислите активы резерва следующим образом, чтобы вернуть массив адресов токенов.

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

Этот метод возвращает структуру, содержащую общую сумму ликвидности, индекс процентной ставки и флаги конфигурации, например:

Напротив, в Compound v3 каждое развертывание соответствует одному рынку (USDC, USDT, ETH и т. д.), и отсутствует единая структура резервов. Вместо этого для составления снимка рынка необходимо выполнить несколько вызовов функций:

• Базовая загрузка
• Общий объем
• Процентная ставка
• Конфигурация залоговых активов
• Параметры глобальной конфигурации

Каждый вызов возвращает только подмножество различных состояний экономики. «Рынок» не является первичным объектом, а представляет собой выводную структуру, составляемую вызывающей стороной.

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

Фрагментация вызывает задержки и риски согласованности

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

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

Потенциальное несоответствие потока данных

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

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

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

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

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

Исполнение трения

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

Последовательность операций в пользовательском интерфейсе (обмен, авторизация, внесение, заимствование), кошелек предоставляет финальный узел «Проверить и отправить», где пользователь или оператор обычно на последнем этапе неформально принимают стратегическое решение. Они часто оценивают безопасность сделки и приемлемость результата предложения при неполной информации. Если сделка завершается неудачей или возникает неожиданный результат, пользователь повторяет попытку, корректирует проскальзывание, меняет путь или полностью отказывается от операции. Система агентов устраняет человека из этого цикла выполнения. Это означает, что система должна заменить три человеческие функции машинным способом:

• Интеграция намерений. Человеческие цели, такие как «перевести мои стабильные монеты в место с оптимальной доходностью с учетом риска», должны быть интегрированы в конкретные планы действий: выбор протокола, рынка, токен-пути, объема, разрешений и порядка выполнения. Для человека этот процесс происходит неявно через пользовательский интерфейс; для агента он должен быть формализован.
• Исполнение стратегии. Нажатие «Отправить транзакцию» — это не только подпись, но и скрытая проверка соответствия транзакции ограничениям: терпимость к проскальзыванию, верхний предел плеча, минимальный коэффициент здоровья, белый список контрактов или «запрет на обновляемые контракты». Агент должен кодировать явные ограничения стратегии в виде машинно-проверяемых правил:
• Выполняющая система должна проверить, соответствует ли предложенный график вызовов этим правилам, прежде чем осуществлять трансляцию.
• Проверка результата. Запись транзакции в блокчейн не означает завершение задачи. Даже при успешном выполнении транзакции цель может не быть достигнута: проскальзывание может превысить допустимый порог, целевой объем позиции не был достигнут из-за лимитов, или процентная ставка изменилась между симуляцией и записью в блокчейн. Люди неофициально проверяют результаты, просматривая интерфейс после завершения. Агенты же должны программно оценивать последующие условия.

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

Многоэтапный рабочий процесс и режимы отказа

Большинство операций в децентрализованных финансах по своей сути многошаговые. Настройка дохода может требовать выполнения нескольких действий: авторизация → обмен → внесение → заимствование → стейкинг. Некоторые шаги могут быть отдельными транзакциями, другие — объединены с помощью мульти-вызовов или роутинговых контрактов. Человек может терпеть частичное выполнение и возвращаться к интерфейсу для продолжения процесса. Агенту же необходима детерминированная оркестрация: если любой шаг завершится неудачей, агент должен решить, повторить попытку, перенаправить, откатить или приостановить процесс.

Это породило новые модели сбоев, которые в человеческих процессах чаще всего скрыты:

• Состояние между принятием решения и записью в цепочку может смещаться. Между моделированием и выполнением процентные ставки, уровень использования или ликвидность могут измениться. Люди принимают такую изменчивость; агенты должны задавать допустимые диапазоны и обеспечивать их соблюдение.
• Неатомарное выполнение и частичное исполнение. Некоторые операции могут выполняться через несколько сделок или давать частичные результаты. Агент должен отслеживать промежуточное состояние и подтверждать, что конечное состояние соответствует цели.
• Предел авторизации и риски одобрения. Люди по инерции подписывают авторизацию через пользовательский интерфейс; агенты должны рассматривать диапазон авторизации (лимит, пользователь, срок) как часть стратегии безопасности, а не просто как шаг пользовательского интерфейса.
• Выбор пути и скрытые операционные издержки. Люди полагаются на контракты маршрутизации и настройки пользовательского интерфейса по умолчанию. Агенты должны включить проскальзывание, риск максимальной извлекаемой стоимости, стоимость газа и влияние на цену в целевую функцию.

Выполнение: Проблемы с нативным управлением машины

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

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

Системы агентов颠覆了这一架构。它们将人类解读员、审批者与验证者从循环中移除，要求这些功能转为机器原生实现。这一转变在四个维度暴露了结构性摩擦：发现、信用判定、数据获取与执行流程。这些摩擦的产生，并非因为执行不可行，而是因为围绕区块链的基础设施在多数情况下仍假设，在状态解读与交易提交之间存在人类参与。

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

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

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