Как оценивать агентов помимо пройденных тестов

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

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

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

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

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

Фиксируйте не только коммит. Записывайте версии инструментов, правила кеширования зависимостей, доступные агенту переменные среды, сетевую политику, точки запуска тестов и ограничения ресурсов. При дрейфе среды оценка смешивает качество агента со случайностями на runner. Образы сборки должны иметь неизменяемые идентификаторы, а фикстуры нужно версионировать рядом с оценочным стендом.

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

{
  "task_id": "billing-credit-rounding-014",
  "repo_commit": "4f93c2a",
  "request": "Preserve tax rounding when a credit line follows a taxable line.",
  "visible_checks": ["test_billing_unit"],
  "hidden_checks": ["credit_after_tax", "mixed_currency_unchanged"],
  "budget": {"wall_seconds": 900, "model_cost_usd": 8.00},
  "allowed_paths": ["src/billing", "tests/billing"]
}

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

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

Почему пройденные тесты дают лишь одну оценку

Тесты показывают, совпали ли выбранные наблюдения с ожиданиями. Они не доказывают, что патч ограничен нужной областью, пригоден для сопровождения, безопасен и совместим с поведением, которое тестовый набор никогда не описывал.

Оценивайте выполнение задачи по уровням. Сначала запустите видимые проверки, доступные агенту. Затем выполните скрытые тесты для соседних входных данных и описанного пограничного случая. После этого проверьте весь репозиторий: линтер, типы, сборки и тесты зависимых пакетов. Наконец, исследуйте свойства, которые тестовые фреймворки замечают редко: изменения запрещённых файлов, новые зависимости, изменения публичного API, миграции, сгенерированные артефакты и подозрительное удаление тестов.

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

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

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

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

Ранее исправленное поведение входит в набор проверок

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

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

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

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

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

Нестабильные проверки нужно помещать в карантин с ответственным и доказательствами, а не молча повторять до зелёного результата. Записывайте каждый запуск. Правило повторной попытки может показать, допускают ли текущие правила CI выпуск патча. Сырые результаты показывают недетерминированность среды оценки или продукта. Если смешать эти данные, агент будет выглядеть лучше, но патч не станет безопаснее.

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

Стоимости нужны знаменатель и журнал сбоев

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

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

Рассматривайте стоимость как минимум с четырёх сторон:

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

Показывайте распределения, а не только средние значения. Медиана описывает обычный запуск, а 90-й или 95-й процентиль обнаруживает агентов, которые ходят по одним файлам по кругу, многократно пересобирают проект или загружают в контекст весь репозиторий. Жёсткий бюджет должен останавливать такие запуски и отмечать исчерпание бюджета отдельно от обычного провала задачи.

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

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

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

Задержку нужно измерять по критическому пути

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

Записывайте время постановки в очередь, готовности sandbox, первого ответа модели, каждого вызова инструмента, первого патча, начала проверки и окончательного результата. По этим событиям вычисляйте время очереди, подготовки, ожидания первой правки, активной работы агента, проверки и общее время. Не смешивайте задержку модели с длительностью команд.

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

CI должна измерять задержку критического пути, а не суммировать параллельную работу. Если модульные тесты и статический анализ идут одновременно восемь минут, пользователь ждёт восемь минут, а не шестнадцать. Ресурсы всё равно могут составить шестнадцать worker-минут, но этот показатель относится к стоимости.

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

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

Запускайте бенчмарк задержки на контролируемых worker, а общую CI наблюдайте отдельно. Контролируемые запуски позволяют сравнивать модели. Общие runner показывают требования к мощности и реальный опыт разработчиков. Объединение даёт шумное число, которое не отвечает ни на один вопрос.

Незнакомые репозитории выявляют другие сбои

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

Типичные сбои начинаются до написания кода. Агент выбирает неверную тестовую команду, принимает сгенерированный код за исходный, не замечает второй язык в сборке, игнорирует местное правило внесения изменений или редактирует общий модуль, не найдя его потребителей. Такие попытки могут собираться и проходить узкий тест. Они терпят неудачу, потому что агент составил неверную карту системы.

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

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

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

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

Ход работы объясняет невидимые в патче сбои

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

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

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

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

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

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

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

Оценочный стенд может сломаться раньше агента

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

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

Затем проверьте изоляцию. Каждой попытке нужны новый worktree, чистое пространство процессов, контролируемые часы для зависящего от времени поведения и отдельные ресурсы сервисов. База данных, оставшаяся после прошлого запуска, может создать видимость правильности следующего патча. Общие кеши зависимостей допустимы, но в них не должно быть изменяемых результатов задач.

Runner должен выдавать компактный стабильный результат, который CI сможет сохранить:

$ ./eval-agent fixtures/billing-credit-rounding-014
task=billing-credit-rounding-014 outcome=regression
target=pass hidden=pass repository=fail
cost_usd=3.42 wall_seconds=286 review=required
artifacts=patch.diff,events.json,test-results.xml

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

Версионируйте оценщик, задачу и оракул независимо. Когда оракул меняется, оставляйте достаточно метаданных для воспроизведения старых показателей и пересчитывайте их, если это возможно. Версия модели не должна выглядеть лучше лишь потому, что в том же pull request кто-то ослабил фикстуру.

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

Таблица результатов должна сохранять жёсткие сбои

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

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

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

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

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

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

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

Внедрению в CI нужны контрольные группы и правила остановки

Внедряйте агента для программирования через CI как измеряемое изменение с фиксированным периодом сравнения и условиями остановки. Немедленный запуск для каждого pull request превращает разработчиков в бесплатную инфраструктуру оценки.

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

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

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

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

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

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

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

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