Context engineering:
управление контекстным окном

Проблема: больше контекста ≠ лучше

Интуиция подсказывает: раз окно 200k токенов, надо использовать его целиком — вся история, все документы, все инструменты. На практике это ухудшает агента сразу по трём осям.

Особенно коварна экономика: у агента каждый шаг reasoning отправляет весь накопленный контекст заново. Диалог из 10 шагов с растущей историей — это не 10 отправок по 1k токенов, а 1k+2k+3k+…: суммарно на порядок больше. Раздутый контекст бьёт по счёту тем сильнее, чем длиннее работает агент.

Бюджет контекста

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

Практика бюджетирования проста: прикинь лимит на каждую статью и следи, чтобы сумма не приближалась к окну (оставив место под ответ). Например: system — до 1k, инструменты — до 2k, RAG — до 4k, история — до 8k. Как только история упирается в свой лимит — включается сжатие (ниже), а не «пусть растёт, окно большое».

Управление историей диалога

История — главный «пожиратель» контекста у агента, потому что она единственная растёт неограниченно. Основные стратегии (часто комбинируют):

KEEP_RECENT = 6          # последние сообщения — дословно
HISTORY_BUDGET = 8000    # лимит токенов на историю

def compact_history(messages: list, summary: str | None):
    if count_tokens(messages) <= HISTORY_BUDGET:
        return messages, summary            # влезаем — ничего не делаем

    recent = messages[-KEEP_RECENT:]        # хвост важен: свежий контекст
    older  = messages[:-KEEP_RECENT]

    # старое сжимаем в сводку (доклеивая к предыдущей — сводка накопительная)
    summary = llm(f"""Кратко суммируй ход диалога, сохранив:
решения, факты, незакрытые задачи. Предыдущая сводка: {summary or '—'}
Новые сообщения: {render(older)}""", temperature=0)

    # сводка идёт как system-сообщение ПЕРЕД свежими
    return [{"role": "system", "content": f"Сводка ранее: {summary}"}] + recent, summary

# обрезаем и «толстые» ответы инструментов — они раздувают историю быстрее всего
def trim_tool_output(text: str, limit: int = 2000) -> str:
    return text if len(text) <= limit else text[:limit] + "\n…[обрезано]"

Отбор: инструменты и документы

История — не единственный источник раздувания. Два других — описания инструментов и RAG-документы, и оба лечатся отбором.

• Инструменты. Описания всех tools уходят в каждый запрос. 40 инструментов — это тысячи токенов на каждом шаге, плюс модели труднее выбрать нужный. Решение: давать только релевантные текущей задаче (динамический отбор по этапу/намерению) — прямая связь с Skills-роутингом из модуля 05.
• RAG-документы. Соблазн «дадим top-50 чанков, вдруг пригодится» вредит: релевантное тонет в шуме (context rot). Лучше меньше, но точнее — качественный retrieval и reranking важнее объёма (модуль 04).
• Порядок важен. Раз середина работает хуже — критичные инструкции и самые релевантные документы ставь ближе к концу промпта, ближе к вопросу.

Изоляция контекста через субагентов

Мощная структурная техника (мостик к модулю 05): если задача требует много «грязной» работы с большими данными, вынеси её в субагента с отдельным контекстным окном. Субагент перелопачивает документы в своём окне и возвращает наверх короткую выжимку, а не сырьё.

❌ Один агент на всё:
  главный контекст ← 50 документов + история + всё подряд → распух, качество ↓

✅ Изоляция через субагента:
  главный агент (чистый контекст, видит только итоги)
       │  «изучи эти 50 документов по теме X»
       ▼
  субагент (СВОЙ контекст: 50 документов, черновая работа)
       │  возвращает выжимку на 300 токенов
       ▼
  главный агент ← +300 токенов вместо +40 000

Грязная работа — в изолированном окне, наверх — только результат.

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

Типичные ошибки

Шпаргалка

КОНТЕКСТ = ограниченный ДОРОГОЙ ресурс с убывающей отдачей (не бесконечная память)
  больше ≠ лучше: КАЧЕСТВО↓ (context rot) · СТОИМОСТЬ↑ · ЛАТЕНТНОСТЬ↑
  CONTEXT ROT: чем длиннее, тем хуже модель находит нужное
  «lost in the middle» — края работают лучше середины · ПОМЕЩАЕТСЯ ≠ РАБОТАЕТ

ЭКОНОМИКА АГЕНТА: каждый шаг шлёт ВЕСЬ накопленный контекст ЗАНОВО
  10 шагов ≠ 10×1k, а 1k+2k+3k+… → раздутый контекст бьёт тем сильнее, чем дольше работа

БЮДЖЕТ КОНТЕКСТА (лимит на каждую статью, + место под ОТВЕТ):
  system · описания tools · ИСТОРИЯ (растёт!) · RAG-документы · запрос

3 РЫЧАГА:
  ① СЖИМАЙ: sliding window (последние N) · summarization старого (накопительная сводка) ·
     ОБРЕЗКА TOOL-ВЫХОДОВ (самый дешёвый выигрыш!) · вынос деталей в файл/БД
     правило: инструмент возвращает ОТВЕТ, а не сырые данные
  ② ОТБИРАЙ: только релевантные tools (40 tools = тысячи токенов КАЖДЫЙ шаг) ·
     меньше, но точнее чанков (reranking > объём) · важное БЛИЖЕ К КОНЦУ
     вопрос не «влезет ли?», а «ИЗМЕНИТ ЛИ ЭТО ОТВЕТ?»
  ③ ИЗОЛИРУЙ: субагент со СВОИМ окном делает грязную работу → наверх выжимка (300 токенов
     вместо 40 000) · файлы как внешняя память · = «агент-как-инструмент» (модуль 05)

ГРАБЛИ: «окно большое — влезет всё» · безлимитная история · сырые tool-выходы ·
        все tools + top-50 чанков всегда

Практическое задание

Что дальше

Мы сократили контекст до необходимого. Но часть его неизбежно повторяется в каждом запросе: системный промпт, описания инструментов, инструкции. Платить за них заново на каждом шаге — расточительство, и провайдеры дают способ этого избежать. Следующий урок — prompt caching: как кэшировать неизменную часть промпта и экономить до 90% стоимости.