Контекст AI-агента — это ресурс. Как я перестал его тратить вслепую
Я потратил час на AI-сессию, только чтобы в конце обнаружить: агент исправил файл, который мы уже поправили в начале. Не потому что он плохой. Контекст переполнился, и модель «забыла» о том, что было в начале разговора. С тех пор я отношусь к контекстному окну как к оперативной памяти: когда кончается — начинаются свопы. И у меня появилась гигиена.
Почему длинный контекст — это не «больше памяти»
Контекстное окно Claude Code — 200 тысяч токенов. Звучит как много. Но авторегрессионные модели работают иначе: каждый следующий токен предсказывается на основе всего предыдущего контекста, и по мере роста его объёма внимание модели распределяется всё тоньше. Это не баг архитектуры — это физика работы трансформера.
На практике это значит вот что: файл, который я открывал в начале сессии, к 50-му обмену уже не в «фокусе». Модель продолжает на него ссылаться, но с нарастающей неточностью. Ранние решения архитектуры забываются. Договорённости о том, что нельзя трогать, размываются.
Это не проблема Claude Code конкретно — это свойство любой LLM на длинном контексте. Но именно Claude Code я использую каждый день в реальных проектах, поэтому и говорю о нём. Управление контекстом — такая же инженерная задача, как управление памятью в долгоживущем процессе.
Как понять, что агент «плывёт»
Три сигнала, которые я поймал на практике:
Повторы. Агент предлагает изменение, которое уже сделали 10-15 сообщений назад. Не идентичное — чуть другое, потому что контекст деградировал неравномерно.
Регрессии. Код, который работал после правки в начале сессии, снова сломан — агент вернул старую версию или применил патч поверх уже исправленного.
Уверенная ложь. Модель отвечает без оговорок, но ответ противоречит договорённостям из начала разговора. Самый дорогой сигнал — именно здесь я терял по 30-40 минут, пока не понял, в чём дело.
Когда вижу любой из трёх — сессию нужно перезапускать. Продолжать дороже.
Правило 1: один файл, одна задача
Главный инструмент управления контекстом — это декомпозиция до запуска сессии, а не борьба с деградацией внутри.
Когда я строил систему SSI-автоматизации на 13 cron-задач, мог сделать это одной большой сессией. Вместо этого каждая задача получила отдельную изолированную сессию со своим TASK.md, своим набором открытых файлов и своей точкой финального результата. Итог: ни одного инцидента с «агент переписал уже готовое». Ни одного повтора между задачами.
Принцип прост: если задача требует работы с более чем тремя-четырьмя файлами одновременно — это признак, что задачу нужно разбить. Не потому что AI не справится. Потому что контекст не резиновый, и платить за это придётся в конце сессии, когда всё уже сделано.
Это не про «ограничить AI». Это про то, чтобы AI делал меньше — и делал это надёжно.
Правило 2: внешняя память вместо длинного контекста
Второй инструмент — вынести постоянный контекст из переписки в файлы.
CLAUDE.md в корне проекта — это якорь. Там живут: что нельзя трогать, какие соглашения по именованию приняты, какие зависимости критичные. Это не документация для людей — это инструкция для агента, которую он получает в начале каждой сессии.
Для каждой задачи — отдельный TASK.md. Минимум три секции: задача в одну строку без «и ещё», явный список «не трогать», конкретный критерий готовности — не «работает», а «endpoint /api/products возвращает 200 без ошибок в логах».
Такой файл заменяет 5-10 сообщений в начале сессии, которые иначе уходят на «введение в контекст». И, что важнее, не занимает место в окне каждый раз — агент читает его один раз при старте.
В Bitrix-проектах это особенно ценно: там много неявных связей — события, обработчики, D7 vs старый API. Если не зафиксировать «не трогай AddEventHandler в модуле X» в файле, агент рано или поздно это затронет. У нас был конкретный случай: агент добавил второй вызов события уведомления об оплате, потому что не знал, что обработчик уже зарегистрирован в соседнем модуле. Клиенты получили два письма. Теперь такие вещи живут в CLAUDE.md, а не в голове.
Правило 3: перезапуск без потери прогресса
Когда вижу признаки деградации — перезапускаю. Но не с нуля.
У меня есть шаблон handoff-промпта:
Ты продолжаешь задачу [название].
Что уже сделано: [2-3 строки, только факты]
Текущий файл: [путь]
Что осталось: [одно действие]
Что нельзя трогать: [список]Никаких объяснений «почему», никакой истории решений — только факты о текущем состоянии. Агент читает это и продолжает с точки перезапуска, не переинтерпретируя предыдущие договорённости.
Перезапуск занимает меньше минуты. Потеря прогресса — ноль. Потеря нервов от деградировавшей сессии — тоже ноль, потому что перезапустил заранее.
Когда эта гигиена не нужна
Для коротких задач — правки одного файла, добавление метода, исправление опечатки — всё это лишнее. Сессия до 20 минут и 10-15 обменов не успевает деградировать так, чтобы это влияло на результат.
Три правила выше — для задач от часа и больше, с несколькими файлами, с зависимостями между частями. Именно там контекст становится узким местом, а не моделью.
Контекстное окно — ресурс. Как RAM: можно открыть 40 вкладок, но браузер начнёт свопить. Гигиена сессии — это не ограничение на AI, а способ получить от него стабильный результат на длинных задачах.
Ссылки по теме: Спецификация до кода: почему я пишу задачу до запроса к AI | Как я пишу задачи для автономных AI-агентов | Автоматизация пайплайна блога: 13 cron-задач