EvoWeb проверяет кодинг-агентов на 320 последовательных запросах к 32 веб-приложениям

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

Как устроен бенчмарк

Основа EvoWeb — реальные продуктовые фичи. Запросы связаны графами функциональных зависимостей: одна возможность опирается на другую, и порядок задач не произволен. Агент работает с постоянной кодовой базой. Результат шага №3 становится исходным материалом для шага №4, а накопленные ошибки никуда не деваются.

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

• работает ли только что запрошенная функциональность;
• интегрируется ли она с функциями из предыдущих запросов;
• не сломалось ли то, что было реализовано раньше.

Третий пункт важен: регрессии в такой постановке не прячутся за итоговым тестом, их видно на каждом шаге.

Надёжность вместо точки остановки

Отдельное решение авторов связано с метрикой. Фиксированного критерия остановки, вроде «считаем, пока агент не провалит запрос», в EvoWeb нет. Вместо него траектория интегрируется по порогам терпимости пользователя. Один заказчик простит один сбой, другой уйдёт после первого. Метрика показывает, как долго агент остаётся полезным при разной строгости к ошибкам. Для инженера это ближе к вопросу «сколько итераций я могу ему доверить», чем сухой процент решённых задач.

Что показали эксперименты

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

Два вывода из анализа:

• Запросы, расположенные позже в цепочке и имеющие более глубокие или многочисленные зависимости, решаются хуже.
• Число ошибок времени выполнения растёт от запроса к запросу.

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

Как использовать результаты на практике

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

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