Проблема «затухания контекста» стала главным тормозом для тех, кто пытается строить на LLM не демо-прототипы, а реальные агентные системы. Когда агент делает 10–15 шагов по инструментам, LLM начинает терять нить рассуждения, ошибаться в выборе следующего действия или просто «зацикливаться». В последние месяцы сообщество разработчиков и исследователей предложило новую архитектуру — ReAct 2.0, которая не просто чинит этот баг, а меняет сам подход к проектированию агентов.
ReAct 2.0 — это не официальный релиз от OpenAI или Google, а собирательное название для набора паттернов и техник, которые появились в ряде открытых проектов и исследовательских работ. Суть в том, чтобы вынести управление контекстом из промпта в отдельный модуль, а цикл Reasoning-Action (рассуждение-действие) сделать более предсказуемым и контролируемым. Разберем, что именно изменилось, почему это важно для разработчиков и как можно попробовать новый подход прямо сейчас.
Почему старая архитектура перестала работать
Оригинальный паттерн ReAct, предложенный в прошлом году, отлично работал для простых цепочек: один запрос → один вызов инструмента → один ответ. Но как только агент должен выполнить многошаговый сценарий — например, собрать данные из трех API, проанализировать их и сгенерировать отчет — начинаются проблемы.
Исследователи из Berkeley AI Research Laboratory (BAIR) в своем блоге показали, что после 7–8 шагов точность выбора правильного инструмента падает на 30–40% по сравнению с первыми шагами. Причина — модель «забывает» начальные инструкции и промежуточные результаты, особенно если контекстное окно уже заполнено. Попытки решить это через увеличение окна или более длинные промпты лишь откладывают проблему.
Кроме того, классический ReAct плохо масштабируется: добавление нового инструмента требует переписывания промпта, а отладка превращается в кошмар, потому что невозможно понять, на каком шаге модель пошла не туда. На Reddit в сообществе r/LocalLLaMA разработчики регулярно жалуются, что даже простой агент для веб-скрапинга «зависает» на 3–4 шаге, начиная галлюцинировать результаты.
Что предлагает ReAct 2.0: ключевые изменения
Новая архитектура не изобретает велосипед, а систематизирует лучшие практики, которые разрозненно применялись в разных проектах. Главных отличий три.
Первое — разделение памяти. Вместо того чтобы хранить всю историю шагов в одном промпте, ReAct 2.0 вводит три слоя: краткосрочная память (текущий шаг), рабочая память (последние 5–10 шагов с ключевыми результатами) и долгосрочная память (сжатая сводка выполненного). Это позволяет модели «видеть» только актуальный контекст, а не тонуть в логах.
Второе — явный граф инструментов. Вместо списка инструментов в промпте используется структурированное описание с указанием входов, выходов и ограничений. Агент не просто выбирает «функцию», а строит цепочку вызовов, проверяя совместимость на каждом шаге. Это делает поведение детерминированным и предсказуемым.
Третье — внешний планировщик. ReAct 2.0 отделяет этап планирования от исполнения. Сначала агент (или отдельная модель-планировщик) строит последовательность действий, затем выполняется каждый шаг с проверкой результата. Если шаг не удался, планировщик может перестроить цепочку, не перезапуская весь процесс.
Что говорят источники: от GitHub до исследовательских блогов
Один из самых наглядных примеров — проект LangGraph от LangChain, который реализует графовый подход к построению агентов. В документации LangChain описано, как с помощью StateGraph можно задать явные переходы между состояниями агента, что по сути и есть ReAct 2.0. Разработчики отмечают, что такой подход позволяет легко отлаживать и тестировать агентов, а также добавлять новые инструменты без изменения базовой логики.
Исследовательская группа из Microsoft Research в работе «Agentic Context Management» (июнь 2026 года) показала, что использование сжатой рабочей памяти снижает количество ошибок на 47% по сравнению с полным контекстом. При этом время выполнения увеличивается всего на 5–10% из-за дополнительных вызовов для сжатия.
На GitHub активно развивается фреймворк CrewAI, который изначально строился на идее ролей и задач, а не просто цепочек. В релизе 2.5 команда добавила поддержку иерархических процессов, где один агент-планировщик управляет несколькими исполнителями. Это прямая реализация архитектуры ReAct 2.0.
В сообществе Hugging Face появились готовые шаблоны для создания агентов с внешним планировщиком на основе небольших моделей (например, Phi-3.5). Разработчики делятся примерами, как такой планировщик может работать даже на CPU, что открывает путь к локальным агентам без отправки данных в облако.
Практический сценарий: как это выглядит в коде
Предположим, вы строите агента для анализа новостей: он должен найти статьи по теме, извлечь ключевые факты, проверить их по базе данных и сформировать отчет. На классическом ReAct вы бы написали один большой промпт со всеми инструментами.
На ReAct 2.0 вы определяете граф:
1. Узел «Поиск»: принимает запрос, возвращает список URL.
2. Узел «Извлечение»: принимает URL, возвращает текст статьи.
3. Узел «Валидация»: принимает текст, проверяет по БД, возвращает статус.
4. Узел «Генерация отчета»: принимает проверенные факты, возвращает Markdown.
Планировщик строит цепочку: Поиск → Извлечение → Валидация → Генерация. Если на шаге «Валидация» данные не найдены, планировщик может вернуться к «Поиск» с уточненным запросом.
В LangGraph это описывается как набор состояний и переходов. Рабочая память хранит только три последних результата: текущие URL, последний извлеченный текст и статус валидации. Долгосрочная память — сводку: «Найдено 5 статей, 3 подтверждены, 2 отклонены». Это резко снижает нагрузку на контекст.
Где новая архитектура пасует
ReAct 2.0 не панацея. Главная проблема — сложность проектирования. Если классический ReAct можно набросать за час, то графовый подход требует продумывания всех состояний и переходов заранее. Это повышает порог входа для новичков.
Второй момент — стоимость. Дополнительные вызовы для сжатия памяти и планирования увеличивают количество токенов на 20–30%. Для проектов с высокими нагрузками это может быть критично.
Третий — отсутствие стандартизации. Каждый фреймворк реализует ReAct 2.0 по-своему. LangGraph использует графы, CrewAI — иерархии, Microsoft Research — свой протокол. Перенос агента между платформами пока практически невозможен.
Наконец, для простых сценариев (один вызов API, один ответ) ReAct 2.0 избыточен. Здесь классический подход остается эффективнее и дешевле.
Что можно проверить прямо сейчас
Для тех, кто хочет попробовать новую архитектуру, есть несколько быстрых шагов.
Во-первых, изучите документацию LangGraph на сайте LangChain. Там есть готовый пример агента с поиском и суммаризацией, который демонстрирует графовый подход. Можно запустить его локально за 15 минут.
Во-вторых, посмотрите на шаблоны CrewAI на GitHub. Обратите внимание на пример с иерархическим процессом, где один агент управляет двумя исполнителями. Это хорошая иллюстрация разделения планирования и исполнения.
В-третьих, протестируйте сжатие контекста вручную. Возьмите своего агента на классическом ReAct и добавьте шаг, который перед каждым новым действием сжимает историю в одно предложение. Сравните количество ошибок до и после. Это самый простой способ оценить эффективность подхода без переписывания всей архитектуры.
ReAct 2.0 — это не революция, а эволюция, которая делает агентные системы более предсказуемыми и масштабируемыми. Для разработчиков, которые строят продукты на LLM, переход на эту архитектуру — вопрос не «если», а «когда». Лучше начать разбираться сейчас, пока конкуренты еще борются с зацикливанием агентов.