Журнал · Rit.work

CoTrace не смешивает опыт терминального агента из разных обвязок

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

Rit.work
Студия разработки
8 октября 2026 г.3 мин чтения

Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.

Терминального агента удалось дообучать без смешивания удачных траекторий, созданных несовместимыми исполняющими обвязками. Лучший вариант CoTrace поднял Qwen3.5-9B с 78 до 90 решённых задач; это препринт, который не прошёл рецензирование и приводит замеры самих авторов. Для команд версия обвязки становится частью происхождения обучающих данных, а не сменяемой инфраструктурной деталью.

Почему удачная траектория подходит не каждой модели

Терминальный агент состоит из языковой модели и исполняющей обвязки (runtime harness). Обвязка формирует запрос, подключает инструменты, обрабатывает ответы терминала, управляет контекстом и пытается восстановиться после ошибок. Поэтому одинаковые веса модели могут вести себя по-разному в разных средах исполнения.

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

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

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

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

Меньший согласованный корпус дал принятые обновления

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

CoTrace-SFT использовала по 30–50 согласованных траекторий и стабильно проводила обновления модели. Итерация требовала 47 GPU-часов — меньше, чем другие варианты совместного обучения в основном сравнении. Работа показывает не преимущество малого датасета само по себе, а цену несовместимого опыта: дополнительные примеры могут мешать, если они созданы другой средой исполнения.

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

Проверку проводили прежде всего на Qwen3.5-9B и поддерживающем эксперименте с Qwen3.5-4B. Основным полигоном служил Tmax с замороженной выборкой из 102 задач для принятия обновлений. Перенос пары модели и обвязки отдельно проверяли на Terminal-Bench 2.1 и SWE-bench Lite, поэтому вывод относится к терминальным и программным агентам с исполняемыми проверками, а не к агентным системам вообще.

Планы меняет учёт обвязки, а не выбор новой модели

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

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

Совместимость важна и при переносе. На SWE-bench Lite одна и та же SFT-модель под сторонней обвязкой часто завершала работу без патча; переход к совместно обученной среде сократил такие случаи со 155 до 64. Значит, поставлять только контрольную точку модели рискованно: часть приобретённого поведения может находиться в паре «модель — обвязка».

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

Источники

Иллюстрация: рисунок из статьи «CoTrace: Data Recipes for Training Terminal Agents with Harness-Model Co-Evolution», Jixuan Chen, Jiaxin Zhang, Qinyuan Ye и др., CC BY 4.0

Пауза в чтении

Похоже на вашу задачу?

Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.

Rit.work

Студия разработки

Собираем мобильные приложения и помогаем командам получать от AI реальную пользу. Основатель и команда, работаем удалённо — с клиентами в России и за рубежом.

← Ко всем материалам
Понравилось? Обсудим вашу задачу