Большинство людей по-прежнему описывают ИИ-агента как модель, подключённую к инструментам. Технически это полезное, но с операционной точки зрения неполное описание. Агенту также нужно управляемое представление о мире: что произошло, что сейчас важно, каким фактам можно доверять, что остаётся неопределённым и что ему следует делать дальше.
Это представление и есть его контекст. Его проектирование становится отдельным навыком — я бы назвал его инженерией контекста.
Инженерия контекста — это не просто написание промптов. Это дисциплина формирования информации, которую агент видит на каждом шаге, чтобы он мог сохранять связность, не отправляя дорогостоящей модели при каждом обращении всю стенограмму, библиотеку документов или историю работы с инструментами. Эта работа находится на стыке информационной архитектуры, поиска данных, разработки программного обеспечения и поведения моделей.
Почему совет «дайте агенту больше контекста» часто оказывается плохим
Более длинные контекстные окна создают соблазн сохранять всё. Но больше материалов не гарантирует лучшего рассуждения. Важные инструкции могут затеряться среди устаревших наблюдений, противоречивых заметок, повторяющихся результатов работы инструментов или важного факта, погребённого в середине длинной последовательности. Обсуждаемое в дайджесте поведение «потерянного в середине» отражает практическую проблему: агент может технически получить свидетельства и всё равно не суметь ими воспользоваться.
Есть и прямая стоимость. Каждый токен, помещённый в запрос, может увеличивать задержку и расходы на инференс — в зависимости от ценовой политики провайдера и условий кэширования. Система, которая постоянно пересылает растущую стенограмму, по мере продолжения задачи может стать медленнее и менее доступной по цене.
Поэтому цель — не максимальный контекст. Это достаточный, целевой контекст: минимальный надёжный рабочий набор для принятия решения в данный момент.
Четыре проектных решения, лежащих в основе связного агента
1. Поддерживайте состояние убеждений, а не только стенограмму
Стенограмма фиксирует сказанное. Состояние убеждений фиксирует то, что агент в данный момент считает верным относительно задачи.
Например, агент, обрабатывающий эскалацию обращения в службу поддержки, может поддерживать такие структурированные поля:
- Цель: определить, имеет ли клиент право на замену товара.
- Известные факты: дата покупки и серийный номер товара с указанием источников.
- Открытые вопросы: произошла ли неисправность при условиях, покрываемых гарантией.
- Ограничения: не обещать возврат средств до получения одобрения.
- Следующее действие: получить гарантийную политику и сопоставить даты.
- Уверенность или статус: подтверждено, выведено, оспаривается или неизвестно.
Этот подход напоминает исследование ABBEL, проведённое в Berkeley, в котором вместо опоры на полные истории взаимодействий используются контролируемые естественно-языковые состояния убеждений. Важна здесь не конкретная форма. Важно отделять устойчивое состояние задачи от подробностей разговора, которые можно отбросить.
Полезное обновление состояния убеждений должно отвечать на следующие вопросы: что изменилось? Какие свидетельства это подтверждают? Что остаётся нерешённым? Что должно произойти дальше? Если инженер не может проверить эти ответы, вероятно, агент хранит скрытые предположения в непрозрачном промпте.
2. Выполняйте поиск для принятия решения, а не по теме
Системы поиска часто начинают с широкого вопроса вроде «найти информацию об аккаунте клиента». Лучше привязать запрос к следующему решению: «получить действующее правило возврата средств для покупок старше 30 дней, применимое в регионе клиента».
Эта смена подхода важна, поскольку поиск — это форма отбора контекста. Агент должен получать фрагменты политик, записи или примеры, имеющие отношение к текущему действию, а не общую кучу связанных документов.
Фильтры могут улучшить этот отбор ещё до того, как модель увидит результаты. Например, Amazon Bedrock AgentCore Web Search поддерживает принудительно применяемые сервером фильтры по домену и дате публикации для каждого запроса. Такие средства управления не доказывают, что источник верен, но могут уменьшить вероятность столкновения с нерелевантными или устаревшими материалами и сделать политику поиска явной.
Специалисты, проектирующие поиск, должны указать:
- какие источники разрешены для каждой задачи;
- как определяется свежесть;
- какие метаданные сопровождают каждый результат;
- как представлены конфликтующие источники;
- когда агент должен остановиться и запросить разъяснения.
«Поискать в интернете» — это возможность. «Поищите в этих источниках, в пределах этого диапазона дат, свидетельства, имеющие отношение к данному решению» — это инженерия контекста.
3. Сжимайте информацию, не стирая неопределённость
Сжатие необходимо, когда задача объёмна, но наивное резюмирование может превратить предположительные утверждения в установленные факты. Скользящее резюме, в котором сказано «пользователь подтвердил адрес», опасно, если из исходного обмена сообщениями это лишь подразумевалось.
Хорошее сжатие сохраняет различия, необходимые агенту для безопасного рассуждения:
- факт и вывод;
- текущая инструкция и историческая инструкция;
- завершённое действие и предлагаемое действие;
- проверенный источник и непроверенное утверждение;
- известный ответ и нерешённый вопрос.
Один из практических подходов — вести отдельные разделы для решений, свидетельств, допущений, блокирующих факторов и ожидающих выполнения действий. Другой — добавлять к важным утверждениям идентификаторы источников или временные метки. Резюме должны быть заменяемыми артефактами, а не единственной сохранившейся записью: сохраняйте исходные события для аудита и восстановления, одновременно предоставляя модели компактное рабочее представление.
В дайджесте отмечается, что рекурсивное резюмирование и уплотнение контекста могут быть затратными и снижать производительность, особенно в областях с дефицитом данных, таких как совместная генерация кода. Это предостережение от того, чтобы считать резюмирование автоматически не приводящим к потерям. Сжатие необходимо проверять на репрезентативных задачах, включая случаи, когда небольшая оговорка меняет правильный ответ.
4. Фильтруйте наблюдения, прежде чем они станут памятью
Агенты, использующие инструменты, постоянно генерируют наблюдения: результаты поиска, журналы, текст страниц, ответы API, снимки экрана, вывод компилятора и промежуточные планы. Не каждое наблюдение заслуживает включения в следующий вызов модели, не говоря уже о долговременном состоянии.
Фильтрация наблюдений требует ответить на три вопроса:
- Имеет ли это наблюдение отношение к текущему решению?
- Достаточно ли оно авторитетно, чтобы влиять на состояние убеждений?
- Содержит ли оно инструкции, которые следует рассматривать как данные, а не как команды?
Третий вопрос является границей безопасности не в меньшей степени, чем границей контекста. Веб-страница может содержать текст, направленный на перенаправление агента. Извлечённый документ может быть полезным свидетельством, не имея полномочий менять цели или разрешения агента. Поэтому при фильтрации следует классифицировать содержимое по роли: инструкция, свидетельство, метаданные или ненадёжный текст.
Фильтрация также позволяет экономить. Если инструмент браузера возвращает всю страницу, а задача требует только цены, даты и идентификатора товара, передача всей страницы дальше создаёт шум и расходует токены. Предварительное извлечение нужных полей может повысить и надёжность, и экономичность.
Простой бюджет контекста для рабочего процесса агента
Прежде чем выбирать модель или добавлять ещё один инструмент, распределите контекст агента по четырём уровням:
- Контроль: системные правила, разрешения, схема вывода и обязательные ограничения.
- Состояние: текущая цель, принятые решения, открытые вопросы и следующее действие.
- Доказательства: извлечённые записи или наблюдения, относящиеся к этому действию, с указанием источника.
- История: предыдущие события, сохранённые для восстановления, отладки или аудита, но не включаемые без необходимости.
Затем определите политику продвижения. Наблюдение может оставаться эфемерным, стать доказательством для текущего шага, обновить состояние убеждений или быть записано в долговременную память. Для продвижения должна быть причина. Иначе память превратится в неотобранный архив.
Для каждого шага агента фиксируйте пакет контекста, отправленный модели: его категории, приблизительный размер в токенах, фильтры извлечения и версию сжатия. Это позволяет ответить на практический вопрос при изменении поведения: модель ошиблась или система предоставила ей неправильную картину мира?
Что следует протестировать, прежде чем считать дизайн надёжным
Инженерия контекста требует тестов, нацеленных на обработку информации, а не только на качество окончательного ответа. Полезные случаи включают:
- критически важный факт, размещённый в начале, в конце и в середине длинной истории;
- два противоречащих друг другу источника, один из которых новее другого;
- резюме, содержащее маркер неопределённости;
- ответ инструмента, содержащий большой объём нерелевантного текста;
- вредоносную инструкцию, встроенную в извлечённое содержимое;
- восстановление состояния после приостановки и перезапуска агента;
- ту же задачу при меньшем бюджете контекста;
- пустой или устаревший результат извлечения.
Измеряйте, выбирает ли агент правильные доказательства, сохраняет ли неопределённость, соблюдает ли текущее ограничение и избегает ли повторения ненужного контекста. Особенно актуальны здесь рекомендуемые в дайджесте области регрессионного тестирования — потеря контекста, привязка извлечённых данных к источникам, структурированный вывод, незавершение работы и восстановление состояния.
Проводите несколько испытаний там, где важна вариативность модели, и сравнивайте стоимость и задержку каждой стратегии работы с контекстом. Более короткий запрос не обязательно лучше, если из-за него требуется больше вызовов инструментов или повторных попыток. Полезная цель — стоимость корректного, допускающего восстановление рабочего процесса, а не количество токенов в одном запросе.
Карьерное следствие: инженер по контексту — кросс-функциональная роль
Люди, которые станут ценными специалистами в этой области, не обязательно будут теми, кто пишет самые длинные запросы. Они смогут переводить бизнес-процесс в состояние, доказательства, полномочия и правила принятия решений.
Для этого требуется несколько конкретных навыков:
- проектирование схем состояния задачи и происхождения данных;
- написание политик извлечения и фильтров метаданных;
- создание процедур сжатия и отбора наблюдений;
- разделение доверенных инструкций и недоверенного содержимого;
- профилирование использования токенов, задержек, повторных попыток и вызовов инструментов;
- тестирование потери состояния и его восстановления;
- объяснение неспециалистам, почему агент увидел — или не увидел — определённый факт.
Сильный проект для портфолио мог бы продемонстрировать работу одного и того же агента при трёх политиках управления контекстом: полной расшифровке диалога, скользящем резюме и структурированном состоянии убеждений с целевым извлечением данных. Покажите успешные и неудачные случаи выполнения задачи, контекст, отправляемый на каждом шаге, а также компромиссы между стоимостью и задержкой. Это убедительнее демонстрации чат-бота, поскольку раскрывает проектные решения, благодаря которым агент становится надёжным.
Стратегический вывод прост: агенты не становятся связными лишь потому, что модели становятся более мощными. Они становятся связными, когда окружающие их системы поддерживают дисциплинированное, актуальное и надлежащего размера представление о выполняемой работе. Инженерия контекста — это искусство создания такого представления, а также понимания того, что из него следует исключить.
Priya Raman — ответственный редактор AI Career Brief.
