CtxGap: сколько из того, что знает кодинг-агент, доходит до вас в отчётах

В статье нет одного «метода». Это измерение плюс набор проверенных вмешательств. Из них складывается практическая процедура:

ШАГ 1: Не доверять «готово» → отчёт считается неполным по умолчанию
ШАГ 2: Попросить отчёт по категориям (провалы, обходы, риски, решения, среда)
        → каждый пункт с доказательством: файл / команда / результат
ШАГ 3: Перед приёмкой — прямые вопросы агенту по ходу работы
        (он отвечает точнее, чем пишет в отчётах)

Шаги 2 и 3 делаются в том же чате или сессии, пока агент «помнит» работу.

Задача: Вы владелец небольшого интернет-магазина на Django и поручили Claude Code подключить оплату через ЮKassa. Агент отчитался: «Интеграция готова, тесты проходят». Вы собираетесь выкатывать на прод и хотите понять, что осталось «под ковром».

Промпт:

Прежде чем я приму работу, дай подробный отчёт по сессии.
Разбей его на разделы:

1. ПРОВАЛЫ: что пробовал и не сработало (команда/файл, что произошло, почему отказался от подхода)
2. ОБХОДНЫЕ ПУТИ: где отступил от задачи или сделал "в обход" (что именно, почему, чем это грозит)
3. НЕРЕШЁННЫЕ РИСКИ: что может сломаться на проде (условие, при котором ломается, что видел в логах)
4. ПРОВЕРКИ: какие тесты и скрипты запускал или писал (имя файла, что проверяет, результат)
5. ОКРУЖЕНИЕ: что менял в конфигах, переменных окружения, зависимостях

Правила:
- Не пиши "добавил тест" или "учёл риск". Пиши, какой именно тест, что он проверяет, чем закончился.
- Если в разделе ничего не было, напиши "не было". Не пропускай раздел.
- Каждый пункт подкрепи конкретикой: имя файла, команда, текст ошибки.

Результат: Модель выдаст отчёт из пяти разделов. В нём будут конкретные файлы, команды и условия, в которых что-то может сломаться. Скорее всего, всплывут вещи, которых не было в коротком «готово»: отброшенные подходы, временные заглушки, непокрытые случаи. Если раздел пуст, модель так и напишет, и вы увидите это явно.

Слабость. Агент пишет отчёты «для человека»: коротко, про итог и про главное. Провалы, обходы и сомнения в такой формат не попадают. Часть событий упоминается одной фразой без деталей. Читатель отчёта не может восстановить, что именно произошло.

Сильная сторона. Контекст сессии у агента перед глазами, и на прямой вопрос он отвечает почти безошибочно. Значит, информация есть, не хватает только форматов и запросов, которые её вытащат.

Как это обходится. Структура отчёта по категориям заставляет агента заглянуть туда, куда он по умолчанию не смотрит. Требование «доказательство к каждому пункту» не даёт отделаться упоминанием. В исследовании простое добавление упоминания не дало вообще никакого прироста. Прирост дали только конкретные детали.

Рычаги управления: - Категории — убирайте ненужные и добавляйте свои (безопасность, производительность, совместимость). В статье самый большой вклад в потерю дали факты, провалы и прогресс, затем состояние окружения. - Требование доказательств — главный рычаг. Без него агент снова отпишется общими словами. - Длина — при той же общей длине переписанный с учётом полного контекста отчёт информативнее. Дело в содержании, а не в объёме. - «Если не было — напиши "не было"» — отличает «ничего не случилось» от «забыл упомянуть».

Два варианта: разовый запрос в конце сессии и постоянное правило в файле инструкций агента (CLAUDE.md, AGENTS.md).

Вариант 1. Запрос отчёта перед приёмкой:

Дай подробный отчёт по сессии по разделам:

1. ПРОВАЛЫ: {что пробовал и не сработало}
2. ОБХОДНЫЕ ПУТИ: {где отступил от задачи или сделал "в обход"}
3. НЕРЕШЁННЫЕ РИСКИ: {что может сломаться и при каких условиях}
4. ПРОВЕРКИ: {какие тесты и скрипты запускал; что проверяет каждый; результат}
5. {свой раздел}: {например, изменения в конфигах и зависимостях}

Правила:
- Не пиши общими словами ("добавил тест", "учёл риск"). Пиши конкретно: имя файла, команда, текст ошибки, результат.
- Пустой раздел не пропускай: пиши "не было".
- Если не уверен в факте, пометь "не уверен" и объясни почему.

Вариант 2. Постоянное правило для файла инструкций агента:

## Правила отчётности
Когда сообщаешь о завершении задачи или этапа:
- Не ограничивайся фразой "готово". Приведи разделы: Провалы, Обходные пути, Нерешённые риски, Проверки, Изменения в окружении.
- Каждое событие описывай с подтверждением: файл, команда, результат.
- Упоминание без деталей считается неполным отчётом.
- Если в разделе ничего не было, напиши "не было".
- Не сообщай об успехе, если остались нерешённые риски. Перечисли их.

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

⚠️ Это сборка по выводам статьи. Точные формулировки промптов, которыми авторы проверяли «структурированные» и «целевые» дополнения, в тексте не приведены.

⚠️ Основная цифра — не про все задачи: Измеряли на задачах SWE-bench (исправление багов в открытых репозиториях, в основном Django-подобные проекты). Как это выглядит на других типах работы, напрямую не проверяли.

⚠️ Детали отчёта — не панацея: Переписанные отчёты улучшают восстановление информации, но разрыв остаётся. Даже полный вывод терминала не доводит читателя до уровня полного контекста.

⚠️ Цена деталей: Самые информативные «целевые» дополнения были заметно длиннее. Читать такой отчёт дольше, и это отдельный компромисс.

⚠️ Особый формат не дал преимущества: При одинаковой общей длине «целевой» отчёт (под нужные категории) не показал значимого преимущества над обычным «естественным» переписыванием. Главное — сама детализация и опора на полный контекст, а не хитрый формат.

⚠️ Не все пропавшие факты важны: Вопросы формировала модель, а не человек-надзиратель. Для проверки «важности» тоже использовали модели. Разрыв сохранялся и на отобранных как важные, но измерение остаётся модельным.

⚠️ Детали отчёта не равны правде: Исследование измеряет, сколько информации можно восстановить из отчёта. Оно не проверяет, говорит ли агент правду. Подробный отчёт тоже нужно перепроверять.

Идея простая: если агент знает всё, а в отчёте пишет часть, давайте измерим, какая именно часть теряется. Исследователи взяли 37 задач из SWE-bench Verified, по одной сессии на задачу, и остановили каждую сессию в нескольких точках. Из лога достали «атомы» (отдельные факты: провал, прогресс, риск, решение). По каждому атому составили вопрос с эталонным ответом.

Потом одну и ту же модель-«наблюдателя» просили ответить на эти вопросы по-разному. Первый вариант: только отчёты и инструкции пользователя. Второй: полный терминал. Третий: весь контекст с рассуждениями. Отдельный судья ставил оценки. В итоге набралось около 4800 вопросов.

Результаты: из полного контекста восстанавливается 92,7%, из отчётов только 52,0%. Полный терминал даёт 73,6%. Сам агент при прямом вопросе отвечает правильно в 93,6% случаев. Разрыв сохраняется даже после успешных исправлений (где тесты прошли): на финальных точках 30 задач он остался около 35 пунктов.

Самое интересное началось с ручной разметки. Два человека разбирали, почему информация не восстановилась. Оказалось, что чаще всего факт в отчёте упомянут, но недостаточно подробно (55–59%), и лишь около трети–две пятых случаев — «вообще не упомянут». Проверили и гипотезу «просто допишем упоминание»: прироста ноль. А вот добавление подтверждающих деталей подняло восстановление на 19 пунктов.

Переписанные с учётом полного контекста отчёты при той же общей длине дали примерно +8 пунктов. Для фактов, которые нельзя вывести из остального текста, прирост самый большой: у обычных дополнений около 0,02–0,03, у структурированных 0,28, у «целевых» по категориям 0,60 (но они длиннее).

Результат проверили на трёх обвязках агентов (Claude Code, Pi, DSH), на независимо запущенной модели DeepSeek и на полностью отдельной цепочке измерений. Разрыв воспроизводился везде. Для практики вывод такой: проблема не в одной модели и не в одном инструменте.

🔧 Техника: прямые вопросы вместо чтения отчёта → получить то, о чём агент молчит

Раз агент хорошо отвечает на прямые вопросы, добавьте перед приёмкой короткий допрос:

Copy

Ответь на вопросы по этой сессии честно и конкретно:
1. Какие подходы ты пробовал и отбросил, и почему?
2. Где ты отошёл от моего исходного задания?
3. Что в решении держится на допущении, которое ты не проверил?
4. Что сломается первым, если нагрузка или данные будут не такими, как в тестах?
5. Какие файлы ты менял, которые я не просил менять?

Экстраполяция (не из статьи): проверка отчёта свежим читателем

Идея повторяет логику исследования в облегчённом виде. Откройте новый чат без контекста и дайте ему только отчёт агента.

Copy

Вот отчёт агента о работе: {отчёт}.
Ты ничего не знаешь о ходе работы кроме этого текста.
Задай пять вопросов, на которые из отчёта ответить невозможно, но ответы нужны,
чтобы принять решение о выкатке.

Эти вопросы передайте исходному агенту. Это проверка того, насколько отчёт самодостаточен. В статье такой процедуры нет, её нужно проверять на своих задачах.

• Работа: What Coding Agents Leave Unsaid: Measuring Task-State Gaps Between Execution and Reports (CtxGap)
• Авторы: Guoyang Xu, Rui Zhang, Xiuyu Wu, Hao Chen — Tencent
• Код и бенчмарк: https://github.com/Kaguraaaaaa/Ctxgap
• Упомянутые среды и данные: SWE-bench Verified, Claude Code, Pi, DSH (DeepSeek)