Prime Agent Benchmark 2026: как принять

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

Эта методика предназначена для руководителей разработки, которые проверяют, лучше ли Prime Agent существующего инструмента. Она также пригодится инфраструктурной команде, оценивающей вычислительные ресурсы и расход API для длинных задач, и AI-инженерам, которые строят систему регрессионных Agent Evals.

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

Зафиксируйте границы теста до первого запуска

Prime Agent — это не просто оболочка над одним ответом модели. Официальное описание указывает на рекурсивную языковую модель, постоянное IPython-окружение, программный вызов дочерних агентов, сохраняемое состояние и продолжение фоновых сессий после отключения терминала. Поэтому тест должен проверять не только качество финального патча, но и поведение всей рабочей системы. Описание архитектуры Prime Agent и документ о модели RLM показывают, почему обычного сравнения «ответил быстрее — значит лучше» здесь недостаточно.

Перед запуском зафиксируйте:

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

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

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

Разделите «готово» на три независимых результата

Одна из главных ошибок в Prime Agent Benchmark 2026 — считать задачу успешной, если агент сообщил о завершении или отдельная команда вернула нулевой код. Для инженерной приёмки используйте три слоя.

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

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

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

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

Проверка точности

• [ ] Есть отдельная проверка соответствия требованиям задачи.
• [ ] Есть скрытые тесты или сценарии, которых агент не видел.
• [ ] Зафиксирован факт прохождения тестов, а не только сообщение агента.
• [ ] Дифф просмотрен человеком.
• [ ] Отдельно записано, сколько времени заняла ручная доработка.
• [ ] Неполное или временное решение не засчитано как успех.

Такой подход согласуется с современными оценками кодирующих агентов: например, ProjDevBench разделяет архитектуру, функциональную корректность и итеративное улучшение, а не сводит оценку к одному финальному ответу. В опубликованном исследовании рассмотрены 20 задач в 8 категориях, а общий показатель принятия решений агентами составил 27,38 %, что хорошо показывает разрыв между демонстрацией и рабочей поставкой. Описание ProjDevBench и его методики.

Измерьте полное время, а не скорость ответа модели

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

Используйте единое определение:

полное время задачи = от отправки задания до подтверждённого результата или ручной остановки.

Разделите журнал на интервалы:

1. инициализация процесса и загрузка окружения;
2. анализ проекта и построение плана;
3. вызовы модели и инструментов;
4. ожидание rlm-подагентов;
5. выполнение тестов и сборки;
6. повторные попытки после ошибки;
7. ручная проверка и исправление.

Проведите минимум три типа испытаний:

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

Не смешивайте холодный и прогретый запуск. У Prime Agent постоянный kernel и фоновые worker-процессы могут изменить поведение после первой инициализации. В официальном документе о длительных сессиях описаны отсоединение клиента, сохранение артефактов, цели, расписания, heartbeat и восстановление после перезапуска. Именно эти этапы должны попадать в журнал времени, если вы оцениваете рабочее использование. Описание длительных и фоновых агентов.

Посчитайте стоимость полной поставки

Цена одного ответа модели почти никогда не равна стоимости задачи. Для Prime Agent нужно учитывать весь граф выполнения:

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

Используйте формулу:

Полная стоимость принятой задачи =
API основной модели
+ API дочерних агентов
+ повторные вызовы
+ внешние инструменты
+ время вычислительного окружения
+ стоимость ручной доработки

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

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

Проведите честное сравнение с текущим агентом

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

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

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

Для каждого задания подготовьте одинаковый пакет:

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

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

Сравнительный лист

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

Проверьте, действительно ли длинная задача завершена

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

Сделайте контролируемое прерывание:

1. запустите задачу на чистом репозитории;
2. дождитесь появления промежуточного изменения и записи состояния;
3. отключите терминал или клиент;
4. проверьте, продолжает ли worker работу;
5. подключитесь к сессии заново;
6. сравните журнал до и после восстановления;
7. убедитесь, что агент не повторяет разрушительные команды;
8. проверьте, что завершённые тесты не выдаются за новые;
9. подтвердите финальный результат независимым запуском проверок.

В официальной документации описано, что отключение интерфейса не должно останавливать resident worker, а сессии и артефакты могут восстанавливаться после перезапуска. Но это описание поведения механизма, а не гарантия корректности каждой конкретной задачи. Документ о восстановлении и фоновых сессиях.

Отдельно тестируйте:

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

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

Сведите результаты в единый отчёт

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

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

Для инфраструктурного решения свяжите итоговые показатели с режимом работы:

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

Примите решение по условиям, а не по впечатлению

Используйте следующие ветки решения:

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

Официальный репозиторий Prime Agent сейчас описывает MIT-лицензию, установку для macOS и Linux, фоновые сессии, RLM-подагентов и команды восстановления, однако эти функции не заменяют вашу проверку конкретных моделей, задач, разрешений и бюджета. Актуальный README проекта и документ об архитектуре процессов нужно сверять перед каждым повторным тестом, поскольку обновление harness может изменить результаты даже при неизменной формулировке задачи.

Если после такой проверки вы планируете запускать Prime Agent на длинных заданиях, текущая схема на личном ноутбуке обычно имеет три слабых места: рабочая машина занята фоновым процессом, состояние трудно изолировать от повседневной разработки, а прерывание или смена пользователя усложняет воспроизводимость. Для короткого локального эксперимента это приемлемо, но для закупочного сравнения лучше получить отдельную среду с одинаковым образом и параллельно запустить Prime Agent и текущий инструмент. Аренда Mac через ZavCloud подходит именно для такого промежуточного этапа: вы сначала собираете собственную базовую линию по времени, расходу API и ручной доработке, а уже затем решаете, нужен ли постоянный Mac, общая среда или эластичный тестовый ресурс.