Context Engineering на примере Claude Fable: память, сжатие контекста, кэширование, экономия

Снижаем расходы и получаем лучший результат методом context engineering, используя внешнюю память, сжатие контекста и кэш.

Context Engineering на примере Claude Fable: память, сжатие контекста, кэширование, экономия

Claude Fable 5 – первая общедоступная модель класса Mythos от компании Anthropic – способна работать над одной задачей в течение нескольких часов: разбивает её на этапы, обращается к инструментам, анализирует полученные результаты, а на максимальном уровне вычислительных способностей самостоятельно проверяет результат. Модель выпущена 9 июня 2026 года и с 1 июля 2026 года вновь доступна всем клиентам. Это модель для длительных асинхронных задач, поэтому от качества управления её контекстом напрямую зависит, будет ли она работать эффективно или качество результата станет постепенно снижаться.

При длительном сеансе возникает соблазн удерживать в контекстном окне все данные подряд: всю предшествующую переписку, результаты всех обращений к инструментам и всю кодовую базу. Такой подход кажется более надёжным, однако это не так. Контекстное окно удерживает данные лишь в пределах одного запроса и не является долговременной памятью. Чем больше данных в него помещается, тем сложнее модели удерживать в фокусе то, что необходимо для текущего шага. Увеличение числа токенов не улучшает понимание модели, а при стоимости 10 $ за миллион входных токенов оно ещё и сопряжено с прямыми расходами. Context Engineering – это способ предоставлять модели ровно те данные, которые требуются для текущего шага, и удерживать всё лишнее за пределами контекстного окна.

Настоящее руководство посвящено работе с контекстом, а не приёмам составления запросов. В нём рассматривается, почему контекст не является памятью, каким образом обеспечить Fable 5 внешней памятью, как выполнять резюмирование и извлечение контекста, за счёт чего кэширование запросов снижает стоимость входных токенов почти на 90 % и как построить цикл сжатия контекста для длительных сеансов – с приведением расчёта расходов.

Контекст вместо памяти

Контекстное окно – это рабочая область модели в пределах одного запроса. Оно не является ни постоянным хранилищем, ни памятью в сколько-нибудь долговременном смысле. По мере добавления новых сообщений в ходе длительного сеанса модель не становится более компетентной – напротив, ей становится труднее сосредоточиться на текущем шаге. Со временем качество контекста снижается; инженеры называют это явление постепенной деградацией контекста (context rot): чем продолжительнее диалог, тем больше устаревших сообщений накапливается в контексте, на их фоне модели труднее выделить главное для текущего этапа, и качество ответов падает.

Представление о том, что длинный промпт делает модель «умнее», применительно к длительным задачам является ошибочным. Все данные, не требующиеся на текущем шаге, лишь дезориентируют модель и замедляют формирование ответа. Fable 5 перед ответом выполняет объёмные рассуждения, поэтому избыточный контекст делает каждый шаг не только дороже, но и медленнее. Увеличение числа токенов не улучшает понимание модели.

Fable 5 располагает контекстным окном на 1 млн токенов – таким же, как у модели Opus 4.8. Однако задействовать его в полном объёме нецелесообразно. Настоящее руководство как раз и посвящено тому, как исключать из контекстного окна всё лишнее, – именно это обеспечивает подлинную надёжность длительных сеансов.

Внешняя память

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

  • Храните состояние работы в структурированном виде, а не в виде переписки с агентом. Отдельный файл с планом, отдельный перечень принятых решений и собранные факты существенно эффективнее, чем сплошная лента сообщений.
  • Предоставьте модели инструменты чтения и записи. Это могут быть чтение и запись файлов либо простой интерфейс «ключ – значение» с функцией поиска, чтобы модель обновляла свою память самостоятельно, не дожидаясь, пока вы добавите контекст.
  • Сделайте внешнюю память единственным источником достоверных данных. При любом изменении незамедлительно вносите правку в хранилище. Тогда на следующем шаге модель возьмёт актуальные данные из него, а не будет восстанавливать их из диалога.

По данным Anthropic, внешняя память в виде файлов оказалась более эффективной для Fable 5, чем для Opus 4.8. Проектирование хранилища, в которое модель может сохранять данные и из которого может их извлекать, – один из наиболее действенных приёмов работы с Fable 5.

Сжатие контекста

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

  • Сжимайте контекст по завершении логического этапа. Не дожидайтесь переполнения контекстного окна: завершив подзадачу, сразу заменяйте переписку на краткое резюме.
  • Сохраняйте только значимые данные – принятые решения, интерфейсы, пути к файлам и нерешённые вопросы. Промежуточные рассуждения модели и отвергнутые ею варианты исключайте.
  • Сохраняйте все резюме, а не только последнее. Резюме – это краткий итог завершённого этапа (что выполнено и какие решения приняты). Каждый новый итог добавляйте к ранее сохранённым, а не замещайте им предыдущие. В этом случае впоследствии или после перезапуска сеанса всю последовательность работы можно восстановить по цепочке резюме, не обращаясь к исходной переписке.

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

Загружать все данные?

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

  • Загружайте данные под конкретный шаг, а не на весь сеанс. Используйте только те файлы, записи или документы, которые нужно обработать прямо сейчас, а весь репозиторий или базу знаний целиком.
  • Позвольте модели самостоятельно запрашивать контекст. Разрешите использование инструментов поиска и чтения, чтобы модель находила недостающие данные; тогда контекст остаётся компактным.
  • Выгружайте данные сразу после использования. Как только фрагмент контекста обработан, исключите его из последующих запросов.

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

Кэширование запросов

Тем не менее не все данные можно вынести из контекстного окна во внешнюю память. Системный промпт, описания инструментов и постоянный контекст проекта требуются модели на каждом шаге, поэтому они должны присутствовать в каждом запросе, и вынести их в файлы невозможно. В этом случае помогает кэширование запросов: Anthropic предоставляет скидку 90 % на кэшированные входные токены, поэтому попадание в кэш обходится примерно в 1 $ за миллион токенов вместо 10 $. Действует простое правило: неизменяемая часть запроса размещается в начале, изменяемая – в конце.

  • Неизменяемую часть запроса размещайте в начале. Системный промпт, инструкции, описания инструментов и обязательный контекст проекта добавляйте первыми и не изменяйте от запроса к запросу – только в этом случае они будут попадать в кэш.
  • Изменяемую часть запроса размещайте в конце. Данные, меняющиеся от шага к шагу, помещайте в самом конце, чтобы они не сбрасывали кэш неизменяемой части.
  • Не изменяйте текст запроса. Достаточно переставить одну строку или добавить в начало новую отметку времени, чтобы кэш сбросился, а стоимость вернулась к 10 $.

Неизменяемая часть запроса объёмом 200 тыс. токенов, переиспользуемая между обращениями, без кэша стоит 200000 / 1 000 000 × 10 = 2 $. При попадании в кэш со скидкой 90 % – около 2 × 0,10 = 0,2 $. За сеанс из нескольких десятков обращений это даёт значительную экономию.

Первое обращение, заполняющее кэш, обходится несколько дороже – за счёт небольшой надбавки за первичную запись в кэш (Anthropic добавляет около 25 % к базовой стоимости входных токенов для пятиминутного кэша); здесь эта надбавка для простоты не учитывается. Она незначительно повышает стоимость первого обращения, но на итоговый уровень экономии не влияет.

Сжатие контекста в цикле

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

  1. Контролируйте заполнение контекстного окна. После каждого шага проверяйте, какой объём контекстного окна уже задействован.
  2. Выполняйте сжатие контекста при достижении порога. Как только заполнение контекстного окна достигает заданного порога, применяйте функцию сжатия (/compact).
  3. После сжатия очищайте контекстное окно от исходных сообщений.
  4. Сохраняйте контрольную точку. Записывайте резюме и текущее состояние во внешнюю память.
  5. Возобновляйте работу с последней контрольной точки, если сеанс был прерван.

Сначала сохраните резюме и состояние сеанса во внешнюю память и только затем очищайте контекстное окно от исходных сообщений. Если начать новый сеанс до сохранения контрольной точки, все выполненные работы будут утрачены.

Оценка экономии

Context Engineering влияет не только на качество, но и на расходы. Пример: 200 тыс. входных и 50 тыс. выходных токенов на Fable 5 стоят 0,2 × 10 + 0,05 × 50 = 2,00 + 2,50 = 4,50 $. Масштабируем этот расчёт до уровня сеанса и сравним два подхода: прямолинейный (весь контекст просто накапливается в окне, без кэширования и сжатия) и оптимизированный.

Возьмём сеанс из 20 обращений к модели с неизменяемым контекстом объёмом 150 тыс. токенов. При прямолинейном подходе контекст разрастается, поскольку каждое обращение в среднем даёт около 250 тыс. входных и 20 тыс. выходных токенов, и кэширование не применяется:

ПодходВходВыходИтого за сеанс
Прямолинейный50 $20 $70 $
Кэширование и сжатие15,85 $20,00 $35,85 $

Итог 70 $ складывается следующим образом: 20 × 0,25 × 10 = 50 $ на вход и 20 × 0,02 × 50 = 20 $ на выход, то есть 70 $ суммарно. При оптимизированном подходе агент кэширует 150 тыс. токенов и сжимает рабочий контекст до 50 тыс. токенов в каждом обращении. Этот фрагмент стоит 1,50 $ при первом (некэшированном) обращении и 0,15 $ за каждое из остальных 19 обращений при попадании в кэш, то есть 1,50 + 19 × 0,15 = 5,85 $. Переменные 50 тыс. токенов на обращение дают 20 × 0,05 × 10 = 10 $, итого 5,85 + 10 = 15,85 $ на вход. Стоимость выходных токенов остаётся неизменной – 20 $, а суммарные расходы составляют 35,85 $.

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

Читайте также

Prompt Injection в ИИ-агентах: классификация атак и 10 практических способов защиты
/9 мин

Prompt Injection в ИИ-агентах: классификация атак и 10 практических способов защиты

Разбираем главную угрозу для LLM-приложений на примере уязвимости CLI-агента Gemini. Подробный разбор явных и неявных инъекций, рекомендации OpenAI и пошаговое руководство по построению эшелонированной защиты.

Loop Engineering на практике: автономный цикл «оркестратор, мейкер, чекер»
/9 мин

Loop Engineering на практике: автономный цикл «оркестратор, мейкер, чекер»

Разбираем рабочий демо-стенд loop engineering: внешний цикл находит задачу в GitHub Issues, изолирует работу в Git worktree, делегирует реализацию мейкеру и независимую проверку чекеру и доводит задачу до pull request – с валидацией по правилам и памятью в state/loop-state.md.