Стратегии контекстной инженерии для ИИ-агентов: руководство для разработчиков
Создавать надежных ИИ-агентов сложнее, чем кажется. Часто они начинают сильно, но по мере усложнения задач появляются трещины. Агенты нередко теряют нить предыдущих шагов, противоречат собственной логике или оказываются перегружены сложностью из-за слишком большого контекста.
Эта проблема вызвала оживленные дебаты в индустрии. Недавно Anthropic (Claude) и Cognition (Devin) схлестнулись в споре о том, что является лучшим путем вперед: многоагентное взаимодействие или одноагентная архитектура. Anthropic указала на эксперименты, показывающие, что многоагентные конфигурации достигают на 90,2% более высоких показателей успеха, тогда как Cognition возразила, что одиночные агенты со сжатием длинного контекста обеспечивают большую стабильность и более низкие затраты.
У обеих сторон есть веские аргументы, и, по сути, они спорят об одной и той же ключевой проблеме: как эффективно управлять контекстом агента.
Думайте об LLM как о CPU, а об их контекстных окнах — как о RAM. Но есть нюанс: в аппаратном обеспечении всегда можно добавить больше RAM. В LLM длина контекста ограничена по замыслу, а ее дальнейшее расширение связано с серьезными издержками с точки зрения скорости и точности. Тем временем агенты генерируют огромные объемы информации в ходе многошаговых рабочих процессов, быстро упираясь в эти ограничения. Это создает критические проблемы:
Информационная перегрузка: контекст превышает емкость → агент дает сбой
Растущие затраты: чем больше обрабатывается токенов, тем выше расходы и задержка
Снижение производительности: избыток информации не делает агентов умнее — он делает их медленнее и менее точными
Именно поэтому инжиниринг контекста стал центральной задачей проектирования агентов следующего поколения. Лидеры индустрии уже опробовали разные способы решения этой проблемы, и многие из них на самом деле работают очень хорошо.
В этом блоге мы рассмотрим, как LangChain, Lossfunk и Manus подходят к этой проблеме с разных сторон, предлагая взаимодополняющие стратегии, которые помогают агентам оставаться и способными, и экономически эффективными.
4 стратегии LangChain для решения проблем контекста агентов
LangChain объединяет проблемы контекста агентов в четыре распространенных режима отказа:
Отравление контекста: проскакивают нерелевантные или неверные детали, что приводит к бессмысленным результатам.
Отвлечение контекста: критически важная информация оказывается погребена под шумом.
Путаница контекста: слишком большой объем несвязанных данных заставляет агента терять фокус.
Конфликт контекста: противоречивые входные данные приводят к непоследовательному поведению.
Чтобы справиться с этими проблемами, LangChain представила фреймворк из четырех стратегий для инжиниринга контекста агентов: Write, Select, Compress и Isolate.
#1 Write Context: предоставление агентам внешней памяти
Люди решают задачи, делая заметки и перенося знания дальше. Агенты учатся делать то же самое. Один распространенный подход — “scratchpad”, где промежуточные рассуждения и находки сохраняются за пределами контекстного окна. Например, во время ревью кода вместо повторного сканирования всей кодовой базы агент может фиксировать проблемы и исправления по каждому файлу. Со временем это формирует постоянную, доступную для запросов память, которая растет вместе с опытом.
#2 Select Context: фильтрация по релевантности
Не каждая часть информации заслуживает внимания. Команда Windsurf показала, что навигация по большим кодовым базам требует сочетания синтаксического анализа с извлечением из графа знаний, чтобы агенты выводили только релевантные фрагменты вместо того, чтобы тонуть в нерелевантных строках.
#3 Compress Context: суммаризация по требованию
Claude Code хорошо демонстрирует этот подход благодаря своей функции «auto-compact». Когда разговор приближается к пределу контекста, система сжимает сотни реплик в краткое резюме, сохраняя критически важные для задачи детали и освобождая место для нового рассуждения.
#4 Изолируйте контекст: модульное управление контекстом
LangGraph применяет этот принцип через многоагентную архитектуру. Сложные задачи делятся на модули, при этом каждый субагент работает в собственном контекстном пространстве. Такое разделение предотвращает вмешательство: один агент может исследовать альтернативы, не загрязняя ход рассуждений другого.
Подробнее см. блог LangChain о контекстной инженерии.
6 практических советов Lossfunk по контекстной инженерии
Другой взгляд предлагает Lossfunk, рассматривающий управление контекстом как инженерную дисциплину, основанную на реальном внедрении. Их подход делает акцент на балансе трех ограничений, с которыми сталкивается каждая production-команда: производительности, надежности и стоимости. Paras Chopra, основатель Lossfunk, сформулировал шесть практических советов по созданию эффективных LLM-агентов с учетом контекста.
#1 Меньше задачи — выше успех
Сложные задачи могут перегружать агентов так же, как и людей. Исследование METR показывает, что LLM достигают своих самых высоких показателей успешности — около 90% — когда задачи ограничены 10–15 минутами работы. Вместо того чтобы просить агента рефакторить всё приложение за один запуск, разбейте проект на более мелкие, атомарные шаги: проанализировать модуль аутентификации, выявить потенциальные проблемы безопасности, а затем предложить точечные исправления. Это отражает то, как работают опытные разработчики: один сфокусированный шаг за раз, с постепенным накоплением прогресса.
Источник: Measuring AI Ability to Complete Long Tasks
#2 Целые файлы > фрагментированный поиск
В отличие от акцента LangChain на фильтрации и сжатии, Paras утверждает, что больше контекста обычно лучше. Его точка зрения заключается в том, что RAG-системы часто дробят информацию на небольшие, неполные фрагменты, из-за чего агенты могут путаться или сомневаться. Вместо этого он предлагает загружать полные файлы или наборы данных непосредственно в контекстное окно, давая модели полную картину.
Lossfunk подкрепляет эту точку зрения данными бенчмарков. На SWE-bench-Verified подходы, использовавшие контекст полного файла, достигали около 95% точности по сравнению примерно с 80% у фрагментированного поиска. Разница возникает из-за связности: с полными файлами модель видит связи по всему документу, а не сшивает разрозненные части.
Конечно, это связано с компромиссами. Предоставление большего контекста LLM-агентам увеличивает как стоимость, так и задержку. Командам необходимо взвешивать преимущества полноты и расходы на более длинные промпты — этот баланс зависит от задачи и production-ограничений.
#3 Добавляйте шаг проверки после каждой задачи
Ошибки склонны накапливаться в длинных цепочках рассуждений. Чтобы снизить этот риск, Lossfunk предлагает проектировать каждый шаг как функцию без сохранения состояния с явными проверками успеха/сбоя. После каждого вызова инструмента или действия рассуждения агент должен подтвердить, удалось ли выполнить операцию, и четко указать следующий шаг.
Этот паттерн похож на модульное тестирование в разработке программного обеспечения: выявляйте небольшие ошибки на раннем этапе, прежде чем они перерастут в более крупные сбои. Встраивая проверку, разработчики создают естественные точки восстановления, которые делают агентов более устойчивыми в производственных рабочих процессах.
#4 Часто напоминайте модели
Модели часто забывают ранние инструкции в длинных диалогах, поэтому крайне важно постоянно подкреплять цели задачи и текущее состояние. Регулярно добавляйте в свои промпты краткие сводки задачи и текущие цели. Не предполагайте, что модель помнит, что она должна была делать 50 обменов назад. Это не ограничение — это просто то, как работает человеческое мышление. Мы используем внешние средства памяти, такие как заметки и напоминания, чтобы не сбиваться с курса при выполнении сложных задач.
#5 Оснастите агентов инструментами чтения/записи, чтобы создавать контекст по требованию
Попытка втиснуть каждый фрагмент информации в окно контекста быстро приводит к перегрузке. Лучший подход — дать агентам инструменты чтения/записи, чтобы они могли извлекать или записывать информацию по мере необходимости. Вместо предварительной загрузки целых наборов документации оснастите своего агента средствами чтения файлов или коннекторами к базам данных и позвольте ему подтягивать релевантные детали по требованию.
Это отражает то, как работают опытные разработчики: они не запоминают всю кодовую базу, но знают, как найти нужную функцию или файл, когда возникает необходимость. Расширяя агентов возможностью запрашивать и обновлять внешние источники, разработчики могут сохранять контекст компактным, одновременно обеспечивая агенту доступ к необходимым знаниям.
#6 Сохраняйте контекст неизменяемым, чтобы использовать KV Cache
Каждый ход диалога с сильно изменяющимся контекстом может становиться чрезвычайно дорогим — иногда превышая $100 за ответ. Чтобы воспользоваться оптимизациями KV cache, сохраняйте как можно большую часть контекста неизменяемой. Вместо замены контекста на каждом шаге добавляйте новую информацию и поддерживайте согласованные, структурированные форматы во всех взаимодействиях.
Эта, казалось бы, небольшая техническая корректировка может принести непропорционально большую пользу: снизить затраты на порядок и одновременно улучшить время отклика. Для производственных развертываний это одна из самых эффективных низкоуровневых оптимизаций, которые разработчики могут применить.
Подробнее см. этот блог Paras.
Manus: 7 уроков из создания агентов
Manus — это полностью автономная мультиагентная AI-система, предназначенная для выполнения сложных задач с минимальным участием человека — от исследований до управления проектами. В рамках своей работы команда Manus поделилась практическими уроками по context engineering, полученными при эксплуатации их системы в продакшене.
#1 Проектируйте с учетом KV-Cache для экономической эффективности
Для production-grade агентов одним из самых критичных показателей производительности является коэффициент попаданий KV-cache, который напрямую влияет как на стоимость, так и на время отклика. Входные данные для современных агентов становятся длиннее — с обширным контекстом и подробными записями вызовов инструментов, — тогда как выходные данные остаются краткими, часто напоминая вызовы функций. Это несоответствие приводит к непропорционально высоким затратам на prefill.
Рекомендуемый подход — сохранять префиксы промптов стабильными и избегать элементов, нарушающих кэширование, таких как временные метки, которые меняются при каждом запросе. Используйте стратегию контекста только с добавлением вместо переписывания существующего содержимого и обеспечивайте детерминированный порядок для сериализации JSON. Некоторые фреймворки моделей также требуют явного обозначения точек разрыва кэша, чтобы максимизировать повторное использование KV-cache. Следование этим практикам может существенно повысить экономическую эффективность в продакшене.
#2 Используйте маскирование инструментов вместо динамической загрузки
По мере того как количество инструментов возрастает до сотен, включая пользовательские инструменты, модели становятся более склонными к ошибкам или застреванию в процессе выбора инструмента. Проблема усугубляется тем, что динамическая вставка или удаление инструментов делает KV-кэш недействительным и вызывает ошибки ссылок на неопределённые инструменты.
Вместо удаления инструментов используйте маскирование. Техники маскирования токенов позволяют динамически настраивать наборы вызываемых инструментов, не нарушая работу кэша. Используйте единые префиксы, такие как browser_, для удобной группировки и ограничения, и применяйте формат Hermes или поддерживаемую API предзаполненную функцию вызова функций, чтобы контролировать пространство выбора.
#3 Используйте файловую систему как контекст
Хотя контекст в 128K кажется достаточным, он становится тесным при работе с большими веб-страницами, PDF-файлами и другими неструктурированными данными. Типичный подход к сжатию, при котором информация отбрасывается на раннем этапе, может привести к тому, что будущие шаги потеряют критически важный контекст.
Подход Manus позволяет агентам использовать операции чтения/записи файловой системы для вынесения данных наружу. Удаляйте содержимое веб-страниц, но сохраняйте URL-адреса, очищайте документы, но сохраняйте пути к файлам, обеспечивая возможность восстановления информации. Это реализует систему «долговременной памяти» и одновременно закладывает основу для будущих, более лёгких архитектур, таких как SSM.
#4 Управляйте вниманием через декламацию
Manus постоянно обновляет todo.md , проговаривая незавершённые цели в конце контекста. Эта техника позволяет избежать проблем «потерянного в середине» и улучшает способность модели сохранять согласованность целей во время длительных процессов. «Самонапоминание» на естественном языке доказало, что является одним из наиболее эффективных методов захвата и удержания внимания.
#5 Сохраняйте следы неудач для обучения
Языковые модели неизбежно сталкиваются с галлюцинациями, сбоями среды и ошибками вызовов. Большинство систем привычно очищают следы неудач, повторяют попытку или выполняют сброс, но это препятствует обучению. Правильный подход сохраняет записи о сбоях, включая трассировки стека и результаты наблюдений, помогая моделям корректировать свои убеждения и избегать повторения идентичных ошибок. Способность восстанавливаться после ошибок является точной мерой интеллекта агента.
#6 Избегайте ловушек few-shot
Few-shot prompting — широко известная техника улучшения выходных данных LLM, но Manus предупреждает, что в агентных системах она может порождать тонкие проблемы. Поскольку модели естественным образом имитируют паттерны контекста, загрузка слишком большого количества повторяющихся few-shot примеров может зафиксировать их в жёстких моделях поведения. Например, когда Manus использовал batch prompting для анализа резюме, модель начала механически повторять одни и те же действия вместо того, чтобы адаптироваться к специфике каждого случая.
Решение — внести вариативность и разнообразие в примеры. Слегка изменяйте шаблоны действие–наблюдение, меняя форматы, порядок или формулировки. Добавление структурированного «шума» предотвращает хрупкость агентов и помогает им оставаться адаптивными. Это сохраняет гибкость, одновременно предоставляя модели полезные ориентиры.
#7 Отдавайте приоритет контекстной инженерии, а не дообучению
В своей ранней работе с моделями вроде BERT Manus в значительной степени полагался на дообучение — процесс, который часто занимал недели итераций и быстро становился неэффективным и дорогостоящим. Основываясь на этом опыте, команда сместила фокус с end-to-end обучения на контекстную инженерию как основной рычаг повышения производительности.
Эффект был значительным: циклы обновления продукта сократились с недель до часов. Обновления моделей можно было интегрировать без лишних сложностей, без переобучения или повторной адаптации. Manus описывает разницу как создание продуктов, подобных кораблям, которые могут менять курс, а не столбам, прибитым к морскому дну и неспособным двигаться при изменении условий. Контекстная инженерия дала им гибкость без ущерба для возможностей.
Подробнее см. в этом блоге Manus.
Как векторные базы данных поддерживают контекстную инженерию
Одна из самых сложных задач для AI-агентов — исчерпание контекста. Когда агентам необходимо обрабатывать огромные внешние базы знаний, длинные истории диалогов или мультимодальные данные, способность динамически хранить, извлекать и повторно использовать информацию становится критически важной для надежности.
Векторные базы данных предлагают практическое решение. Milvus, например, — это open-source высокопроизводительная система, созданная для работы с мультимодальными данными миллиардного масштаба — текстом, изображениями, видео и многим другим. Представляя эту информацию в виде векторов, Milvus позволяет агентам мгновенно извлекать наиболее релевантные фрагменты знаний и прошлые взаимодействия в свой процесс рассуждения. Интегрированный с такими фреймворками, как LangChain или LlamaIndex, Milvus обеспечивает работу систем retrieval-augmented generation (RAG), которые расширяют базу знаний агента и повышают точность инференса. Его управляемый сервис, Zilliz Cloud, предлагает еще более продвинутые возможности и более высокую производительность, такие как запросы на естественном языке, надежность и безопасность корпоративного уровня, а также глобальная доступность в AWS, GCP и Azure.
Developer experience не менее важен. Milvus предлагает хорошо документированный Python SDK, который позволяет легко сохранять и запрашивать векторы всего в несколько строк кода. Это снижает технический порог и позволяет командам быстро выстраивать замкнутый цикл управления контекстом, встраивая надежные возможности памяти непосредственно в своих агентов.
from pymilvus import MilvusClient
# Create local Milvus instance
client = MilvusClient("demo.db")
# Create vector collection
client.create_collection(collection_name="knowledge_base", dimension=768)
# Batch insert vectorized data into knowledge base
client.insert(collection_name="knowledge_base", data=embedding_vectors)
# Retrieve most relevant context information
query_vector = embedding_fn.encode_queries(["What is Context Engineering?"])
results = client.search(
collection_name="knowledge_base",
data=query_vector,
limit=3,
output_fields=["text", "source"]
)
Для получения дополнительной информации ознакомьтесь со следующими ресурсами:
Milvus + Loon: специализированная инфраструктура для AI-агентов
Векторные базы данных занимают центральное место в контекстной инженерии, но они являются лишь одной частью стека. Агентам также нужен способ обрабатывать «грязные» мультимодальные данные на входе, а затем извлекать их с высокой скоростью во время выполнения. Именно поэтому мы спроектировали Milvus и Loon для совместной работы — один отвечает за извлечение, другой готовит данные в масштабе.
Milvus: Milvus — самая широко используемая open-source векторная база данных, оптимизированная для нагрузок миллиардного масштаба с текстом, изображениями, аудио и видео. Она с нуля создана для векторного поиска, обеспечивая извлечение менее чем за 10 мс даже при огромных масштабах. Для агентов это напрямую превращается в отзывчивость: будут ли они ощущаться мгновенными и надежными или медленными и склонными к ошибкам, зависит от скорости извлечения.
Loon (скоро): Loon — наш будущий облачный нативный сервис мультимодального озера данных, предназначенный для мультимодальной предобработки. Реальные наборы данных «грязные» — дублируются, противоречивы и разбросаны по форматам. Loon использует распределенные фреймворки, такие как Ray и Daft, чтобы очищать, дедуплицировать и кластеризовать эти данные перед потоковой передачей в Milvus. Результат: агенты не тратят циклы на шум; они потребляют структурированный, высококачественный контекст с первого дня.
Облачная эластичность: Обе системы масштабируют хранилище и вычислительные ресурсы независимо, позволяя командам балансировать обслуживание в реальном времени с офлайн-аналитикой по мере роста рабочих нагрузок от гигабайтов до петабайтов. Никакого избыточного выделения ресурсов, никаких узких мест — только эластичность, которой требуют современные AI-пайплайны.
Фундамент, готовый к будущему: Сегодняшний приоритет — семантический поиск и RAG-пайплайны; завтрашний — мультимодальное рассуждение и рабочие процессы, управляемые агентами. С Milvus и Loon один и тот же стек поддерживает и то и другое. Вы получаете гибкость для развития без демонтажа инфраструктуры — снижая затраты, риски и сложность.
Контекст — настоящий передний край для AI-агентов
Как показывает дискуссия о дизайне с одним агентом и с несколькими агентами, настоящее узкое место для современных AI-агентов — не только креативность, а контекст. Будь то четырехкомпонентный фреймворк LangChain, ориентированный на продакшен плейбук Lossfunk или выстраданные уроки Manus по созданию полностью автономных систем, индустрия сходится на одном и том же понимании: агенты добиваются успеха или терпят неудачу в зависимости от того, насколько хорошо они проектируют контекст.
Стратегии различаются — одни делают акцент на записи и фильтрации, другие выступают за контекст полного файла или дизайн с учетом кэша, — но цель одна и та же, особенно для готовых к продуктовой эксплуатации агентов: сохранять агентов одновременно способными и экономически эффективными. И хотя ни один отдельный метод не решает всех задач, вместе они формируют растущий корпус практик, которые разработчики могут адаптировать к собственным системам.
В Zilliz мы рассматриваем векторные базы данных, такие как Milvus, как краеугольный камень этого инструментария. Предоставляя агентам масштабируемую и более точную память за пределами контекстного окна, разработчики могут сделать проектирование контекста практичным, гибким и готовым к продакшену. Будущее AI-агентов будет определяться не только более крупными моделями, но и более умными способами проектирования контекста — и именно там произойдут настоящие прорывы.
Читать далее
A Few Notes from Databricks Data + AI Summit 2026: Why the Data Layer Matters Again
James Luan shares notes from Databricks Data + AI Summit 2026 on why production AI is pushing the data layer back to the center of infrastructure.
Vector Databases vs. Document Databases
Use a vector database for similarity search and AI-powered applications; use a document database for flexible schema and JSON-like data storage.
Legal Document Analysis: Harnessing Zilliz Cloud's Semantic Search and RAG for Legal Insights
Enhance legal document analysis with Zilliz Cloud’s Semantic Search and RAG. Improve accuracy, efficiency, and scalability for contracts, case law, and compliance.