Способны ли LLM сами программировать обвязку для ИИ-агентов: разбор исследования HarnessDev

В сфере разработки автономных ИИ-агентов все сильнее проявляется зависимость итогового результата не только от самой языковой модели, но и от программного окружения, в котором она работает. В экспертном сообществе эту среду принято называть агентной обвязкой (agent harness). По сути, это весь управляющий код вокруг модели: ключевой цикл выполнения задач, набор доступных инструментов, механизмы управления контекстом, отслеживание состояния (state), системы восстановления после ошибок и модули проверки результатов.

Наглядную иллюстрацию этого явления дает бенчмарк Terminal-Bench 2.1: одна и та же нейросеть GPT-5 с неизменными весами показывает результат в 35,2% успешно решенных задач внутри среды Terminus 2, но демонстрирует уже 49.6% успеха при работе через интерфейс Codex CLI. Практически все существующие тесты оценивают модели в строго фиксированных обвязках. Однако команда исследователей из ByteDance Seed, Сингапурского университета технологии и дизайна (SUTD), Технологического института Джорджии, M-A-P и TokenWave.AI предложила кардинально иной подход. В созданном ими бенчмарке HarnessDev оценивается не финальный ответ нейросети, а способность самой LLM спроектировать и написать эффективный исполняемый код агентной обвязки.

Двухэтапная архитектура HarnessDev: создание и эволюция

Чтобы объективно проверить, насколько успешно нейросети справляются с ролью системных архитекторов, я выделил в методологии HarnessDev два ключевых последовательных этапа: первичную разработку (Creation) и последующую адаптивную доработку (Evolution).

Этап 1: Создание обвязки (Creation)

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

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

Этап 2: Эволюция и оптимизация (Evolution)

На этапе эволюции модель-создатель берет за основу собственный замороженный код, полученный на первой фазе, и пытается последовательно дорабатывать его. Для этого она использует обратную связь от реального исполнения на фиксированном наборе из 100 задач SWE-bench Pro и всех 89 задач бенчмарка Terminal-Bench 2.1.

Каждая официальная версия-кандидат обязана пройти обе оценки в парном режиме. На весь процесс модели выделяется лимит в 10 парных попыток и не более двух промежуточных зондирующих запусков по 5 задач между ними. Окончательные версии проверяются на 630 отложенных тестовых примерах SWE-Pro, которые модель никогда не видела в процессе разработки. Оценка созданных обвязок проводится по двум критериям: функциональная способность (процент успешного решения задач) и эффективность (расход токенов исполнителем, без учета токенов самого создателя).

Параметры эксперимента и исследуемые модели

В рамках масштабного тестирования ученые проверили 6 передовых моделей-создателей: Opus 4.8, GPT-5.5, Gemini 3.1 Pro, DeepSeek V4 Pro, Qwen 3.7 Max и Seed 2.0 Pro. Создатели работали внутри среды Claude Code 2.1.177, за исключением GPT-5.5, которая функционировала на базе Codex 0.144.3.

Этап создания охватывал 4 предметные области и 5 популярных бенчмарков общей сложностью 2207 тестовых инстансов:

• SWE-bench Pro (открытый сплит) — 731 задача по программированию;
• Terminal-Bench 2.1 — 89 задач по системному администрированию и работе с терминалом;
• MLE-bench — 75 задач по машинному обучению и дата-сайенс;
• EQ-Bench3 — 46 тестов на генерацию текста и гуманитарные задачи;
• BrowseComp — 1266 задач на веб-поиск и сбор информации.

Каждая модель генерировала по 3 варианта обвязки на каждый бенчмарк (итоговый показатель фиксировался как среднее avg@3). В режиме Self-Eval обвязка запускалась с той же моделью, которая ее создала, а в режиме Unified-Eval все обвязки тестировались единым исполнителем — Gemini 3.1 Pro.

Результаты фазы создания: где ИИ превзошел человека, а где провалился

В режиме Self-Eval наивысший средний балл среди всех участников продемонстрировала Opus 4.8, набрав 67,8 пункта при эталонном показателе человеческой разработки в 86,2 пункта. Однако разрыв с человеческим кодом сильно варьировался в зависимости от предметной области.

В задачах программирования Opus 4.8 достигла 69,3 балла на SWE-Pro против 80,0 у эталона. На Terminal-Bench лидером стала Gemini 3.1 Pro с результатом 68,8 балла против 88,8 у ориентира. Самое глубокое отставание нейросетей зафиксировано в веб-поиске: на BrowseComp лучший результат составил всего 52,6 балла (GPT-5.5) при эталонных 92,2 пункта.

Настоящим сюрпризом стали сферы копирайтинга и ML-экспериментов. В тесте EQ-Bench3 модель Opus 4.8 набрала 84,6 балла, превзойдя человеческий ориентир в 83,7 балла. В бенчмарке MLE-bench сразу две модели — Opus 4.8 (32,9 балла) и Gemini 3.1 Pro (32,4 балла) — уверенно обошли человеческий эталон в 24,0 балла. Стоит заметить, что эталонные ориентиры для SWE-Pro, Terminal-Bench и BrowseComp не перепроверялись вживую, а были взяты из официального отчета OpenAI по модели GPT-5.6.

Анализ кода показал, что объем написанного текста никак не гарантирует качества. Суммарно 18 программных обвязок добавили 17 111 чистых строк кода. При этом Gemini написала наименьший объем (всего 1006 строк), но смогла возглавить рейтинг на Terminal-Bench. Количество внутренних самопроверок практически не коррелировало с итоговым баллом (коэффициент Спирмена от 0,13 до 0,26), тогда как количество вызовов циклов ревизии показывало корреляцию 0,57.

Кроме того, огромная часть созданных нейросетями механизмов оказалась абсолютно неработоспособной («мертвый код»). Из 108 проанализированных компонентов 72 вызывались в реальных прогонах, а 18 не сработали ни разу — все они относились к блокам управления состоянием и памятью. В 11 из 18 обвязок модели определили класс State, но за 26 679 пройденных траекторий не было зафиксировано ни одного события сохранения контрольных точек. В текстовых обвязках из 587 созданных функций 124 оказались невостребованными.

Перенос исполнителя и расход токенов

Исследование выявило гигантский разброс в расходе вычислительных ресурсов. На бенчмарке MLE-bench потребление токенов между моделями отличалось почти в 19 раз. Например, GPT-5.5 добилась доли призовых мест в 19,1%, потратив 29,3 млн токенов, в то время как DeepSeek V4 показала близкий результат в 19,6%, израсходовав колоссальные 208,4 млн токенов.

Замена модели-исполнителя на Gemini 3.1 Pro полностью перемешала итоговую таблицу результатов. Модель Qwen прибавила 17,6 пункта на BrowseComp и 12,9 пункта на MLE-bench. А вот показатель Opus 4.8 на SWE-Pro обрушился с 69,3 до 33,0 балла. Причина оказалась банальной: Opus жестко прописала в коде лимит в 120 шагов, рассчитанный именно на свою скорость работы. Более того, в поисковой обвязке Opus доля дублирующих запросов после смены исполнителя взлетела с 10,1% до 88,2%.

Результаты эволюции: почему лишь 34 изменения из 64 были полезны

В ходе эволюционного этапа 9 линейных ветвей разработки сгенерировали 73 официальные версии обвязок и 64 смежных коммита. Все 5 создателей, работавших со своей собственной средой исполнения, смогли улучшить результаты на отложенных тестах — прирост составил от +1,43 до +4,44 пункта (в среднем +3,11).

Однако в условиях фиксированного исполнителя Gemini прогресса добилась только Opus. Модель GPT-5.5 в этой конфигурации и вовсе откатилась назад, потеряв 10,32 пункта.

Развитие обвязок не было монотонным. Из 64 внесенных изменений 8 привела к ухудшению работы на обоих бенчмарках, 16 снизили показатели на одном из них, 27 дали прирост исключительно в пределах статистической погрешности, и лишь 2 правки показали явную статистическую пользу. Разброс оценки одного коммита составлял около ±4,75 балла. Направление изменений на этапе обратной связи совпало с реальным улучшением на скрытых тестах только в 34 из 64 случаев (53,1%). Из 9 финальных заявленных версий обвязок лишь 2 действительно оказались оптимальными на отложенных задачах. Из 169 созданных новых функций и классов 25 не имели ни одного вызова в коде.

Самым ярким успехом эволюции стала находка Opus 4.8. Модель заметила, что из 100 прогонов 99 отчитывались об успешном завершении, хотя реальную проверку проходили только 48. Распознав проблему преждевременного выхода из цикла, Opus добавила специальный шлюз проверки выполнения (completion gate). В остальном диагностика ошибок осталась слабейшим звеном: специальный интерфейс анализа траекторий модели вызвали всего дважды за все время эксперимента.

Главные выводы исследования

Эксперимент HarnessDev доказал, что современным нейросетям уже можно доверить проектирование среды для ИИ-агентов, но до полной автономии еще далеко. Основные итоги исследования можно свести к следующим пунктам:

• Оценка обвязки, а не ответа: HarnessDev оценивает качество написанного кода среды, а не разовый результат генерации.
• Специфика доменов: созданные ИИ обвязки превосходят человеческие в написании текстов и ML-экспериментах, но уступают в кодинге и веб-поиске.
• Привязка к исполнителю: архитектура обвязки сильно заточена под конкретную LLM. Замена исполнителя с Opus на Gemini провалила тест SWE-Pro с 69,3 до 33,0 балла.
• Низкий КПД эволюции: из 64 внесенных правок только 34 (53,1%) реально улучшили работу на скрытых тестах, а сам процесс сопровождается большим количеством мертвого кода.

Источник: www.marktechpost.com