Volcengine lance OpenViking — une base de contexte basée sur des fichiers pour des agents AI comme OpenClaw

Volcengine a publié en open source OpenViking — une base de contexte pour les agents AI, y compris des systèmes comme OpenClaw. Le projet propose de stocker la mémoire, les ressources et les compétences non pas dans des indices vector dispersés, mais dans une hiérarchie proche d’un système de fichiers classique.

Le contexte comme système de fichiers

L’idée principale d’OpenViking est qu’il est peu pratique pour un agent de travailler avec le contexte comme avec un ensemble plat de fragments de texte. Dans un pipeline RAG typique, les documents sont séparés, la mémoire utilisateur est séparée, et les outils ainsi que les compétences vivent carrément ailleurs. À cause de cela, il est difficile pour un développeur de comprendre exactement ce que l’agent a vu, pourquoi il a choisi tel ou tel fragment et où chercher l’erreur si la réponse s’est révélée faible. OpenViking essaie de ramener tout cela à un seul modèle — un système de fichiers virtuel avec des adresses `viking://`.

• `viking://resources` — documentation, dépôts, pages web et autres connaissances externes
• `viking://user` — mémoire sur l’utilisateur, ses habitudes et ses préférences
• `viking://agent` — compétences, instructions et mémoire de travail de l’agent lui-même
• `.abstract` — une courte couche L0 pour vérifier rapidement la pertinence
• `.overview` — une couche L1 avec une vue d’ensemble avant la lecture du contenu complet

À l’intérieur de cette structure, les différents types de contexte sont répartis dans des répertoires avec des URI clairs, et l’agent peut y accéder presque comme un développeur accède à des fichiers locaux.

Grâce à cela, le contexte cesse d’être une boîte noire. Au lieu de l’idée abstraite selon laquelle quelque chose a été trouvé via embedding, on obtient une navigation compréhensible : l’agent peut parcourir l’arborescence, lire des fichiers précis, chercher dans un répertoire, suivre le chemin jusqu’au fragment voulu et contrôler plus finement ce qui entre dans le prompt.

Moins de bruit dans le prompt

Un autre mécanisme clé d’OpenViking est le chargement du contexte sur trois niveaux. Lors de l’écriture, le système ne se contente pas de placer le fichier dans un index, il prépare de manière asynchrone plusieurs niveaux de représentation. L0 est un résumé court en une phrase, L1 est une vue d’ensemble avec une distillation sémantique et des scénarios d’usage, L2 est le matériau source complet. L’agent voit d’abord les niveaux compacts et ne descend dans le détail que si nécessaire. Cette approche réduit la consommation de tokens et limite le bruit dans les tâches longues.

Sous le capot, OpenViking sépare le parsing et le traitement sémantique. D’abord, les documents sont convertis dans une forme structurée, puis une file distincte se charge de la génération des vues d’ensemble et de la vectorization. Cela permet d’importer non seulement du Markdown ou du texte, mais aussi des PDF, HTML, Word, PowerPoint, Excel, EPUB, images, audio et vidéo. Pour le code, il existe un mode séparé avec tree-sitter : le système sait extraire le squelette structurel de fichiers en Python, JavaScript, TypeScript, Rust, Go, Java et C/C++, afin d’éviter des appels LLM inutiles là où un squelette AST suffit.

Recherche et mémoire

La recherche dans OpenViking n’est pas conçue comme une seule requête vector sur toute la base. Le système analyse d’abord l’intention, trouve ensuite rapidement le répertoire ayant le plus de chances de contenir la bonne réponse, puis affine la recherche à l’intérieur de ce répertoire et, si nécessaire, descend plus profondément dans les sous-répertoires. Les développeurs appellent cela directory recursive retrieval. L’idée est que l’agent ne cherche pas seulement un fragment de texte similaire, mais comprend aussi dans quel contexte ce fragment se trouve. Cela améliore la précision et rend les résultats moins aléatoires.

L’observabilité est elle aussi importante. OpenViking conserve la trajectoire de recherche à travers les répertoires, ce qui permet de voir exactement où l’agent est allé et à quelle étape il s’est trompé de direction. Pour les équipes qui déboguent des systèmes d’agents, c’est plus utile qu’un log RAG classique avec quelques valeurs de score.

Le projet intègre aussi un travail avec la mémoire à long terme : après une session, le système peut extraire de manière asynchrone des faits issus des dialogues, des appels d’outils et des résultats de tâches, puis mettre à jour la mémoire de l’utilisateur et celle de l’agent lui-même.

Un scénario pratique a déjà été montré avec l’exemple d’OpenClaw. Il existe un plugin pour celui-ci qui utilise OpenViking comme backend de mémoire à long terme, importe les ressources et les compétences dans les espaces `viking://` correspondants, puis fournit à l’agent des commandes distinctes pour la recherche, la sauvegarde des souvenirs et l’ouverture des archives. Autrement dit, le projet ne ressemble pas à une idée de recherche abstraite, mais à une couche d’infrastructure que l’on peut déjà connecter à de vrais agents dans des pipelines de travail.

Ce que cela signifie

OpenViking montre que le marché de l’infrastructure agentique s’éloigne du schéma primitif chat plus vector database pour aller vers une mémoire plus pilotable, avec hiérarchie, traçage et fonctionnement sur le long terme. Si cette approche s’impose, les développeurs concevront la mémoire des agents avec autant d’intention qu’ils conçoivent aujourd’hui les structures de fichiers, les API et les bases de données.