Инженерия контекста. Единственная инженерия, которая имеет значение в эпоху ИИ агентов.

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

Сегодня существует около 8000 стартапов, созданных через vibe-coding, которым уже требуется рефакторинг стоимостью от 50 000 до 500 000 долларов. По данным Forrester, 75% технических руководителей столкнутся с серьёзным техническим долгом от AI-генерированного кода к концу года.

Промпт инженерия учит задавать лучшие вопросы. Инженерия контекста учит строить лучшие среды. Разница принципиальна.

Идеальный промпт внутри сломанного контекста всё равно производит мусор. Посредственный промпт внутри богатого и структурированного контекста стабильно даёт полезный результат.

Решением стали:

компактация контекста
структурированные заметки
мультиагентные архитектуры, управляющие тем, что попадает в окно

Инженерия контекста — это дисциплина проектирования того:

какая информация достигает модели
когда она появляется
в какой структуре

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

Она состоит из трёх слоёв:

Selection что попадает в окно контекста
Architecture как информация структурирована
Lifecycle когда контекст обновляется

Причина известна: загрязнение контекста накапливается. Один выдуманный факт в окне создаёт новые выдуманные факты дальше по цепочке.

По мере роста задачи управление контекстом становится всей задачей. Когда контекст деградирует, деградирует всё остальное.

Практически каждая AI-ошибка относится к одному из этих типов.

В окно попадает устаревшая или выдуманная информация. Модель доверяет своему контексту. Если там ошибка, вся последующая цепочка наследует её.

Слишком много нерелевантной информации. Окно в 200k токенов не помогает, если 180k из них шум. Модель не различает важное и второстепенное и распределяет внимание почти равномерно.

Слишком много инструментов и инструкций. MCP сначала усугубил эту проблему. Если системный промпт содержит 50 определений инструментов, модель тратит внимание на ненужные инструменты вместо задачи.

Противоречивые инструкции в одном окне. Например СLAUDE.md говорит использовать pnpm, README говорит использовать npm.

Модель начинает переключаться между ними. Так команды получают непоследовательное поведение агентов между сессиями.

Не всё должно находиться в окне одновременно. Модель должна находить нужную информацию, а не получать её заранее.

архитектура системы
код-конвенции
доменные знания

Каждая категория хранится отдельно. Модель загружает только то, что нужно для текущей задачи.

project/ ├── CLAUDE.md # architecture + boundaries ├── .claude/ │ └── memory/ │ ├── MEMORY.md # routing document (< 200 lines) │ ├── patterns.md # confirmed conventions │ ├── decisions.md # architectural choices with reasoning │ └── debugging.md # solutions to recurring problems ├── docs/ │ ├── architecture.md # system design (the model's map) │ └── domain/ # business logic the model needs └── src/ # the actual code

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

В более чем половине эффективных спецификаций агента контекст занимал больше места, чем инструкции.

Плоский контекст масштабируется линейно. Один новый факт добавляет одну единицу ценности. Граф знаний масштабируется комбинаторно.

Именно это нужно агентам для навигации по базе знаний. Основной паттерн:

atomic notes один концепт на файл
wikilinks связь выражена текстом ссылки
maps of content документы-навигаторы
metadata фильтрация и уровни глубины
prose-as-title названия как утверждения

Любая компания уже является графом. Вопрос только в том, можно ли по нему перемещаться. Организационные знания обычно разбросаны:

Slack-треды
десятки версий Google Docs
заброшенные страницы Notion
знания в головах сотрудников

company/ ├── org/ │ ├── decisions/ # every decision with reasoning attached │ ├── strategy/ # vision, positioning, open dilemmas │ ├── competitors/ # competitive landscape │ └── risks/ # threats with triggers and mitigations ├── teams/ │ ├── engineering/ # standards, architecture, runbooks │ ├── marketing/ # campaigns, positioning, analytics │ └── sales/ # playbooks, objections, win-loss ├── projects/ │ ├── product-alpha/ │ │ ├── prd/ # product spec as a graph of claims │ │ ├── features/ # backlog → shipped lifecycle │ │ ├── repo/ # the actual codebase │ │ └── decisions/ # architectural choices │ └── product-beta/ ├── research/ # deep domain knowledge ├── transcripts/ # mined meeting conversations └── CLAUDE.md # teaches the agent how your company works

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

В хорошо структурированном графе агент может:

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

Фактически агент начинает рефакторить собственные инструкции. Инженерия контекста не является одноразовой настройкой. Это живая система, которая улучшается каждый раз, когда агент работает.

Если вынести одну идею из этой статьи, она проста:

Аудит CLAUDE.md. Это конфигурационный файл или обучающий документ? Перепишите его как онбординг для старшего инженера.
Разделите контекст: архитектура, код-конвенции и доменные знания должны храниться отдельно.
Добавьте прогрессивное раскрытие. MEMORY.md должен быть навигационным документом до 200 строк.
Называйте файлы как утверждения. Имя файла должно отвечать на вопрос «это мне нужно читать?».
Извлекайте знания из встреч. Записывайте обсуждения, извлекайте решения и добавляйте их в граф знаний.
Позвольте агенту поддерживать систему. Настройте проверки на противоречия, устаревший контекст и структурный дрейф.
Измеряйте здоровье контекста. Следите за метриками: время повторного объяснения, уровень дрейфа агента, консистентность решений между сессиями. Если агент задаёт один и тот же вопрос дважды, значит в архитектуре контекста есть дыра.