Volcengine lance OpenViking, une base de contexte en fichiers pour les agents IA comme OpenClaw

Volcengine a publié OpenViking en open source : une base de contexte pour agents IA, y compris des systèmes comme OpenClaw. Le projet propose de stocker mémoire, ressources et compétences non pas dans des index vectoriels dispersés, mais dans une hiérarchie qui ressemble à un système de fichiers classique.

Le contexte comme système de fichiers

L'idée centrale d'OpenViking est qu'un agent travaille mal avec un contexte vu comme un ensemble plat de morceaux de texte. Dans un pipeline RAG typique, les documents sont rangés à part, la mémoire de l'utilisateur ailleurs, et les outils et compétences vivent encore dans d'autres endroits. Il est donc difficile pour un développeur de comprendre ce que l'agent a vu exactement, pourquoi il a choisi tel fragment et où chercher l'erreur quand la réponse est faible. OpenViking cherche à 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 couche courte L0 pour vérifier rapidement la pertinence
• .overview — une couche L1 avec une vue d'ensemble avant la lecture du contenu complet

Dans cette structure, les différents types de contexte sont répartis dans des répertoires aux URI lisibles, et l'agent peut y accéder presque comme un développeur à ses fichiers locaux. Le contexte cesse ainsi d'être une boîte noire. Au lieu d'un vague « quelque chose est ressorti par embeddings », on obtient une navigation claire : l'agent peut parcourir l'arborescence, lire des fichiers précis, chercher dans un répertoire, suivre le chemin jusqu'au bon fragment et contrôler plus finement ce qui entre dans le prompt.

Moins de bruit dans le prompt

Autre mécanisme clé d'OpenViking : le chargement du contexte sur trois niveaux. À l'écriture, le système ne se contente pas de déposer le fichier dans un index ; il prépare de façon asynchrone plusieurs niveaux de représentation. L0 est un résumé en une phrase, L1 une vue d'ensemble avec une synthèse du contenu et des scénarios d'usage, et L2 le document complet d'origine. L'agent voit d'abord les niveaux compacts et ne plonge dans le détail que si nécessaire. Cette approche réduit la consommation de tokens et le bruit dans les tâches longues.

En coulisses, OpenViking sépare l'analyse syntaxique du traitement sémantique. Les documents sont d'abord convertis en forme structurée, puis une file distincte gère la génération des vues d'ensemble et la vectorisation. Cela permet d'importer non seulement du Markdown ou du texte, mais aussi du PDF, HTML, Word, PowerPoint, Excel, EPUB, des images, de l'audio et de la vidéo. Pour le code, un mode dédié s'appuie sur tree-sitter : le système sait extraire le squelette structurel de fichiers Python, JavaScript, TypeScript, Rust, Go, Java et C/C++, afin d'éviter des appels superflus au LLM quand un squelette AST suffit.

Recherche et mémoire

La recherche dans OpenViking n'est pas une requête vectorielle unique sur toute la base. Le système analyse d'abord l'intention, repère rapidement le répertoire le plus susceptible de contenir la réponse, affine la recherche à l'intérieur de ce répertoire et, si besoin, descend plus profondément dans les sous-répertoires. Les développeurs appellent cela directory recursive retrieval. L'enjeu : l'agent ne cherche pas seulement un morceau de texte similaire, il comprend aussi dans quel contexte ce morceau se trouve. Cela améliore la précision et rend les résultats moins aléatoires.

L'observabilité compte à part. OpenViking conserve la trajectoire de recherche à travers les répertoires, ce qui permet de voir où l'agent est allé et à quelle étape il a fait fausse route. Pour les équipes qui déboguent des systèmes d'agents, c'est plus utile qu'un log RAG habituel avec quelques valeurs de score.

Le projet intègre aussi une mémoire à long terme : après une session, le système peut extraire de façon asynchrone des faits à partir 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 est déjà présenté avec OpenClaw. Un plugin utilise OpenViking comme backend de mémoire à long terme, importe ressources et compétences dans les espaces viking:// correspondants, puis donne à l'agent des commandes dédiées pour rechercher, enregistrer des souvenirs et déplier des archives. Le projet ressemble donc moins à une idée de recherche abstraite qu'à une couche d'infrastructure que l'on peut déjà brancher à de vrais agents dans des pipelines de production.

Ce que cela signifie

OpenViking montre que le marché de l'infrastructure pour agents s'éloigne du schéma primitif « chat plus base vectorielle » pour aller vers une mémoire plus maîtrisable, dotée de hiérarchie, de traçabilité et d'un mode de longue durée. Si l'approche s'impose, les développeurs concevront la mémoire des agents avec le même soin que celui qu'ils apportent aujourd'hui aux structures de fichiers, aux API et aux bases de données.