К основному содержимому
к выпуску
Конспект выпуска2026Fellow

Сколько обвязки нужно сильной модели?

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

Research Insights Made Simple #466 минут

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

Основная линия материала
01

На исправлении багов разрыв сужается

У простого агента есть цикл из вызова модели, команды и результата. В mini-SWE-agent модель в основном действует через Bash. OpenCode предлагает более богатый интерфейс. Авторы Beyond the Model начинают с публичного лидерборда SWE-bench Verified. При сопоставлении конфигураций с одной и той же моделью разрыв между минимальной и более сложными обвязками уменьшается на более сильных Claude. Ведущий отделяет это наблюдение от собственных прогонов авторов.

В своём эксперименте авторы сравнивают mini-SWE-agent и OpenCode на десяти моделях Qwen и DeepSeek. На 300 задачах SWE-bench Pro преимущество OpenCode снижается с 6 процентных пунктов на Qwen3-Max до 2,67 пункта на Qwen3.7-Max. Для DeepSeek картина менее ровная. У моделей среднего уровня обвязка даёт больший прирост, а на V4-Pro разница сводится к двум задачам. Повторы и интервалы в этой части работы не описаны, поэтому небольшие различия стоит читать вместе с размером выборки.

Авторы смотрят и на действия агента. В OpenCode число шагов у Qwen почти не меняется, хотя сильнейшая модель делает заметно больше вызовов инструментов. В mini-SWE-agent один шаг соответствует примерно одному вызову, а Qwen3.7-Max проходит меньше шагов, чем модели среднего уровня. По мнению авторов, сильная модель лучше выбирает действия в простом интерфейсе. Ведущий отмечает, что по средним значениям видно поведение, а объяснение требует отдельной проверки.

02

На открытой задаче остаётся место для обвязки

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

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

03

Какие части NanoHarness помогают

Чтобы проверить компоненты по отдельности, авторы добавляют к mini-SWE-agent планирование, файловые инструменты, сжатие контекста, субагентов и навыки, которые модель загружает по запросу. На 200 задачах ProgramBench файловые инструменты и узкие субагенты дают наиболее устойчивые прибавки на двух изученных моделях. Узкому субагенту поручают исследовать эталон или проверить различия между реализациями. Ведущий сопоставляет это с общими ролями вроде архитектора и разработчика. У специализированной роли яснее, какую часть работы нужно выполнить и что вернуть основному агенту.

Полная сборка повышает оценку Qwen3.7-Max с 42,88 до 50,25, а DeepSeek-V4-Pro — с 45,14 до 51,35. Сжатие контекста по отдельности уменьшает число токенов промпта примерно на 54 и 77 % соответственно, но оценка падает на 4,86 и 3,85 пункта. При включении всех компонентов растут число вызовов инструментов и длина промпта. Ведущий предлагает держать рядом оценку и расход ресурсов. Токены и вызовы показывают, где изменился объём работы, а стоимость запуска зависит ещё и от цен и условий исполнения.

04

Что видно по траекториям

Два типичных провала выглядят противоположно. Агент может долго исследовать эталон, многократно проверяя близкие случаи. Или слишком рано решает, что понял требования, и начинает писать код. В примере с jq NanoHarness сокращает число проверок эталона со 133 до 43, а доля пройденных тестов растёт примерно с 25 до 68 %. В другом примере, с calcurse, проверок становится больше и итог также улучшается. В этих примерах важен выбор проб и момент перехода к реализации.

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

05

Что меняется в автономной ML-инженерии

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

Ведущий отдельно сопоставляет результаты по контексту. Когда авторы ML-работы ограничивают окно Malena до 64 тысяч токенов со встроенным сжатием OpenCode, оценка доли медалей снижается с 57,5 до 50 %. Интервалы неопределённости перекрываются. В NanoHarness использовался другой способ сжатия и измерялась другая задача. Оба наблюдения дают основание измерить цену потери контекста на своей нагрузке, особенно если агент работает несколько часов.

Обе работы дают способы поставить эксперимент. Абляции NanoHarness охватывают две модели и один набор задач. Результат ML-сравнения относится к другим задачам, моделям и способам измерения. Ведущий предлагает держать минимальный цикл как исходную точку, зафиксировать задачи и бюджет, а после замены модели повторять сравнения. Так видно, какие компоненты ещё окупаются, какие помогают только определённому классу задач и где вырос расход без заметного выигрыша.

Выводы

Что стоит унести с собой

  1. 01На исправлении багов преимущество богатой обвязки может уменьшаться с ростом возможностей модели. Открытые задачи требуют отдельной проверки.
  2. 02Файловые инструменты и специализированные субагенты дали наиболее устойчивые прибавки в абляциях NanoHarness на ProgramBench.
  3. 03Сравнивайте конфигурации по результату, расходу ресурсов и траекториям. Повторяйте проверку после смены модели.

Источники