Контекстная инженерия

Context engineering - это сбор нужной информации для LLM перед тем, как давать ей любое задание. Термин смещает фокус с промптинга на то, что именно попадает в контекстное окно, а не на то, как сформулирована инструкция. Формулировка важна, но содержимое важнее.

Главное наблюдение здесь такое: холодная LLM понятия не имеет, кто вы такой, какие решения уже приняты, как устроена кодовая база и какие действуют ограничения. Большинство некачественных ответов LLM связаны не с тем, что модель глупая, а с тем, что она пытается угадать недостающий контекст. Если передать ей нужный срез предыдущих решений, заметок со встреч, дизайн-документов и кода, результат почти всегда будет ощутимо лучше, чем от бесконечной переформулировки промпта.

Это главный аргумент в filesystem-is-graph-database. Rumproarious описывает markdown-vault на ~52 тысячи файлов не как базу знаний для поиска, а как "систему context engineering" - её ценность в том, что в каждый новый диалог можно сразу передать нужный срез накопленного контекста. Граф создаётся ради того, чтобы лучше был следующий диалог, а не текущий. Оценивать PKM-систему по тому, что из неё удаётся извлечь, - значит упускать главное; если же оценивать её по тому, насколько лучше становится каждое следующее взаимодействие с LLM, польза очевидна.

Context engineering пересекается со смежными темами, но не сводится к ним:

• RAG: поиск автоматически выбирает фрагменты (chunks) из векторного индекса. Context engineering ближе к ручному отбору, когда человек или LLM-агент сам решает, какие файлы загрузить. О том, где автоматический поиск даёт сбой, см. rag-limitations.
• Prompt engineering: фрейминг, ролевые инструкции, few-shot примеры. Context engineering отвечает за половину "загрузить правильные файлы", а prompt engineering - за "задать правильный вопрос".
• Память агентов: долгоживущие агенты, сохраняющие состояние между сессиями. Context engineering - это ориентированная на человека версия той же проблемы (см. agent-memory-decay).

Leonie Monigatti развивает это определение в agentic-search-context-engineering: для агента context engineering - это чаще всего не статичный шаг "загрузить вот эти файлы", а задача поиска. По её оценке, это примерно на 80% agentic-search. За одной стрелкой "курирование контекста" скрывается набор поисковых инструментов, которые агент сам решает вызывать по мере необходимости, обращаясь ко множеству источников (файлы, базы данных, веб, память) через их собственные механизмы поиска. При таком взгляде главный вопрос смещается с формулировки промпта на то, какие инструменты поиска нужны в вашем stack'е с учётом требований к задержке и качеству.

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

Свежий контекст как инструмент

ai-assisted-workflow применяет context engineering на уровне задач: каждая задача по реализации запускается в чистой AI-сессии, а не в рамках длинного непрерывного диалога. Логика проста: накопленный контекст приводит к дрейфу - модель начинает принимать решения на основе того, что она делала ранее, а не того, чего требует текущая задача. Запуск с чистого листа с чётко очерченной задачей (куда включён родительский issue для более широкого контекста) стабильно даёт лучший результат. Это context engineering "от обратного": понимать, что включать не нужно, не менее важно, чем знать, что добавить.