Где агент теряет замысел: разбор статьи arXiv:2610.37830

30 октября 2026 года на arXiv появилась статья «Measuring Where Intent Gets Lost in Agentic Smart Contract Synthesis» (arXiv:2610.37830v1). Авторы — Abhinav Goel и ещё трое исследователей. Работа о том, как проверять, соответствует ли сгенерированный ИИ смарт-контракт исходному заданию, и где именно теряется замысел.

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

Что именно измеряют авторы?

В аннотации сказано: оценка строится на исполнении, а не на статическом анализе. То есть контракт запускают и смотрят на фактические результаты. Это отличается от проверки синтаксиса или соответствия шаблонам.

Авторы ставят вопрос: где запрошенное поведение теряется. Ответ ищут, сравнивая исполнение с ожидаемым. Конкретный метод в аннотации не раскрыт. Деталей в доступном фрагменте нет — данных нет.

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

Почему исполнение, а не чтение кода?

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

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

Авторы, судя по аннотации, строят оценку на исполнении. Какие именно сценарии и как сравнивают — в аннотации не сказано. Данных нет.

Где замысел теряется чаще?

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

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

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

Как это связано с агентной генерацией?

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

В статье, судя по названию, рассматривается синтез смарт-контрактов агентом. Оценка на основе исполнения позволяет поймать такие искажения. Но нужны эталонные сценарии — то есть ожидаемое поведение, с которым сравнивают.

Откуда берутся эталоны? В аннотации не сказано. Данных нет.

Что с этим делать

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

2. Формулируйте задание явно: кто, кому, сколько, при каких условиях. Не полагайтесь на то, что агент угадает контекст.

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

4. Читайте полный текст статьи, когда он будет доступен, чтобы понять метод классификации потерь замысла. В аннотации деталей нет.

5. Не развёртывайте контракт без аудита, даже если он прошёл исполняемые тесты. Тесты покрывают только заложенные сценарии.