Стратегии контекстной инженерии для ИИ-агентов: руководство для разработчиков
Создавать надежных ИИ-агентов сложнее, чем кажется. Часто они начинают сильно, но по мере усложнения задач появляются трещины. Агенты нередко теряют нить предыдущих шагов, противоречат собственной логике или оказываются перегружены сложностью из-за слишком большого контекста.
Эта проблема вызвала оживленные дебаты в индустрии. Недавно 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-агентов будет определяться не только более крупными моделями, но и более умными способами проектирования контекста — и именно там произойдут настоящие прорывы.
Читать далее
We spent 8 years making vector databases faster. Then we stopped.
Rarely queried embeddings still need to stay searchable. See how Vector Lakebase enables on-demand vector search without always-on compute costs.
How to Install and Run OpenClaw (Previously Clawdbot/Moltbot) on Mac
Turn your Mac into an AI gateway for WhatsApp, Telegram, Discord, iMessage, and more — in under 5 minutes.
Why Teams Are Migrating from Weaviate to Zilliz Cloud — and How to Do It Seamlessly
Explore how Milvus scales for large datasets and complex queries with advanced features, and discover how to migrate from Weaviate to Zilliz Cloud.