Как оптимизировать контекст — ценный ограниченный ресурс для AI-агентов
Клара Чонг
7 апреля 2026
8 минут чтения
Много говорят о более совершенных моделях, больших контекстных окнах и более способных агентах. Но большинство реальных сбоев происходят не из-за возможностей модели — они происходят из-за того, как контекст строится, передается и поддерживается.
Это сложная проблема. Пространство быстро развивается и методы все еще эволюционируют. Большая часть остается экспериментальной наукой и зависит от контекста (забавная шутка), ограничений и среды, в которой вы работаете.
В моей работе над многоагентными системами выявилась одна повторяющаяся закономерность: производительность гораздо меньше зависит от объема контекста, который вы передаете модели, и гораздо больше зависит от того, насколько точно вы его формируете.
Эта статья — попытка обобщить мои знания в нечто полезное для вас.
Она сосредоточена на принципах управления контекстом как ограниченным ресурсом — решении о том, что включить, что исключить и как структурировать информацию, чтобы агенты оставались согласованными, эффективными и надежными с течением времени.
Потому что в конце концов, самые сильные агенты — это не те, которые видят больше всего. Это те, которые видят нужные вещи, в правильной форме, в нужное время.
Терминология
Инженерия контекста
Инженерия контекста — это искусство предоставления правильной информации, инструментов и формата LLM для выполнения задачи. Хорошая инженерия контекста означает поиск наименьшего возможного набора высокосигнальных токенов, которые дают LLM наибольшую вероятность получить хороший результат.
На практике хорошая инженерия контекста обычно сводится к четырем приемам. Вы переносите информацию во внешние системы (выгрузка контекста, чтобы модель не должна была все это носить с собой. Вы извлекаете информацию динамически вместо предварительной загрузки всего (извлечение контекста). Вы изолируете контекст, чтобы одна подзадача не загрязняла другую (изоляция контекста). И вы сокращаете историю при необходимости, но только так, чтобы сохранить то, что агенту может понадобиться позже (сокращение контекста).
Распространенный режим отказа с другой стороны — загрязнение контекста: наличие слишком большого количества ненужной, противоречивой или избыточной информации, которая отвлекает LLM.
Деградация контекста
Деградация контекста — это ситуация, когда производительность LLM ухудшается по мере заполнения контекстного окна, даже если оно находится в пределах установленного лимита. У LLM все еще есть место для чтения большего, но его рассуждения начинают становиться нечеткими.
Вы заметили бы, что эффективное контекстное окно, где модель работает с высоким качеством, часто намного меньше, чем то, на что модель технически способна.
Есть две части к этому. Во-первых, модель не сохраняет идеальное воспоминание по всему контекстному окну. Информация в начале и в конце более надежно вспоминается, чем то, что находится посередине.
Во-вторых, большие контекстные окна не решают проблемы для корпоративных систем. Корпоративные данные практически неограниченны и часто обновляются, так что даже если модель могла бы поглотить все, это не означало бы, что она могла бы поддерживать согласованное понимание.
Подобно тому, как люди имеют ограниченный объем рабочей памяти, каждый новый токен, введенный в LLM, истощает некоторый объем бюджета внимания. Дефицит внимания вытекает из архитектурных ограничений в трансформере, где каждый токен взаимодействует с каждым другим токеном. Это приводит к паттерну взаимодействия n² для n токенов. По мере роста контекста модель вынуждена распределять свое внимание тоньше по большему количеству отношений.
Компактификация контекста
Компактификация контекста — это общий ответ на деградацию контекста.
Когда модель приближается к лимиту своего контекстного окна, она суммирует его содержание и инициирует новое контекстное окно с предыдущей сводкой. Это особенно полезно для долгосрочных задач, чтобы позволить модели продолжать работу без слишком большого снижения производительности.
Недавняя работа по складыванию контекста предлагает другой подход — агенты активно управляют своим рабочим контекстом. Агент может ответвиться для обработки подзадачи, а затем свернуть ее после завершения, сворачивая промежуточные шаги при сохранении краткой сводки результата.
Трудность, однако, не в суммировании, а в решении того, что сохраняется. Некоторые вещи должны оставаться стабильными и почти неизменными, такие как цель задачи и жесткие ограничения. Другие могут быть безопасно отброшены. Сложность в том, что важность информации часто выявляется только позже.
Хорошая компактификация поэтому должна сохранять факты, которые продолжают ограничивать будущие действия: какие подходы уже не сработали, какие файлы были созданы, какие предположения были инвалидированы, какие дескрипторы можно пересмотреть и какие неопределенности остаются неразрешенными. В противном случае вы получите аккуратную, краткую сводку, которая хорошо читается человеку и бесполезна для агента.
Оболочка агента
Модель — это не агент. Оболочка — это то, что превращает модель в агента.
Под оболочкой я имею в виду все, что окружает модель и решает, как контекст собирается и поддерживается: сериализация подсказок, маршрутизация инструментов, политики повторных попыток, правила, определяющие, что сохраняется между этапами, и так далее.
Нарисовано автором
Когда вы смотрите на реальные системы агентов таким образом, многие предполагаемые «отказы модели» выглядят иначе. Я столкнулся со многими такими на работе. Это на самом деле отказы оболочки: агент забыл, потому что ничего не сохранило правильное состояние; он повторил работу, потому что оболочка не представила долговечный артефакт предыдущего отказа; он выбрал неправильный инструмент, потому что оболочка перегрузила пространство действий; и так далее.
Хорошая оболочка — это, в некотором смысле, детерминированная оболочка, обернутая вокруг стохастического ядра. Она делает контекст понятным, стабильным и восстанавливаемым достаточно, чтобы модель могла потратить свой ограниченный бюджет рассуждений на задачу, а не на восстановление собственного состояния из беспорядочной трассы.
Коммуникация между агентами
По мере усложнения задач команды переходили на многоагентные системы.
Ошибка заключается в предположении, что больше агентов означает больше общего контекста. На практике сброс гигантской общей стенограммы в каждого подагента часто создает именно противоположность специализации. Теперь каждый агент читает все, наследует ошибки всех остальных и платит одну и ту же контекстную плату снова и снова.
Если общий контекст только частично, появляется новая проблема. Что считается авторитетным, когда агенты не согласны? Что остается локальным и как разрешаются конфликты?
Выход — рассматривать коммуникацию не как общую память, а как передачу состояния через четко определенные интерфейсы.
Для дискретных задач с четкими входами и выходами агенты обычно должны общаться через артефакты, а не через необработанные трассы. Например, агент веб-поиска не должен передавать всю историю просмотров. Ему нужно только показать материал, который могут использовать нижестоящие агенты.
Это означает, что промежуточные рассуждения, неудачные попытки и следы исследования остаются приватными, если явно не требуется. То, что передается дальше, — это дистиллированные выходы: извлеченные факты, проверенные находки или решения, которые ограничивают следующий этап.
Для более тесно связанных задач, например для отладки агента, где последующие рассуждения действительно зависят от предыдущих попыток, может быть введена ограниченная форма обмена следами. Но это должно быть намеренным и ограниченным по объему, а не по умолчанию.
Штраф KV cache
Когда модели AI генерируют текст, они часто повторяют многие из одних и тех же вычислений. KV caching — это техника оптимизации времени вывода, которая ускоряет этот процесс, запоминая важную информацию из предыдущих шагов вместо пересчета всего снова.
Однако в многоагентных системах, если каждый агент делит один и тот же контекст, вы запутываете модель тоннами нерелевантных деталей и платите массивный штраф KV-cache. Несколько агентов, работающих над одной задачей, должны общаться друг с другом, но это не должно быть через совместное использование памяти.
Вот почему агенты должны общаться через минимальные, структурированные выходы контролируемым образом.
Держите инструментарий агента небольшим и релевантным
Выбор инструмента — это проблема контекста, замаскированная под проблему возможностей.
По мере того, как агент накапливает больше инструментов, пространство действий становится сложнее для навигации. Теперь выше вероятность того, что модель пойдет по неправильному действию и выберет неэффективный маршрут.
Это имеет последствия. Схемы инструментов должны быть намного более различными, чем большинство людей понимают. Инструменты должны хорошо понятны и иметь минимальное пересечение в функциональности. Должно быть очень ясно, что такое их предполагаемое использование и иметь ясные входные параметры, которые однозначны.
Один распространенный режим отказа, который я заметил даже в своей команде, заключается в том, что мы имеем тенденцию иметь очень раздутые наборы инструментов, которые добавляются со временем. Это приводит к неясным решениям и