Одна из проблем при разработке долгоживущих AI-агентов - деградация качества решений по мере увеличения контекста.

Представим типичный сценарий. Агент получает задачу, System Prompt, набор инструментов и ограничения. Начинает выполнять действия, анализировать код, вызывать инструменты сохранять промежуточные результаты.

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

И постепенно проблемы становятся более явными:

- Агент игнорирует инструкции, которые всё ещё присутствуют в контексте. - Повторно анализирует уже изученные участки кода. - Теряет связь между первоначальной задачей и текущими действиями. Почему так происходит?

Здесь можно выделить несколько эффектов.

1. Lost in the Middle

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

2. Засорение контекста

Особенно заметно при активном Tool Calling. Агент вызывает инструмент, получает несколько тысяч токенов, использует из них пару значений, но весь результат остаётся в истории. Через десятки вызовов контекст превращается скорее в архив логов, чем в актуальное рабочее состояние.

Казалось бы, решение очевидно — разделять контекст и декомпозировать задачи.

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

Получаем:

- Меньше контекста - Более предсказуемое поведение. - Проще локализовать ошибки.

Но здесь появляется другая крайность.

Мы начинаем дробить задачи настолько сильно, что агент теряет возможность принимать полноценные инженерные решения.

Например, есть задача изменить механизм авторизации. Можно выделить отдельного агента для изменения API, другого для обновления моделей данных, третьего для тестов.

Но если каждый видит только небольшой участок системы, возникает проблема. Агент, который меняет API, может не учитывать ограничения модели данных. Агент, который пишет тесты, может не понимать первоначальную бизнес-логику.

Каждый локально выполняет свою задачу правильно, но итоговое решение оказывается несогласованным. Это уже проблема потери глобального контекста при декомпозиции. И чем сильнее мы дробим задачи, тем больше появляется дополнительной сложности:

- Передача состояния между агентами.

- Синхронизация промежуточных результатов.

- Управление зависимостями между задачами.

- Повторная загрузка общего контекста.

Получается интересный архитектурный компромисс.

Слишком большая задача и перегруженный контекст - агент начинает терять фокус. Слишком маленькая задача и изолированный контекст - агент теряет понимание системы. И в обоих случаях страдает качество разработки.

Как искать баланс? Хорошая архитектура — это не минимальный контекст и не максимальное количество маленьких задач. Это достаточный контекст и такой уровень декомпозиции, при котором агент ещё способен самостоятельно принимать осмысленные решения, а систему при этом не становится сложнее поддерживать. Иногда лучше дать одному агенту чуть больше контекста и ответственности, чем строить дополнительный уровень координации ради экономии нескольких тысяч токенов. #AIEngineering #AIAgents #ContextEngineering #LLM #AgentArchitecture