TL;DR
Structured handoff state (структурированное состояние передачи) — это короткий блок с четырьмя разделами: принятые решения, актуальные факты, уже выполненные действия и оставшаяся работа. Его пишут перед тем, как отдать незаконченную работу другой модели или новой сессии. Исследователи сравнили три способа передачи при одинаковом объёме текста: последние сообщения переписки, пересказ прозой и структурированный блок. Структурированный блок выиграл у обоих.
Главная боль в том, что новая модель не знает, что уже решено и сделано. Хвост переписки обрезает начало, и пользовательский выбор или уже выполненная операция остаются за кадром. Модель переспрашивает, повторяет действие или возвращается к отвергнутому варианту. Удивительнее другое: пересказ прозой оказался хуже сырого хвоста переписки. В красивом связном тексте теряются конкретные «что выбрали» и «что уже сделано».
Метод простой: перед передачей явно разложить состояние по полям. Важно, чтобы устаревшие значения были заменены новыми, а не лежали рядом. Это один дополнительный запрос или одно правило в инструкции агенту. Но выигрыш неравномерный: на одной из шести моделей часть задач стала решаться хуже.
Схема метода
ШАГ 1 (в конце работы первой модели или сессии):
Собрать из истории блок состояния → 4 раздела:
РЕШЕНИЯ / АКТУАЛЬНЫЕ ФАКТЫ / СДЕЛАНО / ОСТАЛОСЬ
ШАГ 2 (новая модель или сессия):
Получает блок + свою задачу → продолжает с учётом блока:
не отменяет решения, не повторяет сделанное, не использует устаревшее
Шаг 1 — отдельный запрос (можно той же моделью, что работала). Шаг 2 — новый чат или сессия. В исследовании блок строила отдельная модель GPT-4.1 по видимой истории.
Пример применения
Задача: Вы три часа делали в Claude Code приём платежей для Telegram-бота записи в барбершоп через ЮKassa. Контекст разросся, и пора открыть свежую сессию. Если просто скопировать последние сообщения, новая сессия не узнает, что вы отказались от поллинга в пользу вебхуков и что миграция БД уже применена.
Промпт (в старой сессии, перед закрытием):
Я передаю эту работу новой сессии, которая не увидит нашей переписки.
Составь блок передачи состояния строго по разделам:
<Решения>
Всё, что мы зафиксировали и что нельзя пересматривать без моего слова
(например: вебхуки вместо поллинга, суммы храним в копейках).
<Актуальные_факты>
Текущие значения. Если что-то изменилось по ходу работы — только
новое значение, старое не упоминай.
<Сделано>
Что уже выполнено и повторять не нужно: изменённые файлы, применённые
миграции, пройденные и упавшие тесты, неудачные попытки и почему
они не сработали.
<Осталось>
Что ещё не сделано, открытые вопросы, рабочие гипотезы
(помечай: «гипотеза, не проверено»).
Только факты из нашей работы. Ничего не додумывай.
Если раздел пуст — напиши «нет».
Результат: Модель выдаст компактный блок из четырёх разделов с конкретикой: названия файлов, статус миграции, какой тест падает. Блок вставляете первым сообщением в новую сессию и пишете «продолжай с раздела Осталось». Новая сессия не переспрашивает про вебхуки и не пытается заново применить миграцию.
Почему это работает
Слабость: модель, получившая обрезанную историю, видит только то, что в окне. Решения и выполненные действия из начала переписки для неё не существуют. Пересказ прозой делает хуже: в нём нет границы между «решили», «пробовали», «сделали» и «думаем». Модель читает всё это как общий фон и может принять отвергнутое за актуальное.
Сильная сторона: модель хорошо читает явно размеченную информацию и следует ей. Если сказано «это зафиксировано» и «это уже сделано», она учитывает это при следующих шагах. Структура превращает неявное состояние в набор проверяемых утверждений.
Как метод использует это: четыре раздела разделяют по ролям то, что в переписке перемешано. «Решения» — это ограничения, «Сделано» — защита от повторов, «Актуальные факты» — защита от устаревших значений, «Осталось» — точка входа.
Рычаги управления:
- Разделы: добавьте раздел под свою работу, например <Формат_вывода> для полей отчёта. В исследовании для задач с отчётом о файлах состояние строили с учётом нужных полей вывода.
- Пометка «гипотеза, не проверено»: убирает риск, что получатель примет догадку за факт.
- «Только новое значение»: главный рычаг против устаревших данных.
- Объём: в исследовании блок был не длиннее остальных вариантов. Если вы его раздуете, преимущество в токенах пропадёт.
Шаблон промпта
Точный промпт авторов в доступной части статьи не приведён. Шаблон ниже собран по их описанию: «факты, обязательства, предыдущие действия и оставшаяся работа».
Мы передаём незаконченную работу другому исполнителю ({модель_или_сессия}),
который не увидит нашей переписки. Составь блок состояния по задаче: {задача}.
<Решения>
Что зафиксировано и не подлежит пересмотру без явного согласия.
Формат: «решение — кем и когда принято».
<Актуальные_факты>
Текущие значения ключевых параметров: {какие_параметры}.
Если значение менялось — только последнее. Старые не переноси.
<Сделано>
Выполненные действия, которые не нужно повторять: {что_считается_действием}.
Включи неудачные попытки с причиной.
<Осталось>
Невыполненные шаги и открытые вопросы. Неподтверждённые предположения
помечай «гипотеза, не проверено».
Правила: используй только то, что есть в истории. Не додумывай.
Пустой раздел — «нет». Длина — не больше {число_слов} слов.
Что подставлять: {задача} — название работы; {какие_параметры} — то, что может меняться (суммы, сроки, адреса, версии); {что_считается_действием} — операции с последствиями (применённая миграция, отправленное письмо, обновлённый адрес в заказе).
🚀 Быстрый старт — вставь в чат:
Вот шаблон блока передачи состояния. Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, какие параметры у вас меняются по ходу работы и какие действия необратимы. От этого зависят разделы «Актуальные факты» и «Сделано»: именно там метод защищает от устаревших данных и повторных операций.
Ограничения
⚠️ Полная история всё ещё лучше: если вся переписка помещается в окно, передавайте её. Структурный блок выигрывает у хвоста и пересказа при равном объёме, но не у полного текста.
⚠️ Неравномерный эффект: выигрыш зависит от модели. У одной из шести средний результат даже просел, а в операциях с инструментами она потеряла около девяти пунктов. Проверьте блок на своей модели-получателе, а не верьте среднему.
⚠️ Не панацея: даже со структурным блоком получатель полностью выполняет все критерии лишь примерно в половине задач. Когда модели дали эталонное состояние, результат вырос до 85%. Значит, главный резерв в качестве блока, а не только в его наличии.
⚠️ Не вернёт то, чего не было: при поиске нужных файлов в коде абсолютные оценки остаются низкими. Блок помогает вспомнить увиденное, но не заменяет новый поиск.
⚠️ Проверено на ограниченном материале: блок строила одна модель автоматически, а продолжение проверяли на синтетических сценариях. Сравнение с прозой сделано на одной модели. Точный формат блока в доступной части текста не показан.
Как исследовали
Идея была в том, чтобы проверить саму передачу работы, а не только итоговый результат. Авторы собрали 1039 задач двух видов. Первые 300: реальные записи работы агента-программиста в 38 репозиториях, обрыв после десяти шагов, и новая модель должна найти нужные файлы и строки кода. Остальные 739 синтетические: разговор, где часть решений остаётся в силе, а часть фактов обновляется; сервис заказов с уже выполненными операциями; отчёт о ходе работы над файлами. Оценка шла по бинарным критериям: сохранил ли получатель решение, учёл ли новый факт, не повторил ли сделанное.
Шесть моделей-получателей (GPT-5.4, Claude Sonnet 5, DeepSeek V3.2, Qwen 3.5 Plus, Gemini 3.5 Flash Lite, Kimi K2) получали одну и ту же историю. Контекст передавали в трёх видах при одинаковом числе токенов: хвост переписки, пересказ прозой и структурный блок. Такое сравнение убирает «просто дали больше текста».
Результаты. Поиск кода: у GPT-5.4 структурный блок поднял line-F1 с 0.075 до 0.229, и прирост был у всех шести. Он максимален (0.132–0.189), когда нужные файлы уже ушли из хвоста переписки. Продолжение работы у GPT-5.4: средний балл 89.73 (хвост), 87.34 (проза), 92.76 (блок), 94.51 (полная история); полное выполнение всех критериев 44.7 → 42.8 → 52.1 → 57.9%.
Что удивило. Во-первых, проза хуже сырого хвоста. Во-вторых, лидеры разные: Claude и Gemini лучше всех находят код, а GPT-5.4 лучше продолжает работу. В-третьих, выигрыш не совпал по моделям: из 300 задач поиска блок помог хоть одной модели в 231, но всем шести лишь в 91. Для практики это значит: выбор получателя и формат блока нужно тестировать вместе.
Адаптации и экстраполяции
🔧 Техника: автоматическая передача → файл HANDOFF.md по правилу в CLAUDE.md
Вместо того чтобы вспоминать про блок вручную, зафиксируйте правило в инструкциях агента:
Когда контекст заполнен больше чем на 70% или я пишу «передаём»:
запиши в HANDOFF.md блок из разделов Решения / Актуальные_факты /
Сделано / Осталось. В «Актуальных_фактах» оставляй только последние
значения. В начале новой сессии прочитай HANDOFF.md первым.
Это моя адаптация: в исследовании проверялась передача блока, а не правило записи в файл.
Экстраполяция: проверка понимания получателем. В исследовании продолжение проверяли по отчёту о состоянии (что решено, что сделано). Тот же приём можно применить на практике: после вставки блока попросить новую сессию пересказать понимание до начала работы.
Прочитай блок состояния. Прежде чем действовать, перечисли своими словами:
1) какие решения нельзя менять, 2) что уже сделано и не повторяется,
3) какой следующий шаг. Жди моего «да».
Расхождение в пересказе сразу показывает, что блок составлен неточно.
Ресурсы
- Benchmarking Task Takeover Across Agent Handoffs (HSC-Bench, Handoff State Continuity Benchmark)
- Авторы: Wenyuan Li, Guang Li, Dongyuan Li, Keisuke Maeda, Takahiro Ogawa, Miki Haseyama — Hokkaido University, The University of Tokyo
- Связанные работы из статьи: ContextBench, CodeTraceBench, LongMemEval, τ-bench, SWE-bench