Сжатие контекста, или compaction, помогает продолжать длинную AI-сессию после приближения к лимиту контекстного окна. Модель получает короткое резюме вместо части истории диалога и экономит место для новых сообщений, файлов и результатов инструментов. Цена такой экономии зависит от качества сводки: если в ней пропущены ограничения, причины решений или незавершенные действия, следующие шаги могут пойти по неверной траектории.
Полную историю лучше сохранить, когда ошибка дорого стоит, задача состоит из множества связанных шагов, а важные детали нельзя надежно восстановить из файлов, логов или задач. Автоматическая компактация подходит для длинных сессий с умеренным риском, особенно если состояние работы регулярно записывается во внешние артефакты. Ручная сводка дает больше контроля там, где критичны точность и понимание причин.
Материалы, доступные для этого разбора, подтверждают общую проблему потери и восстановления контекста. Они не доказывают, что compaction всегда или системно стал работать хуже. Конкретный результат зависит от модели, алгоритма суммирования, структуры рабочего процесса и того, что именно сохраняется за пределами истории диалога.
Короткий ответ: compaction экономит контекст, но может потерять смысл работы
Автоматическая компактация заменяет часть сообщений более коротким представлением. В идеальном случае резюме сохраняет цель, ограничения, решения, текущий статус, результаты проверок и следующий шаг. На практике сводка может передать тему разговора, но потерять связи между фактами и условия, при которых эти факты имеют смысл.
Для простой задачи потеря нескольких промежуточных формулировок почти не заметна. Для кодовой или агентной цепочки она способна привести к повторным вопросам, изменению уже проверенного файла, возврату к отвергнутой гипотезе или нарушению ограничения, которое осталось только в старой части диалога.
Когда полную историю лучше не сворачивать
- Изменяются несколько связанных файлов, а ошибка в одном интерфейсе может вызвать регрессию в другом.
- Идет отладка редкого состояния, которое трудно воспроизвести после сброса контекста.
- Решение принималось через длинную цепочку гипотез и проверок, где важно помнить, какие варианты уже исключены.
- В задаче есть неявные ограничения: нельзя менять конкретный модуль, требуется обратная совместимость, допустим только определенный формат ответа или патча.
- Цена ошибки выше экономии времени, например при изменении конфигурации, миграции данных или подготовке критичного кода.
В этих сценариях полный контекст снижает риск потери деталей, если история остается достаточно компактной и в ней нет большого количества устаревшего шума. При переполненной сессии сохранение всех сообщений тоже не гарантирует правильное продолжение: модели придется выделять актуальное состояние среди повторов, промежуточных вариантов и старых требований.
Что именно может исчезнуть из краткого резюме
Потеря касается нескольких типов информации:
- точной формулировки требования;
- причины, по которой выбран один вариант и отвергнут другой;
- порядка действий, уже выполненных пользователем или агентом;
- связи ограничения с конкретным файлом, функцией или конфигурацией;
- результата команды, теста или вызова инструмента;
- условия, при котором найденное решение считается корректным;
- незавершенного действия, которое нельзя повторять вслепую;
- открытого риска, еще не проверенного в текущем состоянии проекта.
Краткое резюме может сообщить: «ошибка исправлена в модуле авторизации». Для следующего шага этого мало. Нужны сведения о том, какая ошибка возникала, какой файл изменен, какой тест подтвердил исправление, какие сценарии еще не проверены и почему альтернативный подход признали неподходящим.
Контекст, память и база знаний: три разных уровня
Контекст, память и база знаний часто смешиваются в одно понятие, хотя выполняют разные функции. Контекст описывает текущее состояние работы. Память хранит отдельные факты или предпочтения, которые могут пригодиться позднее. База знаний содержит документы, код, логи, задачи и другие внешние материалы.
Эти уровни дополняют друг друга, но не образуют полную копию истории. Документ может сохранить решение, однако не объяснить ход обсуждения. Память может содержать предпочтение пользователя, но не помнить последовательность команд. Таск-трекер может показать итоговую задачу, но пропустить временную гипотезу, которую уже проверили.
Контекст как состояние текущей работы
Оперативный контекст отвечает на вопрос: что нужно учитывать прямо сейчас, чтобы выполнить следующий шаг. В него входят:
- цель задачи и критерии готовности;
- ограничения и запреты;
- принятые решения и их причины;
- измененные файлы, сущности и параметры;
- результаты команд, тестов и инструментов;
- открытые вопросы и нерешенные риски;
- следующее действие, которое еще предстоит проверить.
В рабочей среде информация часто распределена между созвонами, мессенджерами, почтой, задачами и документами. После нескольких обсуждений человек может помнить общую тему, но потерять конкретные договоренности. Первые минуты следующей синхронизации тогда уходят на восстановление состояния. AI-цепочка сталкивается с той же проблемой, если ее актуальное состояние осталось только в длинной истории сообщений.
Память не заменяет историю диалога
Память обычно хранит обобщенный факт: выбранный стек, предпочтительный формат ответа, название проекта или долгосрочное правило. История диалога содержит последовательность действий и реакций на их результаты.
Разница видна на простом примере. Память может сообщать, что проект использует PostgreSQL. История объясняет, почему в конкретной миграции отказались от определенного типа индекса, какая версия схемы уже применена и какой тест обнаружил побочный эффект. Первый факт полезен, но не восстанавливает вторую часть задачи.
Поэтому наличие функции памяти не означает, что модель вернет все детали после compaction. Перед продолжением нужно проверить, какие сведения действительно сохранены, а какие остались только в старых сообщениях.
База знаний хранит материалы, но не всегда ход решения
Внешняя база знаний помогает восстановить объективное состояние, если туда попали нужные материалы. Источниками могут быть исходный код, документация, конфигурация, логи, тесты, история изменений и записи в таск-трекере.
Эти артефакты особенно полезны для проверки фактов. По коду можно узнать текущую реализацию, по логу, результат операции, по истории изменений, какие строки уже менялись, по задаче, какие критерии готовности зафиксированы. История обсуждения при этом может оставаться неполной.
Если причина решения, отклоненная гипотеза или устная договоренность нигде не записаны, новый вызов инструмента их не восстановит. Он покажет текущее состояние, но не обязательно объяснит, почему оно должно оставаться именно таким.
Почему сжатие контекста ухудшает результат в многошаговой цепочке
Многошаговая цепочка зависит от состояния, сформированного предыдущими шагами. После compaction резюме становится входом для следующего вызова. Если в нем есть пропуск, следующий шаг может принять его за факт. Ошибка затем распространяется по цепочке и начинает влиять на действия, проверки и новые решения.
Потеря факта и потеря связи между фактами
Отдельные пункты не всегда сохраняют рабочий смысл. Представим условную задачу: файл parser.py нельзя менять из-за обратной совместимости, а исправление нужно внести в адаптер. Сводка может сохранить оба факта, но потерять связь между запретом и конкретным способом исправления. Следующий вызов тогда изменит запрещенный файл, хотя формально «знает» и о файле, и об ограничении.
Такая потеря связи опаснее пропуска одного факта. Модель продолжает работать с неполной картиной зависимостей. Список требований превращается в набор разрозненных заметок, которые нельзя правильно применить к следующему действию.
Накопление ошибок после повторных вызовов
В агентном пайплайне модель может несколько раз читать файлы, вызывать инструменты, исправлять код и запускать проверки. Каждый вызов опирается на доступное состояние. Если результаты команд или ошибки инструментов не попали в резюме и не сохранились снаружи, следующая итерация начинает восстановление почти с нуля.
Последствия бывают практическими:
- агент повторяет уже выполненную команду;
- возвращается к гипотезе, которую ранее опровергли;
- считает незавершенное действие выполненным;
- исправляет симптом, который уже исчез после другой правки;
- пропускает ошибку инструмента и строит план на несуществующем результате.
Один пропуск не обязательно ломает всю сессию. Риск растет, когда сокращенное состояние используется много раз подряд без сверки с реальными файлами, логами и тестами.
Почему кодовые задачи особенно чувствительны
Кодовая база хранит множество связей, которые не видны в кратком описании: интерфейсы между модулями, соглашения об именах, порядок инициализации, временные обходы, особенности окружения и ограничения по совместимости.
Для отладки полезна цепочка «наблюдение, гипотеза, проверка, изменение, результат». Если резюме оставляет только финальную правку, агент может забыть, что именно проверялось и почему другие варианты исключили. Тогда следующая попытка повторяет старую ошибку или расширяет изменение без достаточных оснований.
При работе с кодом сводка должна описывать состояние репозитория, а не только тему задачи. Нужны измененные файлы, результаты тестов, команды с ошибками, известные ограничения и список открытых рисков. Практика ревью остается обязательной: быстрый патч не подтверждает корректность логики, безопасности и поведения в runtime. Подход к проверке AI-кода разобран в статье о рисках слепого доверия к AI-агенту.
Когда модель может восстановить забытое через инструменты
Инструменты делают потерю контекста частично обратимой. Модель может заново прочитать файл, выполнить тест, изучить лог или посмотреть историю изменений. Это возвращает факты о текущем состоянии системы и иногда позволяет восстановить ход работы.
Восстановление требует двух условий: нужная информация должна сохраниться во внешнем артефакте, а агент должен знать, где ее искать. Сам факт наличия инструментов не гарантирует ни одного из этих условий.
Внешние артефакты как опора для восстановления
Источники истины удобно разделить по типу информации:
| Артефакт | Что помогает восстановить | Что может отсутствовать |
|---|---|---|
| Исходный код | Текущее поведение, интерфейсы, зависимости | Причины предыдущих решений и отвергнутые варианты |
| Тесты | Проверяемые сценарии и ожидаемые результаты | Непокрытые условия и смысл временных проверок |
| Логи | Фактические ошибки, события и порядок операций | Намерения пользователя и интерпретацию результата |
| История изменений | Файлы и строки, которые менялись | Полный контекст обсуждения |
| Таск-трекер | Цель, требования, статус и критерии готовности | Неформальные договоренности и промежуточные гипотезы |
| Документация | Правила, архитектурные решения и ограничения | Актуальность, если документ давно не обновлялся |
Для больших агентных процессов полезно сохранять результаты не в одном общем тексте, а в понятных артефактах: задаче, журнале проверок, файле состояния или истории изменений. Тогда новый вызов может сверить резюме с несколькими независимыми признаками.
При сборе материалов в базу знаний отдельную пользу дает фиксация происхождения факта, его актуальности и связи с исходным документом. Практические проблемы такой работы, включая дедупликацию и проверку чисел, разобраны в материале о сборке базы знаний с помощью AI-агентов.
Что нельзя надежно восстановить новым вызовом
Новый вызов может вернуть состояние файла, но не обязательно вернет:
- намерение, которое пользователь не записал явно;
- устную или неформальную договоренность;
- приоритет между конфликтующими требованиями;
- причину отказа от рабочего на вид варианта;
- порядок рассуждений, если он не отражен в изменениях и логах;
- понимание того, какой риск команда сознательно приняла.
Это ограничение нельзя считать абсолютным для всех моделей и систем. Хорошая сводка или подробные внешние записи могут сохранить нужную информацию. Но если сведения нигде не зафиксированы, повторный вызов инструмента даст факты, а не утраченную интерпретацию.
Где автоматическая компактация особенно рискованна
Риск определяется характером работы, а не длиной диалога сама по себе. Короткая сессия с несколькими жесткими ограничениями может требовать большей точности, чем длинное обсуждение простого текста.
Длинная отладка и изменение кодовой базы
При отладке нужно сохранять наблюдение, гипотезу, проверку, изменение и результат. Если модель помнит лишь последний успешный шаг, она не знает, какие причины уже проверены. Сжатие может привести к циклическому поиску или к расширению правки без подтверждения.
Перед compaction полезно зафиксировать список измененных файлов, команды, результаты тестов и известные регрессии. Отдельно нужно указать, какие части системы запрещено менять. Для оценки кодовых агентов лучше учитывать успешное завершение задачи, число исправлений и стабильность результата, а не одну скорость генерации. Методика компактной проверки таких инструментов описана в статье о практической оценке coding agents.
Агентные сценарии с несколькими инструментами
Агентный пайплайн может одновременно иметь план, фактическое состояние файлов, результаты команд, ошибки доступа и незавершенные операции. Эти слои способны расходиться. Например, план предполагает изменение конфигурации, но вызов инструмента завершился ошибкой, а сводка сохранила только первоначальное намерение.
Сводка для такой работы должна включать вызовы инструментов, их результаты, ошибки, побочные изменения и статус каждого действия. Фраза «агент обновил конфигурацию» недостаточна, если неизвестно, применилось ли изменение и прошла ли проверка.
Задачи с большим числом ограничений
Один пропущенный запрет может сделать результат неприемлемым. Типичные категории ограничений:
- формат и схема итогового ответа;
- совместимость с конкретной версией API;
- запрет на изменение части системы;
- обратная совместимость данных или поведения;
- критерии готовности и обязательные проверки;
- ограничения по безопасности, доступам или публикации данных.
Иллюстрация: если задача требует сохранить публичный интерфейс и изменить только внутреннюю реализацию, сводка должна связать эти два условия. Простого перечня «API сохранен» и «изменен модуль» недостаточно, если не указано, какой модуль допустим и каким тестом проверяется совместимость.
Полный контекст, ручная сводка или compaction: что выбрать
Выбор зависит от пяти параметров: цены ошибки, длины сессии, доступности внешних источников, чувствительности задачи к деталям и возможности проверить итог. Универсального режима для всех AI-сессий нет.
| Подход | Когда подходит | Основной риск |
|---|---|---|
| Полная история | Высокая цена ошибки, мало шума, важны формулировки и последовательность решений | Переполнение окна, повторения и сложность выделения актуального состояния |
| Ручная сводка | Нужен контроль над решениями, ограничениями и открытыми вопросами | Автор может забыть пункт или описать его двусмысленно |
| Автоматическая компактация | Длинная сессия, умеренный риск, есть файлы, логи и тесты для сверки | Потеря связей, причин решений и незавершенных действий |
Полная история: максимум деталей и растущая нагрузка
Полный контекст сохраняет формулировки, порядок обсуждения и промежуточные результаты. Он оправдан, когда деталь трудно восстановить, а неверный шаг может повлечь значительные переделки.
У этого подхода есть издержки. В длинной истории накапливаются повторы, устаревшие требования, неиспользованные варианты и сообщения, которые отвлекают от текущего состояния. Модель может увидеть нужный факт, но применить старую версию требования. Поэтому полная история не отменяет структурированную фиксацию актуального статуса.
Ручная сводка: больше контроля над смыслом
Хорошая ручная сводка похожа на короткий журнал состояния:
- Цель и критерии готовности.
- Подтвержденные требования и запреты.
- Принятые решения с причинами.
- Измененные файлы, функции, документы или записи.
- Результаты тестов, команд и проверок.
- Ошибки и уже исключенные гипотезы.
- Открытые вопросы и оставшиеся риски.
- Следующий проверяемый шаг.
- Источники истины, с которыми нужно свериться.
Факты, гипотезы и устаревшие пункты нужно разделять. Запись «кэш, вероятно, вызывает ошибку» не должна выглядеть как установленная причина. Такая дисциплина занимает несколько минут, зато снижает двусмысленность при продолжении сессии.
Автоматическая компактация: удобство с контролем риска
Автоматическая компактация полезна, когда история уже мешает продолжению, а задача допускает проверку через внешнее состояние. После сжатия модель должна заново прочитать ключевые файлы, проверить текущие логи, сверить критерии готовности и подтвердить статус незавершенных действий.
Для локального стека и IDE-ассистента принцип одинаков: не считать краткое резюме единственным источником истины. Конкретные механизмы хранения контекста, памяти и результатов инструментов зависят от продукта, модели и настроек. Их нужно проверять в рабочем сценарии, а не переносить выводы одного инструмента на другой.
Практический протокол для длинной AI-сессии
Надежность длинной сессии растет, когда состояние задачи регулярно выходит из истории диалога и попадает в проверяемые артефакты.
Что записывать перед компактацией
- Цель: какой результат должен быть получен.
- Статус: что завершено, что выполняется, что заблокировано.
- Решения: какой вариант выбран и по какой причине.
- Изменения: какие файлы, сущности или настройки затронуты.
- Проверки: какие команды и тесты выполнены, с каким результатом.
- Ошибки: какие сбои возникли и что они исключают.
- Ограничения: что нельзя менять и какие условия обязательны.
- Следующий шаг: одно ближайшее действие, которое можно проверить.
Для кодовой задачи полезно приложить краткий статус репозитория и список файлов с изменениями. Для исследовательской цепочки, перечень проверенных материалов и нерешенных вопросов. Для автоматизации, состояние каждого вызова инструмента и его фактический результат.
Как проверить, что сводка сохранила рабочее состояние
Перед новым действием попросите модель восстановить задачу в структурированном виде:
- что уже сделано;
- что осталось незавершенным;
- почему выбран текущий вариант;
- какие варианты уже исключены;
- какие файлы, логи или документы нужно проверить;
- каким будет следующий шаг и как проверить его результат.
Уверенный пересказ не доказывает корректность. Его нужно сопоставить с внешним состоянием. Если модель утверждает, что тест прошел, проверьте журнал. Если она называет файл измененным, изучите актуальный diff. Если сводка содержит требование, найдите его в задаче или исходной спецификации.
Контрольный вопрос должен выявлять пропуски, а не подсказывать желаемый ответ. Например: «Какие ограничения влияют на выбор файла для изменения?» полезнее, чем «Ты помнишь, что нельзя менять публичный API?»
Когда лучше начать новую сессию
Новая сессия предпочтительнее, когда история стала противоречивой, цель изменилась, накопилось много устаревших предположений или есть надежный внешний документ с актуальным состоянием.
Перед стартом перенесите проверенные факты, обязательные ограничения, текущий статус, открытые риски и ближайший шаг. Не переносите все старые сообщения автоматически: они могут содержать ошибочные гипотезы, временные решения и требования, которые больше не действуют.
Чистый старт особенно полезен при смене задачи внутри одного проекта. Старая цепочка продолжает влиять на ответы, даже если пользователь уже мысленно перешел к другому вопросу. Разделение сессий снижает вероятность смешать цели и критерии готовности.
Вывод: compaction, инструмент управления риском, а не обязательный режим
Сжатие контекста помогает продолжать длинную работу в пределах лимита, но краткое резюме не равно полной истории. Оно может сохранить тему и основные факты, потеряв причины решений, связи между ограничениями, результаты промежуточных проверок и незавершенные действия.
Полный контекст выбирайте при высокой цене ошибки и небольшом количестве шума. Ручную сводку используйте, когда нужно точно передать смысл, статус и ограничения. Автоматическая компактация подходит для длинных задач, если внешние артефакты регулярно обновляются, а новое состояние можно проверить через код, логи, тесты, документы и задачи.
Контекст, память и база знаний выполняют разные функции. Новый вызов инструмента способен вернуть факт, который сохранился в файле или логе, но не всегда восстановит утраченное намерение или причину выбора. Качество результата определяется конкретной реализацией compaction, моделью и процессом работы, поэтому универсальное утверждение о деградации сжатия требует отдельного тестирования.
Для практической оценки сравнивайте три режима на одинаковых задачах и фиксируйте число повторных вопросов, ошибочных изменений, возвратов к исключенным гипотезам, успешных проверок и времени до корректного результата. Сравнение coding agents по типу задачи, контексту и числу итераций разобрано в материале о выборе coding agent под конкретную работу.