作者：Zack Pokorny，Galaxy Digital助理研究员；来源：Galaxy Digital；编译：Shaw 金色财经

Введение

Сценарии применения и возможности AI-агентов (AI Agent) начали постепенно развиваться. Они уже постепенно реализуют самостоятельное выполнение задач; соответствующие разработки также продвигаются в направлении того, чтобы агенты могли владеть и конфигурировать средства, выявлять стратегии сделок и доходности и т. п. Хотя эта экспериментальная трансформация все еще находится на самом раннем этапе, ее вектор уже радикально отличается от прошлого — ранее агенты в основном использовались лишь как социальные и аналитические инструменты.

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

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

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

Архитектура блокчейна и AI-агенты

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

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

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

Процессы действий агентов и традиционные алгоритмические стратегии

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

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

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

Такое механическое автоматическое устройство, как «механическая утка-«пожиратель»», может имитировать правдоподобное поведение, но каждое движение заранее задано.（《Scientific American》, январь 1899年1月）

Традиционные алгоритмы, сканируя новый рынок кредитования, могут распознавать события, которые им знакомы, или разворачиваемые контракты, соответствующие известным заводским шаблонам (фабричным паттернам). Но если появляется новый тип базового кредитного компонента с незнакомым интерфейсом, система не может его оценить. Необходимо вручную проверять контракт, понимать механизм его работы, определять, следует ли включать его в opportunity pool, и писать интеграционную логику. Только после этих шагов алгоритм может взаимодействовать с ним. За интерпретацию отвечает человек, за исполнение — алгоритм. А агентные системы на основе базовых моделей разрушают эту границу. Они могут реализовывать за счет выученной способности к рассуждению:

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

• Универсально адаптироваться к новым типам интерфейсов. Агенты могут читать незнакомый код контрактов, разбирать документацию или проверять ранее не встречавшиеся бинарные интерфейсы приложения (ABI) и выводить экономическую функцию этой системы. Им не нужно заранее строить парсеры для каждого типа протокола. Сейчас эта способность еще несовершенна: агент может ошибаться, но он способен попробовать взаимодействовать с системой, которая не была предусмотрена на этапе разработки.

• Рассуждать о достоверности и нормативности в условиях неопределенности. Когда сигналы доверия размыты или неполны, базовая модель может вероятностно взвесить вывод, а не просто применять бинарные правила. Этот смарт-контракт — официальный оригинал? С учетом имеющихся доказательств этот токен с высокой вероятностью легитимен? Традиционные алгоритмы имеют только два состояния — «есть правило» или «нет правила», тогда как агент может рассуждать на основе уровня уверенности.

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

Эти возможности реальны, но пока еще несовершенны. Базовая модель может галлюцинировать, неверно интерпретировать информацию и делать ошибочные выводы, выглядящие уверенно. В противоборствующей среде, связанной с деньгами (то есть когда код может контролироваться или активы могут быть приняты), «попытка взаимодействовать с не предусмотренной системой» может означать прямую потерю средств. Основной тезис этой статьи не в том, что сегодня агенты могут надежно выполнять эти функции, а в том, что они способны делать попытки таким образом, который традиционные системы обеспечить не могут, и что будущая инфраструктура, вероятно, сделает такие попытки более безопасными и надежными. Рассматривать их как непрерывный спектр, а не как абсолютную классификацию, проще для понимания: часть традиционных систем уже встраивает обучение-ориентированное рассуждение, часть агентных систем тоже может в критических участках опираться на хардкод-правила. Различие между ними имеет направленческий характер, а не бинарный. Агентные системы переносят больше интерпретации, оценки и адаптации в runtime-рассуждение, а не в заранее заданную разработчиком стадию. Это напрямую связано с аргументом о препятствиях из предыдущего раздела, потому что именно то, что агент пытается делать, традиционные алгоритмы полностью обходят. Традиционные алгоритмы обходят стоимость обнаружения путем ручного отбора контрактов на стадии разработки; обходят стоимость расходов на уровень контроля через поддерживаемые операторами white-lists; обходят стоимость данных за счет заранее подготовленных парсеров для известных протоколов; обходят стоимость исполнения за счет работы в пределах заранее заданной области безопасности. Человек заранее выполняет работу по подготовке смыслов, доверия и уровня стратегий, а алгоритм исполняет только внутри очерченных границ. Ранние версии ончейн-агентных процессов могут продолжать этот паттерн, но их ключевая логика — перенести обнаружение, доверие и оценку стратегий в runtime-рассуждение, а не в заранее предусмотренную разработчиком стадию.

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

Где возникает трение

Структурно это противоречие не является следствием дефектов консенсуса блокчейна; оно обусловлено способом эволюции всего стекa взаимодействия вокруг него.

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

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

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

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

Стоимость обнаружения

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

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

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

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

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

Стратегически-ограниченное обнаружение отличается от открытого обнаружения

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

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

Трение на уровне контроля

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

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

1789年的 механический турецкий человек (Mechanical Turk) — это играющий автомат, который на первый взгляд выглядит как автономно работающая шахматная машина, но на самом деле в ней работает скрытый оператор。（洪堡大学图书馆）

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

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

Идентификация официальных контрактов не является нативной функцией протокола

Проблема не в том, что контракты сложно обнаружить; проблема в том, что в ончейне обычно не существует нативного понятия «это официальный контракт конкретного приложения X». Эта нехватка в какой-то степени является свойством permissionless-систем, а не дизайном как таковым; но она все равно создает координационную дилемму для автономных систем. Проблема частично обусловлена архитектурой открытых систем со слабой нормативной идентичностью, частично — незрелостью реестров, стандартов и механизмов распространения доверия. Если агент хочет взаимодействовать с Aave v3, ему нужно определить, какие адреса являются официальными (пулы средств, конфигураторы, источники данных и т. д.), а также являются ли эти адреса неизменяемыми контрактами, прокси/апгрейд-контрактами или контрактами, находящимися в состоянии изменения, ожидающего исполнения через governance-предложение.

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

• proxy-режим и направленность на реализационный контракт

• управленческие полномочия и time-lock-контракты

• модули обновления параметров под governance-контролем

• соответствие bytecode / ABI (application binary interface) между известными деплойментами контрактов

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

Проблема подлинности токенов и метаданных — та же по сути

Токены вроде бы «самоописываются», но их метаданные не являются авторитетными: это просто байтовые данные, возвращаемые кодом контракта. Типичный пример — обертка Ethereum (WETH). В широко используемых контрактах WETH явно определено:

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

• symbol() = “WETH”

• decimals() = 18

• name() = “Wrapped Ether”

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

На Ethereum есть почти200 токенов с названием “Wrapped Ether” и символом “WETH”. Не прибегая к сторонним платформам, вы сможете определить, какой из них является настоящим WETH?

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

Как в лабиринте: чтобы распознать «истинный» путь в цепочке, нужен внешний ориентир; стандартных сигналов не предоставлено。（Музей и художественные галереи Бирмингема）

Вот почему токен-листы и реестры существуют как слой off-chain фильтрации: они предоставляют механизм, который мэппит концепцию «WETH» на конкретный адрес — именно поэтому кошельки и фронтенды поддерживают white-list или полагаются на доверенные агрегаторы. Для агента ключевая проблема не только в ненадежности метаданных, а в том, что «нормативная идентичность» обычно устанавливается на уровне соцсети или институционального слоя, а не является нативной для протокола. В ончейне самым надежным уникальным идентификатором служит адрес контракта; однако перевести человечески понятные намерения (например, «обменять на USDC») в правильный адрес все равно в высокой степени зависит от off-protocol фильтрации, реестров, white-list’ов или иных слоев доверия.

Трение с данными

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

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

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

Эта проблема усиливается в разных типах протоколов. Цена долей в хранилище (vault), коэффициент залога на рынке кредитования, глубина ликвидности в DEX-пуле, ставка наград за стейкинг и т. п. — это экономически значимые базовые показатели, но ни один из них не раскрывается через стандартизированный интерфейс. У каждого протокольного стека свой способ чтения, форматы структур и договоренности об единицах измерения; даже в рамках одного класса реализоции способы отличаются.

Рынок кредитования: показательный пример фрагментации

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

Рассмотрим Aave v3. Перечисление рынка и чтение состояния резервных активов разделены на шаги; типовой процесс выглядит так:

Через следующие способы перечисления резервных активов

Эта функция вернет массив адресов токенов.

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

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

В отличие от этого, в Compound v3 (Comet) каждое развертывание соответствует одному единственному рынку (например, USDC, USDT, ETH и т. д.), и не существует единой структуры резервов. Поэтому нужно выполнить несколько вызовов функций, чтобы собрать полную снапшот-таблицу рынка:

Базовая утилизация (utilization rate)

Итого (total)

Процентные ставки

Конфигурация обеспечивающих активов

Глобальные параметры конфигурации

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

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

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

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

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

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

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

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

В ончейне существуют также базовые компоненты push-моделей. WebSocket-подписки могут в реальном времени транслировать новые блоки и журналы событий, но они не содержат большую часть экономического смысла хранимого состояния, если протокол не решил специально записывать его избыточно как лог. Агент не может напрямую получить, например, utilization rate кредитного рынка, резерв ликвидности пула или коэффициент здоровья позиции через ончейн-подписки. Эти значения хранятся в storage контрактов, и большинство протоколов не предоставляет нативных механизмов, чтобы пушить изменения в хранении downstream-пользователям. Наиболее практичный подход — подписаться на заголовки новых блоков и заново запрашивать состояние хранилища на каждом блоке. Даже если это инициируется потоковыми событиями, по сути доступ к состоянию остается pull-моделью. Логи лишь подсказывают, что данные могут измениться, но не кодируют финальное экономическое состояние; чтобы его реконструировать, все равно требуется явное чтение и доступ к историческому состоянию.

Агентные системы, напротив, больше подходят для обратного направления потока данных. Агенту не нужно опрашивать сотни контрактов о каждом изменении состояния; вместо этого он может получать структурированные, предварительно вычисленные обновления состояния и напрямую передавать их своему runtime-окружению (например, обновленные utilization rate, коэффициенты здоровья или изменения по позициям). Push-архитектура снижает избыточные запросы, уменьшает задержку между изменением состояния и тем, когда агент о нем узнает, и позволяет промежуточному слою упаковывать состояние в семантически ясные обновления, а не заставлять агента самому разбирать смысл из первичного storage.

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

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

Трение в исполнении

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

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