Fallback-стратегии для LLM-агентов на примере Claude: что делать, когда агент начинает деградировать

Сейчас многие радуются большим окнам контекста: 200k, 1M токенов и выше. На бумаге это почти решение всех проблем. На практике - нет.

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

И вот тут приходит главная проблема: агент начинает деградировать задолго до формального лимита контекста.

Как выглядит деградация

Снаружи это ощущается довольно быстро:

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

Самое неприятное - это редко происходит мгновенно. Деградация нарастает постепенно: сначала пара странных ответов, потом растёт шум, и агент уже как будто "плывёт".

Почему это происходит

Проблема не только в памяти. Проблема глубже.

Даже большой контекст конечен. Внутри длинной сессии агент начинает терять приоритеты: что важно, что вторично, что уже устарело.

По сути, накапливаются три вещи:

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

Дрейф задачи. Изначальная цель размывается. Агент продолжает работать, но опирается не на актуальный фокус, а на накопленный шум.

Снижение управляемости. Чем больше монолитная задача, тем тяжелее агенту держать траекторию выполнения.

Мониторинг: откуда взялась цифра 600k

Я не проводил никаких формальных тестов. Просто наблюдал.

Когда контекст переваливает за 600–700k токенов, появляется то, что я называю "зоной опасений". Агент ещё работает, но если прямо сейчас придёт сложная задача - высокая вероятность, что что-то пойдёт не так. Не потому что есть формальное доказательство. Просто насмотренность.

Поэтому правило простое: контекст выше 600k + тяжёлая задача впереди = сначала чистим.

У меня агент сам показывает размер контекста при каждом ответе. Это убирает управление вслепую.

Отдельно про CLAUDE.md. Это файл, который агент читает при старте - он должен быть ссылочным: инструкции, ключевые правила, указатели на другие файлы. Метрики, история, саммари - всё это пишется в отдельные файлы, а в CLAUDE.md идёт только ссылка. Как только начинаешь складывать туда всё подряд, агент деградирует не от нехватки памяти, а от её избытка.

Три уровня fallback

Soft reset - мягкий сброс через /compact. SDK сжимает историю примерно на 20%. Агент получает более чистое рабочее пространство и восстанавливается, не теряя нить задачи.

Hard reset - полный сброс через /new. Удаляется история переписки, обнуляется session ID. Следующий запрос стартует с чистого листа. Можно сразу давать задачу: /new напиши пост про деплой - сбросит и тут же начнёт работать.

Важный нюанс: после /new агент не помнит ничего из прошлой сессии. Внешняя память (mem0) частично спасает, но только то, что ты явно решил сохранить.

Circuit breaker - инженерный режим. На практике это retry-логика: если запрос не прошёл, система пробует ещё 5 раз до того, как выбросить ошибку. В более продвинутом варианте circuit breaker реагирует на признаки деградации ещё до падения: режет контекст, запускает soft reset, в тяжёлых случаях hard reset, и не даёт агенту брать новые тяжёлые задачи.

Реальный инцидент

Один раз агент опубликовал материал без подтверждения.

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

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

Ритуал перед /new

Когда делаю hard reset, я не просто бью /new и заново объясняю задачу.

Перед сбросом - или в конце дня, или в конце рабочего блока - говорю агенту: "Перечитай свою историю за сессию, расскажи мне саммари". Это саммари отправляю в векторную базу. Иногда, если в процессе всплывает что-то важное, говорю сохранить сразу.

После /new агент не помнит детали, но может достать сохранённый контекст из mem0 при необходимости.

Декомпозиционный паттерн

Большая задача никогда не должна попадать в агент целиком.

У меня есть опыт тимлида и работы в Scrum, поэтому я примерно понимаю сложность задачи и сколько итераций она требует. Мой подход: сначала проговорить с агентом, как бы он её делал. Если агент режет задачу на 3–4 блока - создаём 3–4 задачи, и каждую описываем планом.

Почему важно явно записывать план? Потому что в реальной работе постоянно отвлекаешься: выпустить сертификат, проверить зависимость, ответить на сообщение. Контекст забивается побочным, и первая задача растворяется.

Если план записан явно, достаточно сказать "у тебя есть задача с планом - следуй ему". Агент восстанавливается. Без записанного плана - объясняешь заново.

Параллельность: не для всего

У меня два агента с разными правилами.

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

Второй параллелит, но только лёгкие операции: проверки, сбор данных, счётчики. Для всего, что требует принятия решений или архитектурного выбора - строго последовательно.

Правило простое: параллелить нужно лёгкое и независимое. Тяжёлое и связанное - поэтапно.

Про внешнюю память

Сначала я пробовал автоматическую кюрацию: агент сам ходил через промт в LLM и выбирал факты для сохранения. Итог - в базе накапливался мусор, который потом путал агента.

Теперь решаю вручную: что сохранять, какому агенту, на какой срок. Да, это требует внимания. Но база остаётся чистой, и при следующей сессии агент получает только то, что реально нужно.

Три слоя работы с памятью:

1. Компрессия текущего контекста через /compact
2. Оставление только актуального фокуса
3. Вынесение знаний во внешнее хранилище с ручным контролем

Рабочая связка

В итоге сложилась такая схема:

• программный мониторинг контекста с индикатором при каждом ответе
• порог 600k как красный флаг для тяжёлых задач
• /compact для быстрого восстановления без потери нити
• /new для зашумлённых сессий с ритуалом сохранения саммари
• CLAUDE.md как ссылочный файл, не свалка
• mem0 с ручной кюрацией вместо авто-экстракта
• обязательная запись плана в задачи - страховка при любом сбросе
• дробление больших задач с агентом до начала работы

Короткий управляемый контекст + внешняя память + fallback-механизмы + декомпозиция + записанные планы.

Главный вывод

Проблема современных LLM-агентов не в том, что мало контекста. Проблема в том, что контекст без архитектуры быстро превращается в свалку.

Следующий этап зрелости агентных систем - это не просто больше токенов, а:

• наблюдаемость
• декомпозиционный паттерн
• fallback-стратегии
• внешняя память с ручным контролем
• аккуратный orchestration параллельности
• явная фиксация планов

Чем раньше начинаешь смотреть на агента как на систему, а не как на волшебный чат, тем быстрее он начинает приносить реальную пользу.