Почему инструкции для ИИ-агента на самом деле не работают до конца сессии
Пользователи агентных инструментов регулярно натыкаются на одно и то же: в начале сессии агент чётко следует правилам, а через полсотни шагов вдруг начинает их игнорировать, повторять одни и те же ошибки или выдавать обобщённые ответы вместо конкретных находок. Выглядит так, будто модель «устала» или «сломалась». На деле это не баг, а прямое следствие того, как устроено внимание в трансформерах и как агентные системы управляют контекстным окном.
Агент, который сам боится кончиться
Свежий пример от Anthropic показывает эту механику особенно наглядно. Команда, работающая над агентной инфраструктурой компании, обнаружила у модели Claude Sonnet 4.5 поведение, которое назвали «context anxiety»: команда заметила, что Claude Sonnet 4.5 преждевременно сворачивала задачи, когда чувствовала приближение лимита контекста — поведение, которое они назвали «context anxiety». Модель начинала срезать углы и закрывать задачу раньше времени, даже когда свободного места в окне оставалось ещё много.
Решение на тот момент было простым — встроить в harness (обвязку вокруг модели) принудительный сброс контекста. Но когда ту же обвязку применили к более новой модели Opus 4.5, выяснилось, что поведение исчезло само: в прежней работе команда обнаружила, что Claude Sonnet 4.5 сворачивала задачи раньше времени, почувствовав приближение лимита контекста. Проблему решили добавлением сбросов контекста в harness. Но при использовании той же обвязки с Claude Opus 4.5 оказалось, что поведение исчезло. Сбросы превратились в мёртвый груз. Это хорошая иллюстрация общего правила: обвязки вокруг модели чинят конкретную слабость конкретной версии, а не контекстное окно как таковое.
Модель читает контекст неравномерно
Даже без «тревожности» у любой модели есть более фундаментальное ограничение: внимание распределяется по контексту неравномерно. Классический эффект называется «потерянный в середине» — модели куда надёжнее извлекают и используют информацию из начала и конца длинного контекста, чем ту, что зарыта в середине. Причём это не плавная деградация: информация, оказавшаяся в средней трети длинного контекста, значительно чаще игнорируется, искажается или трактуется неверно — даже если формально она находится внутри контекстного окна и модель не исчерпала токены для её обработки.
У открытых моделей с длинным контекстом добавляется ещё один слой сложности: часть архитектур физически не просматривает всю историю на каждом шаге. В части современных моделей используется схема «скользящее окно + глобальные слои»: локальный слой смотрит только на последние N токенов, глобальный — на всё окно. Это значит, что правило, заданное в начале долгой сессии, формально остаётся в контексте, но реального «взгляда» на него модель может и не бросить — внимание просто устроено по-другому.
Как агенты сами топят свои инструкции
Отдельная проблема — файлы с правилами, которые пользователи сами пишут для агентов (аналоги системных промптов для конкретного проекта). Чем длиннее такой файл, тем хуже модель следует даже важным пунктам. В документации по лучшим практикам прямо говорится: раздутые файлы с инструкциями заставляют модель игнорировать фактические инструкции. Разработчики, тестировавшие это на практике, приводят конкретные цифры деградации: файлы до 200 строк показывают compliance rate выше 92%, а после 400 строк — всего 71%.
Получается замкнутый круг: пользователь видит, что агент что-то нарушает, дописывает ещё одно правило — файл растёт — а соблюдение остальных правил падает ещё сильнее.
Что с этим делать на практике
- Держите файл правил коротким. Если удаление строки не приведёт к конкретной ошибке — удаляйте её. Общие описания проекта («это Next.js-приложение на TypeScript») не работают как инструкция и просто съедают внимание.
- Дублируйте критичные правила в конце, а не только в начале. Раз модель лучше всего видит начало и конец контекста, самое важное ограничение стоит напомнить непосредственно перед тем, как агент должен его применить, а не рассчитывать, что оно «долетит» из системного промпта.
- Разбивайте длинные задачи на этапы с явным сбросом контекста. Вместо одной многочасовой сессии — несколько более коротких с чистым стартом и кратким резюме результата предыдущего этапа.
- Следите за процентом заполнения окна, а не только за лимитом токенов. Деградация начинается задолго до технического потолка — часто уже на середине доступного объёма.
- Проверяйте поведение заново при смене модели. Обходные приёмы, подобранные под одну версию, на следующей могут оказаться бесполезными или даже вредными.
Что это меняет
Понимание того, что инструкции для агента — это не «установка один раз и забыл», а ресурс, который расходуется и слабеет по ходу сессии, меняет сам подход к работе с ИИ-инструментами. Вместо того чтобы считать странное поведение агента поломкой, стоит воспринимать его как сигнал: контекст пора почистить, правило — продублировать, а задачу — разбить на части.
Если хотите попробовать агентные сценарии и разные модели на практике, посмотрите, какие инструменты и модели для чата, кода и генераций уже доступны в GEMERA AI — там можно сравнить, как разные модели держат контекст на длинных задачах, не разбираясь предварительно во всех архитектурных тонкостях.