Tout est un fichier : De la philosophie de conception d'Unix aux agents d'IA
Tout est un fichier : De la philosophie de conception d'Unix aux agents d'IA
Original Ethan 业成


Un écho à travers un demi-siècle
Au début des années 1970, aux Bell Labs, les pères d'Unix, Ken Thompson et Dennis Ritchie, ont proposé pour la première fois un principe de conception audacieux, voire obsessionnel : Everything is a file - Tout est un fichier.
Plus de cinquante ans plus tard, les frameworks d'agents d'IA explosent. Manus, Claude Code, OpenClaw... Ils proviennent d'équipes différentes, de piles technologiques différentes, d'objectifs commerciaux différents, mais ils ont tous fait le même choix : utiliser le système de fichiers comme squelette cognitif de l'agent.
Manus donne à l'agent une machine virtuelle, et les produits de la tâche sont stockés sur le disque sous forme de fichiers. Claude Code lit et écrit directement sur le système de fichiers local de l'utilisateur, en utilisant un fichier CLAUDE.md pour contenir toutes les instructions et le contexte. Les frameworks open source tels que OpenClaw organisent également la décomposition des tâches et les états intermédiaires à l'aide d'une structure de répertoires.
Lorsque des ingénieurs séparés par un demi-siècle, confrontés à des problèmes techniques complètement différents, convergent indépendamment vers la même solution, ce n'est pas une coïncidence, c'est une résonance de la philosophie de conception.
La décision d'Unix
Pour comprendre l'importance de cette décision, il faut d'abord revenir à ce qu'Unix a fait.
La conception du système de fichiers Unix est largement reconnue comme l'une des conceptions les plus élégantes de l'histoire de l'informatique. Elle résout un problème extrêmement complexe : comment gérer une grande variété de ressources matérielles et de données avec une interface unifiée et simple.
Avant les années 1970, les systèmes d'exploitation fonctionnaient de la manière suivante : pour lire un disque, vous appeliez l'interface du disque ; pour lire une bande magnétique, vous appeliez l'interface de la bande magnétique ; pour accéder à un terminal, vous appeliez l'interface du terminal. Chaque périphérique avait sa propre API, et chaque API avait sa propre sémantique. Si vous aviez N périphériques et M opérations, la complexité du système était de N × M.
Thompson et Ritchie ont fait quelque chose qui semblait simple, voire stupide :
Transformer tout en fichiers. Utiliser les quatre verbes open, read, write, close pour tout manipuler.
Son sens profond est que toutes les ressources du système d'exploitation - documents, répertoires, disques durs, modems, claviers, imprimantes, voire les connexions réseau et les informations de processus - peuvent être abstraites en un flux de fichiers (Stream of Bytes).
Cela signifie que vous n'avez besoin d'apprendre qu'un seul ensemble d'API - open(), read(), write(), close() - pour manipuler toutes les ressources de l'ordinateur.
Dès lors, la complexité s'effondre de N × M à 4 × 1. Quatre verbes, une couche d'abstraction.
Le génie de cette approche ne réside pas dans le nom - Mémoire persistante : La fenêtre de contexte des LLM est volatile, et la chaîne de pensée disparaît avec la session. C'est comme si la mémoire était récupérée après la fermeture d'un processus - vous avez besoin d'un endroit pour persister l'état intermédiaire, sinon chaque conversation recommence à zéro.
- Contexte progressif : Les tâches complexes ne peuvent pas être accomplies en une seule étape. L'Agent doit accumuler progressivement le contexte au cours de plusieurs cycles de raisonnement, tout comme un processus Unix transmet l'état entre plusieurs exécutions en lisant et en écrivant des fichiers. Le système de fichiers offre naturellement ce mode de fonctionnement progressif de type "écrire un peu, lire un peu, puis écrire un peu plus".
- Orchestration unifiée des outils et des compétences : L'Agent doit appeler des outils hétérogènes (Tools/Skills) tels que la recherche, l'exécution de code, la génération d'images, etc., tout comme Unix doit gérer des périphériques hétérogènes tels que des disques, des réseaux, des imprimantes, etc. Vous avez besoin d'une couche d'abstraction unifiée, sinon vous devrez écrire un nouvel ensemble de logique d'intégration pour chaque nouvel outil.
- Limites d'autorisation pour l'utilisation de l'ordinateur : Lorsque l'Agent a la capacité d'opérer un ordinateur, la question de "ce qu'il peut toucher et ce qu'il ne peut pas toucher" devient une question de vie ou de mort. Le système de permissions de fichiers d'Unix (rwx) fournit justement un modèle de sandbox prêt à l'emploi - le répertoire est la limite, la permission est le contrat.
Quatre exigences. Cela vous semble familier ?
C'est précisément le problème auquel les systèmes d'exploitation étaient confrontés dans les années 1970.
Mémoire persistante - le système de fichiers le résout naturellement, l'écriture est la persistance. Contexte progressif - la structure du répertoire elle-même est construite de manière incrémentale, mkdir, touch, append, le contexte croît avec le fichier. Orchestration unifiée des outils - l'essence du pipeline Unix : la sortie standard d'un processus est l'entrée standard d'un autre processus, le support intermédiaire est le flux d'octets. La chaîne d'outils de l'Agent est également ainsi : le fichier de sortie de l'étape précédente est l'entrée de l'étape suivante. Limites d'autorisation - les permissions rwx du système de fichiers, la sandbox chroot, définissent naturellement le "cercle de capacité" de l'Agent.
Donc, lorsque les concepteurs du framework Agent sont confrontés à la question de "où placer l'état de travail de l'Agent", la réponse est presque prédéterminée : dans le système de fichiers. Parce qu'il n'y a pas de solution plus simple qui puisse satisfaire simultanément ces quatre contraintes.
Lorsque le système a besoin de "gérer l'interaction d'un grand nombre de ressources hétérogènes", vous avez deux voies :
Voie A : Concevoir des interfaces dédiées pour chaque ressource. N ressources × M opérations = NM interfaces. Précis mais explosif.
Voie B : Trouver une couche d'abstraction suffisamment fine pour que toutes les ressources portent le même vêtement. 4 opérations × 1 couche d'abstraction. Grossier mais combinable.
Unix a choisi B. Plus de cinquante ans plus tard, le framework Agent choisit à nouveau B.

Une couche plus profonde : Le fichier est l'extériorisation de la pensée
Mais si nous nous arrêtons à la "convergence des solutions techniques", nous passons à côté de quelque chose de plus essentiel.
Rappelez-vous comment les humains eux-mêmes traitent les tâches complexes.
Vous recevez un gros projet, la première chose que vous faites n'est pas de commencer à travailler, mais de : créer des dossiers. Dossier racine du projet, dossiers des sous-tâches, dossiers des documents de référence, dossiers de sortie. Vous utilisez la structure des dossiers pour décomposer la tâche chaotique en unités gérables. Vous utilisez les noms de fichiers pour nommer chaque unité. Vous utilisez le contenu des fichiers pour enregistrer le processus de pensée et les produits intermédiaires.
Le système de fichiers n'est pas seulement une solution de stockage. C'est l'outil original d'extériorisation de la pensée humaine.
Cette observation explique pourquoi le framework Agent converge vers le système de fichiers : la "pensée" du LLM doit être extériorisée - sa fenêtre de contexte est limitée, le raisonnement à long terme doit s'appuyer sur une mémoire externe. Et le système de fichiers est justement le format de "mémoire externe" le plus universel que l'humanité ait inventé.
De ce point de vue, le CLAUDE.md de Claude Code n'est pas un fichier de configuration. C'est un contrat cognitif extériorisé - l'humain écrit l'intention dans un fichier, l'Agent lit le fichier comme une intention. Le fichier devient la couche d'interface entre l'esprit humain et l'intelligence artificielle.
Ceci est étonnamment cohérent avec la philosophie du pipeline Unix :
Write programs to handle text streams, because that is a universal interface.Remplacer "programmes" par "agents", et "flux de texte" par "fichiers", cette phrase sera toujours vraie en 2026.
Retour aux principes fondamentaux
Les grandes abstractions ne se démodent pas, elles trouvent simplement de nouvelles instances dans de nouveaux domaines.
"L'unification des interfaces résout la complexité" n'est pas une invention d'Unix, c'est une loi éternelle de la conception de systèmes. Unix l'a implémentée par hasard avec le nom "fichier". AI Agent l'a implémentée par hasard à nouveau sous la forme d'un "répertoire de travail".
La prochaine génération de systèmes sera également confrontée au même choix : concevoir des interfaces dédiées pour chaque chose, ou trouver une abstraction fine, générique et composable ?
Si l'histoire nous enseigne quelque chose, la réponse est déjà écrite à côté de /dev/null :
Keep it simple. Make it compose. Everything is a file.





