Чем context engineering отличается от промпт-инжиниринга
Промпт-инжиниринг - это работа над написанием и организацией инструкций для модели ради оптимального результата, дискретная задача, которую решают один раз. Context engineering - это набор стратегий по подбору и поддержанию оптимального набора токенов во время инференса модели, включая всю остальную информацию, которая туда попадает помимо самого промпта. Ключевое отличие: это не разовая, а повторяющаяся работа - этап курирования происходит каждый раз, когда решается, что именно передать модели.
Почему контекст - конечный ресурс: context rot
Производительность модели снижается по мере роста контекста. Это явление называют context rot: с увеличением числа токенов способность модели точно вспоминать информацию из этого контекста снижается. Причина - в архитектуре: трансформерные модели создают n в квадрате попарных связей для n токенов, и с ростом длины последовательности способность улавливать эти связи растягивается тонким слоем. К тому же модели обычно обучаются на более коротких последовательностях, поэтому у них меньше опыта и специализированных параметров именно для зависимостей на всю длину контекста. В итоге модели остаются вполне способными на длинных контекстах, но могут показывать сниженную точность в извлечении информации и рассуждениях на большом расстоянии.
Шаг 1. Найдите правильную высоту системного промпта
Эффективный системный промпт избегает двух крайностей. Первая - излишняя жёсткость: инженеры зашивают сложную, хрупкую логику, которая создаёт хрупкость и увеличивает сложность поддержки. Вторая - излишняя расплывчатость: слишком общие указания, не дающие модели конкретных сигналов о желаемом результате. Оптимум - достаточно конкретен, чтобы эффективно направлять поведение, но достаточно гибок, чтобы дать модели сильные эвристики.
На практике: организуйте промпт в отдельные секции через XML-теги или заголовки Markdown - например, background_information, instructions, ## Tool guidance. Начните с минимального промпта на лучшей доступной модели для вашей задачи, а затем добавляйте чёткие инструкции и примеры для улучшения результата, основываясь на паттернах сбоев, найденных при начальном тестировании.
Шаг 2. Спроектируйте инструменты по трём принципам
Инструменты должны быть экономными по токенам и поощрять эффективное поведение агента. Три требования к дизайну: самодостаточность и ясность - если человек-инженер не может однозначно сказать, какой инструмент нужен в конкретной ситуации, агент тоже не сможет; минимальное пересечение функций - избегайте раздутых наборов инструментов, покрывающих слишком много сразу; описательные параметры - входные параметры должны быть описательными, недвусмысленными и играть на сильных сторонах модели. Курирование минимально достаточного набора инструментов для агента улучшает надёжное сопровождение и прополку контекста в долгих взаимодействиях.
Шаг 3. Curate примеры вместо списка edge case
Вместо перечисления каждого частного случая соберите набор разнообразных канонических примеров, которые эффективно показывают ожидаемое поведение. Для языковых моделей примеры - это «картинки», которые стоят тысячи слов. Не набивайте промпт длинным списком частных случаев - несколько хорошо подобранных примеров работают эффективнее.
Шаг 4. Выберите стратегию для длинных задач
Компакция подходит задачам, требующим долгого обмена репликами: диалог, приближающийся к пределу окна контекста, сжимается в резюме, и открывается новое окно контекста с этим резюме. При настройке компакции сначала максимизируйте полноту - убедитесь, что промпт компакции захватывает каждую значимую деталь из истории, - а затем итеративно повышайте точность, убирая лишнее. Один безопасный приём компакции - очистка вызовов инструментов и их результатов: раз действие уже выполнено, агенту незачем видеть сырой результат снова.
Структурированные заметки подходят итеративной разработке с чёткими вехами: агент регулярно пишет заметки, сохраняемые вне окна контекста, и подтягивает их обратно позже - это позволяет отслеживать прогресс по сложным задачам, сохраняя критичный контекст и зависимости, которые иначе потерялись бы за десятки вызовов инструментов. У Anthropic есть memory tool в бете на Claude Developer Platform - файловая система, позволяющая агентам накапливать базу знаний со временем и сохранять состояние проекта между сессиями.
Архитектура с сабагентами подходит сложным исследованиям и анализу, где параллельное изучение окупается: специализированные сабагенты берут на себя фокусные задачи с чистым окном контекста, а основной агент координирует общую стратегию. Каждый сабагент может исследовать очень широко, используя десятки тысяч токенов и больше, но возвращает в основной поток только сжатую, дистиллированную выжимку - обычно 1000-2000 токенов. Это даёт чёткое разделение ответственности: детальный контекст поиска остаётся изолированным внутри сабагентов, а ведущий агент фокусируется на синтезе и анализе результатов.
Чек-лист
- Системный промпт не скатился ни в жёсткую хрупкую логику, ни в расплывчатые общие указания
- Инструменты агента самодостаточны, понятны и не пересекаются по функциям друг с другом
- Примеры в промпте - небольшой набор разнообразных канонических случаев, а не список всех edge case
- Для долгого диалога выбрана компакция, для итеративной разработки - заметки, для параллельного исследования - сабагенты
- При компакции сначала проверена полнота захвата важной информации, а потом убрано лишнее