أطلقت Machine Learning Mastery دليلاً عن هندسة السياق للوكلاء الذكيين الموثوقين

Machine Learning Mastery выпустила практический гид по context engineering для AI-агентов — дисциплине, которая определяет, какие данные модель видит в каждый момент работы. Главный тезис статьи: продакшен-проблемы у агентных систем чаще связаны не с качеством модели, а с тем, как разработчики управляют контекстом, историей и токенами.

Почему агенты ломаются

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

Контекстное окно — это не обходное ограничение, а главный параметр дизайна агентной системы.

Отсюда и типичный сбойный сценарий: агенту просто «доклеивают» всё подряд — старые ответы, сырые tool outputs, дублирующиеся фрагменты из retrieval и устаревшие решения. В итоге растут задержка и стоимость, а полезный сигнал тонет в шуме. В статье это сравнивают с RAM: быстрая память мощная, но конечная. Всё, что не нужно агенту прямо сейчас, должно храниться во внешней памяти и попадать в контекст только по запросу.

Как собирать контекст

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

Динамическая часть — это текущий запрос пользователя, свежие результаты инструментов, последние шаги агента и документы, которые действительно нужны именно на этом этапе. Перед сборкой промпта автор советует сделать аудит всех слоёв, которые обычно заполняют context window: системные инструкции и few-shot-примеры; история диалога, ответы агента и результаты tool calls; внешние данные из базы знаний, файлов или поиска; рабочее состояние: промежуточные выводы, план, next steps. Практический вывод простой: не надо минимизировать каждый слой любой ценой, нужно убирать только то, что не помогает текущему шагу.

Полезной выглядит двухпроходная схема. Сначала система поднимает постоянный каркас: system prompt, кэшируемые правила, долгоживущие summary. Затем дозагружает переменную часть: актуальное состояние задачи, свежий retrieval и короткий релевантный хвост истории.

Такая сборка ещё и упрощает отладку, потому что сразу видно, проблема в конфигурации или в данных текущей сессии.

Как контролировать качество

Отдельный блок статьи посвящён двум зонам, где агенты деградируют быстрее всего: истории диалога и retrieval. Простое накопление всей переписки быстро раздувает контекст и закрепляет ошибки модели как будто это факты. Автор советует уходить от сырой истории к rolling summary или даже к структурированному session state, где отдельно фиксируются намерение пользователя, принятые решения, выполненные действия и следующий шаг.

Это даёт агенту память без бесконечного роста токенов. С retrieval логика похожая: каждая найденная пачка данных расходует бюджет, поэтому её нельзя считать бесплатной. В статье рекомендуют фильтровать результаты до вставки в промпт, использовать semantic chunking вместо нарезки фиксированными кусками и, где нужно, совмещать семантический поиск с keyword- или metadata-фильтрами.

Для зрелых систем более сильным вариантом считается agent-controlled retrieval, когда сам агент вызывает поиск только в тот момент, когда он реально нужен, а не автоматически на каждом ходе. Для продакшена автор предлагает измерять не только финальный ответ, но и качество самого контекста. Среди полезных метрик — заполнение бюджета токенов, степень сжатия после summary, точность retrieval и признаки context drift, когда агент начинает перечитывать уже обработанные файлы или уходит от исходной задачи.

Ещё один практический приём — probe-based evaluation: после сжатия или retrieval системе задают контрольные вопросы, чтобы проверить, сохранились ли нужные факты, артефакты и возможность продолжить многошаговую задачу с того же места.

Что это значит

Гайд Machine Learning Mastery хорошо фиксирует сдвиг в агентной разработке: качество AI-агента теперь зависит не только от выбора модели, но и от того, насколько дисциплинированно устроены память, retrieval и бюджет токенов. Для команд, которые выводят агентов в прод, это прямой сигнал проектировать контекст как отдельный слой архитектуры, а не как хвост промпта.