Перейти к содержимому

Контекст-инжиниринг

Контекст-инжиниринг (context engineering) управляет тем, что попадает в контекстное окно (context window) модели: какие файлы, какая история диалога, какие результаты инструментов. Если промптинг отвечает на вопрос «что я говорю агенту», то контекст-инжиниринг отвечает на вопрос «что агент видит вообще». Это следующий уровень после промптинга: даже идеально сформулированная задача провалится, если она утонула в сотне тысяч токенов мусора.

Почему это важно, объясняет страница Токены и контекстное окно: контекст конечен, и модель работает хуже, когда он забит. Здесь речь о практических следствиях.

Контекст «портится» постепенно, и полезно узнавать признаки:

  • Агент забывает начало. Вы договорились о подходе час назад, а он делает иначе: договорённость вытеснена или потерялась среди тысяч строк логов.
  • Агент путается. Смешивает две задачи, которые вы обсуждали в одной сессии; правит файл, который был нужен для предыдущего вопроса.
  • Агент повторяет ошибки. Вы уже показали, что подход А не работает, но неудачная попытка осталась в истории, и модель снова тянется к ней, потому что «видит» этот код перед глазами.
  • Ответы становятся вязкими. Больше общих слов, меньше конкретики, агент «соглашается» с вами вместо того, чтобы работать.

Если вы узнали свою сессию, проблема, скорее всего, не в модели и не в промпте, а в накопленном контексте.

Новая сессия на новую задачу. Самое простое и самое действенное правило. Закончили задачу, начните новую сессию, а не продолжайте в старой «раз уж всё открыто». Для новой задачи история прошлой становится чистым шумом, который стоит токенов и внимания модели.

Компакция (compaction). Когда сессия длинная, но бросать её нельзя, харнесы умеют сжимать историю: заменять подробный диалог кратким пересказом. Это освобождает окно, но детали теряются, поэтому после компакции полезно проверить, что агент всё ещё помнит ключевые договорённости, и повторить их одной фразой, если нет.

Знания храните в файлах, а не в диалоге. Всё, что должно пережить сессию, должно жить в файле, а не в истории чата: правила проекта в файле памяти (CLAUDE.md / AGENTS.md), текущий план в план-файле, промежуточные выводы исследования в заметке. Файл можно открыть в любой новой сессии; история диалога умирает вместе с сессией.

Интуиция «чем больше информации дам агенту, тем лучше» обманывает. Работает обратное: давайте ровно то, что нужно для текущего шага.

  • Ссылки на файлы вместо простыней. Не вставляйте в промпт тысячу строк кода или весь текст договора. Назовите путь к файлу. Агент прочитает сам, причём часто только нужную часть, и в контекст попадёт меньше лишнего.
  • Только нужные MCP-серверы и скилы. Каждый подключённый MCP-сервер добавляет описания своих инструментов в контекст ещё до начала работы. Десяток «на всякий случай» подключённых серверов стоит тысячи токенов налога на каждую сессию и добавляет лишние варианты действий, среди которых модель может выбрать неверный. Подключайте то, что нужно для задачи; остальное отключайте.
  • Отложенная подгрузка инструментов. Харнесы начали смягчать этот налог: описания попадают в контекст не все сразу, а по мере надобности, остальные агент находит поиском по каталогу инструментов. Это тот же приём, на котором работают скилы. Плату он уменьшает, но правило выше не отменяет: лишний сервер остаётся лишним вариантом действия, даже когда его описание не занимает места.
  • Субагенты для грязной работы. Объёмный поиск по кодовой базе или анализ логов можно поручить субагенту: он «сожжёт» свой отдельный контекст, а в ваш вернётся только краткий вывод.

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

Схема работы:

  1. Агент пишет план. «Изучи задачу и напиши план в plan.md: шаги, затронутые файлы, риски. Ничего не выполняй».
  2. Человек правит. Вы читаете план глазами, вычёркиваете лишнее, исправляете неверные предположения. Править план в разы дешевле, чем править код.
  3. Агент выполняет по плану, отмечая сделанные шаги прямо в файле.

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

Смысл в том, что план-файл работает внешней памятью, не зависящей от контекстного окна. Сессия переполнилась или прервалась? Новая сессия начинается с «прочитай plan.md, продолжи с шага 4», и агент в курсе дела через полминуты. Тот же файл служит и точкой передачи задачи коллеге.

Автор учебника: Шахматов Алексей