Самое актуальное слово в маленьком мире агентов ИИ — это контекстная инженерия.

Кажется, что придумали еще один лейбл, чтобы продавать то, что мы уже делали. Частично это так. Однако, как это часто бывает, ярлык приживается, потому что он дает название настоящей боли.

Боль вот в чем: модели не терпят неудачу только потому, что они «не думают». Они часто терпят неудачу, потому что мы отправляем их работать не в ту комнату.

Мы даем им старые инструкции. Мы скрываем от него важные файлы. Мы передаем им слишком длинные документы, в которых не говорится о главном. Мы показываем им логи без приоритета. Мы даем им десять инструментов, не объясняя, когда их использовать. Затем мы удивляемся, если агент движется как человек, проснувшийся в неизвестной квартире.

Подсказка — это фраза, которую вы ему говорите. Контекст — это мир, который вы готовите вокруг него.

От оперативного проектирования к контекстному проектированию

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

Контекстная инженерия ближе к архитектуре.

Вы не просто спрашиваете «как мне сформулировать запрос?». Он спрашивает:

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

Это тонкое, но огромное изменение. Потому что когда вы работаете с агентами, контекст не является статическим блоком. Оно меняется на каждом шагу.

Агент открывает файл, что-то изучает, запускает тест, получает ошибку, обновляет план, вызывает инструмент, обнаруживает зависимость. На каждом круге ему приходится решать, что взять с собой, а что оставить.

Это инженерия.

Контекст не свалка

Шаблоны с большими контекстными окнами вызвали у нас искушение: давайте закинем все подряд.

Это понятно. Если у меня есть миллион токенов, почему я должен выбирать?

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

Хороший контекст имеет иерархию:

1. системные инструкции и политики;
2. конкретная цель;
3. текущий статус;
4. соответствующие данные;
5. ограничения;
6. доступные инструменты;
7. отслеживать уже принятые решения.

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

Контекстная инженерия также означает присвоение весов, а не только данных.

Память: запоминайте меньше, запоминайте лучше

Память у агентов — одна из самых скользких тем.

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

Полезная память должна обладать как минимум тремя качествами:

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

Без этих трёх вещей память становится суеверием.

Мне нравится думать об агентной памяти как о рабочей тетради, а не как о волшебном разуме. Есть временные заметки, подтвержденные решения, стилевые предпочтения, технические ограничения, ссылки на источники. Некоторые вещи устаревают. Некоторые придется переписать. Некоторых необходимо устранить, поскольку агент неправильно их понял.

Хорошая система должна сделать это обслуживание нормальным. Не героический.

Извлечение и инструменты — это не одно и то же.

Когда мы говорим о контексте, мы часто сразу оказываемся на RAG. Встраивание, векторная база данных, фрагментирование, переранжирование.

Все полезно. Но извлечение — это только один из способов внести информацию в модель. Он не единственный.

Агент может получить контекст, читая файлы, запрашивая API, вызывая сервер MCP, открывая браузер, запуская тесты, выполняя поиск в Slack, просматривая панель управления и спрашивая человека.

Самое интересное — решить, какой маршрут использовать и когда.

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

Контекст — это не база данных. Это рабочий процесс.

Хороший агент тоже умеет игнорировать

Признаком зрелости агентов будет способность сказать: мне не нужна эта информация.

Это кажется тривиальным, но это очень сложно. Многие агентные системы накапливаются. Каждый вызов инструмента добавляет текст. Каждая ошибка остается в буфере. Каждое чтение файла добавляется в стек. В конце концов, у модели очень долгая история и нет карты.

Сжатие необходимо. Необходим промежуточный синтез. Его необходимо структурировать.

Не «вот и все, что было», а:

• цель все еще актуальна;
• текущая гипотеза;
• файлы уже проверены;
• принятые решения;
• открытые риски;
• следующее действие.

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

Разработка контекста для команд, а не для оперативных исполнителей

Причина, по которой эта тема меня интересует, заключается в том, что она перекладывает ответственность с человека на систему.

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

Чистый репозиторий становится лучшим контекстом. Хорошо написанная тема становится лучшим топливом. Обновленный модуль Runbook экономит токены и избавляет от беспокойства. Четкий журнал изменений уменьшает галлюцинации.

Это хорошая и несколько неприятная новость. Красиво, потому что вознаграждает за хорошие практики. Неудобно, потому что умной подсказкой все не решить.

Агенты усиливают гигиену системы, которую они обнаруживают.

Как бы я применил это завтра

Если бы мне пришлось внедрить контекстную инженерию в реальный проект, я бы начал с мелочей:

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

Тогда я бы измерил простую вещь: сколько раз агенту приходится просить разъяснений или уходить не в ту сторону?

Если это происходит часто, я бы не стал сразу добавлять модель большего размера. Я бы посмотрел на контекст.

Мое чтение

Да, контекстная инженерия — немного раздутое слово. Но концепция здравая.

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

Человеческая часть такова: хорошая подготовка контекста — это форма заботы. Он говорит агенту, а также команде: «Я не хочу, чтобы вы гадали, я хочу, чтобы у вас было то, что вам нужно».

Меньше магии. Более чистая комната. Агентам это нужно так же, как и нам.

Источники

• Блог LangChain: Развитие контекстной инженерии
• Саймон Уиллисон: Контекстная инженерия
• [Протокол контекста модели: введение] (https://modelcontextprotocol.io/introduction)
• Антропный: создание эффективных агентов
• OpenAI: Новые инструменты для создания агентов