Что такое проактивные AI-агенты и почему они ломают привычную контекстную инженерию
Индустрия AI-агентов сошлась на одной рабочей схеме: языковая модель работает в цикле, вызывает инструменты и живёт внутри песочницы. Вокруг этой схемы сложился набор практик работы с контекстом. Следующий шаг, постоянные проактивные агенты с целями, ставит перед этими практиками вопросы, на которые у LangChain и у отрасли пока нет общих ответов.
Проактивный агент не запускается под одну задачу и не завершается вместе с ней. Он работает в фоне, слушает потоки событий или просыпается по heartbeat-сигналам, сам решает, когда действовать, и сам отправляет результат пользователю. Меняется не только рантайм. Меняется то, что и когда попадает в контекст.
Эту смену разбирает Харрисон Чейз (Harrison Chase), генеральный директор LangChain, в блоге In the Loop. Его наблюдение: за последние месяцы каждый разработчик агентов, с которым он общался, думал о проактивных, постоянно работающих, ориентированных на цели агентах. Пост вышел 2 ноября 2026 года: New context engineering challenges in late 2026. Дальше речь идёт о позиции практика и открытых вопросах индустрии, а не о готовых рецептах.
Чем агент под задачу отличается от постоянного агента с целями
Разница видна на уровне жизненного цикла. Агент под задачу получает запрос, делает несколько вызовов инструментов, возвращает ответ и завершается вместе со своим контекстом. Проактивный агент существует во времени: копит наблюдения, помнит прошлые решения, возвращается к незакрытым целям.
| Критерий | Агент под задачу | Проактивный агент |
|---|---|---|
| Триггер | Запрос пользователя | Событие в потоке или heartbeat |
| Время жизни | Минуты, до финального ответа | Дни и недели, без явного конца |
| Кто инициирует действие | Пользователь | Агент, исходя из целей |
| Что попадает в контекст | Известный сценарий | История, события, заметки о целях |
| Кто получает результат | Пользователь по запросу | Пользователь в любой момент |
Практическое следствие: у агента под задачу контекст можно спроектировать заранее, потому что сценарий известен. У постоянного агента сценарий заранее неизвестен, и контекст приходится собирать на ходу.
Почему контекстная инженерия становится центральной темой
Контекстное окно остаётся ограниченным ресурсом. Постоянный агент складывает туда историю диалогов, результаты вызовов инструментов, фоновые события и собственные заметки о целях. Через несколько дней работы это уже не помещается в окно целиком.
Контекстная инженерия решает, что держать в окне сейчас, что вынести в файлы, что сжать до выжимки и что записать в долговременную память. Когда агент жил минуты, эти решения казались технической деталью. Когда агент живёт недели, они определяют, сохранит он смысл задачи или начнёт путаться в собственных логах.
Типовая архитектура AI-агента: на чём сошлась индустрия
It feels like everyone is converging on the same agent architecture: an LLM, running in a loop, calling tools, running in a sandbox.
Формулировка Чейза точна: сходится архитектура, а не фреймворк. Модель, цикл вызовов, инструменты, песочница. Различия между продуктами остаются, каркас один.
LLM в цикле с вызовом инструментов и песочница: что это даёт на практике
Цикл выглядит так. Модель получает контекст, выбирает инструмент, получает результат, снова смотрит на контекст и решает, что делать дальше, пока не признает задачу закрытой.
Песочница ограничивает последствия. Код, работа с файлами, сетевые запросы выполняются в изолированном окружении, где агент не достанет до данных за пределами отведённой папки. Для агента, который пишет и запускает скрипты, это базовая гигиена, а не роскошь.
Примеры архитектуры: Claude Code вышел больше полутора лет назад и стал одним из первых громких продуктов на этой схеме. Deep Agents от LangChain запущен больше года назад и развивает тот же каркас. Унификация упрощает жизнь: практики, собранные под один harness, переносятся на другой, потому что базовые элементы совпадают.
Стандартные практики контекстной инженерии, которые уже устоялись
Чейз перечисляет набор приёмов, которые де-факто стали стандартными. Формального стандарта нет, есть общий знаменатель. Ниже, какую проблему решает каждый приём и где у него слабое место.
- Суммаризация: длинный диалог сжимается в выжимку, когда перестаёт помещаться в окно.
- Вынос больших результатов: вывод инструмента хранится вне контекста, в окно попадает ссылка или превью.
- Скиллы: инструкции подгружаются по мере необходимости, а не лежат в промпте все сразу.
- Поиск по инструментам: вместо полного каталога агент ищет нужный инструмент по описанию.
- Субагенты: шумная подзадача решается в отдельном контексте, наружу возвращается результат.
- Bash: одна оболочка закрывает файлы, пайпы, запуск скриптов и утилит.
Суммаризация диалогов и вынос больших результатов инструментов
Суммаризация спасает окно, но теряет детали. Сжатая выжимка не помнит точное имя переменной или номер строки в логе. Порог, после которого включается сжатие, подбирают под задачу: слишком ранний старт съедает детали, слишком поздний приводит к деградации рассуждений на забитом контексте.
Вынос результатов решает ту же проблему мягче. Инструмент вернул 4 тысячи строк логов или JSON на пару сотен килобайт, и складывать это в окно бессмысленно. Результат уезжает в файл, в контекст попадает путь и короткое превью. Агент вернётся к файлу, если данные понадобятся. В отличие от усечения, ничего не пропадает безвозвратно.
Как эти приёмы собираются в работающий harness, разобрано в материале Context Engineering в Deep Agents: offloading, суммаризация, skills, subagents, память в markdown-файле и middleware, через которые всё это встраивается в запуск.
Скиллы и поиск по инструментам: прогрессивное раскрытие
Скиллы для AI-агентов работают как справочник, который открывают на нужной странице. Пока навык не понадобился, в контексте висит его название и краткое описание. Понадобился, агент подгружает полную инструкцию. Сотня навыков перестаёт быть проблемой: в окне живут не сотни инструкций, а оглавление.
Поиск по инструментам агента решает похожую задачу для MCP-серверов и внутренних API. При десятках инструментов полный список с описаниями съедает контекст ещё до начала работы. Тогда в контекст кладут каталог, а нужный инструмент находят поиском.
Слабое место у обоих приёмов общее: добавляется шаг, и на этом шаге можно ошибиться. Агент выберет не тот навык или не найдёт инструмент по неудачному описанию. Экономия контекста обменивается на риск ошибки выбора.
Субагенты и Bash как основной инструмент
Субагент решает подзадачу в своём контексте. Основной агент получает сжатый результат, а не полторы тысячи строк поиска. Дешёвый способ изолировать шум.
Bash интереснее. Один инструмент заменяет десятки: чтение и запись файлов, grep, пайпы, запуск скриптов, обращение к CLI-утилитам. Меньше инструментов означает меньше описаний в контексте и меньше шансов запутаться в выборе. Плата за универсальность известна: оболочка требует песочницы и аккуратных прав, иначе агент получает доступ куда шире, чем нужно для задачи.
Новые проблемы проактивных агентов: обзор открытых задач
Постоянный агент с целями ломает привычные практики в шести местах. Список по Чейзу: баланс проактивности и навязчивости уведомлений; выбор того, что именно запоминать; асинхронная работа инструментов и субагентов; удержание цели на длинных горизонтах; риск, что агент начнёт слишком агрессивно оптимизировать цель вплоть до «читерства»; управление контекстом браузера.
Позиция автора прямая: готовых решений у LangChain и в индустрии нет, по крайней мере общих (пост Чейза). Дальше каждый пункт разбирается отдельно. Это карта проблем, а не список ответов.
Проактивность против навязчивости: как калибровать уведомления
Агент должен уметь отправлять результат пользователю сам. Без этого проактивность теряет смысл. При переизбытке уведомлений пользователь перестаёт их читать, и ценность фоновой работы исчезает. Калибровка «не слишком много, не слишком мало» остаётся сложной задачей контекстной инженерии, по словам Чейза.
Почему это задача контекста, а не настройка уведомлений. Решение, стоит ли беспокоить пользователя, опирается на то, что агент о нём знает: прошлые реакции, текущие цели, контекст общения. Отсюда практический вопрос: где и в каком виде эти знания хранятся, чтобы агент мог использовать их через неделю.
Два гипотетических сценария. Агент мониторинга цен заметил падение на 3 процента и отправил сообщение. Если пользователь трижды проигнорировал такие сообщения, следующий разумный шаг - не отправлять его вовсе или объединить с другими. Агент-ассистент почты нашёл письмо от ключевого клиента: здесь уведомление уместно сразу. Разницу между сценариями задаёт контекст, а не универсальное правило.
Готового решения нет.
Память AI-агента: структура данных и интеллектуальный слой
Модель Чейза простая и полезная. Система памяти делится на две части: структуру данных и интеллектуальный слой, то есть агента вокруг этих данных. Структуры обычно примитивные: файлы, а иногда одна строка. Вся сложность в слое, который решает, что туда писать и что оттуда читать.
Рабочий пример такой архитектуры с двухуровневой памятью, песочницей и прокси для секретов разобран в материале про внутренних агентов LangChain.
Что именно запоминать: две крайности и почему обе плохи
Здесь Чейз видит главную трудность интеллектуального слоя. Легко ошибиться в обе стороны. Агент, который не запоминает ничего, переспрашивает одно и то же и повторяет свои ошибки. Агент, который тащит в память каждую мелочь, забивает контекст мусором и теряет в нём важное.
Логика та же, что с уведомлениями: нужна калибровка, а не максимизация. Универсального критерия отбора нет. Разумная эвристика: писать в память то, что повлияет на будущие решения, а не то, что просто произошло. И даже она требует проверки на своём кейсе.
Асинхронность: длинные инструменты, субагенты и отзывчивость основного агента
Агенты работают всё дольше и общаются с системами, которые тоже работают всё дольше: инструментами и другими агентами. При этом основной агент, который разговаривает с пользователем, почти всегда должен оставаться отзывчивым к новым сообщениям.
Конфликт понятен на примере. Инструмент собирает данные 20 минут. Если вызов блокирующий, агент всё это время молчит, и пользователь решает, что процесс завис. Если вызов уходит в фон, нужно решить, куда придёт результат, как подшить его обратно в основной контекст и что делать, если за эти 20 минут пользователь поменял задачу.
Субагенты помогают с изоляцией, добавляя вопросы синхронизации: кто владеет результатом, как он попадёт в основной контекст, что случится с фоновой подзадачей при отмене цели. В доступном фрагменте поста Чейза раздел об асинхронности обрывается, поэтому конкретных архитектурных рекомендаций там нет. Вопрос открыт.
Отслеживание целей на длинных горизонтах и риск «читерства»
Агенту нужно помнить, зачем он работает. На длинном горизонте цель размывается: суммаризация сжимает формулировку, вынос данных в файлы убирает подробности, и через день агент продолжает активность, потеряв связь с исходной задачей.
Риск, который в разборе Чейза входит в список открытых вопросов, - слишком агрессивная оптимизация цели вплоть до «читерства». Агент начинает выполнять метрику вместо задачи. Типичные формы: закрыть тикет, не решив проблему; пройти тест, подогнав ответ под проверку; отчитаться о прогрессе, которого нет.
Оговорка по источнику: в доступном фрагменте поста этот пункт детально не раскрыт, поэтому механики и примеры выше даны как иллюстрация риска, а не как описание конкретных случаев от LangChain.
Что можно сделать на уровне практики: формулировать цель вместе с критерием приёмки и проверять результат по существу, а не по факту отчёта. Как выстроить такие проверки для автономной работы, подробно разобрано в материале про governance для агентной разработки.
Браузер как ключевой инструмент и управление контекстом: изображения против DOM
Для универсального агента браузер - главный путь к внешнему миру: сайты без API, формы, панели администрирования, личные кабинеты. Там же возникает отдельная задача управления контекстом браузера агента. Тезис о браузере как ключевом инструменте и о выборе между изображениями и DOM взят из разбора Чейза; в доступном фрагменте поста детали не приведены, поэтому ниже разбор самого компромисса.
| Подход | Что попадает в контекст | Плюсы | Минусы |
|---|---|---|---|
| DOM | Дерево элементов с атрибутами | Компактно, точные селекторы и клики | Ломается на динамической вёрстке, canvas и теневых компонентах |
| Скриншоты | Изображение страницы | Работает там, где DOM бесполезен | Дороже по токенам, нужна vision-модель, координаты кликов приблизительные |
DOM даёт структуру: агент видит кнопки, поля и ссылки как элементы с атрибутами. Контекст компактный, действия точные, отладка проще. Слабое место - хрупкость к изменениям интерфейса.
Скриншоты ближе к тому, как видит страницу человек, и работают в интерфейсах, где разметка ничего не говорит агенту. Плата - токены на изображения и меньшая точность попадания по элементам. Конкретных цифр по стоимости того и другого в источнике нет, и придумывать их не стоит.
Гибридизация выглядит логичным ответом: DOM для навигации и точных действий, скриншот для проверки результата. Но критерии переключения, бюджеты токенов и обработка ошибок остаются открытым вопросом.
Что делать разработчику уже сейчас: практические выводы
Общих решений новых проблем нет, это признаёт и автор разбора. Значит, работаем с тем, что устоялось, и аккуратно экспериментируем с остальным.
- Берите типовой каркас: LLM в цикле, инструменты, песочница. Свой рантайм оправдан только тогда, когда вы упёрлись в конкретное ограничение.
- Настройте базовые практики работы с контекстом до того, как агент начнёт жить долго: вынос больших результатов, суммаризация по порогу, скиллы, поиск по инструментам, субагенты.
- Давайте bash вместе с песочницей. Оболочка без ограничения прав - самый короткий путь к неприятностям на рабочей машине.
- Стройте память как простую структуру плюс слой решений: файлы, которые вы контролируете, и правила записи, которые можно пересмотреть.
- Проектируйте уведомления с явной калибровкой: порог важности, группировка, учёт прошлых реакций пользователя.
- Уводите долгие операции в фон и держите основной диалог отзывчивым. Заранее продумайте, как результат вернётся в контекст и что будет при отмене.
- Формулируйте цель с критерием приёмки и проверяйте результат по существу, чтобы агент не начал оптимизировать отчёт вместо задачи.
Для локальных LLM и self-hosted агентов эти практики переносятся почти без изменений. Файловая память и bash особенно уместны на домашнем сервере: данные лежат у вас, модель можно сменить, не потеряв накопленное. Песочница здесь обязательна, потому что агент с оболочкой и доступом к диску получает те же права, что и вы.
Если хотите собрать такой каркас своими руками, разбор архитектуры с кодом на Python и метриками latency, cost и reliability есть в материале Строим AI-агента с нуля.
Открытые вопросы проактивных агентов в 2026 году остаются открытыми (разбор Чейза). Рабочий путь один: измерить поведение своего агента на своём сценарии и подогнать пороги суммаризации, памяти и уведомлений под него, а не под дефолты фреймворка.