Введение
Этот транскрипт основан на вебинаре LangChain и Manus о контекстной инженерии для AI-агентов.
Я дам краткий обзор контекстной инженерии, как я ее понимаю, сошлюсь на их статью, а затем Пит представит презентацию с новыми идеями, не освещенными в статье. Если вы уже читали статью, мы рассмотрим новые вещи, что должно быть довольно интересно.
Введение в контекстную инженерию
Возможно, вы слышали термин "контекстная инженерия" - он появился в этом году. Если посмотреть на тренды Google поиска, промпт-инженерия началась после ChatGPT в декабре 2022 года. Контекстная инженерия появилась в этом году примерно в мае и соответствует идее "года агентов".
Почему это важно?
Одна из вещей, которую наблюдают люди, создающие агентов - контекст растет, и растет очень специфическим образом. Когда вы создаете агента, у вас есть LLM, связанная с некоторым количеством инструментов. LLM может вызывать инструменты автономно в цикле.
Проблема в том, что для каждого вызова инструмента вы получаете наблюдение от инструмента, которое добавляется в список чата. Эти сообщения растут со временем, и вы можете получить неограниченный взрыв сообщений по мере работы агентов.
- Manus: типичные задачи требуют около 50 вызовов инструментов
- Anthropic: продакшн-агенты могут участвовать в разговорах, охватывающих сотни ходов
Парадокс контекста
Проблема в том, что агенты накапливают большое количество контекста через вызовы инструментов, но мы знаем, что производительность падает по мере роста контекста. Это парадокс: агенты используют много контекста из-за вызовов инструментов, но производительность падает по мере роста контекста.
Карпати ввел этот термин в Twitter в начале года. Контекстную инженерию можно рассматривать как "деликатное искусство и науку заполнения контекстного окна именно той информацией, которая нужна для следующего шага".
Основные подходы к контекстной инженерии
1. Выгрузка контекста (Context Offloading)
Центральная идея: не весь контекст должен жить в истории сообщений вашего агента. Вы можете взять информацию и выгрузить ее, отправить куда-то еще, чтобы она была вне контекстного окна, но могла быть извлечена.
Одна из самых популярных идей - использование файловой системы. Возьмите вывод сообщения инструмента, сохраните его в файловой системе, отправьте агенту только минимальную информацию, необходимую для ссылки на полный контекст при необходимости.
Используется в: Manus, Deep Agents, Open Deep Research, Claude Code, долгоработающие агенты
2. Сокращение контекста (Context Reduction)
Похоже на выгрузку, но вместо этого вы суммируете или сжимаете информацию:
- Суммирование выводов вызовов инструментов
- Обрезка вызовов инструментов или сообщений инструментов
- Claude 4.5 теперь поддерживает это из коробки
- Суммирование полной истории сообщений
- Сжатие при передаче между агентами
3. Извлечение контекста (Context Retrieval)
Классические дебаты о правильном подходе для извлечения контекста:
- Cursor: использует индексирование и семантический поиск, а также простые файловые инструменты поиска
- Claude Code: использует только файловую систему и простые инструменты поиска
4. Изоляция контекста (Context Isolation)
Разделение контекста между мульти-агентами. Каждый под-агент имеет свое контекстное окно, что позволяет разделить ответственность.
5. Кэширование контекста
Manus много говорит об этом - очень интересный трюк для оптимизации производительности и снижения затрат.
Презентация Пита (Manus)
Свежие уроки контекстной инженерии
Я говорю "свежие уроки", потому что понял, что последний блог-пост о контекстной инженерии я написал в июле, а июль в году агентов - это практически прошлая эра. Сегодня я хочу углубиться в области, которые либо недостаточно глубоко рассмотрел раньше, либо вообще не затрагивал.
Почему нужна контекстная инженерия?
Особенно когда файн-тюнинг или пост-тренинг моделей стал более доступным сегодня. Например, команда Thinking Machine выпустила Tinker API с отличным дизайном.
До создания Manus я уже провел более 10 лет в обработке естественного языка (NLP). Manus - моя вторая или третья компания, и в предыдущем стартапе мы обучали собственную языковую модель с нуля для извлечения информации из открытых доменов и построения графов знаний.
Это было болезненно. Скорость инноваций нашего продукта была полностью ограничена скоростью итераций модели. Даже тогда модели были намного меньше по сравнению с сегодняшними, но один цикл обучения плюс оценка мог занять одну-две недели.
Вместо создания специализированных моделей слишком рано, стартапы должны полагаться на общие модели и контекстную инженерию как можно дольше.
По мере созревания продукта и усиления базовых моделей с открытым исходным кодом, очень заманчиво думать: "Может, мне стоит взять сильную базовую модель, дообучить ее на моих данных и сделать действительно хорошей для моего случая использования?"
Мы тоже это пробовали. И знаете что? Это еще одна ловушка.
Опасности раннего файн-тюнинга
Чтобы заставить это работать хорошо, вы обычно фиксируете пространство действий, разрабатываете награду вокруг текущего поведения продукта и генерируете тонны роллаутов и обратной связи.
Но это опасно, потому что мы все еще в ранние дни ИИ и агентов. Все может измениться за ночь. Для нас классический пример - запуск MCP. Он полностью изменил дизайн Manus от компактного статического пространства действий к чему-то бесконечно расширяемому.
Будьте тверды в том, где проводите границу. Прямо сейчас контекстная инженерия - это самая четкая и практичная граница между приложением и моделью.
Сокращение контекста: Компактизация vs Суммирование
В Manus мы разделяем операции сокращения на два типа: компактизация и суммирование.
Компактизация
Для каждого вызова инструмента и результата инструмента у нас есть два формата: полный и компактный. Компактная версия убирает любую информацию, которая может быть восстановлена из файловой системы или внешнего состояния.
Инструмент записи в файл имеет поля path и content. После возврата инструмента файл уже существует в среде. В компактном формате мы можем безопасно убрать длинное поле content и оставить только path. Если агент достаточно умен, он может просто извлечь файл по пути при необходимости.
Мы считаем такую обратимость критически важной, потому что агенты делают цепочки предсказаний на основе предыдущих действий и наблюдений. Никогда не знаешь, какое прошлое действие внезапно станет важным через 10 шагов.
Суммирование
Компактизация может завести только до определенного момента. В конце концов контекст все равно будет расти и достигнет потолка. Тогда мы комбинируем компактизацию с традиционным суммированием, но делаем это очень осторожно.
- Перед суммированием мы можем выгрузить ключевые части контекста в файлы
- Иногда мы даже более агрессивно сохраняем весь пре-суммарный контекст как текстовый файл в файловую систему, чтобы всегда можно было его восстановить
Управление порогами
Мы отслеживаем пороги длины контекста:
- Жесткий лимит модели (например, 1 миллион токенов)
- Практический порог деградации (обычно 128K-200K токенов)
Когда размер контекста приближается к порогу деградации, мы запускаем сокращение контекста, начиная с компактизации, а не суммирования. Мы можем компактизировать старейшие 50% вызовов инструментов, сохраняя новые в полной детализации, чтобы модель имела свежие примеры правильного использования инструментов.
Изоляция контекста: Коммуникация vs Разделение памяти
Я согласен с блогом Cognition, где они предупреждают против использования мульти-агентских настроек, потому что синхронизация информации между ними становится кошмаром. Но это не новая проблема - координация многопроцессности была классическим вызовом в ранние дни программирования.
"Не общайтесь через разделение памяти, вместо этого разделяйте память через общение"
Переводя термин "память" в "контекст", мы видим два паттерна:
Паттерн коммуникации
Классическая настройка под-агентов. Главный агент пишет промпт, который отправляется под-агенту, и весь контекст под-агента состоит только из этой инструкции.
Когда использовать: Если задача имеет короткую, четкую инструкцию и важен только финальный результат (например, поиск в кодовой базе конкретного фрагмента).
Паттерн разделения памяти
Под-агент может видеть весь предыдущий контекст - всю историю использования инструментов, но имеет свой собственный системный промпт и пространство действий.
Когда использовать: Для сложных сценариев, где финальный отчет зависит от множества промежуточных поисков и заметок (например, глубокое исследование).
Компромисс: Разделение контекста дорого, потому что каждый под-агент имеет больший ввод для предзаполнения, и поскольку системный промпт и пространство доступа отличаются, вы не можете переиспользовать KV-кэш.
Выгрузка контекста: Многоуровневое пространство действий
Когда люди говорят о выгрузке, они обычно имеют в виду перемещение частей рабочего контекста во внешние файлы. Но по мере роста системы, особенно при интеграции MCP, вы понимаете, что сами инструменты тоже могут занимать много контекста.
Слишком много инструментов в контексте приводит к путанице - модель может вызывать неправильные или несуществующие инструменты.
Многоуровневое пространство действий в Manus
Уровень 1: Вызов функций
Классический подход. Схемно-безопасный благодаря ограниченному декодированию, но имеет недостатки:
- Нарушение кэша
- Слишком много инструментов может вызвать путаницу
- Чтение и запись файлов
- Выполнение shell-команд
- Поиск файлов в интернете
- Операции браузера
Уровень 2: Утилиты песочницы
Каждая сессия Manus работает в полной виртуальной машине-песочнице на нашей кастомизированной Linux-системе. Manus может использовать shell-команды для запуска предустановленных утилит:
- Конвертеры форматов
- Утилиты распознавания речи
- MCP CLI для вызова MCP
Преимущества:
- Можно добавлять новые возможности без изменения пространства вызова функций
- Большие выводы могут записываться в файлы
- Можно использовать Linux-инструменты для обработки результатов
Уровень 3: Пакеты и API
Manus может писать Python-скрипты для вызова предавторизованных API или кастомных пакетов:
- 3D-дизайн библиотеки
- Финансовые API для рыночных данных
- Мы покупаем все эти API от имени пользователя
Преимущества:
- Идеально для задач, требующих много вычислений в памяти
- Код и API очень композитны
- Можно объединять много вещей в один шаг
Недостатки:
- Не схемно-безопасно
- Очень сложно делать ограниченное декодирование
Баланс пяти измерений
Выгрузка, сокращение, извлечение, изоляция и кэширование не независимы:
- Выгрузка и извлечение обеспечивают более эффективное сокращение
- Стабильное извлечение делает изоляцию безопасной
- Изоляция замедляет контакты и снижает частоту сокращения
- Больше изоляции и сокращения влияет на эффективность кэша и качество вывода
Контекстная инженерия требует идеального баланса между множественными потенциально конфликтующими целями.
Избегайте чрезмерной контекстной инженерии
Оглядываясь на прошедшие 6-7 месяцев с запуска Manus, самые большие скачки не пришли от добавления более сложных слоев управления контекстом или умных хаков извлечения. Они пришли от упрощения или удаления ненужных трюков и большего доверия модели.
Каждый раз, когда мы упрощали архитектуру, система становилась быстрее, стабильнее и умнее. Цель контекстной инженерии - сделать работу модели проще, а не сложнее.
Стройте меньше и понимайте больше.
Сессия вопросов и ответов
Как LLM вызывает различные shell-инструменты?
/usr/bin. Мы делаем две вещи:
1. У нас есть подсказка в системном промпте, говорящая Manus, что есть много предустановленных утилит командной строки в определенной папке
2. Для наиболее часто используемых мы уже включили их в системный промпт, но очень компактно - мы не говорим агенту, как использовать инструменты, только перечисляем их
Мы говорим агенту, что он может безопасно использовать флаг
--help, потому что все утилиты разработаны нашей командой и имеют одинаковый формат.
Используете ли вы индексирование?
grep и glob.
Но если вы рассматриваете создание долгосрочной памяти или интеграцию корпоративной базы знаний, вам все равно придется полагаться на внешний векторный индекс. Это зависит от масштаба.
Есть ли у вас понятие памяти между сессиями?
Мы также исследуем более автоматические способы. Интересная вещь в агентах - по сравнению с чат-ботами, пользователи часто исправляют агента. Например, при визуализации данных на китайском, японском или корейском часто возникают проблемы со шрифтами. Пользователь скажет: "Используй CJK-шрифт". Разные пользователи будут делать одинаковые исправления, и нам нужно найти способ использовать эту коллективную обратную связь.
Как вы подходите к рефакторингу архитектуры с улучшением моделей?
У нас есть внутренняя теория для оценки архитектуры агентов: мы фиксируем архитектуру агента и переключаемся между моделями. Если ваша архитектура может много выиграть от переключения с более слабой модели на более сильную, то ваша архитектура более устойчива к будущему.
Мы часто делаем такие проверки каждые 1-2 месяца, используя открытые модели и ранний доступ к проприетарным моделям для подготовки к следующему релизу.
Лучшие практики для форматов хранения данных?
grep или читать из диапазона строк. Markdown иногда может вызывать проблемы - модели обучены хорошо использовать markdown, но иногда выводят слишком много маркированных списков. Мы предпочитаем обычный текст.
Как промптить для хорошего суммирования?
Например: "Вот файлы, которые я изменил", "Вот цель пользователя", "Вот где я остановился". Если использовать структурированную схему, вывод стабилен и можно итерировать.
Выбор модели и использование открытых моделей?
Распределенный KV-кэш очень сложно реализовать с открытыми решениями. Если использовать передовых провайдеров LLM, у них более надежная инфраструктура для распределенного кэширования глобально.
Иногда, если посчитать, использование флагманских моделей может быть даже дешевле, чем открытые модели.
Сейчас мы используем не только Anthropic - модели Anthropic лучший выбор для агентских задач, но мы также видим прогресс в Gemini и OpenAI. Передовые лаборатории не сходятся в направлениях: для кодинга используйте Claude, для мультимодальности - Gemini, OpenAI отлично подходит для сложной математики и рассуждений.
Для компаний приложений, как мы, одно из наших преимуществ - мы не должны строить поверх только одной модели. Можно делать маршрутизацию на уровне задач или даже подзадач.
Планирование в Manus?
todo.md - это было глупо и тратило много ходов. Треть действий была об обновлении списка дел.
Сейчас мы используем более структурированное планирование. Есть планировщик внизу системы - отдельный агент, управляющий планом, используя парадигму "агент как инструмент". Очень важно иметь отдельного агента с другой перспективой для внешнего обзора. Можно использовать разные модели для планирования.
Гарантии безопасности?
У нас есть проверки исходящего трафика, чтобы токены не выходили из песочницы. У нас есть браузер внутри Manus, что очень сложно - содержимое веб-страницы может быть вредоносным.
Сейчас в Manus каждый раз при выполнении чувствительных операций требуется ручное подтверждение. Это прогрессивный подход - пока ограждения в самой модели не улучшатся, мы позволяем пользователю чаще брать управление на себя.
Подход к оценкам (evals)?
Сейчас у нас три вида оценок:
1. Самое важное: Для каждой завершенной сессии мы просим пользователя дать обратную связь от 1 до 5 звезд. Это золотой стандарт.
2. Автоматизированные тесты с проверяемыми результатами. Мы создали собственный датасет с четкими ответами, сосредоточенный на выполнении, потому что большинство бенчмарков сосредоточены на задачах рассуждения.
3. Человеческие оценщики - много стажеров для оценки вещей как генерация веб-сайтов или визуализация данных, потому что очень сложно создать хорошую модель вознаграждения, которая знает, визуально ли привлекателен вывод.