Контекстная инженерия: модный термин или реальный навык? Что за ним стоит

Каждая вторая рассылка — про context engineering. И каждая вторая врёт

Март 2026. Открываю ленту — «Context engineering — новый prompt engineering». Открываю статью — «структурируйте системный промпт, добавьте RAG, опишите инструменты». Закрываю статью.

Это не контекстная инженерия. Это форматирование промптов с красивым названием.

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

Почему на первый день всё работает, а на тридцатый — нет

Представьте: вы запустили AI-агента для DevOps-команды. День первый — контекст чистый, задача ясная, агент отвечает точно. День тридцатый — агент провёл 2 000 диалогов. Помогал деплоить, дебажить, настраивать базы. Каждое взаимодействие сгенерировало потенциально полезное знание.

Контекстное окно — те же 128K токенов.

Вопрос не академический. Вопрос конкретный: что засовывать в промпт прямо сейчас?

Пользователь две недели назад мигрировал с PostgreSQL на MySQL — этот факт ещё актуален?
В четверг был OOM-краш при деплое — это релевантно, если сейчас он пишет README?
Workflow деплоя менялся трижды после сбоев — какая версия текущая?

Вот это и есть настоящая контекстная инженерия. Не шаблоны промптов. Архитектура памяти. И у неё больше общего с проектированием операционных систем, чем с подбором слов для ChatGPT.

Почему «просто возьми векторную базу» — не ответ

Стандартный совет: загони всё в векторную БД, делай similarity search. Работает — до первого серьёзного кейса. Потом начинаются проблемы.

Проблема рецентности. Векторный поиск не знает, что вчера пользователь сменил стек. Старые факты по-прежнему «ближе» в пространстве эмбеддингов. Вы получаете рекомендацию по PostgreSQL, хотя человек уже на MySQL.

Проблема нарратива. События имеют временной порядок и причинно-следственные связи. «База упала» и «добавили шаг миграции» — связаны. Но только если вы знаете, что одно вызвало другое. Cosine similarity этого не видит.

Проблема статичности. Если процедура сломалась, её эмбеддинг не меняется. Система продолжает подтягивать битую инструкцию. Снова и снова.

Базы данных решали аналогичные задачи десятилетиями. Разные типы данных требуют разных стратегий хранения. Кэш — это не лог. Лог — это не индекс.

Архитектура, которая работает: три слоя памяти

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

Семантический слой — факты и предпочтения

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

Эпизодический слой — события с контекстом

Не просто «что было сказано», а «что произошло и чем закончилось». Таймстемпы, исходы, связи между событиями. Если в четверг был OOM-краш при деплое, а в пятницу увеличили лимиты памяти — эпизодический слой это помнит как связанную цепочку.

Процедурный слой — версионируемые воркфлоу

Тут начинается самое интересное. Рабочие процессы имеют версии. Когда шаг 3 ломается — процедура эволюционирует до v4 с фиксом. Старая версия не удаляется — она помечается как superseded.

Почему это важно: если отслеживать сбои процедур и автоматически их эволюционировать, агенты реально становятся лучше со временем. Вместо повторения одних и тех же ошибок — накопление рабочих решений.

Вопрос доверия, который все обходят

Статьи про context engineering стабильно игнорируют вопрос доверия. Если мы говорим о системах, которые сохраняют знания между сессиями, между пользователями, во времени — вопрос governance стоит остро.

Мой минимальный набор:

Прозрачность. Пользователь видит ровно то, что система о нём помнит. Без скрытых полей.
Self-hosting как опция. Не «мы думаем об этом», а «вот Docker-образ».
Редактируемость. Память можно изменить и удалить. Это не чёрный ящик.

«ИИ персонализирует ваш опыт» — недостаточное обоснование для персистентной памяти. «ИИ помнит, что прошлый раз этот паттерн деплоя вызвал OOM-краш, и вот 3-шаговый фикс, который сработал» — вот это обоснование.

Куда это движется

На ICLR 2026 — целый воркшоп по памяти для LLM-агентов. MCP перешёл под Linux Foundation. LangChain выпустил Deep Agents с явной архитектурой памяти.

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

Итого

Контекстная инженерия — не buzzword. Но 90% того, что под этим названием продают — buzzword чистой воды. Настоящая задача — не «как написать хороший промпт», а «как управлять знаниями агента, который работает месяцами и обслуживает тысячи сессий».

Это инженерная дисциплина. И она только начинается.