FUSE AI Agents 2026 : Plan/Scratch pour un raisonnement fiable

Points clés

• Externaliser le contexte long via plan.md, scratch.md, decisions.json et trace.log stabilise le raisonnement multi-étapes et rend le débogage routinier.
• Les montages FUSE permettent aux agents d’utiliser la sémantique POSIX standard (ls/grep/mv/append), réduisant les wrappers d’outils sur mesure et améliorant la reproductibilité.
• MCP agit comme pont standardisé vers les systèmes d’entreprise tandis que le système de fichiers fournit un espace de travail local unifié ; ensemble ils permettent des flux gouvernés et observables.
• Les déploiements local-first/on-prem s’alignent sur la conformité et la résidence des données ; montages par tâche et ACL au niveau chemin aident à appliquer le moindre privilège.
• Les benchmarks sont encore précoces ; traitez les affirmations de performance comme des hypothèses et priorisez les méthodes d’évaluation et l’observabilité.

Pourquoi les fichiers battent les prompts éphémères pour le contexte long

Quand les plans, artefacts intermédiaires et décisions sont capturés dans des fichiers—plan.md, scratch.md, decisions.json, trace.log—ils deviennent la source de vérité du raisonnement plutôt qu’un souvenir qui s’estompe dans la fenêtre de tokens. Les fichiers apportent le versioning, les diffs et les points de contrôle. Vous pouvez revoir l’évolution d’un plan, annuler des branches incorrectes et reproduire une exécution depuis un état connu. Le système de fichiers est la mémoire de travail de l’agent que vous pouvez auditer, pas un fil de prompt invisible.

L’essai de Jakob Emmerling début 2026 plaide conceptuellement pour les agents « filesystem-first », avec des motifs comme email-comme-répertoires et les opérations POSIX read/write/list/move comme actions naturelles. Voir « FUSE is All You Need – Giving agents access to anything via filesystems ». Pour les compromis d’architecture : How LLM Agent Architectures Work.

L’avantage pratique est la reproductibilité : des fichiers comme decisions.json et trace.log donnent des traces déterministes de ce qui s’est passé et pourquoi. Ils améliorent aussi la collaboration entre ingénieurs et agents—les humains peuvent lire plan.md, éditer une section et laisser l’agent continuer. Aucun outil spécial nécessaire.

Exemple en cours — connaissance ingénierie multi-repo avec flux plan/scratch

Workspace concret : /workspace/repoA, repoB/docs, patterns, plans/plan.md, scratch/scratch.md, logs/trace.log, state/decisions.json. Les agents utilisent les opérations POSIX familières (ls, grep, mv/cp, echo >>, diff/patch). Cycle de vie : (1) Créer ou charger plan.md avec objectifs et contraintes. (2) Itérer dans scratch.md : essayer des extraits, capturer les résultats, noter les blocages. (3) Enregistrer les décisions dans decisions.json avec justification et horodatages. (4) Logger les actions dans trace.log avec IDs d’action agent. (5) Promouvoir les artefacts validés et ouvrir une PR via MCP. Cela fonctionne bien pour la connaissance ingénierie sur plusieurs repos car les agents peuvent « penser » en fichiers et opérer sans adaptateurs sur mesure ; le système de fichiers fournit une abstraction et MCP expose les systèmes externes via une interface standardisée.

Modèles d’implémentation pour agents FUSE et interop MCP

• FUSE local uniquement avec système de fichiers virtuel adossé à SQLite : adapté aux machines de dev et petits pilotes. Voir proposition AgentFS (Penberg).
• FS virtuel adossé à une DB (SQLite en local, Supabase ou similaire ensuite) : note « AgentFS FUSE » de Turso.
• AgentFS adossé à un object store : pour les grandes organisations, désagréger le stockage et monter un système de fichiers virtuel avec cache.

Traitez MCP comme le pont standardisé vers les trackers d’issues, la CI, les stockages de documents et les services internes. Références : spécification anniversaire MCP, mise à jour autorisation MCP, exécution de code avec MCP (Anthropic), docs MCP JetBrains.

Gouvernance, sandboxing et conformité

Filesystem-first ne signifie pas sans garde-fous. Concevez avec le moindre privilège : montages par tâche, ACL au niveau chemin et journaux d’audit, contrôles au niveau OS (SELinux, AppArmor, Landlock). Local-first/on-prem aide pour la résidence et la conformité. Alignez les périmètres MCP sur le même modèle de moindre privilège.

Observabilité et évaluation

Traçage POSIX, métriques clés (taux de succès, latence, reproductibilité, auditabilité), méthodologie de benchmark : comparer un agent filesystem-first à une chaîne API/MCP seule. Pour le « contexte » dans les systèmes d’agents : Building a RAG Model That Scales.

Limites et quand les APIs gagnent

FUSE ajoute de la médiation en espace utilisateur (plus de CPU et latence). Les domaines de streaming ou transactionnels peuvent encore privilégier les SDK/APIs directs. Modèle hybride : système de fichiers pour plan/scratch/state et MCP pour les appels structurés et transactionnels.

Où une base de contexte s’intègre

Divulgation : Puppyone est notre produit.

Une base de contexte gouvernée peut sous-tendre cette architecture : connaissance d’entreprise en « Know-How » structuré (JSON/Graph), indexation hybride, déploiement local via Docker. Context Base Puppyone. How Agentic Process Automation Is Transforming Enterprise Operations in 2026.

Prochaines étapes et ressources

Commencer petit : montage FUSE local avec plan/scratch sur deux repos, connecteurs MCP pour PRs/issues, traçage POSIX. Définir tôt les montages à moindre privilège et les ACL au niveau chemin. Références : FUSE is All You Need, AgentFS (Penberg), Turso AgentFS FUSE, anniversaire MCP, Anthropic MCP, JetBrains MCP.

FAQs

Q1 : Le surcoût FUSE impacte-t-il significativement les performances de l’agent ?

FUSE ajoute une latence modérée ; les charges des agents sont typiquement à dominance lecture avec des écritures en rafales. Le cache page du noyau atténue le surcoût après les premières lectures. Les pilotes Turso montrent une latence <10 ms pour des tâches d’ingénierie comme grep inter-repos—négligeable face à l’inférence LLM. Les append par lots ou partitions scratch adossées à la RAM gèrent les pics d’écriture. Un compromis de latence de 5–15 % est justifié par la traçabilité déterministe (trace.log) et les flux rejouables à partir des checkpoints plan.md.

Q2 : Comment démarrer un pilote filesystem-first sans refonte d’infrastructure ?

Choisir une tâche limitée à deux repos (ex. documenter un flux d’auth). Monter uniquement ces repos plus les répertoires vides plans/, scratch/, logs/ avec fusepy ou fuse-turso en local. L’agent initialise plan.md, itère dans scratch.md et écrit dans trace.log. Ajouter un connecteur MCP minimal pour les PR GitHub. Tout sur un laptop de dev ; valider reproductibilité et gains de débogage en deux semaines—sans modification de production.

Q3 : Quand éviter filesystem-first au profit d’APIs directes ?

Pour le streaming haute fréquence (données de marché en temps réel), les transactions ACID critiques (paiements) ou les tâches mono-étape sans état (résumé d’URL). Ces cas exigent une latence sub-milliseconde ou des garanties transactionnelles natives que FUSE ne peut pas fournir. Utiliser un modèle hybride : système de fichiers pour plan/scratch/state et appels sensibles à la latence via des outils MCP scopés. Règle pratique : si demain vous voudriez faire un git diff plan.md pour auditer une décision, filesystem-first apporte de la valeur.