Рабочие агенты ошибаются чаще из-за неверного контекста в неверный момент, чем из-за слабой модели, и InfoQ предлагает рассматривать контекст как control plane. Главный вопрос — что агент должен знать, когда он должен это знать, как долго помнить и что следует забыть. Специальный context engine должен отбирать, фильтровать, ранжировать, сжимать и защищать информацию до вызова LLM. Для бизнеса это переносит работу от составления промптов к системному инжинирингу.
От поиска данных к управлению контекстом
В статье разделены три слоя: контекст, знания и память. Контекст описан как control plane, управляющий слой с организационными, поведенческими и ситуационными данными о том, кто, что и почему. Знания — это официальный учебник: политики, управление, ключевая бизнес-логика и базы данных. Память связывает исторические данные и сигналы реального времени в состояние, готовое для рассуждений в текущей задаче. Неверный контекст резко повышает вероятность галлюцинаций модели.
Context engine находится внутри этого управляющего слоя и работает как оркестратор вокруг модели. Он забирает данные из знаний, упорядочивает их в памяти и определяет, что нужно агенту в конкретную миллисекунду. До генерации он проверяет подлинность входных данных, сверяет их с бизнес-логикой, удаляет персональные данные PII и изолирует их в песочнице. Используется аналогия с компилятором: сырые, исторические и живые данные переводятся в структурированное состояние. Так создается более детерминированная основа для вероятностных рассуждений.
Архитектура должна согласовать историческую память и ввод в реальном времени. Историческая память включает прошлые взаимодействия, принятые решения, предпочтения пользователей, правила предметной области, документацию и накопленные наблюдения, обеспечивая непрерывность. Ввод в реальном времени включает текущую задачу, последние события, живую телеметрию, свежие выводы инструментов и изменения среды, удерживая агента в настоящем. Пример — DevOps-агент при сбое сервера: руководства runbook из векторной базы недостаточно без потока журналов ошибок за последние пять секунд. Пакетные и потоковые источники нужно объединять асинхронно.
Что это меняет для рабочих агентов
Для компаний, переходящих от чат-ботов к автономным агентам, работающим с инструментами, сессиями, пользователями и живыми системами, следствие носит архитектурный характер. Перекос в историю делает агента устаревшим, переносящим вчерашние допущения в сегодняшнюю реальность. Перекос в живые сигналы делает его реактивным и забывчивым, теряющим широкий смысл. Небольшие команды получают четкое разделение durable-состояния и transient-событий, а крупные организации — шаблон управления многими агентами через один слой контекста вместо жестких правил в каждом приложении.
Второе следствие касается стоимости и надежности поиска. В статье критикуется подход SELECT *, когда больший объем данных кажется лучшим, характерный для стандартных RAG-конвейеров с фрагментированными чанками в промпте. Приводится иллюстрация: десять неотредактированных wiki-страниц скрывают нужный сигнал и тратят вычислительные ресурсы. Альтернатива — курирование знаний через фоновые воркеры и ML-конвейеры, которые очищают, агрегируют и ранжируют данные по релевантности. Один из названных приемов — сведение миллиона записей к одной записи каждые 12 часов в графы знаний или краткие сводки.
Признаком закрепления тренда станет появление у вендоров и платформенных команд context engine с фильтрацией, ранжированием, сжатием, обработкой PII и слиянием пакетных и потоковых данных, а не только продажа больших контекстных окон. Внедрение курируемых конвейеров знаний с cadence около 12 часов и доказанное слияние эпизодической и сенсорной памяти в таких задачах, как разбор сбоев, подтвердит сдвиг. Без этих механизмов агенты останутся дорогими, шумными и склонными к галлюцинациям.
