Claude учат работать через файлы, а не через контекст

Осенью 2025 года Anthropic описала в блоге для разработчиков паттерн, который она использует в связке Claude и инструмента Claude Code: вместо того чтобы загружать в контекстное окно модели всю историю задачи, агент пишет промежуточные результаты в файлы на диске и подгружает только то, что нужно на текущем шаге. Тот же принцип независимо продвигают команды вокруг фреймворков для агентов — от LangGraph до самодельных обёрток над OpenAI Assistants. Идея простая: файловая система становится памятью агента, а контекст модели — рабочим столом, который регулярно расчищают.

Звучит буднично, но за этим стоит конкретная проблема с ценой. Длинный контекст стоит денег и деградирует по качеству, а файл на диске не стоит почти ничего и не забывается.

Что не так с «просто длинным контекстом»

Контекстное окно* современных моделей выросло радикально: у Claude Sonnet и Opus линейки 2025 года оно достигает 200 000 токенов, у Gemini 1.5 Pro Google заявляла до 1–2 млн токенов. Соблазн очевиден — положить в окно весь проект, всю переписку, всю документацию и не думать о структуре.

На практике у этого три издержки.

• Деньги. Вход в модель тарифицируется за токены. Если агент на каждом из 40 шагов задачи тащит с собой всю накопленную историю, вы платите за одни и те же данные десятки раз.
• Скорость. Чем больше токенов на входе, тем дольше модель формирует ответ. Длинный контекст — это латентность на каждом шаге.
• Качество. Известен эффект «потери в середине» (lost in the middle): модель хуже находит факты, лежащие в середине очень длинного контекста, чем в начале или конце. Про это писали исследователи из Стэнфорда и Беркли в работе о длинных контекстах ещё в 2023 году; точную актуальную величину эффекта для конкретной модели стоит проверять по её карточке.

Оркестрация через файлы: как это устроено

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

Типичный цикл выглядит так:

1. Агент получает большую задачу и разбивает её на шаги, записывая план в файл plan.md.
2. На каждом шаге он читает только нужный кусок: не весь код проекта, а конкретный файл; не всю переписку, а последнюю запись в notes.md.
3. Результат шага агент сохраняет обратно на диск — новый файл или дописанная строка в лог.
4. Контекст между шагами очищается или сжимается: в окно попадает короткое резюме «что уже сделано» плюс путь к файлам, а не полный дамп.

Модель не обязана помнить всё. Она обязана знать, где что лежит и как это прочитать. Диск дешевле и надёжнее внимания.

В связке Claude Code это выглядит естественно: у агента есть доступ к терминалу и файловой системе, он сам создаёт вспомогательные файлы, ведёт to-do лист и сверяется с ним. Тот же приём работает и в самописных агентах на базе любого API с вызовом инструментов (function calling) — файловые операции просто оформляются как обычные tool-функции: read_file, write_file, list_dir.

Файлы против альтернатив

Файловая система — не единственный способ дать агенту память сверх контекстного окна. Ниже — сравнение трёх популярных подходов. Доступность и детали зависят от конкретного фреймворка, цифры проверяйте по его документации.

На практике их комбинируют. RAG — для внешней базы знаний, файлы — для рабочего состояния конкретной задачи, длинный контекст — для того, что реально нужно модели прямо сейчас. Файловый подход выигрывает именно там, где важна воспроизводимость: результат каждого шага лежит на диске, его можно открыть глазами, поправить и перезапустить агента с середины.

Кому это пригодится и кому нет

Когда файлы оправданы

• Длинные многошаговые задачи. Рефакторинг большого репозитория, генерация документации по десяткам модулей, миграция данных — там, где 40 шагов и накопленная история не влезает в бюджет токенов.
• Нужна отладка. Если агент ошибся на шаге 12, вы открываете файл с результатом шага 11 и видите, где всё пошло не так, вместо расшифровки гигантского лога контекста.
• Параллельные под-агенты. Несколько агентов работают над разными частями задачи и обмениваются результатами через общие файлы, а не через раздувание одного окна.

Когда это лишнее

• Короткий диалог. Разовый вопрос, генерация одного письма, перевод абзаца — здесь файловая обвязка только усложняет.
• Задача помещается в окно с запасом. Если весь ваш контекст — это 8 000 токенов, городить файловую оркестрацию незачем.
• Нет доступа к файловой системе. В браузерном чат-интерфейсе без инструментов агент не может писать на диск — там придётся обходиться сжатием контекста или внешним хранилищем через API.

Что это значит для стоимости

Главный аргумент — экономика. Представьте задачу из 20 шагов, где на каждом шаге контекст в наивной реализации разрастается в среднем на 5 000 токенов. К последнему шагу вы отправляете в модель около 100 000 токенов входа — и так на каждом из финальных шагов. При файловом подходе на входе держится короткое резюме и путь к нужному файлу, скажем 3 000–8 000 токенов на шаг независимо от прогресса.

Точную выгоду в рублях считать нужно по актуальному прайсу API вашей модели — цены Anthropic, OpenAI и Google на входные и выходные токены различаются и меняются. Но порядок понятен: вы перестаёте платить за многократную пересылку одних и тех же данных.

* Контекстное окно — максимальный объём текста в токенах, который модель способна учитывать за один запрос: и то, что вы прислали, и то, что она сгенерирует. Всё, что не влезло, модель «не видит».

** RAG (retrieval-augmented generation) — подход, при котором перед ответом система ищет релевантные фрагменты во внешней базе (обычно по векторным эмбеддингам) и подкладывает их модели в контекст.