TL;DR
AgentBaton — подход «эстафетная палочка» для долгих агентных задач (программирование, терминал). Дорогая модель делает первую часть: план, рабочий прототип, первые запуски. Затем один раз управление передаёт дешёвой модели, и та доводит работу до конца. Авторы добавили к этому маленький обученный детектор, который сам выбирает момент передачи. Но главная ценность для практика не в нём, а в правилах передачи, которые они проверили.
Главная находка — асимметрия. Если начать дешёвой моделью и позвать сильную «на сложное», результат обычно хуже, чем у одной сильной, а экономии почти нет. Дешёвая за первые шаги успевает наломать дров, и сильной приходится это разгребать. Обратный порядок работает: сильная сделала основу и получила обратную связь от запусков, а дешёвая чинит, проверяет и дочищает. Точность при этом почти сохраняется, а цена падает на две трети и больше. Просить саму модель «передай управление, когда будешь готова» бесполезно. Одни модели так не делают вообще, другие передают всегда, но экономия получается небольшая.
Суть метода в трёх правилах: (1) передавай сверху вниз, один раз; (2) выбирай момент по состоянию работы, а не по счёту шагов; (3) выбирай способ передачи истории по направлению. Вверх (дешёвая → сильная) лучше отдавать историю файлом-журналом. Вниз часто лучше оставить её в том же диалоге.
Схема метода
ШАГ 1: Сильная модель берёт задачу → план, прототип, первые запуски
ШАГ 2: Проверка готовности к передаче (3 признака):
• есть рабочий прототип или нужный артефакт
• запускали/тестировали и получили обратную связь (даже плохую)
• остаток работы локальный: починить, проверить, довести
ШАГ 3: ОДНА передача → дешёвая модель получает то же рабочее пространство
+ историю (в диалоге ИЛИ файлом-журналом)
ШАГ 4: Дешёвая модель доводит до конца. Назад не переключаем.
Шаги идут в одной сессии агента. Переключение модели — это ручное действие или настройка инструмента.
Пример применения
Задача: Вы — владелец небольшого магазина на Ozon. Нужен скрипт, который каждое утро забирает остатки из 1С через выгрузку и обновляет их в Ozon Seller API. Работаете в Claude Code, на задачу есть и дорогая, и дешёвая модель.
Что делаете: 1. Дорогая модель проектирует скрипт, пишет первую рабочую версию и прогоняет её на тестовых данных. Часть остатков не обновилась из-за кодировки в артикулах. Это нормальная обратная связь: проблема сузилась. 2. Проверяете три признака. Прототип есть. Запуск был, и мы знаем, где падает. Остался локальный ремонт. 3. Переключаете модель на дешёвую. Продолжаете в том же диалоге или даёте ей журнал (см. шаблон ниже).
Промпт для дешёвой модели (передача через журнал):
Ты продолжаешь работу над задачей. Исходная задача: скрипт ежедневной
синхронизации остатков из выгрузки 1С в Ozon Seller API.
История работы предыдущего исполнителя лежит в файле ./handoff/log.jsonl.
Каждая строка — один шаг: номер шага, ответ модели и список действий.
У каждого действия есть команда, код возврата, stdout и stderr.
Записи идут по порядку времени. Сначала прочитай ПОСЛЕДНИЕ записи,
чтобы понять текущее состояние. Рабочие файлы уже в папке проекта.
Что нужно: исправить обработку артикулов с кириллицей, прогнать тест
на tests/sample_stocks.csv, убедиться, что все позиции обновились.
Результат: дешёвая модель сначала откроет конец журнала, найдёт упавший запуск и точечно починит кодировку. Потом прогонит тест и закончит работу. Дорогие токены ушли только на проектирование и первый прототип.
Почему это работает
Слабость. Дешёвая модель в долгой задаче чаще начинает с неверных предположений и уходит по ложному пути. Сильная потом тратит силы, чтобы это исправить. Поэтому передача «вверх» и частое переключение «по ходу» дают потери: переключения накапливают ошибки и накладные расходы. Сама сильная модель тоже не умеет надёжно решать, когда отдать управление. Это показали эксперименты с инструкцией «передай, когда готова».
Сильная сторона. Дешёвой модели не нужно придумывать решение с нуля. Ей достаточно видеть готовый артефакт и результат запуска, чтобы локально чинить, проверять и дописывать. Здесь она почти не уступает сильной. Даже неудачный запуск полезен, если он сужает проблему: он показывает, где именно ломается.
Как метод это использует. Сильная берёт на себя неопределённую часть работы (замысел, основа, поиск причины). Дешёвая берёт определённую часть (доводка). Момент передачи определяется состоянием работы, а не процентами или числом шагов.
Рычаги: - Момент передачи. Для разных пар моделей он разный: от примерно 30% до 60% траектории сильной модели. Если сомневаетесь, передавайте позже, но до финальной доводки. Чем позже, тем меньше экономия. - Способ передачи истории вниз. Если у исходной модели виден ход рассуждений, оставьте историю в диалоге. Если нет, попробуйте журнал-файл. Для некоторых моделей разница была заметной, для других смешанной. - Способ передачи истории вверх. Журнал-файл в большинстве случаев давал и лучшую точность, и меньшую цену, чем вставка всего в контекст. - Инструкция по чтению журнала. «Сначала последние записи» помогает быстрее понять текущее состояние.
Шаблон промпта
Это текстовая инструкция для новой сессии на принимающей модели. Структура взята из статьи: исходная задача, путь к журналу, описание полей, порядок записей, указание читать конец первым.
Ты продолжаешь работу над задачей, которую начал другой исполнитель.
ИСХОДНАЯ ЗАДАЧА:
{исходная_задача}
ИСТОРИЯ РАБОТЫ лежит в файле: {путь_к_журналу}
Формат: одна запись на каждый шаг прежнего исполнителя. Поля записи:
- номер шага
- его исходный ответ
- список действий: команда, код возврата, stdout, stderr
Записи идут в хронологическом порядке. Начни с ПОСЛЕДНИХ записей,
чтобы понять, в каком состоянии сейчас работа. К ранним записям
возвращайся, только если нужно выяснить, почему что-то было сделано так.
Рабочие файлы уже лежат в {папка_проекта} в том состоянии,
в каком их оставил предыдущий исполнитель.
ЧТО ОСТАЛОСЬ СДЕЛАТЬ:
{остаток_работы}
КАК ПОНЯТЬ, ЧТО ГОТОВО:
{критерий_готовности}
Что подставлять:
- {исходная_задача} — дословная постановка, которую получила сильная модель.
- {путь_к_журналу} — файл, куда выгружена история. Если инструмент сам его не создаёт, попросите сильную модель в конце своей части записать журнал по этой схеме.
- {остаток_работы} — локальные дела: починить конкретную ошибку, проверить, довести.
- {критерий_готовности} — тест, команда или проверка, которая подтверждает результат.
🚀 Быстрый старт — вставь в чат:
Вот шаблон передачи работы между моделями. Адаптируй под мою задачу: [твоя задача].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, какая у тебя исходная задача, что уже сделано, что упало или не проверено и как понять, что работа закончена. Эти данные нужны, чтобы принимающая модель получила чёткий остаток работы, а не «разберись сам».
Ограничения
⚠️ Детектор требует обучения: сам AgentBaton — это отдельная обученная маленькая модель, которая обучалась на сотнях тысяч шагов агентных запусков. Читателю без GPU и команды разработки она недоступна. Применимы только выводы из анализа, и момент передачи придётся выбирать вручную.
⚠️ Ручной выбор момента не проверен: признаки готовности авторы выделили разбором примеров и использовали для разметки. Как работает человек с чек-листом, они не измеряли.
⚠️ Точность иногда падает: в ряде пар при передаче дешёвой модели точность падала заметно, в некоторых случаях на 5–12%. В других случаях была на уровне базы, а иногда выше. Итог зависит от пары моделей.
⚠️ Запросить «передай сам» не получится: инструкция сильной модели «передай управление, когда готова» не сработала. Одна модель не передавала никогда, другая почти никогда. Третья передавала всегда, но экономия была скромной.
⚠️ Только кодинг и терминал: проверяли на программировании и терминальных задачах, в основном на одном простом агентном каркасе. Для текстовых и аналитических задач перенос не проверен.
⚠️ Одна передача: переключаться туда-обратно не пробовали. Авторы считают, что частое переключение накапливает ошибки.
⚠️ Учёт стоимости: локальные модели в расчёте считались бесплатными. Если вы платите за облачную дешёвую модель, экономия будет меньше.
Как исследовали
Исследователи взяли три сильные модели и одну дешёвую (27B) и два бенчмарка: терминальные задачи и сложные задачи по разработке в реальных репозиториях. Сначала прогнали каждую модель в одиночку и записали траектории. Затем воспроизвели действия сильной модели до выбранной точки (15%, 30%, 45%, 60%, 75%, 90% пути) и дали другой модели продолжить с того же рабочего состояния. Так можно честно сравнить «передали здесь» и «не передавали».
Результат оказался несимметричным. Передача вверх обычно давала потерю точности, а экономия была малой. У одной модели на 30% траектории точность чуть выше, 70,8% против 68,1%, но цена упала всего на 6,1%. Передача вниз показала противоположное. Kimi K3 на 45% пути: 72,57% против 73,45% у себя, при этом на 61,5% дешевле. GLM-5.3 на 30%: 61,1%, ровно как у одной, и на 82,4% дешевле. GPT-5.6 Sol на 60%: 67,26% против 68,10%, на 47,9% дешевле.
Затем сравнили два способа передачи истории: вставить в контекст или положить файлом-журналом. Для передачи вверх журнал был лучше почти везде. Для передачи вниз результат зависел от модели. Авторы предполагают, что дело в том, видны ли у исходной модели её рассуждения.
Чтобы понять, что именно делает передачу успешной, они взяли случаи, где дешёвая модель проваливалась после ранней передачи, но справлялась после следующей. Они посмотрели, что сильная модель сделала между этими точками, и вывели три признака готовности. Попытка просто попросить модель самой решать, когда передавать, провалилась. Это и привело к обучению детектора на 4000 траекторий. Детектор — маленькая модель на 2 млрд параметров, обученная на 16 GPU H100, она отвечает за 0,3 секунды. Через 11 пар моделей и два бенчмарка он в среднем сокращает затраты на 65,9% и в лучшем случае даёт прирост до 8,8 п.п. к точности одной сильной модели.
Адаптации и экстраполяции
🔧 Техника: чек-лист готовности перед переключением → меньше ложных передач
Прежде чем менять модель, попросите сильную модель ответить на три вопроса. Это моя адаптация: авторы признаки выделили, но человеческую проверку не измеряли.
Прежде чем я передам работу другой модели, ответь коротко:
1. Есть ли уже рабочий прототип или нужный артефакт? Какой?
2. Что мы запускали или проверяли, и что показала проверка?
3. Что осталось: локальная правка/проверка или ещё нужно что-то придумывать?
Если ответ на (3) — «нужно придумывать», передавать рано.
Передача по ответам: если на пункт 3 модель говорит «локальная правка», можно переключать. Это дополнение, а не результат статьи. Пользуйтесь им как отправной точкой и проверяйте на своих задачах.
Ресурсы
- AgentBaton: Efficient Model Collaboration in Agentic Tasks — Junlong Li (HKUST), Jindong Jiang, Yonggan Fu, Jiarui Yao (UIUC), Hanrong Ye, Wonmin Byeon, Peter Belcak, Hao Zhang, Pavlo Molchanov; NVIDIA, 2026.
- Бенчмарки: Terminal-Bench 2.1 и DeepSWE v1.1; каркас агента — mini-SWE-agent.
- Данные для обучения детектора: SWE-rebench V2.