Инжиниринг контекста для AI-агентов с длинным горизонтом

В совокупности анализ Arize, статья arXiv о переполнении контекстного окна, производственное объяснение Redis и сравнение инжиниринга обвязки от Atlan указывают на практический сдвиг в проектировании агентов. Долгосрочных агентов всё меньше оценивают по размеру контекстного окна модели и всё больше — по управляющему слою вокруг него. Arize делает этот сдвиг конкретным: называет выпущенные инструменты агентов и системы памяти/обвязки, включая Pi, OpenClaw, Claude Code и Letta, примерами инжиниринга контекста на уровне обвязки и описывает интерактивный симулятор, который показывает, как заполняется окно на 200 тыс. токенов.

Публичные детали в цитируемых источниках неравномерны. Arize приводит конкретные цифры реализации для Pi, OpenClaw, Claude Code и Letta. Исследовательская статья о решении проблемы переполнения контекстного окна в AI-агентах даёт более общий механизм обработки выводов инструментов, которые могут превышать любое практическое окно. Объяснение Redis о переполнении контекстного окна резюмирует производственные симптомы: жёсткие ошибки API, незаметное снижение качества, накопление выводов инструментов и рост задержки по мере увеличения prompt. Сравнение Atlan между prompt engineering, context engineering и harness engineering даёт полезную метафору стека: prompt engineering формирует сообщение, context engineering формирует то, что видит модель, а harness engineering формирует всю среду агента.

Главная новость не в том, что контекстные окна слишком малы. Разработчики уже это знают. Более полезный вывод в том, что описанные агентные системы сходятся к четырём механизмам обвязки, которые поддерживают работу после того, как транскрипт перестаёт быть надёжным источником истины.

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

Более чистый способ прочитать первый набор ограничений:

• Pi: чтение файлов останавливается на 2 000 строках или 50 КБ — в зависимости от того, что наступит раньше. Возвращаемое содержимое включает подсказку о продолжении: она сообщает модели, какой диапазон строк был показан и как продолжить с помощью offset и limit. OpenClaw наследует это поведение, а затем добавляет отдельные лимиты: bootstrap-файлы ограничены 12 000 символами на файл и 60 000 символами всего. Для результатов инструментов действует ещё один бюджет: 16 000 символов или 30% контекстного окна — что меньше.

Claude Code использует двухступенчатую схему. По данным Arize, перед открытием файла он проверяет лимит в 256 КБ по байтам, а затем после чтения считает токены результата относительно бюджета в 25 000 токенов. Даже для файлов ниже лимита он по умолчанию возвращает 2 000 строк с начала и обрезает строки длиннее 2 000 символов. Если модель повторно читает тот же диапазон файла, а файл не изменился, Claude Code может вернуть заглушку вместо повторения полного содержимого.

Это не просто оптимизация. Это меняет режим отказа. Вместо того чтобы позволить одному большому чтению вытеснить задачу, обвязка превращает «прочитать всё» в «прочитать контролируемый фрагмент». Если модели нужно больше, она может запросить продолжение. Для разработчиков, которые проектируют обвязки агентов с нуля, это первая линия защиты: не позволяйте внешним данным в сыром виде по умолчанию становиться транскриптом.

Следующий паттерн — относиться к контексту как к области просмотра, а не как к хранилищу.

Pi и Claude Code предоставляют пагинацию через offset и limit. OpenClaw в некоторых местах добавляет обрезку по началу/концу, сохраняя начало и конец, когда середина с меньшей вероятностью важна. Arize пишет, что OpenClaw использует разбиение 75% начало / 25% конец для слишком больших bootstrap-файлов и может сохранять и начало, и конец для результатов инструментов, когда хвост выглядит важным: например, содержит ошибки, закрывающие скобки JSON или ключевые слова, похожие на резюме.

Letta идёт дальше: файлы живут вне prompt. Загруженные файлы разбираются, нарезаются на фрагменты и индексируются эмбеддингами в векторном хранилище, давая агенту прямой просмотр, точный поиск и семантический поиск. Когда файл открыт в контексте, Letta показывает управляемое представление, размер которого масштабируется вместе с контекстом модели: 5 000 символов для контекста 8K, 15 000 для 32K, 25 000 для 128K и 40 000 для 200K+. Количество одновременно открытых файлов тоже масштабируется: от 3 для малых моделей до 15 для очень крупных, с политикой LRU, которая вытесняет файлы, к которым обращались давнее всего.

Это та же идея проектирования, что лежит в основе производственных RAG-систем: не запихивать весь корпус в prompt, а извлекать важную часть. Разница в том, что обвязки агентов должны делать это непрерывно — по файлам, выводам инструментов, памяти и промежуточным планам. То же ограничение применимо к RAG-системам: извлечение связано не только с релевантностью, но и с сохранением достаточного бюджета контекста для фактического шага рассуждения.

Redis делает связанный вывод: более крупные контекстные окна не отменяют необходимость управления контекстом. Системные prompt, извлечённые документы, история диалога и выводы инструментов конкурируют за одно и то же пространство. Даже до достижения жёсткого лимита качество моделей может снижаться, когда релевантная информация оказывается погребена в длинных входных данных.

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

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

Arize сообщает, что Pi запускает сжатие, когда оценочное число токенов контекста превышает контекстное окно минус резервные токены; резерв по умолчанию — 16 384 токена. Он сохраняет примерно 20 000 самых свежих токенов и сводит более старое содержимое в синтетическое пользовательское сообщение, добавленное перед сохранённым хвостом. Он также избегает разрезания пар «вызов инструмента / результат инструмента».

OpenClaw добавляет более агрессивную политику истории. Когда история превышает 50% контекстного окна, он разбивает сообщения на равные по массе токенов фрагменты, удаляет самый старый фрагмент, суммаризирует удалённое содержимое через staged multi-pass summarization и восстанавливает парность вызовов/результатов инструментов. Он также выполняет pre-compaction flush: тихий агентный ход даёт агенту шанс сохранить состояние в файлы памяти до того, как история исчезнет. Отдельно он очищает результаты инструментов в памяти с поведением soft-trim и hard-clear при TTL кэша 5 минут.

Claude Code сжимает ближе к концу окна. Arize пишет, что триггером служит эффективное контекстное окно минус буфер в 13 000 токенов, что даёт сжатие примерно на 167K токенов для модели с контекстом 200K. Его prompt для суммаризации просит структурированные разделы, покрывающие основной запрос, технические концепции, файлы и код, ошибки и исправления, решение проблем, сообщения пользователя, незавершённые задачи, текущую работу и следующий шаг. После сжатия он может заново прикрепить до 5 недавно прочитанных файлов в рамках токенного бюджета.

Паттерн понятен: сжатие — это не «суммаризировать чат». Это чекпойнтинг. Долгосрочному агенту нужен эквивалент файла сохранения: цель, ограничения, решения, открытые дескрипторы, свежие доказательства и следующее действие.

Некоторые выводы вообще не должны помещаться в контекстное окно.

Статья arXiv делает это конкретным на примере рабочего процесса из материаловедения. Один инструмент генерирует электронную сеточную структуру для молекулы: 3D-матрицу размером 128 × 128 × 128, всего 2 097 152 элемента float32. Такой вывод намного превышает контекстное окно широко используемых LLM. Но следующему инструменту эта сетка нужна как входные данные.

Предложенное решение — хранить большие значения вне контекста модели и возвращать короткие идентификаторы, или указатели. Обёртки инструментов проверяют входные данные, чтобы понять, являются ли они сырыми значениями или путями в памяти. Слишком большие выводы сохраняются в runtime-памяти по пути, а последующие инструменты могут получить указатель и разрешить его внутри себя. Модель работает со ссылками, а обвязка сохраняет полные данные. По данным статьи, в одном сравнительном эксперименте, где оба метода сработали, подход на основе указателей использовал примерно в семь раз меньше токенов, чем традиционный рабочий процесс.

Это самое чистое разделение рассуждения и транспорта данных. Модели не нужно «видеть» матрицу из 2 миллионов элементов, чтобы передать её другому инструменту. Ей нужно знать, что матрица существует, что она представляет и какая операция должна использовать её дальше.

Та же логика применима далеко за пределами научных массивов. Большие ответы JSON, PDF, логи, эмбеддинги, медиафайлы и экспорт баз данных часто должны находиться в хранилище, а не в prompt. Для систем, построенных вокруг инструментов MCP или пользовательских API-коннекторов, передача указателей должна быть первоклассным проектным решением, а не заплаткой после первого переполнения.

Контекстное окно на 200K токенов кажется большим, пока агент не начинает действовать. Системный prompt, определения инструментов, несколько извлечённых документов, чтение файлов, логи, трассировки ошибок и сводки могут занять его быстрее, чем ожидается. Практическая рамка — не то, насколько большим окно выглядит на бумаге, а то, как быстро агенты расходуют его во время выполнения. Рекомендации Redis по памяти агентов указывают на внешнюю, долговечную память для состояния, которое должно переживать вызовы, а рамка context engineering от Atlan отделяет лучшие prompt от лучшей сборки контекста. Вместе они рассматривают контекстное окно не как склад, а как ограниченный рабочий набор.

Более глубокий урок в том, что контекстное окно — дефицитный ресурс времени выполнения. Относиться к нему как к «памяти» полезно, но только если обвязка ведёт себя как операционная система: выделяет, вытесняет, подкачивает, сжимает, дедуплицирует и сохраняет. Разделение уровней у Atlan здесь полезно. Prompt engineering не исправит читатель файлов, который сбрасывает 80 000 нерелевантных токенов в следующий вызов. Context engineering может улучшить рабочий набор. Harness engineering решает, защищён ли этот рабочий набор изначально.

Это также меняет то, как командам следует оценивать агентов. Демонстрационного prompt недостаточно. Оценка длинного горизонта должна включать растущие транскрипты, повторное чтение файлов, большие выводы инструментов, неудачные вызовы инструментов, возобновление после сжатия и задачи, где правильный следующий шаг зависит от раннего ограничения. Наше руководство по инжинирингу контекста для агентов описывает версию этой проблемы на стороне модели; слой обвязки — там, где она становится операционной.

Во-первых, задайте бюджеты для каждого источника контекста. У файлов, выводов инструментов, извлечённых фрагментов, вставок памяти и истории диалога должны быть явные лимиты. Один глобальный максимум токенов — слишком грубый инструмент.

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

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

В-четвёртых, выносите большие значения из prompt. Храните их, называйте их и передавайте указатели через инструменты. Это особенно важно для агентов, которые вызывают API, обрабатывают документы или координируют многоагентные системы.

Наконец, тестируйте потерю цели отдельно от переполнения. Агент может оставаться ниже жёсткого окна и всё равно дрейфовать. Правильный вопрос не только «принял ли API prompt?». Он звучит так: «служит ли следующее действие исходной задаче?»

Сводка ниже превращает эти паттерны в короткий чек-лист перед FAQ.

• Агенты с длинным горизонтом дают сбой и из-за переполнения контекста, и из-за потери цели, поэтому обвязка должна управлять не только длиной prompt.
• Производственные агентные системы используют жёсткие бюджеты для файлов, выводов инструментов и истории до того, как сырые данные попадут к модели.
• Пагинация, поиск и управляемые представления трактуют контекст как ограниченную область просмотра, а не как постоянное хранилище.
• Сжатие лучше всего работает как чекпойнтинг: оно сохраняет цели, ограничения, решения, незавершённую работу и целостность вызовов инструментов.
• Большие выводы инструментов часто должны находиться во внешнем хранилище, а между инструментами лучше передавать короткие указатели, а не полные значения в prompt.

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

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

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

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

Указатели позволяют модели ссылаться на большие значения, сохранённые в runtime-памяти, например матрицы, логи или PDF, а последующие инструменты разрешают полные данные без помещения их в контекстное окно.

Нет. Большие окна помогают, но системные prompt, определения инструментов, извлечённые документы, логи и история всё равно конкурируют за место, а релевантная информация может быть погребена ещё до достижения жёсткого лимита.