§7.06 Проектирование контекста для агента
Время: 45 мин чтение + 30 мин
В одном предложении: Человек думает, что качество ответа агента зависит от модели, а на самом деле половина успеха — в проектировании контекста: что написать, что включить, как сжать и что отделить.
Мем, который снимается. «Я просто напишу вопрос агенту. Он умный — разберётся. Зачем тратить время на формулировки?» Эта установка исходит из опыта общения с людьми: мы привыкли, что собеседник дочитывает между строк, помнит предыдущие разговоры, понимает наш контекст. Агент не делает этого автоматически. У него нет памяти о ваших прошлых задачах, если вы её не предоставили. Он не знает ваших приоритетов, если вы их не сформулировали. Каждый запрос — это начало нового разговора, если только вы не спроектировали контекст.
Понятия. Context Engineering — проектирование информационного окружения запроса к агенту для получения качественного ответа. Prompt — формулировка запроса: что именно попросить, в какой форме, с какими ограничениями. Контекстное окно — объём информации, который агент может обработать за один запрос; ограниченный ресурс, требующий приоритизации. Хороший контекст проектируется по четырём принципам: Write — что написать в запросе; Select — какую информацию включить из внешних источников; Compress — как сжать большой контекст до размеров окна; Isolate — какие части контекста отделить в отдельные запросы или MCP-подключения.
Объяснение. Проектирование контекста — это не «красивые слова», это архитектура информационного потока. Первый принцип — Write: чёткая формулировка задачи с критериями качества. Не «посмотри код» — а «найди три потенциальных источника утечки памяти в этом модуле и ранжируй по критичности». Второй — Select: агенту не нужно знать всё. Из всего Pack выберите только то, что релевантно задаче. Лишний контекст — это шум, который снижает качество ответа. Третий — Compress: если контекст не влезает в окно, его нужно сжать. Сжатие — не удаление, это структурирование: вместо полного текста дайте оглавление, вместо истории коммитов — список ключевых изменений, вместо файла — его структуру с пометками. Четвёртый — Isolate: не всё нужно передавать в одном запросе. Статический контекст (архитектура, соглашения) можно вынести в MCP-подключение или системный промпт. Динамический контекст (текущая задача, конкретные файлы) передаётся в запросе. Разделение статического и динамического снижает нагрузку на окно и повышает предсказуемость ответов. Хороший контекст — это половина успеха. Плохой контекст может сделать бесполезным даже самый продвинутый запрос.
На практике. Практика «Перепроектируй запрос» (30 мин):
- Найдите один недавний запрос к агенту, ответ на который вас не удовлетворил. Перепишите запрос по принципу Write: добавьте критерии качества и формат вывода. (10 мин)
- Определите, какую информацию вы включили в запрос. Выберите только ту, которая необходима для задачи — уберите всё остальное (Select). Если контекст большой — сожмите: замените полные тексты на структуры или ссылки (Compress). (10 мин)
- Проверьте: есть ли в запросе статическая информация, которую можно вынести в системный промпт или MCP? Если да — вынесите (Isolate). Отправьте перепроектированный запрос и сравните ответы. (10 мин)
Типичный кейс. Продуктовый аналитик отправлял агенту запрос: «Проанализируй данные и скажи, что делать.» В ответ получал обобщённые рекомендации, которые не учитывали специфику продукта. Он перепроектировал контекст по четырём принципам. Write: «Проанализируй воронку конверсии с этапа просмотра до покупки за последние 30 дней. Выдели один этап с максимальным падением. Предложи две гипотезы причины и один способ проверки для каждой.» Select: вместо полного датасета приложил только структуру таблиц и определения ключевых метрик. Compress: историю изменений заменил на список трёх последних релизов с датами. Isolate: архитектуру продукта и бизнес-ограничения вынес в системный промпт, который подключал при каждом запросе по продукту. Результат: агент стал давать ответы, которые можно было использовать без доработки. Время на анализ сократилось с трёх часов до 40 минут.
Типичная ошибка. «Чем больше контекста, тем лучше ответ.» Люди склонны перегружать запрос информацией, потому что боятся, что агенту «чего-то не хватит». Но контекстное окно ограничено, и избыток информации снижает качество так же, как и недостаток. Агент не может отличить важное от второстепенного без вашей помощи. Другая ошибка: «Prompt Engineering — это манипуляция словами.» Нет. Хороший промпт — это не подбор волшебных формулировок, это чёткое описание задачи, критериев и формата. Это проектирование, а не магия.
Степени мастерства:
- Объяснение. Могу назвать четыре принципа Context Engineering и объяснить разницу между статическим и динамическим контекстом. Критерий перехода: перепроектировал один запрос по четырём принципам.
- Умение. Систематически применяю Write / Select / Compress / Isolate при подготовке запросов к агенту. Критерий перехода: десять запросов подряд с контекстом, спроектированным заранее.
- Навык. Автоматически замечаю, когда запрос неудачен из-за контекста, и перепроектирую его без чеклиста. Критерий перехода: коллега обратилась ко мне за помощью в формулировке запроса к агенту.
- Мастерство. Создаю шаблоны контекста для типовых задач: системные промпты, MCP-подключения, структуры Pack, которые позволяют любому пилоту получать качественные ответы. Критерий перехода: новый пилот в команде получил качественный ответ от агента по моему шаблону без моего участия.
Проверка себя.
- Могу назвать четыре принципа Context Engineering и применить их к текущему запросу
- В последнем запросе к агенту я заранее продумал, какую информацию включить и какую убрать
- Я замечаю, когда агент даёт общий ответ из-за плохого контекста, а не из-за ограничений модели
- У меня есть системный промпт или MCP-подключение для повторяющихся типов задач
На практике. Возьмите текущую задачу, которую хотите делегировать агенту. Прежде чем писать запрос, ответьте: Что именно я хочу получить? Какая информация критична? Как её сжать? Что можно вынести в системный промпт? Теперь напишите запрос. Сравните ответ с тем, что вы получили бы без подготовки.
См. также: Множественные агенты — PD.GUIDE.3.S4.SS4, Проектирование протоколов подключения — PD.GUIDE.3.S7.SS3.
Что дальше. Следующий подраздел — об эволюции IWE: как изменять среду системно, не разрушая её стабильность.