С 2025 года многие, возможно, постепенно привыкнут к новому способу взаимодействия: сказать GPT или Gemini «Помоги спланировать поездку в Гонконг на следующей неделе и подбери подходящие авиабилеты и отели», и он в фоновом режиме выполнит поиск информации, фильтрацию условий, выбор маршрута, сравнение цен и ряд других шагов, в конечном итоге представив вам результат для подтверждения.
Однако, если перенести те же ожидания в ончейн, история кардинально меняется.
Например, если вы дадите указание DeFi Agent: «Конвертируй ETH в моем кошельке в USDC, переведи в сеть Base, а затем полностью внеси на Aave», объективно говоря, с точки зрения «понимания потребности» и «планирования пути» сегодняшние Agent, возможно, и способны на это, но реальный разрыв возникает на этапе выполнения:
Вам, скорее всего, все равно придется шаг за шагом выполнять подписание, авторизацию, обмен, кросс-чейн перевод и внесение депозита, причем каждый шаг подвержен рискам изменения проскальзывания, колебаниям Gas, задержкам бриджинга и изменениям состояния блокчейна. Это означает, что если какой-либо промежуточный этап отклонится от ожиданий, предыдущие действия могут быть не отменены, а последующие — не выполнены, и в конечном итоге в блокчейне останется лишь незавершенный фрагмент процесса.
Проблема не в том, что AI недостаточно умен, а в том, что ончейн уровень исполнения до сих пор не имеет真正 подходящего для Agent способа выражения.
Именно поэтому в начале апреля 2026 года Biconomy и Ethereum Foundation совместно выпустили ERC-8211, направленный на решение проблемы «статических ограничений» при исполнении смарт-контрактов, предоставляя уровень исполнения с большей выразительностью для AI-агентов и сложных DeFi-воркфлоу, пытаясь восполнить этот недостающий элемент.
一、Последний разрыв при подключении AI Agent к ончейн
В последние год-два внимание криптоиндустрии явно смещается с масштабирования L2, ликвидности RWA на то, как AI Agent сможет真正 взять на себя ончейн операции — эту весьма颠覆ную тему.
Объективно говоря, от «формулирования многошаговых DeFi-стратегий на естественном языке» до «позволить автономному Agent управлять целым кросс-чейн инвестиционным портфелем» мы recently также видели множество практик, и большинство концепций уже成熟ы на демо-уровне, будь то генерация многошаговых DeFi-стратегий на естественном языке, автономное исполнение ребалансировки, автоматическая миграция доходности, кросс-чейн корректировка позиций и даже более сложное управление портфелем.
С точки зрения рассуждений и оркестрации, возможности AI уже продвинулись очень далеко, однако при помещении его в production-среду недостатки уровня исполнения становятся все более очевидными.
Если действительно говорить о production-среде, этот недостаток можно概括ь одной фразой: DeFi динамичен, но сегодня большинство batch-обработок (пакетных обработок) все еще статичны.
На сайте ERC-8211 и в обсуждениях эта проблема четко обозначена: существующие ERC-4337 и EIP-5792 действительно продвинули старую модель «одна подпись — один вызов» до нового этапа «одна подпись может打包 несколько вызовов» (упаковать несколько вызовов), но параметры в этих вызовах по существу все еще заморожены в момент подписания.
То есть, суммы, целевые значения, ожидаемые выходные данные, которые пользователь ввел при подписании, не будут автоматически корректироваться при реальном исполнении из-за изменений состояния блокчейна.
Но сам DeFi как раз полон неопределенности. Фактический вывод одного свопа зависит от проскальзывания и ликвидности в блоке исполнения; время поступления и окончательная сумма при бриджинге зависят от механизма и комиссий самого моста; коэффициент share-to-asset в кредитных протоколах или Vault также постоянно меняется.
В конце концов, значения, которые пользователь или Agent видят при подписании, часто являются лишь текущей оценкой, а не реальным результатом при исполнении.
Чтобы понять, что решает ERC-8211, рассмотрим самый типичный пример: предположим, Agent хочет сделать, казалось бы, обычную вещь — конвертировать ETH на счете в USDC, а затем внести всю сумму в Spark для получения процентов.
В существующей модели статической batch-обработки Agent должен заранее оценить, сколько USDC будет получено после свопа, часто вынуждая вас заранее прописывать входную сумму для второго шага при подписании. Если оценка завышена, реально полученной суммы недостаточно, и вся партия откатывается; если оценка занижена, часть средств останется бездействовать в кошельке.
Другими словами, вы basically оказываетесь в所谓的дилеме: либо承担риск失败 (нести риск неудачи), либо承担альтернативные издержки (нести альтернативные издержки). Вот почему многие, казалось бы, несложные ончейн-процессы, как только steps растягиваются до 5, 8 шагов или даже跨двух链 (пересекают две цепи), быстро становятся хрупкими. Это не потому, что стратегия сама по себе слишком сложна для описания, а потому, что существующая парадигма исполнения слишком зависит от заранее прописанных параметров.
Короче говоря, верхний предел возможностей статической batch-обработки фактически определяет верхний предел стратегий, которые Agent может真正 безопасно выполнить.
С этой точки зрения, ERC-8211旨在решить (нацелен решить) не то, как AI Agent принимает решения, а то, что после того, как Agent уже принял решение, есть ли в ончейн более естественный, стабильный и безопасный способ его выполнения. Тем самым впервые предоставляя ончейн-исполнению форму выражения, изначально разработанную для AI Agent.
二、Что именно меняет ERC-8211?
Ключевой прорыв ERC-8211 заключается не в том, чтобы запихнуть больше шагов в одну подпись, а в升级 (апгрейде) batch-обработки из последовательности транзакций с зафиксированными параметрами в «программу, где параметры динамически вычисляются в момент исполнения».
Звучит действительно абстрактно, но понять несложно,官方использовалиоднуфразудляегоописания (официальные лица использовали одну фразу для его описания): From transactions to programs (От транзакций к программам).
Это означает, что ERC-8211 больше не рассматривает batch как список действий для последовательного выполнения, а视为 (рассматривает его) как программу исполнения с проверкой условий во время выполнения. Если具体разобрать (конкретно разобрать), он достигает этого с помощью трех композируемых примитивов:
- Fetchers (Извлекатели): Определяют, откуда берется значение параметра. Это может быть запрос текущего баланса某个地址 (какого-либо адреса), что позволяет параметру быть не снимком на момент подписания, а实时показанием (показанием в реальном времени), захваченным из состояния блокчейна в момент исполнения;
- Constraints (Ограничители): После того как параметр извлечен, он должен пройти проверку встроенных ограничений — например, «полученное USDC должно быть ≥ 2500» или «проскальзывание не может превышать 0.5%». Эти ограничения проверяются до того, как значение будет передано в следующий вызов; если какое-либо из них не выполняется, вся партия немедленно откатывается;
- Predicates (Предикаты/Условия срабатывания): Можно理解为 (понять как) привратников между шагами. Они не отвечают за генерацию значений, а отвечают за判断 (определение), продолжать ли выполнение. Например, в кросс-чейн сценарии, batch на стороне Ethereum может через predicate ожидать выполнения условия «WETH, переведенный через мост, уже поступил», и не提交 (не отправлять/не подтверждать) до поступления;
В этой конструкции каждый параметр должен ответить на два вопроса:第一 (во-первых), откуда должно взяться это значение при исполнении;第二 (во-вторых), каким условиям оно должно удовлетворять, прежде чем быть использованным в вызове. После комбинации этих трех элементов, batch перестает быть просто последовательностью транзакций, а становится программой со встроенными проверками безопасности.
В конечном счете, ментальная модель статической batch-обработки — это список — выполнить шаги A, B, C по порядку; а ментальная модель ERC-8211 — это программа с условиями — после выполнения A, взять реальный вывод A作为 (в качестве) ввода для B; B удовлетворяет ограничениям, только тогда перейти к C; если какой-либо шаг не соответствует ожиданиям, вся партия откатывается.
Мы其实можем简单理解 (на самом деле можем просто понять) это как «интеллектуальный механизм пакетной обработки», специально разработанный для AI Agent и сложных DeFi-операций, потому что в традиционных ончейн-операциях выполнение сложной DeFi-стратегии часто требует多个独立交易 (нескольких независимых транзакций): извлечение средств из кредитного протокола, обмен токенов, внесение в другой протокол (延伸阅读《加密 AI 协议全景:从以太坊的主战场出发,如何为 AI Agent 搭建新操作系统?》 Расширенное чтение «Панорама крипто-AI протоколов: отправляясь с главного поля битвы Ethereum, как построить новую ОС для AI Agent?»).
Каждый шаг требует отдельной подписи и подтверждения, что уже обременительно для человеческого пользователя, а для AI Agent, требующего高频自主操作 (высокочастотных автономных операций), это更是瓶颈 (узкое место). Решение ERC-8211 позволяет组合执行 (комбинированно выполнять) несколько блокчейн-операций в одной транзакции, причем каждый шаг解析 (анализирует/вычисляет) фактические значения во время выполнения, и должен满足预定义条件 (удовлетворять предопределенным условиям), прежде чем перейти к следующему шагу.
Например, Agent может в одной подписанной транзакции выполнить: извлечение средств из Aave → обмен фактически полученной суммы на Uniswap → внесение результата обмена в Compound — все выполняется атомарно, без необходимости编写新的智能合约 (писать новые смарт-контракты).
三、Почему говорят, что это больше связано с кошельками, особенно с умными кошельками
То, что ERC-8211 заслуживает внимания индустрии кошельков, не только потому, что он подходит для Agent, но и потому, что он переопределит позицию кошелька в цепочке взаимодействия.
Раньше кошелек был больше похож на безопасный подписыватель, его обязанностью было хранение приватного ключа, отображение транзакции, получение подтверждения пользователя и отправка подписи. Эта роль была достаточно важна в эпоху EOA и продолжает оставаться таковой в эпоху абстракции аккаунтов. Но если в будущем все больше ончейн-операций будет выполняться Agent-ами, то роль кошелька станет более центральной и важной.
Причина проста: когда пользователь больше не управляет ончейн-действиями пошагово, а начинает授权 (авторизовывать) Agent-а на выполнение整套целей (целого набора целей), кошелек должен иметь возможность承接 (принимать) этот более высокоуровневый объект взаимодействия. Ему нужно отображать не просто某个合约地址и一段calldata (какой-то адрес контракта и calldata), а целую программу исполнения «намерение — логика получения значений — проверка условий — конечный результат».
Следовательно, будущим кошелькам нужно понимать不再只是交易, а программы (уже не просто транзакции, а программы). ERC-8211 именно на этом уровне предоставляет кошелькам более четкий инструмент, потому что он явно записывает эти семантики исполнения в структуру кодирования, включая то, откуда берутся параметры, каким условиям должны удовлетворять, когда продолжать, когда откатывать — все это не черный ящик, скрытый в backend-логике, а объекты, которые могут быть интерпретированы, смоделированы и отображены кошельком.
С точки зрения кошелька, весь этот механизм в конечном итоге направлен на одно и то же: пользователь больше не подписывает набор низкоуровневых вызовов, которые ему трудно fully прочитать, а подписывает программу исполнения, ориентированную на результат, с четкими границами и проверяемыми условиями:
- AI Agent может отвечать за理解用户意图 (понимание намерений пользователя), генерацию пути (генерацию пути);
- Кошелек отвечает за то, чтобы представить этот путь пользователю для审核 (аудита/проверки) более понятным способом;
- А relayer отвечает только за提交 (отправку/подтверждение) при выполнении условий, не имея прав на篡改результатов (изменение результатов);
Именно поэтому некастодиальное исполнение считается前提 (предпосылкой) для Agentic DeFi, потому что агент может участвовать, но суверенитет, ограничения и окончательный расчет остаются в ончейн. Это также то место, где ERC-8211真正契合 (действительно совпадает) с умными кошельками, — он записывает в стандарт协议层 (уровня протокола) дело «безопасного выражения сложных намерений».
Стоит отметить, что ERC-8211 полностью совместим с фреймворками абстракции аккаунтов, такими как ERC-4337, EIP-7702, ERC-7579. Он не заменяет абстракцию аккаунтов, а поверх нее добавляет для Agent слой программируемой семантики исполнения.
Если ERC-4337 решил «кто может代表me发起交易 (представлять меня для инициации транзакций)», EIP-7702 решил «как EOA может временно обладать способностями смарт-контракта», то ERC-8211 решает: 一旦Agent开始替我操作 (как только Agent начинает操作за меня (оперировать за меня)), сможет ли он за одну подпись завершить целую цепочку решений.
Оглядываясь на эволюцию парадигмы ончейн-взаимодействия в Ethereum за последние 10 лет:
- Первый этап: одна подпись = один вызов функции (эпоха EOA)
- Второй этап: одна подпись = группа статически упакованныхвызовов (вызовов) (эпоха ERC-4337, EIP-5792)
- Третий этап: одна подпись = программа намерения с динамическим вычислением (эпоха ERC-8211)
Каждый скачок означает, что пользователь (или представляющий его Agent) может表达更复杂的目标 (выражать более сложные цели) с меньшим трением.
Хотя ERC-8211 в настоящее время все еще находится на стадии черновика, технические обсуждения продолжаются, и大规模протоколов接入 (масштабное подключение протоколов) также потребует времени, но направление, на которое он указывает, уже достаточно ясно: когда AI Agent真正начинает (действительно начинает) принимать ончейн-решения за человека, в ончейн необходим匹配的 (соответствующий), изначальный синтаксис исполнения.
