Проблема не в промпте: как Claude Code плывет на длинных задачах и как управлять контекстом

На коротких задачах coding-агент выглядит почти как живой разработчик: читает код, гоняет тесты, находит проблему, предлагает diff, но на длинной дистанции магия заканчивается. Стоит агенту или пользователю подмешать еще пару логов, несколько файлов "на всякий случай" или еще один MCP-сервер, и агент начинает забывать договоренности, повторять уже проверенные шаги и терять план.

Обычно это объясняют так: "модель тупит" или "надо лучше промптить", но на практике проблема часто в другом: мы складируем состояние задачи в историю чата и надеемся, что модель удержит его сама. Не удержит.

Контекст у LLM - это не бездонный мешок, а рабочая часть "памяти" модели, ее нужно проектировать: что хранить отдельно, что подмешивать just-in-time, что выбрасывать после шага и что обязательно возвращать после compaction.

В этой статье я разберу context engineering на примере coding agents, а конкретно на Claude Code: почему long context до сих пор деградирует, почему проблема особенно больно бьет по агентам, чем полезны /compact и Plan Mode, и как собрать минимальный контекстный конвейер без магии и лишней философии.

Для кого эта статья

Этот текст будет полезен, если вы:

• уже используете Claude Code, Cursor, Copilot Chat, OpenCode или похожие инструменты;

• пробовали давать агенту задачи длиннее, чем "сделай маленький diff";

• замечали, что после 10-20 шагов агент начинает "плыть";

• хотите не еще один магический промпт, а инженерный минимум: артефакты, правила, хуки и политику управления контекстом.

Ниже примеры будут в основном на Claude Code, но сама проблема шире одного продукта: похожие эффекты возникают у большинства coding-агентов, которые живут в одной длинной сессии, читают код, запускают команды и накапливают историю действий.

Long context: о чем мы вообще говорим

Дальше я опираюсь на исследования long context, работы про coding-агентов и документацию Claude Code. Это разные типы источников: часть работ 2025-2026 годов пока существует как свежие preprint'ы, а docs описывают механику конкретного продукта. Но вывод у них общий: длинная агентная сессия деградирует не потому, что вы "неправильно написали промпт", а потому что рабочая память модели ограничена.

Поэтому контекст в такой задаче - это не вся история чата, а только то, что модель получает для следующего шага. Вопрос не в том, как поместить в окно побольше, а в том, как положить туда нужное.

Чтобы дальше не путаться в терминах, удобно зафиксировать четыре понятия:

• Рабочий контекст (working context) - то, что модель реально видит прямо сейчас и использует для следующего шага.

• Устойчивое состояние (durable state) - то, что должно переживать compaction, длинную паузу, новую сессию и смену фазы "plan -> act -> review".

• Compaction - освобождение места за счет очистки старых tool outputs и сжатия истории разговора.

• Re-inject - повторное подмешивание критичного состояния после compaction или при старте новой сессии.

Контекст не копится. Он компилируется под следующий шаг.

Одна из первых широко цитируемых работ, которая хорошо показывает проблему длинного контекста, - это Lost in the Middle. В ней авторы показали, что модель может заметно хуже использовать релевантную информацию, если нужный фрагмент находится в середине длинного ввода, а не в начале или в конце.

Более свежие работы только усиливают этот вывод.

Context Rot показывает, что даже рост числа входных токенов сам по себе начинает подъедать качество, даже когда сама задача не становится сложнее. Проблема не только в "очень длинных документах", а в самом факте разрастания входа.

NoLiMa убирает прямой lexical overlap между вопросом и нужным фрагментом и показывает, насколько быстро модели теряют надежность, когда нельзя просто зацепиться за буквальное совпадение слов.

На коде все выглядит еще интереснее.

LongCodeU показывает просадку на задачах понимания длинного кода задолго до маркетинговых размеров окна.

ContextBench смотрит не только на финальный "решил / не решил", но и на то, как coding-агент вообще добывает контекст: один из неприятных выводов в том, что между тем, что агент исследовал, и тем, что он реально использовал, остается заметный зазор.

LongCLI-Bench показывает, что long-horizon программирование остается тяжелой задачей даже для frontier-систем: а human-agent collaboration даёт более заметный прирост.

Если подвести итог по этим работам, получится очень простой вывод:

Почему проблема особенно болезненна для coding-агентов

Когда мы говорим "длинный контекст", легко представить один большой документ, но у coding-агента контекст растет иначе. Он раздувается не только текстом-кодом, но и всем процессом работы:

• историей диалога;

• кусками файлов и результатами поиска;

• выводом тестов и shell-команд;

• CLAUDE.md;

• загруженными skills;

• определениями инструментов из MCP;

• промежуточными summary;

• уже проверенными гипотезами и планами.

В документации How Claude Code works система описана как цикл gather context -> take action -> verify results -> repeat. Туда же в явном виде попадают история разговора, содержимое файлов, вывод команд, CLAUDE.md, skills и системные инструкции. Отдельно оговаривается, что MCP-серверы добавляют определения инструментов в запросы и тоже расходуют контекст.

Именно поэтому для coding-агентов проблема long context ощущается особенно резко. Через 15-20 шагов в "окне" у вас уже живут не задача и доказательства, а история исследования. И если эта история не вычищается и не выносится в устойчивые артефакты, сессия почти неизбежно начинает дрейфовать.

Почему /compact полезен, но не лечит проблему

На длинной сессии первый и естественный подход - /compact. И да, он действительно полезен - помогает продолжить работу, когда окно уже подходит к пределу.

Но важно понимать, какую задачу он решает. В Claude Code compaction - это прежде всего механизм освобождения места. В официальной документации прямо сказано: когда контекст заполняется, система сначала чистит старые tool outputs, а затем суммаризирует разговор. Одновременно документация предупреждает, что ранние инструкции из разговора могут потеряться, и рекомендует держать persistent rules в CLAUDE.md.

То есть /compact - это, по сути, сборщик мусора, а не архитектура памяти.

Это хорошо совпадает и с работами про управление контекстом. Например, The Complexity Trap показывает, что сложная LLM-суммаризация истории не всегда принципиально лучше простой очистки старого шума. А Context as a Tool предлагает смотреть на контекст как на отдельный рабочий инструмент, а не как на append-only ленту истории.

Практический вывод здесь очень простой:

Почему Plan Mode тоже не панацея

Plan Mode в Claude Code - однозначно полезный режим. Он переводит агента в read-only работу: сначала разобраться, собрать план, только потом переходить к изменениям. В документации это описано в том же разделе How Claude Code works.

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

Но у Plan Mode есть важное ограничение: он дисциплинирует поведение, но не решает проблему работы с памятью.

Если план живет только в сообщениях, то:

• compaction его размоет;

• новая сессия не гарантирует, что агент снова соберет тот же state;

• в длинной сессии план начнет дрейфовать вместе с остальным контекстом.

В issue tracker Claude Code есть показательный кейс #26061, где после context compression терялся workflow state вида plan approved -> implementation in progress. Это в некотором виде является хорошим сигналом, что хранить состояние процесса только в истории диалога - плохая идея.

Если совсем коротко, формула такая:

• Plan Mode полезен как режим исследования;

• /compact полезен как механизм очистки;

• но устойчивость длинной coding-сессии появляется только тогда, когда у вас есть внешнее состояние и явная политика контекста.

Что такое context engineering для coding-агентов

Если упростить до одной фразы:

• Prompt engineering - это что сказать модели.

• Context engineering - это что именно положить модели в рабочее окно на текущем шаге, что оставить снаружи как срез некоторого состояния, что выбросить и что вернуть после compaction.

Но для больших задач этого определения уже мало, на практике context engineering для coding-агентов - это не "чуть лучше собрать промпт", а построить для агента управляемую память.

У большой задачи почти всегда есть два разных слоя:

1. Рабочий контекст текущего шага - файлы, фрагменты кода, вывод команды, кусок лога, текущая цель.

2. Устойчивое состояние задачи - план, текущая фаза, уже принятые ограничения, подтвержденные факты, опровергнутые гипотезы, ссылки на полные логи и артефакты.

Проблема в том, что в реальной сессии эти два слоя очень легко слипаются и чат начинает играть сразу три роли:

• интерфейса управления;

• временного рабочего окна;

• хранилища истины о задаче.

Именно в этот момент длинная сессия начинает деградировать, а чем дольше вы работаете, тем больше "история" вытесняет из окна "состояние задачи".

Поэтому context engineering - это в первую очередь дисциплина разделения:

• что должно жить в рабочем окне только сейчас;

• что должно жить вне окна постоянно;

• что нужно удалять сразу после шага;

• что нужно возвращать после compaction или новой сессии;

• что лучше изолировать в самостоятельную логику, например в subagent или skill.

Если смотреть совсем прагматично, у context engineering для coding-агентов есть пять обязательных решений.

1. Что считать источником истины

Если план, ограничения и подтвержденные факты живут только в переписке, то после 10-20 шагов они уже не являются надежным состоянием. Значит, нужен внешний источник истины: PLAN.md, TODO.md, DECISIONS.md, EVIDENCE.md, лог-файлы, issue, ADR или любой другой устойчивый артефакт.

2. Что именно попадет в окно на следующем шаге

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

3. Что надо выкидывать без сожаления

Большая часть tool outputs полезна ровно один раз, например полный stack trace, огромный grep, verbose stdout и длинный diff редко нужны модели целиком на следующем шаге. Их надо выносить в файл, а в окно оставлять summary.

4. Что надо возвращать после compaction

Compaction освобождает место, но не гарантирует сохранность workflow state, поэтому нужно заранее определить минимальный пакет re-inject: текущая фаза, активный TODO, ключевые решения, может быть 3-5 строк последнего подтвержденного summary.

5. Что надо изолировать

Исследование большого репозитория, чтение длинных логов, code review, сравнение вариантов исправления - это кандидаты на отдельную логику работы. Их удобно выносить в subagents, skills или хотя бы в отдельную свежую сессию.

Именно поэтому для длинных задач context engineering - это не nice-to-have и не "продвинутый стиль работы", а это обязательная инженерная практика и как только задача перестает быть маленьким diff'ом, вы уже работаете не только с моделью, но и с ее памятью.

В этом смысле контекстный конвейер выглядит примерно так:

rules -> state -> JIT retrieval -> pruning -> compaction policy -> re-inject -> isolation

Это и есть минимальная рабочая модель, которая отделяет длинную агентную задачу от просто длинного чата.

Где именно ломается длинная сессия Мини-кейс: баг в checkout

Как собрать минимальный контекстный конвейер

1. В чат - управление, в файлы - состояние

Что лечит: потерю task state после длинной сессии, /compact или новой сессии.
Правило: чат - не источник истины. Источник истины - внешние артефакты.

• PLAN.md - фазы работ

• TODO.md - активные шаги

• DECISIONS.md - принятые ограничения и rejected paths

• EVIDENCE.md - подтвержденные факты и ссылки на логи

• logs/ - сырые outputs

Пример: минимальный каркас и стартовый prompt

2. Сырые tool outputs не должны жить в основном окне

Что лечит: context explosion из-за длинных логов, stack traces и verbose stdout.
Правило: полный stdout - в файл. В окно - только summary и путь к полному выводу.

• полный вывод -> logs/...

• в чат -> 5-8 строк summary

• в EVIDENCE.md -> выжимка + путь к файлу

Пример: редирект логов и запрет шумных команд

3. JIT retrieval лучше, чем "прочитай весь репозиторий"

Что лечит: низкую точность отбора контекста.
Правило: сначала сузить область поиска, потом читать.

• один проход поиска

• не больше 5 файлов до первого summary

• не больше ~200 строк на файл

• сначала карта потока, потом следующее чтение

Пример: prompt и manual skill для JIT retrieval

4. CLAUDE.md должен быть коротким и high-signal

Что лечит: постоянный налог на context window.
Правило: CLAUDE.md - это always-on rules, а не wiki проекта.

Оставлять в CLAUDE.md стоит только:

• workflow rules

• build/test команды

• архитектурные ограничения

• формат артефактов

• compact instructions

Пример: короткий high-signal CLAUDE.md

5. После compaction делайте re-inject критичного состояния

Что лечит: потерю workflow state после /compact.
Правило: compaction не восстанавливает state. Если state важен, его нужно вернуть явно.

Минимальный пакет re-inject:

• текущая фаза

• активный TODO

• ключевые решения

• последние подтвержденные выводы

Пример: SessionStart hook для re-inject

6. Изолируйте шум через subagents, skills

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

Подходит для:

• длинных логов

• code review

• поиска root cause

• исследования большого репозитория

• сравнения вариантов исправления

Пример: subagent, manual skill и минимизация MCP

Короткий чек-лист, что можно сделать:

• вынести план из чата в PLAN.md;

• вынести решения в DECISIONS.md;

• перестать хранить длинные логи в сообщениях чата;

• сократить CLAUDE.md до короткого high-signal файла;

• добавить re-inject после compaction;

• вынести хотя бы одну шумную исследовательскую подзадачу в subagent;

• между несвязанными задачами использовать новую сессию или /clear, а не один бесконечный чат.

Этого уже хватает, чтобы coding-агент реже "забывал, где находится", и чаще принимал решения по фактам, а не по шуму "чата".

Заключение

В основе большинства провалов длинной агентной сессии лежат две проблемы.

Первая - рабочий контекст быстро превращается в шум. Туда попадают длинные логи, лишние файлы, старые tool outputs, промежуточные гипотезы и куски прошлых решений. Модель формально "видит много", но использовать этот массив надежно уже не может, отсюда повторные шаги, случайные решения по нерелевантным кускам и дрейф после compaction.

Вторая - состояние задачи слишком часто живет только в чате. План, текущая фаза, подтвержденные факты, опровергнутые гипотезы и принятые ограничения остаются внутри истории диалога, хотя именно они должны переживать compaction и новую сессию. В результате агент теряет не только детали, но и сам workflow state.

Из первой проблемы следует необходимость pruning, JIT retrieval и изоляции шума. Из второй - необходимость устойчивого состояния, внешних артефактов и re-inject критичного контекста.

Именно на пересечении этих двух задач и появляется context engineering, это не украшение поверх prompt engineering и не "продвинутая техника для энтузиастов". Для больших задач context engineering - обязательный подход к работе, как только вы просите агента не просто сделать маленький diff, а пройти длинный инженерный флоу, вы обязаны управлять его "памятью" так же внимательно, как управляете кодом, тестами и архитектурными ограничениями.

Большие задачи у coding-агентов выигрывают не от максимального объема контекста, а от правильной организации контекста и в этом смысле самый важный сдвиг очень простой: перестать воспринимать чат как хранилище истины и начать строить контекстный конвейер.