AgentLens benchmark для coding agents: почему pass/fail уже мало

По состоянию на 9 июля 2026 года AgentLens - это свежий открытый benchmark для coding agents, который оценивает не только финальный pass/fail, а весь сеанс работы агента. Авторы paper формулируют проблему просто: агент может пройти узкую проверку и всё равно быть неудобным, хрупким или вводящим пользователя в заблуждение. Бывает и наоборот: финальная проверка красная, но агент правильно нашёл причину, аккуратно пользовался инструментами и сделал часть полезной работы.

Для разработчиков это важный сдвиг. Большинство публичных рейтингов удобно читать как таблицу победителей, но в реальной работе с coding agent важны другие вопросы: следовал ли он инструкции, не ломал ли лишние файлы, проверял ли свои изменения, восстановился ли после ошибки, честно ли описал итог. AgentLens пытается превратить именно эти признаки в измеримый отчёт.

Новый paper AgentLens: Production-Assessed Trajectory Reviews for Coding Agent Evaluation вышел на arXiv 7 июля 2026 года, PDF датирован 9 июля. Код и первый открытый fold опубликованы в репозитории agent-lens/agent-lens-bench под Apache-2.0.

Почему pass/fail мало для coding agents

Классический benchmark для задач программирования чаще всего сводится к вопросу: прошли ли тесты. Для leaderboard этого достаточно. Для продукта, которым разработчик пользуется весь день, такого сигнала мало. Агент может случайно пройти проверку, пропустить часть требований, объявить успех после упавшего build или бесконечно гонять неработающие команды до тайм-аута.

Мы уже видели похожую проблему в соседнем кластере: Rubric-Based GRM для SWE agents разбирает, почему итоговый pass/fail даёт слишком грубый сигнал для обучения и оценки. AgentLens смотрит на другую сторону той же проблемы: не на reward-модель, а на пользовательскую траекторию production coding assistant.

Ключевая идея AgentLens в том, что объект оценки - не patch и не один score, а trajectory. В paper под траекторией понимается весь записанный сеанс: запросы симулированного пользователя, ответы агента, вызовы инструментов, правки файлов, команды, попытки проверки, финальный ответ и финальное состояние репозитория.

Как устроен AgentLens benchmark

Открытый релиз начинается компактно: Java fold содержит 16 сценариев и две персоны пользователя, neutral/default и toxic. Значит, на каждого оцениваемого агента приходится 32 траектории. Helpful persona в paper тоже описана, но в released fold основной парой стали default и toxic. Такой размер выбран не случайно: benchmark должен запускаться часто, в том числе в nightly или CI pipeline, а не только как редкая академическая проверка.

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

Сбор и оценка идут в два этапа. IDE runner проигрывает диалог между LLM-пользователем и агентом внутри headless IDE, записывает чат, tool calls, file diffs, verifier outputs и telemetry. Затем Python evaluator прогоняет formal checks и LLM-written trajectory reviews. В README репозитория отдельно сказано, что framework не привязан к Java или IntelliJ IDEA: это первый открытый fold, а другие языки и JetBrains IDE планируются к публикации.

Formal verification остаётся там, где она нужна. В AgentLens есть проверки состояния репозитория, regex-чекеры, запуск тестов через Maven или Gradle, build-system tasks и статический анализ. Но авторы честно фиксируют границу: формальная проверка не видит pleasantness, instruction compliance, misleading validation и плохую работу с инструментами. Для этого нужны judge metrics.

Какие метрики смотрит AgentLens

В базовом fold используются пять LLM-judge метрик: End Result, Instruction Compliance, Pitfalls, Pleasantness и Tool Calls. Каждая метрика даёт score и письменный review с evidence pointers в траекторию. В агрегате к ним добавляется Formal, а Quality Index считается как простое среднее этих компонент, масштабированное до 0-100.

Это хорошо ложится на практические проблемы агентного кодинга. В материале про SWE-Explore мы разбирали похожий провал: агент может найти правильный файл, но ошибиться на уровне строк и правок. AgentLens добавляет к такой диагностике ещё слой поведения: что агент делал до ошибки, как проверял гипотезы и как объяснял итог пользователю.

Что показал первый leaderboard

По состоянию на 9 июля 2026 года в официальном CSV репозитория и Table 6 paper верхняя часть Java fold выглядит так. Важно читать её как результат конкретного benchmark: 32 trajectory на агента, Java-сценарии, single-run reviews с GPT-5.4 в роли judge, часть моделей через официальных провайдеров, часть через OpenRouter.

Самое интересное здесь не первое место. Авторы сами пишут, что leaderboard - не главная часть benchmark. Агент с близким QI может быть сильнее по instruction compliance и слабее по completion, лучше сохранять границы задачи, но хуже доводить результат до конца. AgentLens нужен как раз для того, чтобы этот trade-off не потерялся в одной цифре.

Для внешнего читателя есть ещё одна важная оговорка. Эти строки нельзя автоматически переносить на все coding agents, все IDE, все языки и все корпоративные проекты. AgentLens оценивает конкретный класс задач, а первый открытый релиз остаётся Java-only. Такой срез не измеряет general intelligence моделей и не заменяет все существующие benchmarks.

Зачем нужны письменные reviews

Письменные trajectory reviews ценны там, где число вводит в заблуждение. В Section 4.3 paper есть хороший пример: Kimi K2.6 оказался внизу таблицы, но ToolCalls review показал, что главный провал был связан не с reasoning, а с provider-side ошибкой парсинга аргументов на OpenRouter. Судя по review, 20 из 21 проверок зафиксировали хотя бы одну schema/argument parse error, а 17 из 21 описали один и тот же wrapper mistake.

Это ровно тот тип сигнала, который теряется в простой таблице. Если смотреть только на место в leaderboard, можно решить, что модель слабая. Если читать trajectory review, виден другой диагноз: контракт между агентом и провайдером ломал tool calls, а часть вызовов начинала работать после выравнивания JSON. Для команды, которая развивает агентный продукт, это не академическая тонкость. От такого вывода зависит, чинить ли модельный слой, adapter, prompt, tool schema или инфраструктуру провайдера.

Похожая логика применима к регрессиям. AgentLens рассчитан на side-by-side сравнения с anchor run: новая версия агента прогоняется по тем же сценариям, а reviews показывают, где она стала лучше или хуже. В paper приведён пример с regression в parallel tool calling, где нормальный на вид финальный ответ скрывал crash и ухудшение Pitfalls/ToolCalls. Для nightly pipeline это полезнее, чем общий score без причины.

Где можно ошибиться в трактовке

Первая ошибка - назвать AgentLens заменой SWE-bench. Авторы сами ставят его рядом с repository-level и terminal benchmarks, но фокус другой. SWE-bench проверяет способность решать реальные GitHub issues через итоговое состояние репозитория и тесты. AgentLens оставляет formal checks, но добавляет обзор полной пользовательской траектории. Это соседний слой, а не «новый SWE-bench».

Вторая ошибка - расширить результат до всех AI-агентов. В paper прямо указано: AgentLens оценивает конкретный класс coding-agent задач, а текущий открытый релиз Java-only. Если команда пишет Python-агента, security-agent или RAG-agent, ей придётся адаптировать сценарии, метрики и verifiers под свой контекст.

Третья ошибка - поверить LLM-judge без контроля. Авторы обсуждают риск self-preference: judge может предпочитать систему из собственной модельной семьи, особенно когда сравниваемые агенты близки по качеству. В их проверке GPT-5.5 и Sonnet 4.6 judges выбирали разных победителей в 23% task-metric comparisons, а self-favoring pattern проявился в 18% всех comparisons. Метод остаётся полезным, но требует осторожности: judge нужно фиксировать, проверять и не превращать в единственный источник истины.

Четвёртая ошибка - читать leaderboard как закупочный рейтинг. В материале про то, как бенчмарки ИИ-агентов ломаются, мы уже разбирали риск такой логики: публичный score легко спутать с реальной пригодностью для вашего workflow. AgentLens сильнее именно там, где его используют не как витрину, а как диагностику поведения собственного агента.

Что делать команде, которая внедряет coding agents

Практический вывод из AgentLens не в том, что всем надо срочно прогнать этот Java fold. Полезнее забрать принцип: оценивать не только результат, но и путь к нему.

1. Соберите 10-20 типичных сценариев из реальной работы команды: багфикс, тесты, документация, миграция, refactor, разбор CI.
2. Для каждого сценария разделите формальные checks и поведенческие критерии. Тесты и build важны, но они не отвечают на вопрос, следовал ли агент инструкции.
3. Записывайте полную траекторию: сообщения, tool calls, diff, команды, проверки, ошибки и финальный ответ. Без этого вы видите только тень работы агента.
4. Используйте side-by-side сравнение при обновлении модели, prompts, tool schemas или harness. Regression часто прячется не в итоговом score, а в объяснении.
5. Не отдавайте решение одному LLM-judge. Фиксируйте judge model, проверяйте спорные кейсы руками и отдельно смотрите на bias в близких сравнениях.

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

Итог

AgentLens важен не как очередная таблица моделей. Он фиксирует более зрелый взгляд на coding agents: качество находится не только в финальном patch, но и в том, как агент к нему пришёл. Для production assistants это ближе к реальности разработчика, чем один зелёный или красный чек.

Ограничения у paper существенные: первый fold компактный, Java-only, LLM-judge требует контроля, часть результатов зависит от провайдеров. Но направление верное. Если coding agents становятся рабочим инструментом, их нужно оценивать как рабочий процесс: с инструментами, проверками, ошибками, восстановлением и коммуникацией, а не только по последней строке отчёта.

FAQ

Что такое AgentLens?

AgentLens - открытый benchmark для coding agents, который оценивает полный сеанс работы агента: сообщения, tool calls, правки файлов, команды, проверки, восстановление после ошибок, финальный ответ и итоговое состояние репозитория.

Чем AgentLens отличается от SWE-bench?

SWE-bench в первую очередь проверяет, решил ли агент задачу в репозитории и прошли ли тесты. AgentLens сохраняет formal verification, но добавляет LLM-written trajectory reviews и side-by-side comparisons, чтобы увидеть поведение агента по ходу работы.

Можно ли использовать AgentLens в CI?

Да, авторы прямо описывают nightly/CI pipeline: агент собирает траектории, evaluator считает формальные проверки и reviews, а side-by-side сравнение с anchor run помогает ловить регрессии между версиями.

Можно ли по leaderboard AgentLens выбрать лучшую модель?

Нельзя без оговорок. Текущий leaderboard относится к 32 Java-траекториям на агента и конкретному harness. Его стоит читать как диагностический сигнал, а не как универсальный рейтинг всех моделей и coding agents.

Источники и дата проверки

Факты, числа и ограничения проверены 9 июля 2026 года по первоисточникам: страница arXiv 2607.06624, PDF paper AgentLens, репозиторий agent-lens/agent-lens-bench и официальный leaderboard CSV.