NeurIPS 2026: как оценивать кодовых Agent, а не только прохождение тестов?

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

Тесты зелёные, но непонятно, действительно ли Agent нашёл причину ошибки или просто случайно прошёл проверку.

Быстрое решение: не принимайте кодового Agent по одному итоговому статусу. Сверяйте результат с требованиями задачи, проверяйте Agent execution trace — то есть траекторию действий Agent, — отдельно оценивайте проверку изменений и повторяйте запуск в целевой среде. Исследования, связанные с программными Agent и представленные на NeurIPS 2026, могут подсказать подходы к оценке, но их выводы нужно проверять на собственных задачах.

Материал пригодится инженерам, оценивающим генерацию и исправление кода: он поможет расширить регрессионную проверку. Руководители команд оценки найдут способ разбирать качество процесса и причины провалов, а не только сводный результат. Исследовательским группам статья поможет подготовить среду для воспроизведения исследований по программным Agent.

Почему успешный тест ещё не означает надёжное исправление

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

Это не значит, что тесты бесполезны. Это значит, что итоговый статус — лишь часть оценки. В инженерном решении важны как минимум три вещи:

• Соответствие задаче. Исправлен ли требуемый сценарий, а не только конкретный тест?
• Качество действий. Есть ли в изменениях связь с причиной дефекта? Проверял ли Agent результат после правки?
• Воспроизводимость. Можно ли повторить работу в той же версии репозитория и зависимостей?

Масштаб различия между задачей и простым тестовым прогоном виден на SWE-bench. Авторы описали набор из 2 294 задач на исправление реальных проблем в открытых репозиториях; описание и состав набора приведены в статье SWE-bench. Это не означает, что любой успешный результат в таком наборе доказывает надёжность Agent. Напротив, число разных задач подчёркивает, что проверка одного удобного сценария не заменяет оценку на репрезентативном наборе.

Отдельный пример того, как задачу можно подготовить к проверке, — SWE-bench Verified. В официальном описании говорится о 500 задачах, выбранных и проверенных вручную. Этот размер относится именно к данной версии бенчмарка, а не является универсальной нормой для командного тестирования; см. описание SWE-bench Verified.

В публикационном плане NeurIPS 2026 есть относящиеся к программным Agent исследовательские материалы. Мы рассматриваем их как источник проверяемых идей, а не как доказательство общих инженерных правил. В официальном списке материалов NeurIPS 2026 найдите нужную запись, затем сверьте её с текстом соответствующей работы и публичными материалами авторов. До этой сверки не переносите формулировки из карточки конференции в отчёт как подтверждённые результаты.

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

Тестовый набор должен представлять разные типы задач

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

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

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

Это не готовая универсальная таксономия бенчмарка, а схема организации внутреннего набора. Для каждой задачи сохраняйте исходное описание, базовый commit, требуемое поведение и независимый способ проверить результат. В репозитории SWE-bench можно сверить, как проект описывает задачи и использование своего набора. Не стоит переносить его разметку без адаптации: структура репозитория и доступные проверки команды могут отличаться.

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

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

Траектория действий должна объяснять ход выполнения

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

Минимально полезная запись включает:

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

Именно по этой логике удобно разбирать сбой: сначала установить, какую информацию Agent получил; затем — какое решение принял; после этого — какие файлы изменил и какие проверки запускал. В документации SWE-agent по траекториям показано, как проект представляет журнал действий. Используйте это как пример формата и состава записей, а не как доказательство того, что конкретный формат автоматически повышает качество.

Разделяйте наблюдаемые события и оценку. Событие — тест завершился с ошибкой; оценка — Agent не проверил изменение. Первое можно подтвердить журналом. Второе требует контекста: возможно, проверка была невозможна, а команда завершилась до неё. Аналогично, количество вызовов инструмента не является метрикой качества без привязки к задаче.

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

Проверка траектории помогает оценить надёжность исправления

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

Удобно проверять процесс по четырём связкам:

• Задача → исследование: изучал ли Agent код, связанный с описанной проблемой?
• Исследование → изменение: следует ли правка из найденной причины или появилась без объяснимой связи?
• Изменение → проверка: покрывает ли проверка изменённое поведение?
• Проверка → отчёт: совпадают ли итоговые заявления Agent с выводом команд?

Для командной приёмки можно использовать простую шкалу от 0 до 2. Ноль означает, что подтверждения нет; один — подтверждение частичное или неполное; два — есть воспроизводимое свидетельство. Оценивайте отдельно соответствие задаче, качество изменения, проверку после последней правки и возможность повторить запуск. Это предложенная внутренняя рубрика, а не опубликованная шкала NeurIPS или SWE-bench.

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

Повторная оценка в собственном репозитории: пошаговая схема

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

1. Закрепите задачи. Сохраните точные формулировки, исходную версию кода и критерии приёмки. Не меняйте условие после запуска, чтобы оно лучше соответствовало полученному результату.
2. Подготовьте изолированную среду. Фиксируйте зависимости, переменные окружения, доступные инструменты и права на запись. Контейнер может помочь ограничить файловую систему и команды, но режим запуска нужно выбирать с учётом угроз и требований проекта; см. документацию по запуску контейнеров.
3. Сохраните исходное состояние. Запишите версию репозитория, статус рабочей копии, команды сборки и проверки. Убедитесь, что исходные тесты проходят или зафиксируйте известные проблемы до запуска Agent.
4. Запустите Agent и сохраняйте события. Записывайте вызовы инструментов, изменения, тестовые команды, ошибки и ответы. Не полагайтесь только на финальный текстовый отчёт.
5. Проведите независимую проверку. Запустите заранее определённые проверки после завершения изменений. Отдельно проверьте требования, которые автоматические тесты не охватывают.
6. Повторите запуск в тех же условиях. Сравните итоговые изменения, проверки и траектории. Повтор нужен не для получения удобного среднего, а чтобы заметить зависимость результата от случайности, состояния окружения или нестабильного процесса.
7. Разберите расхождения. Если Agent получил разные результаты, установите источник: случайный порядок тестов, сеть, время, недетерминированные зависимости или различающиеся исходные файлы. Не объединяйте такие прогоны в один показатель без объяснения.

Для воспроизводимости отдельно проверяйте разрешения на чтение и запись, доступ к сети и возможность устанавливать зависимости. Чрезмерно широкие права могут сделать запуск опасным; чрезмерно ограниченные — искусственно ухудшить результат. В отчёте укажите границы доступа, а не просто отметьте «контейнер использовался».

Если независимый повтор не совпал с первым запуском, сначала сравните исходное состояние, версии зависимостей и команды. До выяснения причины нестабильный результат не следует записывать как надёжное исправление.

Условия воспроизводимости нужно проверить до масштабирования

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

Перед масштабированием проверьте:

• Зависимости: зафиксированы ли версии и способ их установки?
• Тесты и разрешения: доступны ли Agent те же проверки, которые будут использоваться при приёмке? Может ли он изменить сами тесты?
• Случайность: записываются ли настройки, влияющие на выбор действий, и сравниваются ли повторные прогоны?
• Состояние репозитория: одинаковы ли базовая версия, рабочая копия и незакоммиченные изменения?
• Внешние условия: зависит ли задача от сети, внешнего сервиса, времени или недетерминированных данных?

Заранее определите, какие изменения тестов допустимы. Если задача прямо просит добавить проверку, это ожидаемая часть результата; если Agent меняет существующий тест так, что тот перестаёт проверять требование, зелёный статус не должен считаться достаточным. Проверяйте diff тестов отдельно от diff кода.

Обязательно сверяйте карточку конференции с первоисточником работы и доступным кодом до того, как включать метод в собственный протокол. Запись в списке NeurIPS 2026 подтверждает наличие соответствующего материала в официальных загрузках, но не заменяет чтение эксперимента. Для исследовательской воспроизводимости сохраняйте версию статьи, ссылку на публичные материалы авторов, конфигурацию запуска и известные ограничения. Если публикация или код обновились, зафиксируйте, какую именно версию воспроизводила команда.

Критерии готовности оценки к командному использованию

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

Если требуется провести временный исследовательский запуск без подготовки локального Mac, сравните его с привычной схемой выполнения по конкретным пунктам: сколько времени уходит на настройку отдельной машины, насколько просто изолировать эксперименты от рабочего окружения и можно ли повторно получить тот же доступ к среде. Аренда Mac не заменит плохо определённый набор задач, независимые тесты или анализ траектории. Для длительной непрерывной нагрузки либо требований к физическим интерфейсам собственная машина может оказаться подходящим выбором. Если же команде нужна временная среда для проверки гипотез, можно изучить доступные варианты облачного Mac и отдельно сверить опубликованные условия перед запуском. Например, вариант облачного Mac в Сингапуре имеет смысл рассматривать только после проверки, подходит ли он по фактической доступности и требованиям эксперимента. ZekVPS здесь — возможный вариант аренды среды, а не замена корректной методике оценки.

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