От инженерии промптов к инженерии контекста: писать, выбирать, сжимать, изолировать
Курс по инженерии контекста для ИИ-агентов: почему инженерия промптов недостаточна, как заполняется окно контекста, четыре стратегии, RAG для инструментов, Claude Code.
Источники: Context Engineering for AI Agents: Complete Course
Любой, кто создавал агента, вероятно, сталкивался с такой же ситуацией. В первые несколько шагов его поведение хорошее: он выбирает подходящие инструменты, четко обосновывает свои действия и сосредотачивается на задаче. Примерно на 15-м или 20-м шаге его работа становится хаотичной: он забывает, что от него требовалось, использует инструменты, неуместные для выполнения задачи, или начинает получать некачественные результаты.
Обычно первой причиной считают модель. Однако чаще всего виновато то, что показывается модели. Определение того, что будет предоставлено модели, в каком формате и в какой момент, называется инжинирингом контекста, и для создателей агентов это становится одним из самых ценных навыков.
В следующих разделах рассматривается, что такое инжиниринг контекста и почему агентам он необходим, четыре стратегии, лежащие в основе практически всех техник, четыре способа возникновения ошибок в контексте, конкретные рекомендации по составлению промптов для систем и определению инструментов, поэтапная работа, объединяющая эти стратегии, а также то, как Claude Code, Manus, ChatGPT Agent и Google’s Agent Development Kit решают эту задачу.
От инжиниринга промптов к инжинирингу контекста в окне контекста
Инжиниринг промптов — это искусство написания хороших инструкций для языковой модели: четкое формулирование запросов, предоставление примеров, назначение роли. Для чата с одним вопросом и ответом этого часто бывает достаточно.
Агенты меняют ситуацию. Агент не отвечает сразу: он исследует информацию, вызывает API, пишет код и выполняет команды шаг за шагом, иногда десятками шагов, без участия человека. Каждый шаг генерирует результат, и все они попадают в контекст модели, размер которого фиксирован.
Поэтому инжиниринг контекста — это проектирование всей информационной системы вокруг модели. Это включает системные указания, определения инструментов, результаты предыдущих вызовов инструментов, историю общения и многое другое на каждом этапе. Инженерная команда Anthropic определяет контекст как набор токенов, включаемых при генерации ответа из модели, а инжиниринг контекста — как оптимизацию того, насколько полезны эти токены для достижения желаемого результата. Проще говоря, агент должен видеть правильную информацию в правильном формате в нужное время.
Anthropic также рассматривает это как естественную следующую стадию после инжиниринга промптов. Все, что было важно при создании промптов (четкие инструкции, хорошие примеры, структурированный формат), остается актуальным, но добавляется ещё один уровень: инструменты, внешние данные, история сообщений, память и динамическое состояние. Инжиниринг промптов становится его частью.
Время играет важную роль. По прогнозам Gartner к концу 2026 года 40% корпоративных приложений будут включать ИИ-агентов, предназначенных для выполнения конкретных задач, что противопоставляется менее 5% в 2025 году. Эти агенты заменяют статические промпты и фиксированные процессы поиска информации на динамическую систему, в которой каждый вызов инструмента, полученный документ и принятое решение помещаются в окно, заполняющееся материалом, о котором пользователь никогда прямо не просил. Команды, которые учатся управлять этим процессом, обычно создают надежных агентов, поскольку они перестают винить модель в проблемах, возникающих из-за её входных данных.
Окно контекста как рабочая память
LangChain предлагает удобную аналогию. Рассматривайте большие языковые модели как новый тип операционной системы: модель — это процессор, выполняющий мыслительные процессы, а окно контекста — оперативная память, в которой хранится всё, что модель может видеть в данный момент. Точно так же, как компьютер замедляет работу при заполнении оперативной памяти, способность агента к логическим рассуждениям снижается по мере заполнения его окна контекста.
У этого явления есть название — «порча контекста». Компания Chroma протестировала восемнадцать передовых моделей, в том числе GPT-4.1, Claude 4, Gemini 2.5 и Qwen3, и обнаружила, что каждая из них показывает худшую производительность по мере увеличения длины входных данных, даже при значительно меньших значениях, чем заявленные лимиты. Модель с окном контекста на 200 тысяч токенов может начать существенно снижать качество работы уже при 50 тысячах токенов. Здесь нет резкого падения, а лишь постепенное снижение качества. Собственные технические материалы компании Anthropic приходят к тому же выводу и рассматривают это снижение как постепенную зависимость.
Причина кроется в принципе работы трансформеров. Каждый токен уделяет внимание всем остальным токенам, что приводит к возникновению n² парных связей. По мере увеличения размера окна способность модели отслеживать все эти связи снижается, что похоже на ситуацию, когда от кого-то требуют запомнить всё больше и больше элементов. В какой-то момент что-то упускается.
Второй хорошо изученный эффект — это явление «потери информации в середине». Исследовательская группа под руководством Лю обнаружила, что механизм внимания имеет форму буквы U: информация, расположенная ближе к началу контекста, запоминается хорошо, информация ближе к концу также запоминается хорошо, а информация в середине упускается; точность воспроизведения снижается более чем на тридцать процентных пунктов, когда соответствующий фрагмент перемещается из начала в середину. Представьте агента, чьи первоначальные инструкции находятся под слоем из пятидесяти тысяч токенов результатов работы инструментов — эти инструкции фактически исчезают.
Специалисты разработали приблизительные правила. Пользователи Claude Code отмечают, что качество вывода начинает снижаться примерно на уровне 40–60 процентов времени работы агента, задолго до наступления какого-либо жесткого лимита.
Что конкурирует за пространство
В контексте агента за место борются семь типов информации:
- Системное указание — это идентичность агента: правила поведения, структура управления и рекомендации для различных типов задач. Для агента это гораздо больше, чем просто фраза «полезный помощник», и может определять способ работы всей системы.
- Определения инструментов. Каждый инструмент, который может использовать агент, требует схемы, описывающей его функции, принимаемые параметры и моменты применения.
- Результаты работы инструментов. Каждый вызов добавляет свой вывод. Загруженная веб-страница может содержать от пяти до десяти тысяч токенов, а результат чтения файла — примерно столько же.
Четыре основные стратегии с примерами RAG и Claude Code
При ограниченном и сокращающемся временном окне возникают вопросы о том, что входит, что остается снаружи и что вытесняется. Широко используемая фреймворк LangChain классифицирует все методы работы с контекстом на четыре категории: запись, выбор, сжатие и изоляция. Как только вы ознакомитесь с ними, практически любой метод, с которым вы столкнетесь, относится к одной из этих категорий.
Запись
Агенты забывают. Когда полный контекст сжимается, информация исчезает, и если агент не сохранил её в другом месте, она теряется навсегда. Запись предполагает предоставление агенту способов сохранять информацию вне временного окна. Она принимает три распространенных формы.
Scratchpads — это инструмент для ведения заметок, который агент может использовать в процессе выполнения задачи для записи временных результатов, решений и информации, понадобящейся позже. Компания Anthropic создала инструмент "think", предоставляющий Claude специальное место для размышлений над проблемой; на тестовой платформе tau-bench это улучшило производительность на некоторых задачах на 54%.
Файлы с правилами служат постоянной процедурной памятью. Пользователи Claude Code знакомы с файлом CLAUDE.md. Эти файлы загружаются в начале каждой сессии в качестве постоянных инструкций, описывающих архитектуру проекта, правила форматирования, способы запуска тестов и моменты, на которые следует обратить внимание, чтобы основные аспекты не забывались.
Извлечение информации из памяти позволяет агенту хранить факты, предпочтения и выученные шаблоны в файловой системе и обращаться к ним в последующих сессиях, полностью вне окна взаимодействия.
Выбор
Заметки полезны лишь в том случае, если правильные из них появляются в нужный момент. Выбор означает предоставление агенту того, что ему необходимо на данном этапе, а не всего, что он мог бы использовать. Агент с десятками инструментов, обширной базой знаний и несколькими историческими сессиями не может загрузить всё это сразу, поэтому кто-то должен решать, что является релевантным, и настоящий вопрос заключается в том, кто осуществляет это решение.
В классическом RAG решение принимает система: поступает вопрос, извлекаются документы и вставляются в промпт, при этом у модели нет права голоса. В агентном RAG сам агент выбирает, что искать, какие инструменты использовать, как уточнять запросы и когда у него уже достаточно информации. Процесс извлечения данных превращается в итеративный, что уместно, поскольку релевантность меняется на каждом этапе длительной задачи, и только агент знает, что ему нужно дальше.
Как LangChain, так и Pinecone выделяют три вида памяти, из которых можно черпать информацию. Эпизодическая память представляет собой примеры из небольшого количества случаев, когда ранее решалась похожая ситуация. Семантическая память — это хранилище фактов, которые агент узнал или ему сообщили. Процедурная память — это постоянные инструкции к действию, такие как файлы с правилами, упомянутыми выше. Хорошо спроектированный агент использует все три вида памяти в зависимости от текущего шага.
Инструменты создают наибольшие проблемы с выбором. При наличии чуть более сорока инструментов в контексте может оказаться около десяти тысяч токенов с определениями ещё до начала работы. Как показано в разделе о сбоях ниже, чрезмерное количество инструментов не только занимает место, но и активно сбивает модель с толку.
Решение заключается в применении технологии RAG непосредственно к описаниям инструментов с использованием семантического поиска, который выделяет лишь те немногие инструменты, которые могут понадобиться на текущем этапе. В статье под названием RAG-MCP это было проверено, и точность выбора инструментов выросла с примерно 14% до 43%, что в три раза больше, в то время как количество токенов запроса сократилось примерно вдвое.
Общая рекомендация компании Anthropic — использовать гибридный подход. Заранее загружают небольшое количество необходимых материалов для ускорения работы, например файл CLAUDE.md, а остальное позволяют агенту получать по мере необходимости. На практике это означает, что агент хранит легкие ссылки, такие как пути к файлам, запросы и ссылки, а тяжелый контент открывает только тогда, когда это требуется на данном этапе. Загрузка основных данных заранее и получение остального по запросу позволяет сохранять оптимальную производительность, не оставляя агента без информации.
Сжатие
Даже при хорошем выборе окно продолжает заполняться. Представьте агента, который совершил двадцать вызовов инструментов. Он несет с собой восемьдесят тысяч токенов результатов, истории и следов логических рассуждений, большая часть которых уже была обработана. Эти старые данные по-прежнему занимают место, отвлекают внимание и увеличивают затраты и задержки. Это снова проблема «гниения контекста», и сжатие решает ее путем уменьшения количества токенов при сохранении важной информации. Это можно сделать в трех этапах.
До того, как информация попадет в контекст. Фрагментация разделяет большие документы на более мелкие целостные части, а переранжирование позволяет в окно попадать только лучшие фрагменты. Результаты работы инструментов также можно кратко обобщать прямо в процессе, прежде чем они войдут в основной контекст.
Пока агент работает. Распространённой техникой является краткое изложение хода разговора: постоянно обновляемое резюме после каждого обмена сообщениями позволяет сохранять компактную запись всего произошедшего до этого момента. Популярным гибридным подходом является сохранение последних десяти сообщений слово в слово, поскольку точные детали могут всё ещё понадобиться, в то время как все более старые сообщения сводятся к краткому изложению. Другим вариантом является простое сокращение с использованием заранее заданных правил — удаление старых сообщений по достижении определённого лимита объёма. Claude Code включает в себя функцию автоматического сжатия: при достижении окном 95% его ёмкости происходит краткое изложение всего хода разговора. Это своего рода резервный механизм. В идеале сжатие должно происходить заранее, а не при возникновении чрезвычайной ситуации.
После того, как агент что-то использовал. Простое решение — очистка результата работы инструмента. Если инструмент выполнил пятнадцать шагов назад, а агент уже воспользовался полученным результатом, можно удалить сырой текст. Полную веб-страницу, загруженную давно, можно заменить однострочным резюме или полностью удалить.
Изоляция
Именно изоляция позволяет многокомпонентным системам агентов функционировать эффективно. Предположим, один агент занимается исследованиями, планированием, программированием, тестированием и отладкой в рамках одного длинного диалога. Его контекст будет заполняться, но более серьезной проблемой является «загрязнение» контекста. Результаты поиска файлов, полученные на этапе исследований, остаются в системе, и эти старые данные становятся помехой, отвлекая модель в тот момент, когда ей нужно писать чистый код.
Решение заключается в предоставлении отдельным частям работы отдельных окон контекста.
Очевидным способом являются подагенты. Родительский агент поручает конкретную задачу, например поиск всех файлов, связанных с аутентификацией, подагенту, который работает в собственном окне. По завершении подагент возвращает лишь краткое резюме, а вся сложная процедура поиска остается внутри него, не влияя на родительский агент.
Другой вариант — изоляция схемы состояния, реализованная в LangGraph. Состояние агента спроектировано таким образом, что разные поля хранят разные виды контекста, и модель видит только те поля, которые важны для текущего шага. Результаты работы инструментов могут находиться в скрытом поле, которое модель никогда не видит, пока что-то намеренно не выведет их на поверхность. Это позволяет осуществлять тонкую настройку без создания дополнительных агентов.
Короче говоря, стратегии заключаются в записи, выборе, сжатии и изоляции, и все последующие решения основаны на одной или нескольких из них.
Почему агенты терпят неудачу
Варианты сбоев показывают, чего следует избегать. В середине 2025 года Дрю Бройниг опубликовал влиятельную двухчастную серию, в которой описал четыре отдельных способа, какими агенты теряют функциональность по мере усложнения их контекста.
Отравление контекста. В контекст попадает галлюцинация или ошибка, которая затем упоминается снова и снова. Возможно, инструмент вернул некорректные данные, или агент сделал ошибочный вывод пять шагов назад. Теперь эта ошибка остается в контексте, и агент продолжает работать с ней; поскольку агенты итерируют свои собственные выводы, каждый неверный шаг усугубляет ситуацию. Решение заключается в прунинге: активном удалении устаревшей или противоречивой информации по мере поступления новых данных, проверке результатов работы инструментов (особенно из внешних источников) перед их включением в контекст, а также сжатии неудачных попыток после того, как агент восстановится от ошибки, чтобы десять шагов тупикового отладки не оставались, если важна лишь решение проблемы. Если эти отказанные попытки оставить без внимания, они продолжат соблазнять модель возвращаться к уже неудачным подходам.
Отвлечение из-за большого объема контекста. При очень большом объеме контекста модель начинает слишком сильно опираться на недавнюю информацию и слишком мало — на то, что она выучила во время обучения. Она прекращает создавать что-то новое и повторяет ранее виденные шаблоны, вновь используя прошлые действия вместо того, чтобы разработать новый план. Решение заключается в том же общем совете: активно сводить краткость и удалять ненужное, даже если объем данных огромен.
Путаница в контексте. Модель усваивает избыточный контент, что снижает качество ответа. Классическим примером является путаница с инструментами. В одном из исследований на тестовой базе GeoEngine использовалась квантизированная модель Llama 3.1 8B. При наличии всех сорока шести доступных инструментов модель не смогла справиться с задачей, хотя объем контекста полностью входил в её лимит; однако при использовании лишь девятнадцати инструментов она сработала. Инструменты вписывались в заданные рамки, но их было слишком много, чтобы модель могла четко обрабатывать информацию. Решением является динамическое управление инструментами: необходимо сократить список доступных инструментов до тех, которые соответствуют текущей фазе работы агента, причем с помощью поискового механизма в стиле RAG-MCP выбирать наиболее релевантные инструменты для каждого шага.
Конфликт контекста. Новая информация, собранная в ходе выполнения задачи, противоречит уже имеющимся в контексте данным. В системном запросе может быть указано одно, в то время как в полученном документе — совсем другое. Агент не может согласовать эти данные и ведет себя неконсистентно: иногда следует за одним источником, иногда — за другим, а иногда делает что-то, что не соответствует ни тому, ни другому. Решение заключается в четком порядке приоритетов: системный запрос имеет приоритет над полученными фактами, а полученные факты — над историей разговора. Перед внедрением новой информации необходимо проверить ее согласованность с уже имеющимися данными, а также использовать структурированные разделы, такие как XML-теги или четкие заголовки, чтобы модель могла понять, откуда взялась каждая часть информации и насколько ей можно доверять.
Хорошая новость в том, что определение причины сбоя обычно указывает на соответствующую стратегию. Проблему отравления решают с помощью сжатия и упрощения структуры, отвлечения — сжатием, путаницы — выбором, а конфликтов — структурированным форматированием текста и выбором подходящих решений. Всё сводится к процессам написания, выбора, сжатия и изоляции.
Подсказки системы для агентов
Формулировка запросов для агентов сильно отличается от формулировки запросов для чат-ботов. Запрос к чат-боту в основном задаёт тон: быть дружелюбным, кратким. Запрос к агенту определяет его архитектуру. В нём описывается поток управления, то есть как обрабатывать различные типы задач, какие инструменты подходят для тех или иных ситуаций, что делать при ошибках и какие существуют ограничения безопасности. Это больше похоже на описание должностных обязанностей автономного сотрудника.
Anthropic говорит о необходимости формулировать задания на подходящей высоте, существуя так называемая зона «золотой середины». Чрезмерно строгие правила делают систему хрупкой. Представьте правило, согласно которому необходимо использовать инструмент X каждый раз, когда пользователь упоминает вопросы оплаты, просит возврат суммы превышающей сто долларов. Оно будет нарушаться при каждом неожиданном случае. Чрезмерная неопределённость также плоха. Фраза «Будьте полезны и используйте соответствующие инструменты» не даёт агенту никаких указаний, поскольку он не знает, какие инструменты подходят для конкретных задач, и не может принимать решения без конкретных сигналов. Идеальный вариант — правила, достаточно конкретные, чтобы направлять автономное поведение, но достаточно гибкие, чтобы модель могла проявлять осторожность в новых ситуациях. Необходимы сильные эвристики, а не жёсткие правила.
Несколько практических привычек помогут:
- Создайте структуру запроса с использованием XML-тегов или маркированных заголовков, которые разделяют контекст, инструкции и рекомендации по использованию инструментов.
- Начните с минимальной версии и постепенно улучшайте её на основе возникающих ошибок. Запустите агента на реальных задачах, определите моменты сбоев и добавьте инструкции, направленные именно на эти проблемы, вместо попыток заранее предусмотреть все крайние случаи.
- Минимум не означает краткость. Инструкция для сложного рабочего процесса может составлять тысячи токенов, и это нормально, если каждый токен имеет свою необходимость.
- Используйте примеры с небольшим количеством случаев. Показ примеров правильного выбора инструментов, обоснованных решений и корректной многократной обработки задачи гораздо эффективнее, чем описание всех правил словами.
Определения инструментов
Каждый вызываемый инструмент требует схемы, описывающей его назначение, параметры и ситуации, когда его следует использовать. Хорошее определение должно быть самодостаточным, устойчивым к ошибкам и четко формулировать инструкции; затратой при этом является объем используемого контекста.
В реальных условиях инструменты всё чаще подключаются через MCP — протокол Model Context Protocol, стандартный способ для агентов получать доступ к внешним инструментам и данным. Один сервер MCP для GitHub, другой — для базы данных, третий — для файловой системы; все они предоставляют инструменты через единый интерфейс. Проблема в том, что подключение инструментов становится настолько простым, что люди переусердствуют. При подключении четырёх-пяти серверов определения могут занимать тысячи токенов ещё до выполнения первого шага.
Стандартная рекомендация — сформировать минимально необходимый набор инструментов. Когда агенту действительно требуется множество инструментов, эффективно работают два подхода.
Первый пример приводит Manus — платформа для агентов. Они советуют не добавлять и не удалять инструменты в процессе разговора по причине, о которой многие разработчики не знают: из-за кэша KV. Когда токены поступают в LLM, модель вычисляет для каждого из них представления в формате ключ-значение, что требует значительных ресурсов, поэтому поставщики хранят их в кэше. Если начало контекста (префикс) остается одинаковым между вызовами, поставщик использует уже сохраненные данные и обрабатывает только новые токены в конце, что делает процесс быстрее и дешевле.
Если изменить порядок или отредактировать первую часть контекста между вызовами, кэш становится недействительным, и все данные приходится вычислять заново. С Claude Sonnet стоимость кэшированных токенов входных данных составляет тридцать центов за миллион, тогда как для некэшированных — три доллара за миллион, что в десять раз больше. Агент, выполняющий тридцать–сорок вызовов на задачу, быстро это ощущает.
Поэтому Manus предпочитает маскировку инструментов их удалению. Каждое определение остаётся на своём месте в кэшированном префиксе, но некоторые инструменты отмечаются как недоступные на текущем этапе. Определения сохраняются для стабильности кэша, в то время как агент знает, что не должен ими пользоваться, а единообразные префиксы имен помогают ему классифицировать инструменты.
Второй подход — это выбор на основе RAG, о котором говорилось ранее: извлекаются только те инструменты, которые актуальны для текущего шага; как показали исследования RAG-MCP, это увеличивает точность более чем в три раза при одновременном сокращении использования токенов вдвое. Оба метода дополняют друг друга: маскировка подходит для умеренного набора инструментов, а извлечение — для очень большого набора.
Под всем этим лежит один основной принцип. Стабильный контент размещается в верхней части контекста: системное сообщение, определения инструментов и всё то, что не меняется между этапами. Динамический контент (история, текущий шаг, состояние агента) находится в нижней части.
Поэтапный рабочий процесс, объединяющий всё
Эти принципы применимы как к готовым помощникам по программированию, так и к специально созданным агентам. Единственная разница заключается в том, создаёте ли вы самостоятельно структуру рабочего процесса или разрабатываете агента для этой цели.
Генеральный директор HumanLayer Декс Хорти выступил на конференции AI Engineer Code Summit, описав метод, который наглядно иллюстрирует всё это. По его словам, его команда использовала этот метод, чтобы за одну семичасовую сессию внести примерно тридцать пять тысяч строк кода в крупную базу кода на языке Rust. Он называет этот подход «Частая целенаправленная компактизация». Работа намеренно делится на этапы: каждый этап создаёт компактный результат — например, структурированный краткий отчёт в формате Markdown — и каждый новый этап начинается в отдельном окне, содержащем только этот результат. Таким образом достигается цель оставаться в пределах примерно 40–60 процентов объёма окна.
Первый этап — исследование. Прежде чем написать хоть какой-то код, агент исследует кодовую базу: читает файлы, отслеживает потоки данных и составляет карту архитектуры, важной для выполнения задачи. Подагенты выполняют первичный поиск и анализ, поэтому все результаты grep и содержимое файлов остаются в их окнах и никогда не влияют на окна родительского агента. Это и есть изоляция. Результатом этапа является исследовательский файл — компактный документ в формате markdown с указанием путей к файлам, сигнатур функций, существующих шаблонов и потенциальных проблем. Это уже процесс записи, поскольку полученные данные сохраняются вне окна. Затем контекст сбрасывается. Первичное исследование может занимать от 60 до 80 процентов пространства окна, тогда как готовый результат сокращает его до примерно 15–20 процентов. Это и есть сжатие.
Второй этап — планирование. Открывается совершенно новое окно, содержащее только файл с исследованиями и описание проблемы, и агент использует эту чистую основу для разработки подробного плана реализации. Именно здесь также наилучше проводить проверку человеком. Логические ошибки, обнаруженные на этом этапе, легко исправить, поэтому любой, кто создаёт собственного агента, должен включить контрольный пункт с участием человека именно здесь.
Третий этап — реализация. В другом новом окне находится только сам план, и агент выполняет его шаг за шагом. Для задач, требующих нескольких циклов сжатия, файл progress.md фиксирует, что уже выполнено, а что остаётся, что также представляет собой ещё одну операцию записи.
Такая или похожая версия используется в большинстве производственных систем.
Как реальные продукты обрабатывают контекст
Claude Code. Инструмент для программирования в командной строке от Anthropic относится к числу наилучшим с точки зрения документации. Он использует гибридный подход к поиску информации: файлы CLAUDE.md загружаются заранее в начале каждой сессии для формирования базового контекста, в то время как такие инструменты, как glob и grep, позволяют осуществлять поиск в кодовой базе в реальном времени. Система не создает предварительный индекс всего контента, а осуществляет поиск по мере необходимости. Автоматическое сжатие данных запускается при уровне использования 95% и позволяет сохранять архитектурные решения, а также пять самых недавно открываемых файлов. Инструмент может создавать подагентов с чистыми рабочими окнами для решения сложных подзадач, а инструмент для хранения информации сохраняет данные между сессиями. Основная философия заключается в том, чтобы делать самое простое решение, которое сработает, доверяя модели способность самостоятельно определить необходимое и предоставляя ей инструменты для его поиска.
Manus. Этот подход предполагает более интенсивное использование инфраструктуры и подходит для универсальных агентов, обслуживающих сотни тысяч пользователей, где важна эффективность в масштабе. Основной особенностью является упорядочивание операций с учётом KV-кэша, что обеспечивает стабильность префиксов на протяжении нескольких шагов для максимального повторного использования кэша, а также использование маскировки инструментов вместо их удаления. Пайплайн сжатия данных обрабатывает выходные данные каждого инструмента до того, как они попадут в контекст агента. Перманентный список задач отслеживает состояние, а файловая система служит дополнительной памятью для хранения вытесненных данных из контекста.
ChatGPT Agent. Агент от OpenAI, возникший на основе Operator, архитектурно отличается от обоих предыдущих вариантов. Он работает на основе модели Computer-Using Agent и использует графический интерфейс в качестве основного инструмента. Вместо вызовов инструментов в текстовом формате он управляет визуальным браузером, при этом скриншоты поступают в контекст в виде кадров, над которыми модель анализирует информацию вместе с историей предыдущих скриншотов и действий. Это изменяет характер задач. Визуальные токены имеют высокую стоимость, поэтому агенту необходимо тщательно выбирать, сколько скриншотов сохранять. OpenAI использует метод усиленного обучения для поиска эффективных стратегий использования инструментов, тренируясь на тысячах виртуальных машин вместо того, чтобы жестко прописывать, когда использовать тот или иной инструмент. Deep Research и Operator делятся состоянием, что обеспечивает плавную переключаемость между просмотром веб-страниц, анализом текста и выполнением кода. По сравнению с ориентированным на код, основанным на текстовых инструментах и имеющим большое окно Claude Code, этот инструмент носит визуальный характер и предназначен для универсального использования. Оба требуют работы с контекстом, но сталкиваются с разными проблемами и имеют разные решения.
Набор инструментов для разработки агентов от Google. ADK занимает наиболее принципиальную архитектурную позицию, предусматривая три принципа проектирования контекста агента. Необходимо разделять хранение данных и их отображение, поскольку устойчивое состояние не всегда совпадает с тем, что отображается при определенном вызове API. Следует использовать явные преобразования, то есть названные, упорядоченные процессоры, которые преобразуют контекст в тестируемых, комбинируемых шагах, вместо спонтанного объединения строк. По умолчанию контекст ограничивается определенными рамками, так что каждый вызов модели видит только минимум необходимой информации, и ничто не попадает в контекст, если оно не было явно включено. В результате сбор контекста рассматривается как процесс с четкими этапами, а не как текст-запрос, к которому постоянно добавляют новое.
Общий процесс обработки контекста
Если рассмотреть все эти платформы, на каждом шаге агента проявляется одна и та же структура:
- Сбор кандидатов: ввод пользователя, история, результаты инструментов, полученные документы и состояние агента.
- Выбор того, что актуально для текущего шага, в рамках оставшегося лимита токенов.
- Сжатие путем краткого изложения, обрезки или перестройки выбранного материала для соответствия лимиту.
- Упорядочивание всего содержимого для повторного использования в KV-кэше: сначала стабильное содержимое, затем динамическое.
- Сформирование окончательного контекста и выполнение запроса.
Эта область развивается быстро, и ещё многое предстоит изучить, поэтому лучший способ совершенствования — экспериментировать: создавать что-то новое, наблюдать, где возникают проблемы, и вносить коррективы.
Связанные материалы
- Инжиниринг контекста для приложений на основе LLM: структурированные результаты, инструменты и ограничения агентов: Как целенаправленно формировать входные данные для модели: выбор контекста, шаблоны запросов, схемы JSON, ограниченная декодировка, вызов инструментов, циклы агентов и ограниченная автономия.
- Стратегии разбиения на чанки для производственных систем RAG: фиксированный размер, семантическое разбиение и структура «родитель-дочерний»: Практический обзор методов разбиения на чанки в системах RAG — от фиксированного размера и рекурсивного разделения до структуры «родитель-дочерний», использования предложений, позднего формирования чанков, технологии RAPTOR, таблиц, кода и методов оценки эффективности.