Взгляд Anderson
Почему ИИ трудно продолжать незавершённую задачу

Хотя агенты ИИ способны решать сложные задачи, новое исследование указывает, что им трудно продолжать работу, начатую кем-то другим. Это приводит к повторению усилий, замедлению работы и росту затрат.
Одна из самых утомительных, но необходимых сторон работы с агентами ИИ и их интерфейсами — необходимость вводить ИИ в курс дела в начале почти каждого обмена сообщениями.
Хотя популярные языковые модели, такие как ChatGPT, предлагают некоторый доступ к постоянной персонализированной памяти, эта функция работает с переменным успехом. В конечном счёте обычно надёжнее потратить силы на объяснение ИИ контекста задачи*, хотя бы чтобы модель не угадала его неверно на основе своего сформированного при обучении латентного пространства.
Как приходится подхватывать чужую работу на практике
Разумеется, эта проблема возникла раньше ИИ. Многие компании уже требуют от сотрудников вести документацию по процессам, которые те разрабатывают или совершенствуют: отчасти ради более лёгкого введения новых работников в курс дела, но, как можно предположить, и для того, чтобы не усиливалась переговорная позиция сотрудников.
На практике, однако, часто только более крупные и лучше финансируемые организации действительно создают, обновляют и поддерживают документацию. Сотрудникам, которым нужно подхватить чужую работу, вместо этого очень часто достаётся своего рода детективная задача: приходится кропотливо восстанавливать последовательность событий, приведших к незавершённой работе, которую им теперь поручили.
Безупречная документация, несомненно, сэкономила бы дни, недели или даже месяцы работы — если бы только её подготовка была экономически оправданна.
Однако, когда работу выполняют агенты ИИ, возможностей решить эту проблему может оказаться больше.
Передача задачи
Новое исследование из США количественно оценивает бремя отсутствия документации и называет эту проблему долгом передачи.
Если технический долг описывает ситуацию, когда сегодняшние быстрые, временные и дешёвые технические решения в будущем делают системы хрупкими или трудными в сопровождении, то долг передачи определяет стоимость повторного выяснения — тщательного восстановления по оставленным следам шагов работника или другой сущности, которая недоступна для консультаций, например после увольнения в условиях конфликта, из-за занятости или смерти. Она также может быть не способна помочь, как большая языковая модель, давно потерявшая контекст, который привёл к нынешнему состоянию работы.
Новая статья† — совместная работа независимых исследователей и исследователей, связанных с Georgia State University, — рассматривает долг передачи применительно к агентам-программистам, которым нужно продолжить работу в кодовой базе с того места, где остановился другой сеанс, человек или иная сущность.
Одна из целей — установить, сколько документации нужно для уменьшения долга передачи и какие процедуры и протоколы можно рекомендовать как будущую стандартную практику, чтобы свести проблему к минимуму.
Бюджетные ограничения
В идеальном случае можно было бы включить подробное журналирование в режиме verbose и просто передать новому агенту, который подхватывает задачу, журналы незавершённой работы.
Однако извлечение полезной информации из такого объёма данных требует времени, расходует бюджет токенов и может столкнуться с ограничениями места для хранения.
Это является бюджетной проблемой: обработка сырых выгрузок обременительна, тогда как отобранные и упорядоченные журналы менее запутанны, но требуют предварительного выделения ресурсов.
Специально подготовленные заметки очень эффективно ввели бы нового агента в курс дела. Но их составление требует ещё больше усилий, которые могут вовсе не понадобиться, если логика работы в итоге окажется очевидной, работу забросят или больше никогда не будут пересматривать.
Авторы новой работы, озаглавленной Handoff Debt: The Rediscovery Cost When Coding Agents Take Over Interrupted Tasks, рассмотрели все эти сценарии и приспособили существующие модели задач к новым способам количественной оценки долга передачи и работы с ним. Хотя исследование посвящено именно агентам-программистам, оно может указать полезные направления и для более широкого применения ИИ, а также организации политики документирования.
Авторы заявляют:
«Долг передачи возникает, когда агент добивается видимого прогресса, но оставляет состояние, из которого преемнику трудно продолжить работу: необъяснённые изменения, временные рабочие файлы, скрытые предположения или отсутствие свидетельств проверки.
«Метрика, основанная только на окончательном решении задачи, не позволяет отличить дорогостоящее повторное выяснение от эффективного продолжения работы.
«Два предшествующих агента могут оставить одну и ту же контрольную точку репозитория, однако затраты их преемников на продолжение будут сильно различаться: один сможет сразу двигаться дальше, а другому потребуется много взаимодействий с инструментами, чтобы восстановить замысел по временным файлам и неполной истории команд».
Метод
Авторы определяют предшественника как предыдущего агента, который начал работу или выполнял её последним, а преемника как нынешнего агента, которому поручено подхватить работу.
Чтобы построить бенчмарк для измерения стоимости передачи незавершённых задач программной инженерии между агентами, 75 задач из SWE-bench Verified были преобразованы в 181 сценарий передачи, каждый из которых соответствует моменту, когда работу прервали и передали следующему агенту. Затем три разные модели преемников испытали в 2 172 попытках подхватить задачу.
В испытаниях передачи использовали в разных сочетаниях следующие семейства моделей: Qwen, Gemma и Devstral.
Эксперименты рассматривали четыре уровня наследуемой информации. В самом ограниченном варианте преемник получал лишь состояние репозитория, словно попадая в зону бедствия без документации. Другие варианты давали всё более подробный контекст: от записей активности и истории команд до кратких сводок уже испробованных подходов и полученных сведений.
| Только репозиторий
Преемник получает только репозиторий и описание задачи, без записи предыдущих действий, решений или неудачных попыток. |
Необработанный журнал
Преемник получает полную историю предшественника: каждую команду, наблюдение, правку, успех и неудачу. |
| Краткие заметки
Преемник получает сводку на естественном языке, созданную по истории действий предшественника и излагающую ключевую информацию связным текстом. |
Структурированные заметки
Преемник получает компактный документ передачи со стандартными полями, описывающими состояние задачи, внесённые изменения и результаты проверки. |
Исследование было разработано не только для оценки того, решена ли задача в итоге, но и для измерения самой стоимости продолжения работы , с учётом использования инструментов, расхода токенов и усилий, нужных для восстановления рассуждений, лежащих в основе предыдущей работы.
Для экспериментов определили три момента, запускающих передачу и три состояния передачи :
| Момент передачи | Состояние при передаче |
|---|---|
| После первой правки исходного кода. После первой правки кода. Первый агент начал работать, но еще не проверил, работает ли изменение. | Требуется завершение. Задача незавершена, и преемнику необходимо продолжить работу, чтобы достичь правильного решения. |
| После первой проверки. Предыдущий агент уже выполнил тест или проверку, что даёт некоторые сведения о прогрессе. | Уже решено: сохранить результат. Задача фактически завершена, и преемник должен лишь не испортить результат. |
| После первой правки вслед за неудачей. Тест завершился неудачно, и предыдущий агент уже попытался отреагировать, внеся ещё одно изменение. | Нарушена существовавшая функциональность. То, что раньше работало, теперь не работает. |
Данные и испытания
Для создания реалистичных сценариев передачи авторы взяли 75 задач программной инженерии из SWE-bench Verified, сосредоточившись на проблемах, решение которых обычно занимает от 15 минут до 4 часов.
Вместо оценки только завершённых задач исследователи фиксировали несколько промежуточных контрольных точек во время работы, создавая ситуации, в которых один агент ИИ должен подхватить работу другого:

Построение бенчмарка подхвата задач. Из 75 задач SWE-bench Verified получили 181 точку передачи, охватывающую три этапа работы. Их разметили по состоянию репозитория в момент передачи и оценили в четырёх условиях обмена информацией, получив в общей сложности 2 172 запуска, в которых преемник подхватывает задачу. Источник
Поскольку каждая задача могла дать несколько точек передачи, а каждую точку проверяли с четырьмя формами передаваемой информации, бенчмарк быстро вырос. Итоговые данные включали 181 отдельную задачу передачи и 724 оценки подхвата на каждую модель преемника: всего 2 172 запуска в трёх испытанных системах ИИ.
Для испытаний использовали среду агентов-программистов в стиле OpenHands, с действиями в терминале, фиксацией состояния репозитория в точках передачи, редактированием файлов и официальной проверкой SWE-bench.
В основном исследовании все точки передачи получали из запусков, в которых предшественником был Qwen. Это давало неизменную отправную точку для сравнения разных комбинаций агентов и сценариев.
Испытали пары Qwen → Qwen, Qwen → Gemma и Qwen → Devstral.
Необработанный журнал дал наибольшее сокращение усилий преемника: число событий агента уменьшилось на 57–59%, тогда как краткие заметки и структурированные заметки сократили число событий на 20–46%. Расход входных токенов также снизился во всех трёх подходах, на 42–63%:
| Условие | Запуски | Доля решённых задач (Δ п.п.) | События агентов (Δ%) | Входные токены (Δ%) |
|---|---|---|---|---|
| Qwen → Qwen | ||||
| Только репозиторий | 181 | 46,4% | 99 | 1,63 млн |
| Необработанный журнал | 181 | 52,5% (+6,1 п.п.) | 41 (-59%) | 811 тыс. (-50%) |
| Краткие заметки | 181 | 51,4% (+5,0 п.п.) | 53 (-46%) | 602 тыс. (-63%) |
| Структурированные заметки | 181 | 50,8% (+4,4 п.п.) | 55 (-44%) | 660 тыс. (-60%) |
| Qwen → Gemma | ||||
| Только репозиторий | 181 | 42,5% | 49 | 738 тыс. |
| Необработанный журнал | 181 | 49,2% (+6,6 п.п.) | 21 (-57%) | 300 тыс. (-59%) |
| Краткие заметки | 181 | 44,2% (+1,7 п.п.) | 33 (-33%) | 319 тыс. (-57%) |
| Структурированные заметки | 181 | 43,6% (+1,1 п.п.) | 39 (-20%) | 317 тыс. (-57%) |
| Qwen → Devstral | ||||
| Только репозиторий | 181 | 34,3% | 175 | 3,94 млн |
| Необработанный журнал | 181 | 49,2% (+14,9 п.п.) | 73 (-58%) | 1,66 млн (-58%) |
| Краткие заметки | 181 | 43,6% (+9,4 п.п.) | 123 (-30%) | 2,30 млн (-42%) |
| Структурированные заметки | 181 | 44,8% (+10,5 п.п.) | 125 (-29%) | 2,30 млн (-42%) |
При передаче только репозитория преемникам требовались дополнительные взаимодействия, чтобы восстановить замысел предшественника, прежние свидетельства и неудачные подходы. Необработанный журнал, краткие заметки и структурированные заметки передавали часть сведений напрямую, снижая необходимость повторного выяснения, хотя для этого требовались более длинные начальные промпты.
Чтобы проверить, реальны ли преимущества, каждую передачу с более полным контекстом сопоставили с передачей только репозитория, начинающейся с той же точки. Во всех парах моделей более полный контекст последовательно сокращал объём работы преемников.
Полные журналы событий давали наибольшее сокращение затрат, но краткие и структурированные заметки тоже обеспечивали значительную экономию. Эффект наблюдался во всём бенчмарке и не объяснялся несколькими необычными случаями:
| Условие | Сопоставленные запуски | События агента при передаче только репозитория | События агентов (Δ%) | 95% ДИ для Δ событий | Входные токены (Δ%) |
|---|---|---|---|---|---|
| Qwen → Qwen | |||||
| Необработанный журнал | 181 | 99 | 41 (-59%) | [-50%, -42%] | 798 тыс. (-51%) |
| Краткие заметки | 181 | 99 | 53 (-46%) | [-38%, -28%] | 572 тыс. (-65%) |
| Структурированные заметки | 181 | 99 | 55 (-44%) | [-34%, -24%] | 646 тыс. (-60%) |
| Qwen → Gemma | |||||
| Необработанный журнал | 181 | 49 | 21 (-57%) | [-47%, -33%] | 300 тыс. (-59%) |
| Краткие заметки | 181 | 49 | 33 (-33%) | [-25%, -8%] | 319 тыс. (-57%) |
| Структурированные заметки | 181 | 49 | 39 (-20%) | [-18%, -1%] | 317 тыс. (-57%) |
| Qwen → Devstral | |||||
| Необработанный журнал | 181 | 175 | 73 (-58%) | [-45%, -22%] | 1,65 млн (-58%) |
| Краткие заметки | 181 | 175 | 123 (-30%) | [-28%, -15%] | 2,28 млн (-42%) |
| Структурированные заметки | 181 | 175 | 125 (-29%) | [-28%, -17%] | 2,29 млн (-42%) |
Чтобы подтвердить, что эффект не объясняется несколькими необычными случаями, исследователи сравнили каждую передачу с передачей только репозитория, начинающейся с той же точки. Сокращение затрат оставалось устойчивым во всех парах моделей, что указывает на значимую закономерность, а не несколько исключительных примеров.
Главный вывод…
Вкратце†, авторы обнаружили, что, когда один агент ИИ передаёт задачу другому, даже простые заметки помогают второму эффективнее продолжить работу.
Лучше всего действуют полные записи событий, но любая информация при передаче предпочтительнее ситуации, когда преемник должен восстановить всё только по коду. Приведённые результаты также показывают, что использование полного необработанного журнала неизбежно обходится дороже по токенам.
Заключение
Хотя сама статья рассчитана исключительно на коллег-исследователей и мало привлекает обычного читателя, новая работа затрагивает одну из самых интересных и насущных проблем нынешних интерфейсов и протоколов взаимодействия человека с ИИ.
Хочется надеяться, что подходы и выводы таких исследований в итоге можно будет распространить на более широкие области применения ИИ, а не только на программирование агентами.
Ещё одно направление будущих исследований — оценивать минимальный объём документации для конкретного проекта на основе его особенностей и назначения. Однако даже функция, которая помогла бы рациональнее расходовать время и деньги, сама требует времени и денег. Поэтому бюджетную дилемму документирования по-прежнему трудно обойти.
* Лично я для сессий ChatGPT, которые замедляются из-за задержек и избытка контекста, в последнее время стал экспортировать, хотя и с некоторым трудом, чистый PDF разговора и использовать его как отправную точку новой сессии, которая становится «частью 2».
† К сожалению, это не самая доступная для понимания статья, которую я прочитал в этом году. Поэтому я не могу посоветовать читателю обратиться к исходной работе, хотя её результаты в более понятном изложении остаются интересными.
Впервые опубликовано в среду, 3 июня 2026 года












