Сравнивать компоненты, сохраняя остальную систему
Разбор начинается с вопроса о причинах результата. Если два готовых агента по-разному решают задачи, сравнение итоговых баллов не объясняет, что помогло: модель, план, инструменты или обработка истории. Авторы собирают лёгкую обвязку с циклом ReAct: мысль, действие, наблюдение. Вокруг него меняют три компонента, оставляя общими ограничения числа ходов, настройки генерации и другие условия.
В работе сравниваются 176 настроек: четыре модели на двух наборах задач. SWE-bench Verified содержит 500 задач по исправлению Python-репозиториев, Terminal-Bench 2.1 — 89 задач через командную строку. Используются три размера Nemotron-3 и Mistral Medium 3.5. Основная сетка меняет политику контекста и размер окна; отключение плана и файловых инструментов проверяется лишь при политике T4 и окне 128 тысяч токенов. Полного перебора сочетаний здесь нет.
План и история выполняют разные роли
План хранится вне истории разговора. На первом ходу обвязка напоминает о необходимости его составить, затем подставляет актуальное состояние в следующие обращения к модели. Агент может обновлять пункты; одновременно в работе должен находиться ровно один. Такая конструкция задаёт порядок продвижения. В варианте без плана модель сама решает, как разбить задачу, опираясь на инструкции и доступную историю.
Отдельная настройка определяет действия. Полный набор включает bash и специальные инструменты чтения, поиска и редактирования файлов. В альтернативном варианте файловую работу приходится выполнять через bash. Сравнение имеет важную оговорку: диагностика после правки встроена в инструмент редактирования и исчезает вместе с ним. Поэтому разница результатов отражает не только удобство команд, но и доступную обратную связь. Механизмы плана и возврата истории рассматриваются отдельно от файлового интерфейса.
Контекст сначала освобождают, затем пересказывают
Авторы сравнивают пять политик. T0 сохраняет историю без сжатия. T1 заменяет старые результаты заглушками, T2 дополнительно позволяет вернуть вытеснённое событие из внешнего хранилища. T3 использует пересказ, а T4 сочетает вытеснение, возврат и пересказ. Системная инструкция, исходная задача и последние ходы остаются доступными: сокращать предлагают промежуточную часть истории, чтобы агент сохранял цель и понимал недавние действия.
В комбинированной политике вытеснение начинается примерно при заполнении 60% окна, пересказ — при 85%. Так дорогой пересказ не становится первой реакцией на рост истории. На маленьком окне активное управление особенно помогает: без него запуск может оборваться раньше, чем агент вообще попробует изменить код. Анализ траекторий связывает значительную часть выигрыша с предотвращением такого обрыва. Это объяснение полезнее общего утверждения, будто сжатие само по себе делает модель умнее.
Сохранённая информация не обязательно используется
По рассмотренным оценкам комбинированная политика оказывается наиболее дешёвой в среднем. Сначала убрать старые результаты, а затем при необходимости пересказать оставшееся выгоднее, чем каждый раз оплачивать пересказ большого объёма. При этом минимальная стоимость не означает максимальную долю решённых задач во всех условиях. Выбор требует сопоставить оба показателя, а не принять одну политику как безусловного победителя.
Возможность восстановить вытеснённую информацию используется редко. Чаще к ней обращаются небольшие модели при тесном окне. Наличие внешнего хранилища ещё не означает, что агент заметит пробел и запросит нужное событие. Поэтому полезно измерять реальные вызовы возврата и их результат. Ведущий предлагает смотреть на поведение конкретной модели: механизм может выглядеть убедительно в архитектуре и почти не участвовать в решении задачи.
План меняет момент остановки
У слабой Nemotron-3 30B на SWE-bench план увеличивает медианное число ходов с пяти до сорока. Модель реже сдаётся до правки, меньше застревает и решает почти вдвое больше задач. План здесь поддерживает продолжение работы: разбитая на шаги задача становится направлением, по которому агент способен двигаться.
Для более сильных моделей картина обратная. У Nemotron-3 550B медиана сокращается со 108 до 74 ходов, у Mistral — с 68 до 53. Меньше времени уходит на проверки после правки, снижается расчётная стоимость. Однако доля успеха слегка падает: на 2 и 0,4 процентного пункта соответственно. Поэтому экономию нельзя автоматически назвать улучшением качества. Формат плана и критерии завершения остаются предметом дополнительных экспериментов, а небольшие различия требуют повторных прогонов.
Bash не становится универсальным интерфейсом
У маленькой Nemotron готовые инструменты помогают, а переход на один bash резко ухудшает успешность. У большой Nemotron направление меняется: модель объединяет несколько операций в скрипт и выполняет больше работы за один вызов. Интерфейс определяет размер действия, поэтому число ходов нельзя оценивать отдельно от того, что происходит внутри каждого. Короткая траектория может означать и раннюю сдачу, и удачное объединение команд.
Mistral не укладывается в правило «сильной модели достаточно bash». На исправлении репозиториев инструменты полезны: без них 32,8% запусков заканчиваются без правки против примерно 1,2% с ними. На терминальных задачах направление результата обратное; даже с полным набором модель отправляет через bash почти 72% действий. Вывод зависит от сочетания модели и задачи. После смены модели стоит заново проверить инструменты, размер контекста и обратную связь, сохраняя сопоставимые условия.
Траектория объясняет балл и подсказывает следующий опыт
Авторы анализируют последовательности действий с помощью GPT-5.5 и сопоставляют разметку с человеческой проверкой. Такой анализ нужен, чтобы перейти от итогового балла к причине: переполнению окна, остановке до редактирования, повторным проверкам или вызовам несуществующих инструментов. Например, сначала выяснить, действительно ли план уменьшает число запусков без правки.
Ведущий связывает этот подход с предыдущим разбором Anthropic: изменение сразу нескольких частей затрудняет поиск причины ухудшения. Практический порядок — зафиксировать исходную конфигурацию, изменить один компонент и изучить результат вместе с ходом работы. Телеметрия помогает выбрать следующий эксперимент. Она не заменяет проверку готового решения: агент может сделать меньше действий, но закончить с неверной правкой.
Переносить стоит метод, проверяя ограничения
В исследовании выполнен один прогон на задачу при температуре ноль. Модели запускались локально через SGLang, а стоимость оценивалась по тарифам OpenRouter на август 2026 года. Это расчёт по токенам, а не измеренный счёт за локальное оборудование. Четыре модели из двух семейств, небольшой Terminal-Bench и ограниченные условия отключения компонентов сужают переносимость результата. Температура ноль не даёт оценки разброса между повторными запусками.
В финале обсуждаются ограничения SWE-bench Verified: отдельные проверки могут отвергать функционально верные решения, а задачи и ответы — попадать в обучение. Для собственной системы ведущий предлагает собрать актуальный набор задач, повторять прогоны и исследовать больше сочетаний механизмов. Польза статьи — в воспроизводимом способе задавать вопросы к обвязке. После обновления модели каждый компонент должен снова подтвердить полезность по качеству результата, стоимости и причинам наблюдаемых сбоев.
Что стоит унести с собой
- 01Управление контекстом особенно полезно, когда запуск обрывается до попытки исправить код. Измерять нужно причину остановки и готовый результат.
- 02План может продлить работу слабой модели и сократить работу сильной. Изменение числа ходов нужно оценивать вместе с качеством и стоимостью.
- 03Выбор между готовыми инструментами и bash зависит от модели, задач и обратной связи после действий; универсального победителя исследование не даёт.
- 04После смены модели повторяйте сравнение компонентов на своих задачах и используйте траектории для проверки причин, а не только итоговые баллы.