Почему ИИ-агент тупеет ещё до конца окна — и как этим управлять

Коротко (TL;DR)

Контекст-инжиниринг — это дисциплина осознанного управления тем, что попадает в контекстное окно агента на каждом шаге: что туда класть, что оттуда убирать и что хранить снаружи. В отличие от prompt engineering (как сформулировать один запрос) речь идёт о курировании всего окна на протяжении долгой задачи.

Зачем это нужно: модель начинает ошибаться задолго до того, как окно заполнится. Это измеренное явление, а не ощущение — и именно оно делает управление контекстом, по словам инженеров Cognition, «задачей номер один» для того, кто строит агентов. Формулировка не случайна: когда агент работает десятками шагов, качество каждого следующего решения зависит не столько от того, насколько умна модель, сколько от того, что именно лежит у неё перед глазами в этот момент. Плохо собранный контекст превращает даже топовую модель в источник уверенных ошибок, а грамотно собранный вытягивает результат там, где сырой промпт давно бы захлебнулся. Поэтому контекст-инжиниринг — это не «продвинутый промптинг», а отдельная инженерная дисциплина со своими правилами.

Что важно понять сразу:

• «Правило 40%» («держи окно заполненным меньше чем на 40%») — не факт от Anthropic, а полезная, но грубая эвристика конкретного практика. Реальная деградация зависит от типа задачи, а не от одного универсального процента.
• Есть структурная рамка приёмов — WSCI (Write / Select / Compress / Isolate): что писать вне контекста, что выбирать в него, что сжимать, что изолировать.
• Контекст ломается не одним способом, а четырьмя — и у каждого своя защита.

Это статья про принципы, а не про кнопки. Конкретную механику Claude Code (/compact, resume, шаблон handoff-документа) мы разбираем в отдельном материале курса про передачу контекста; здесь — фреймворк, применимый к любому агенту.

Bybit · Rewards Hubдо $30,100Внеси депозит, торгуй 14 дней — и забери награды в Rewards HubЗабрать бонус →

Context rot: что реально измерено

Начнём с факта, а не с анекдота. Исследователи Chroma в отчёте от 14 июля 2025 года прогнали 18 моделей и показали: точность падает нелинейно по мере роста контекста даже на простых задачах. Это не «модель устала» — это воспроизводимый эффект, названный context rot («гниение контекста»).

Генератор против критика: как несколько ИИ ловят баги, которые пропускает один

«Готово» — это оценка агента или чека? TDD и eval-driven разработка с ИИ

Как запускать несколько агентов Claude Code одновременно и не ловить конфликты файлов

Пять периметров безопасности Claude Code: что реально настроить, а что вас удивит

Claude Code без интерфейса: headless-режим, Agent SDK и подводные камни автоматизации

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

Практический смысл: чем больше вы напихали в окно, тем хуже работает модель с тем, что там уже есть. Контекст — не склад, куда всё влезет без последствий, а рабочий стол: чем больше на нём вещей, тем труднее найти нужную.

Почему так происходит на уровне механизма. Модель обрабатывает окно через механизм внимания, где каждый токен «смотрит» на все остальные. Чем длиннее окно, тем больше конкурирующих связей и тем сильнее размывается сигнал: нужный факт тонет среди тысяч нерелевантных. Это не поломка, а фундаментальное свойство архитектуры — и оно объясняет, почему даже модели с окном в миллион токенов не работают одинаково хорошо на всём этом объёме. Заявленный размер окна говорит, сколько текста влезет, но не сколько модель реально удержит в фокусе.

Правило 40% и «Dumb Zone»: что доказано, а что нет

Отсюда родилась популярная эвристика. «Dumb Zone» и «правило 40%» — идея держать заполнение окна ниже 40%, потому что после 40–60% качество проседает. Важно точно назвать источник: это формулировка практика Dex Horthy (HumanLayer), а не измеренный факт и не официальная позиция Anthropic. Полезная как ориентир, но не закон природы.

Более того, её прямо критикуют. Разбор на agentpatterns.ai под названием «правило 50% слишком простое» показывает, что деградация — это скорее абсолютный токен-порог, зависящий от типа задачи, чем универсальный процент. Разные бенчмарки дают разную картину:

Ключевой вывод: retrieval-задачи (найти факт) держатся почти до предела окна, а reasoning-задачи (рассуждать, связывать) рушатся на 10–20% эффективного окна. Поэтому «одно число на все случаи» вводит в заблуждение. Полезнее знать: чем больше рассуждений требует задача, тем раньше стоит чистить контекст. Заявленный размер окна конкретной модели — это верхняя граница, а не рабочий объём.

BYBITВсё ещё смотришь со стороны?Рынок работает без выходных. Счёт на Bybit открывается за 2 минуты.Начать сейчас

Разные модели и вовсе имеют разное эффективное окно при одинаковом заявленном — это стоит учитывать, сравнивая модели под свою задачу: цифра «1 миллион токенов» на витрине и объём, на котором модель реально рассуждает без провалов, могут отличаться в разы. Практический вывод для вайб-кодера: не доверяйте маркетинговому размеру окна вслепую. Прежде чем полагаться на то, что агент «удержит весь проект в голове», проверьте на своей задаче, где именно у него начинает сыпаться качество, — и стройте рабочий процесс вокруг этого реального порога, а не заявленного.

Четыре способа, которыми ломается контекст

Дрю Бройниг систематизировал (22 июня 2025 года) четыре режима отказа контекста — и это удобнее, чем общее «модель запуталась»:

• Poisoning (отравление). В контекст попала ошибка или галлюцинация и закрепилась — модель ссылается на неё снова и снова. Задокументированный пример — агент, застрявший в игре Pokémon с ложной «целью» в контексте.
• Distraction (отвлечение). Окно распухло, и модель тонет в нерелевантных деталях вместо сути.
• Confusion (путаница). Лишние инструменты и данные сбивают выбор действия — на Berkeley function-calling leaderboard видно, как избыток доступных инструментов роняет точность вызовов.
• Clash (конфликт). В окне противоречащие друг другу куски. В экспериментах Microsoft и Salesforce «рубленые» (sharded) промпты с рассинхроном давали падение качества до 39%.

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

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

Фреймворк WSCI: четыре рычага

Чтобы приёмы не были разрозненными советами, LangChain предложил рамку из четырёх категорий — WSCI:

1. Write (писать вовне). Выносите информацию из окна во внешнее хранилище — заметки, файлы, базу знаний проекта — и подтягивайте по мере надобности, а не держите всё в контексте.
2. Select (выбирать). На каждом шаге кладите в окно только то, что нужно именно сейчас, а не «всё, что может пригодиться».
3. Compress (сжимать). Сворачивайте историю в саммари, отбрасывайте отработавшие результаты инструментов.
4. Isolate (изолировать). Разносите подзадачи по отдельным контекстам (суб-агентам), чтобы шум одной не заражал другую.

Эти четыре рычага и есть инженерия контекста «по-взрослому»: не «держи ниже 40%», а осознанно решай для каждого куска — вынести, выбрать, сжать или изолировать.

Разберём на бытовом примере. Вы просите агента доработать модуль оплаты в большом проекте. Наивный подход — вывалить в окно весь код проекта «чтобы он всё видел». Подход по WSCI: справочник по API платёжного провайдера остаётся во внешнем файле, откуда агент подтянет нужную страницу (Write); в окно кладём только файлы модуля оплаты и связанные тесты, а не весь репозиторий (Select); историю предыдущих итераций сворачиваем в короткое «что уже сделано и почему» (Compress); а исследование, скажем, совместимости со сторонней библиотекой поручаем суб-агенту, который вернёт вывод в пару абзацев (Isolate). Результат — окно занято сутью задачи, а не шумом, и модель держит фокус.

Progressive disclosure и цена изоляции

Отдельно про Isolate, потому что это самый мощный и самый недооценённый рычаг. Progressive disclosure (послойное раскрытие) — принцип, при котором агент не загружает всё сразу, а раскрывает контекст по мере навигации: ссылки на документы вместо вставки их целиком, вызов суб-агента вместо @-импорта всех файлов. По данным Anthropic, суб-агент может исследовать десятки тысяч токенов, а вернуть родителю сжатую выжимку в 1000–2000 токенов — родительское окно остаётся чистым.

Но у изоляции есть цена, и о ней прямо говорит сама Anthropic. Мульти-агентная система дала прирост качества около 90% — но ценой в разы больше токенов: обычные агенты тратят примерно в 4 раза больше токенов, чем чат, а мульти-агентные системы — примерно в 15 раз больше. Более того, около 80% разброса результата объясняется просто объёмом потраченных токенов, а не хитростью архитектуры. Иными словами, «умная» мульти-агентность местами эквивалентна «потратить больше токенов» — и во сколько это обходится на реальных числах, стоит прикинуть заранее.

Есть и обратная сторона, которую почти не обсуждают. Cognition приводит пример: два суб-агента, работая изолированно, приняли неявно конфликтующие решения (в кейсе с игрой — разные визуальные стили), и на сборке это вылезло. Изоляция убирает шум, но создаёт риск рассогласования — суб-агенты не видят решений друг друга.

Отсюда практическое правило выбора: изолируйте то, что действительно самостоятельно (собрать данные, проверить факт, прогнать тест), и держите в одном контексте то, что требует согласованности (единый стиль, общая архитектура, сквозные решения). Progressive disclosure — не «всегда дроби на суб-агентов», а «раскрывай ровно столько контекста, сколько нужно текущему шагу». Ссылка на документ вместо его вставки, вызов суб-агента вместо загрузки всех файлов — это способ платить вниманием модели только за то, что реально в работе прямо сейчас. Экономия окна здесь прямо конвертируется в качество ответа.

Свежий контекст между стадиями

Долгую задачу полезно резать на стадии с context reset между ними: не тащить всю историю из начала в конец, а на границе стадии начинать с чистого окна плюс короткий передаточный документ (handoff) с сутью сделанного. Это тот же принцип, что стоит за агрессивными циклами вроде Ralph Loop из соседнего урока PRO-серии: оставаться в «умной зоне» окна через сброс, а не через накопление.

Конкретная механика этого в Claude Code — команда /compact, resume и формат самого handoff-документа — разобрана в отдельном материале курса про передачу контекста; здесь важен принцип: свежее окно на каждой стадии почти всегда работает лучше, чем одно распухшее на всю задачу.

Хороший handoff — это не «скопируй всю историю в новое окно», а короткая выжимка: что за задача, что уже сделано, какие приняты решения и почему, что осталось. Несколько абзацев вместо тысяч токенов истории. Парадокс в том, что агент на свежем окне с грамотной выжимкой обычно работает лучше, чем тот же агент, дотащивший всю переписку с самого начала: он не отвлекается на отработанные детали и не рискует зациклиться на ранней ошибке. Кстати, официального числового порога, при котором Claude Code сам сжимает контекст, Anthropic не публикует — сторонние оценки расходятся, так что полагаться на конкретный процент не стоит.

Риски и слабые места подхода

У самой дисциплины контекст-инжиниринга тоже есть цена и подводные камни:

Риск наивного правила. Если вы механически чистите контекст на 40%, но задача — это retrieval по большому документу, вы выбрасываете нужное на ровном месте: такие задачи держат точность почти до предела окна. И наоборот, на тяжёлом reasoning даже 30% окна может оказаться много. Правило 40% — это будильник «пора задуматься о чистке», а не автопилот. Инженер из команды Manus предлагает считать бюджет контекста заранее: по его наблюдению, для окна в миллион токенов деградация нередко начинается уже около 256K токенов — это данные одной команды, независимо не перепроверенные, но как ориентир полезны.

Риск переусердствовать с изоляцией. Разбив задачу на десять суб-агентов ради «чистого контекста», вы получаете счёт за токены в разы больше и риск рассогласования решений — суб-агенты не видят выборов друг друга. Иногда одно аккуратное окно дешевле и надёжнее десяти изолированных.

Риск потери информации при сжатии. Агрессивный Compress экономит окно, но может выбросить деталь, которая понадобится через три шага. Сжатие — это ставка на то, что вы правильно угадали, что важно, а что нет; иногда угадать не удаётся.

Зависимость цифр от модели и бенчмарка. Все приведённые пороги (16% у RULER, 10–20% на reasoning, ~256K у Manus) получены на конкретных моделях и задачах и не переносятся один в один на вашу. Это ориентиры направления, а не константы. Проверяйте на своей нагрузке, а не берите чужое число как истину.

Общий вывод: контекст-инжиниринг снижает деградацию, но не отменяет её и сам требует суждения. Это не набор магических настроек, а дисциплина, где каждое решение — компромисс между чистотой окна, стоимостью и риском что-то потерять.

Как это связано с остальным курсом

Чтобы не путать уровни:

• Базовое понятие «что такое контекстное окно» — отдельная объяснялка для новичка; здесь мы на него опираемся, но с нуля не разбираем.
• Механика Claude Code (/compact, resume, handoff-шаблон) — отдельный материал про передачу контекста между сессиями.
• Долгая память проекта между произвольными сессиями — это про накопление знаний, другой уровень, чем окно одной сессии.
• Ralph Loop — прикладной пример дисциплины «оставайся в умной зоне» через агрессивный reset.

Контекст-инжиниринг — это зонтик над всеми ними: принцип, который каждый из этих инструментов применяет по-своему.

FAQ

Чем контекст-инжиниринг отличается от prompt engineering? Prompt engineering — как сформулировать один запрос. Контекст-инжиниринг — как управлять всем окном на протяжении долгой задачи: что в него класть, что убирать, что хранить снаружи. Второе важнее для агентов, которые работают многими шагами.

Правда ли, что нужно держать окно заполненным ниже 40%? Это полезная эвристика практика Dex Horthy, а не доказанный факт Anthropic. Реальная граница зависит от типа задачи: reasoning деградирует уже на 10–20% окна, retrieval держится почти до предела. Используйте 40% как сигнал «пора подумать о чистке», а не как жёсткий порог.

Что такое context rot? Измеренное явление (исследование Chroma, 18 моделей): точность падает нелинейно по мере роста контекста даже на простых задачах. Проще говоря — чем больше в окне, тем хуже модель работает с тем, что там уже есть.

Стоит ли всегда дробить задачу на суб-агентов? Нет. Изоляция контекста повышает качество, но стоит в 4–15 раз больше токенов и создаёт риск, что суб-агенты примут конфликтующие решения. Дробите там, где подзадачи действительно независимы, а не по умолчанию.

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

Почему модель ошибается, если окно ещё не заполнено? Из-за механизма внимания: чем больше токенов в окне, тем сильнее размывается сигнал и тем труднее модели удержать нужное в фокусе. Это context rot — измеренное явление, а не сбой. Поэтому заявленный размер окна — верхняя граница вместимости, а не объём, на котором модель работает одинаково хорошо.

Что делать в первую очередь? Примените WSCI: вынесите справочные данные во внешние файлы (Write), кладите в окно только нужное сейчас (Select), сворачивайте историю в саммари (Compress) и разносите независимые подзадачи (Isolate). Это даёт больше, чем погоня за конкретным процентом заполнения, и работает одинаково на любой модели и в любом агентном инструменте, а не только в одном конкретном.