Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Появился способ автоматически улучшать код, который управляет LLM-агентом, не меняя саму модель и среду. В работе Microsoft Research Asia и нескольких университетов, которая не прошла рецензирование, все числа получили сами авторы: HarnessFlow поднял средний результат агента с 58,59% до 69,48%. Для команд это превращает обвязку из набора ручных настроек в отдельный объект оптимизации.
Поиск меняет всю исполняемую обвязку
Авторы называют исполняющей обвязкой (harness) программу, которая собирает контекст, хранит состояние, вызывает инструменты и решает, когда продолжать или завершать работу. Это не один системный запрос и не таблица параметров: кандидат представляет собой полноценную кодовую базу.
Такое представление позволяет менять связанные механизмы вместе. Например, дополнительная проверка результата может потребовать сохранить новые данные, изменить цикл работы и пересмотреть условие остановки. Оптимизатор вправе добавить, удалить или переписать эти части за одну попытку.
Каждый вариант обвязки становится узлом дерева, а изменение кода — ветвью от родительского варианта. После проверки система сохраняет код, итоговую оценку, журнал исполнения и связь с родителем. Неудачные изменения тоже остаются в архиве: агент для работы с кодом может увидеть, какие решения уже пробовали и где они сломались.
Сам код меняет LLM-агент, а поиск по дереву Монте-Карло решает, какой вариант дать ему следующим. HarnessFlow выбирает среди пяти лучших узлов, но учитывает не только их оценку. Часть вероятности получают варианты, у которых пока мало дочерних ветвей. Так система не тратит весь бюджет на последовательную доработку первого удачного решения.
Агент также получает библиотеку из 21 готового модуля: для сжатия наблюдений, хранения заметок, ведения журналов, проверки аргументов инструментов и управления циклами. Он копирует нужный код в кандидата и может его переписать, поэтому библиотека подсказывает механизмы, но не задаёт конечную архитектуру.
Пятнадцати попыток хватило, чтобы обойти альтернативы
На каждый набор задач HarnessFlow получал 15 попыток улучшить обвязку. Лучший вариант выбирали по валидационной части, а затем один раз проверяли на отдельной тестовой части, которую оптимизатор не видел.
Средняя тестовая оценка составила 69,48%. Это на 10,89 процентного пункта выше исходных обвязок и на 3,95 пункта выше Meta-Harness — метода, который также переписывает весь код, но последовательно дорабатывает кандидатов без постоянного дерева вариантов.
Запуск найденных обвязок в среднем стоил 41,4% от запуска Codex. Сравнение учитывает только дальнейшее исполнение задач; сам поиск требует дополнительных прогонов на валидационном наборе и остаётся отдельной разовой статьёй расходов.
Эксперименты охватили TAU2-bench и AppWorld для агентных задач, WebShop и BrowseComp-Plus для работы в веб-среде, а также SWE-bench Verified и BigCodeBench-Hard для кода. Во всех опытах использовали GPT-5.4-mini, одинаковый доступ к инструментам и одинаковые лимиты ресурсов. Каждый вариант запускали пять раз, а HarnessFlow сравнивали с исходной реализацией, Meta-Harness и ручными обвязками Claude Code, Codex, OpenHands и Hermes.
Когда HarnessFlow меняет план разработки агента
Работа меняет план, если команда уже выбрала модель и среду, но продолжает вручную настраивать память, вызовы инструментов, проверки и условия остановки. В таком проекте можно зафиксировать исполнитель и вынести поиск обвязки в отдельный этап после появления стабильной автоматической оценки.
Для этого нужен представительный валидационный набор. Оценка должна работать без ручной проверки каждого прогона, потому что один кандидат запускается на множестве задач, а поиск сравнивает результаты между ветвями. Отдельный тестовый набор нужен, чтобы выбрать не вариант, который приспособился к известным примерам, а обвязку, которая переносит изменения на новые задачи.
Подход особенно уместен для повторяющихся процессов: поддержки, работы с внутренними системами, программирования или веб-операций. Разовый расход на поиск тогда распределяется по последующим запускам. Для редких сценариев стоимость проверки кандидатов может оказаться важнее выигрыша от найденной обвязки.
Результат не означает, что одна найденная программа подойдёт разным продуктам. В опытах поиск запускали отдельно для каждой среды при фиксированных инструментах, модели и правилах оценки. Практический артефакт здесь — не универсальная обвязка, а воспроизводимый процесс её поиска под конкретную задачу.
Есть и архитектурная граница: каждый кандидат наследуется от одного родителя. Архив позволяет агенту подсматривать решения из других ветвей, но дерево напрямую не объединяет две удачные реализации в одну. Для команды это аргумент хранить найденные механизмы как отдельные модули и проверять их сочетания тем же автоматическим прогоном.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
