Как перестать кормить LLM лишними токенами и навести порядок в памяти агентов

Представьте, что вы строите сложного AI-агента. Сначала всё идет гладко: пара промптов, небольшая база знаний. Но как только проект разрастается, начинается хаос. Память о прошлых диалогах разбросана по коду, документы лежат в одной векторной базе, инструменты — в другой. В итоге контекстное окно забивается мусором, модель начинает «галлюцинировать», а счета за токены растут быстрее, чем количество успешных запусков. Знакомая ситуация?

Недавно наткнулся на интересный проект от команды Volcengine (это ребята из ByteDance) под названием OpenViking. Они решили подойти к проблеме контекста для агентов с неожиданной стороны — через метафору файловой системы.

В чем идея

Разработчики OpenViking называют свое детище «базой данных контекста». Вместо того чтобы просто складывать эмбеддинги в плоский список, они предлагают структуру, похожую на обычный диск вашего компьютера.

У вас есть виртуальный протокол viking://, где всё разложено по полочкам:

• viking://resources/ — здесь живут ваши документы, код и внешние данные.
• viking://user/ — тут хранятся предпочтения пользователя и его история.
• viking://agent/ — навыки самого агента и его опыт выполнения задач.

Такой подход позволяет агенту не просто искать «что-то похожее» по семантике, а буквально перемещаться по директориям, делать ls или find. Это превращает управление контекстом из гадания на кофейной гуще в предсказуемую работу с данными.

Три уровня погружения

Одна из самых крутых фишек проекта — иерархическая загрузка контекста. Вместо того чтобы пихать в модель весь документ целиком, OpenViking делит данные на три слоя:

1. L0 (Abstract): Короткое описание в одно предложение. Нужно, чтобы агент быстро понял, стоит ли вообще «открывать» этот файл.
2. L1 (Overview): Обзорная информация на пару тысяч токенов. Помогает агенту составить план действий.
3. L2 (Details): Полный исходный текст. Загружается только тогда, когда агент уже точно знает, что ему нужны детали.

Это реально экономит деньги. В тестах с плагином OpenClaw разработчики получили снижение затрат на входные токены до 90% при одновременном росте качества ответов. Когда агент сначала смотрит на «оглавление», а не читает всю библиотеку сразу, он меньше ошибается.

Как это работает на практике

Установка стандартная для Python-проектов:

pip install openviking --upgrade

Для работы понадобятся ключи от LLM. Проект поддерживает модели Doubao (что логично для ByteDance), OpenAI и через LiteLLM — практически всё остальное: Claude, DeepSeek, Gemini или локальные модели через Ollama.

Конфигурация описывается в JSON-файле. Вот пример того, как выглядит настройка сервера:

{
  "storage": {
    "workspace": "/path/to/your/workspace"
  },
  "embedding": {
    "dense": {
      "provider" : "openai",
      "model"    : "text-embedding-3-large"
    }
  },
  "vlm": {
    "provider" : "openai",
    "model"    : "gpt-4-vision-preview"
  }
}

После запуска сервера можно общаться с контекстом через CLI. Например, добавить репозиторий проекта в ресурсы:

ov add-resource https://github.com/volcengine/OpenViking
ov ls viking://resources/
ov find "как работает иерархическая память"

Почему это лучше обычного RAG

Традиционный RAG часто работает как черный ящик: вы кинули запрос, получили куски текста, а почему именно эти — бог весть. В OpenViking реализована «рекурсивная стратегия поиска по директориям».

Сначала система анализирует намерение пользователя, находит нужную директорию через векторный поиск, а затем начинает «зарываться» вглубь, уточняя детали. Весь путь поиска (траектория) визуализируется. Если агент нашел не то, вы сразу увидите, на каком этапе дерево поиска свернуло не туда. Это сильно упрощает отладку.

Еще одна полезная штука — автоматическая итерация памяти. В конце сессии агент может сам проанализировать свои успехи и ошибки, обновить «папку» с опытом и в следующий раз не наступать на те же грабли.

Технический стек

Под капотом у OpenViking довольно бодрый микс:

• Python для основного API и логики агентов.
• Go для компонентов файловой системы (AGFS).
• Rust для быстрого CLI-интерфейса.
• C++ для некоторых расширений ядра.

Требования к окружению серьезные (нужен Python 3.10+, Go 1.22+ и свежий компилятор C++), но для серьезного инструмента это оправдано.

Кому стоит попробовать

Если вы пишете простого чат-бота для ответов на FAQ, OpenViking, скорее всего, будет избыточен. Но если ваш проект — это автономный агент, который должен:

• Работать с огромными кодовыми базами или архивами документации.
• Накапливать долгосрочный опыт общения с конкретным пользователем.
• Минимизировать расходы на API дорогих моделей вроде GPT-4o или Claude 3.5 Sonnet.

В этих случаях структура «контекст как файловая система» может стать тем самым фундаментом, которого не хватает для стабильной работы. Проект сейчас активно растет (уже больше 5000 звезд на GitHub), так что самое время пощупать его в деле, пока он не оброс сложными энтерпрайз-абстракциями.

Посмотреть код и документацию можно в репозитории OpenViking. Там же есть готовый фреймворк VikingBot, чтобы быстро собрать первого агента на этой базе.