Запись архива

AI-агенты с LLM: когда автоматизация упирается в контекстное окно

Рост популярности AI-агентов на базе LLM сталкивается с узким местом — контекстным окном. Разбираем, почему долгие сессии и сложные цепочки вызовов ломают логику агентов и что с этим делают разработчики инструментов и провайдеры моделей.

Визуализация ограничения контекстного окна для AI-агентов с интерфейсом API и логами
Визуализация ограничения контекстного окна для AI-агентов с интерфейсом API и логами
Редакционная тематическая обложка COMRAD404

AI-агенты, построенные на больших языковых моделях (LLM), обещают полностью автономное выполнение многошаговых задач: от парсинга документов до генерации кода и развёртывания микросервисов. Однако каждый, кто пробовал запустить агента в production, рано или поздно упирается в стену — контекстное окно. Чем длиннее сессия, тем больше модель «забывает» начало диалога, путает инструкции и начинает галлюцинировать. Проблема не в качестве модели, а в фундаментальном ограничении архитектуры Transformer: фиксированном размере контекста.

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

Почему контекстное окно стало проблемой для агентов

Когда мы говорим про AI-агента, мы подразумеваем цикл: наблюдение → рассуждение → действие. Агент получает задачу, вызывает инструменты (API, базы данных, файловую систему), получает результат, анализирует его и делает следующий шаг. Весь этот диалог — все сообщения, все ответы инструментов, все промежуточные рассуждения — хранится в контекстном окне модели.

Проблема в том, что у GPT-4 Turbo контекст — 128K токенов, у Claude 3.5 Sonnet — 200K, у Gemini 1.5 Pro — до 2 млн токенов. Но цифры обманчивы. Исследования показывают, что модели «помнят» начало контекста значительно хуже, чем конец, а точность извлечения информации падает задолго до достижения лимита. В реальных агентных сценариях, где каждый вызов инструмента прибавляет тысячи токенов, проблема становится критической уже на 10-15 шагах.

Что говорят источники: три ключевых наблюдения

Официальная документация и блоги провайдеров моделей подтверждают, что контекстное окно — активно исследуемая область. Anthropic в своём гайде по построению агентов прямо указывает: «С увеличением числа шагов агент может терять из виду первоначальную цель или совершать неоптимальные действия». Компания рекомендует явно фиксировать цель в системном промпте и периодически напоминать агенту о текущем статусе задачи.

OpenAI в документации по Assistants API обсуждает механизм thread — цепочку сообщений, которая автоматически усекается при превышении лимита токенов. Однако усечение — грубое решение: модель теряет не только старые сообщения, но и контекст, необходимый для корректного завершения задачи.

Google DeepMind в статье «The Frontier of AI Agents» (2025) отмечает, что даже модели с 2M контекстом показывают деградацию производительности на задачах, требующих точного извлечения информации из середины контекста. Это особенно критично для агентов, которые работают с большими документами или кодом.

Практический сценарий: что ломается первым

Рассмотрим типичного агента для автоматизации техподдержки. Он получает запрос, проверяет базу знаний (2-3 документа), ищет в логах ошибки (ещё 2-3 запроса), генерирует ответ и отправляет его. На каждом шаге агент добавляет в контекст результат вызова инструмента — часто это полный текст документа или лога. Уже на пятом шаге контекст может превысить 50K токенов.

Вот что происходит дальше:

Шаг агента Действие Добавлено токенов Общий контекст Наблюдаемая проблема
1 Получение запроса 500 500
2 Поиск в БЗ (док 1) 15 000 15 500
3 Поиск в БЗ (док 2) 12 000 27 500
4 Поиск в логах 20 000 47 500 Модель «забывает» запрос
5 Генерация ответа 3 000 50 500 Ответ не релевантен запросу
6 Коррекция 5 000 55 500 Галлюцинации, цитирование несуществующих документов

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

Что делают разработчики: обзор решений

На уровне фреймворков и инструментов появилось несколько подходов к обходу ограничения.

LangChain в своей библиотеке LangGraph предлагает механизмы «persistent memory» и «conversation summarization». Вместо того чтобы хранить полную историю, агент периодически генерирует сжатое резюме предыдущих шагов и подставляет его в контекст. Это снижает нагрузку на токены, но добавляет риск потери деталей.

Microsoft AutoGen использует концепцию «agent orchestration», где несколько агентов общаются друг с другом через структурированные сообщения, а не через единый контекст. Каждый агент хранит только свою часть диалога, что ограничивает разрастание контекста для одной модели.

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

На стороне провайдеров моделей прогресс идёт медленнее. Anthropic внедрила в Claude 3.5 Sonnet механизм «prompt caching», который позволяет хранить системный промпт и часто используемые документы в кэше, не тратя токены на их повторную загрузку. Google Gemini 1.5 Pro с контекстом в 2M токенов частично решает проблему для задач, где нужен доступ к большим документам, но не спасает от деградации производительности на середине контекста.

Где проходят границы текущих решений

Ни одно из перечисленных решений не является серебряной пулей. Резюмирование теряет детали — если агент работал с кодом, сжатое описание может упустить важную переменную или вызов функции. Кэширование помогает только для статичных частей промпта, но не для динамически добавляемых результатов вызовов инструментов. Увеличение контекстного окна до 2M токенов не решает проблему «забывания середины» — модель всё равно хуже работает с информацией, расположенной в центральной части контекста.

Кроме того, все эти решения увеличивают задержку и стоимость: резюмирование требует дополнительного вызова модели, кэширование — дополнительной настройки, а большой контекст — больше токенов на каждый запрос. Для production-систем, где каждый лишний шаг означает рост времени ответа и затрат, это критично.

Что можно проверить уже сейчас

Если вы разрабатываете или используете AI-агентов, вот несколько практических шагов, которые можно сделать сегодня:

  • Замерьте среднюю длину контекста вашего агента после 10-15 шагов. Используйте логирование длины сообщений в токенах (большинство API возвращают usage-данные).
  • Проверьте, как модель ведёт себя на середине контекста: задайте агенту задачу, которая требует точного извлечения информации из 3-4 документа, и оцените точность на разных шагах.
  • Попробуйте явно добавлять в системный промпт инструкцию «перед каждым действием напомни себе текущую цель задачи». Anthropic рекомендует этот приём в своей документации.
  • Если используете LangChain или LangGraph, включите summarization и оцените, теряет ли агент важные детали после сжатия контекста.

Ограничение контекстного окна — не временная трудность, а фундаментальная архитектурная проблема Transformer-моделей. Пока не появятся модели с truly infinite context (а это, вероятно, потребует смены архитектуры), разработчикам агентов придётся проектировать свои системы с учётом этого ограничения. Хорошая новость в том, что инструменты для обхода проблемы уже существуют — но они требуют осознанного применения и тестирования под конкретный сценарий.