Adieu l'Historique de Chat: L'Évolution de l'Architecture à Contexte à Trois Niveaux pour la Programmation par IA

Après avoir utilisé OpenCode de manière intensive pendant un certain temps, j’ai découvert que le simple bricolage et les correctifs ne suffisaient plus à répondre à mes besoins.

J’ai pris conscience d’une erreur architecturale fondamentale: Pour la programmation par IA, l’historique de conversation linéaire (Chat History) n’est pas un atout, c’est un fardeau.

Le Point Douloureux: Le Flux (Stream) ne peut pas porter l’État (State)

Les modèles d’interaction actuels ont l’habitude de déverser le System Prompt + User History d’un seul bloc dans le modèle. À mesure que le nombre d’échanges augmente, les inconvénients deviennent flagrants:

• Rapport Signal/Bruit extrêmement faible: L’historique est rempli d’essais et d’erreurs, de messages d’erreur et de code déjà corrigé. L’IA doit gaspiller une énorme quantité d’Attention pour chercher des signaux au milieu du bruit.
• Pollution du Contexte: Les anciennes pistes de réflexion erronées persistent dans le Contexte, amenant l’IA à “tourner en rond” de manière répétée.
• Abus de Tokens: Pour modifier une simple fonction, on peut être contraint de traîner dix tours de bavardages non pertinents.

Le dialogue est un Flux (Stream), mais la programmation maintient essentiellement un État (State).

Tenter d’utiliser un flux de dialogue linéaire et éphémère pour maintenir l’état complexe et structuré d’un projet est probablement le plus grand goulot d’étranglement architectural des outils de programmation par IA actuels.

La Rupture: Architecture Double Couche Manager-Worker

Pour résoudre ce problème, j’expérimente une nouvelle architecture. Son cœur réside dans le découplage des fonctions de l’IA en un Agent Manager (Le Cerveau/Chef de Projet) et un Agent d’Exécution (La Main/Ingénieur), et dans l’abandon total de l‘“Historique de Chat” comme contexte central.

Dans cette architecture, le contexte n’est plus une bouillie informe, mais est strictement géré par niveaux.

Schéma du Flux de Données de l'Architecture

Agent Manager (Cerveau)
├── Maintient: État Global du Projet Niveau 1 (Persistant)
└── Action: Distiller (Distill)
       │
       ▼
Agent d'Exécution (Main)
├── Reçoit: Contexte de Tâche Niveau 2 (Ensemble Complet Minimal)
├── Exécute: Contexte d'Exécution Niveau 3 (Croissance Dynamique)
│      └── Action: Requête à la Demande (LSP/Lecture de Fichier)
└── Production: Changements de Code -> Synchronisation vers le Manager

Innovation Centrale: Le Système de Contexte à Trois Niveaux

Nous divisons le contexte du macro au micro en trois niveaux, chacun ayant un cycle de vie et des responsabilités distincts:

Niveau 1: Contexte du Projet (Project Context)

• Détenteur: Agent Manager
• Contenu: La topologie globale du projet. Cela inclut la structure de l’arborescence des fichiers, les graphiques de dépendances, les listes de besoins confirmés, les spécifications de la stack technique, etc.
• Caractéristiques: Persistant, Haute Abstraction. Il agit comme une carte ; il ne contient pas les détails spécifiques du code mais sait “où se trouve chaque chose”.

Niveau 2: Contexte de Tâche (Task Context)

• Détenteur: Généré par le Manager, transmis à l’Agent d’Exécution.
• Contenu: L‘“Ensemble Complet Minimal” requis pour exécuter la tâche spécifique actuelle.
  • Mauvais Cas: Jeter tout le dossier src à l’IA.
  • Bon Cas: “Modifier la fonction login dans auth.ts ; se référer uniquement à la définition de l’interface User dans user.ts.”
• Caractéristiques: Jetable, Hautement Distillé. C’est un contexte qui a été “distillé” par le Manager, débarrassé de tout bruit non pertinent.

Niveau 3: Contexte d’Exécution (Execution Context)

• Détenteur: Agent d’Exécution (Runtime)
• Contenu: L‘“Établi” pendant que le Worker est actif. Il contient le Contexte de Tâche, mais plus important encore, il inclut des détails supplémentaires requêtés dynamiquement par le Worker pendant l’écriture du code.
• Caractéristiques: Croissance Dynamique, Chargement à la Demande, Brûlé Après Usage. Par exemple, lorsque le Worker découvre une définition de type manquante, il peut lire activement la définition via des outils LSP plutôt que de se fier aux devinettes du Manager.

Processus de Collaboration Dynamique: Du “Gavage” à la “Demande”

Le RAG traditionnel fonctionne comme “Je prédis que tu as besoin de ça, alors je te fourre tout”. L’architecture à Contexte à Trois Niveaux supporte le Lazy Loading (Chargement Paresseux).

Exemple de Scénario:

Lorsque le Manager envoie une tâche “Réparer le Bug de Connexion”, l’Agent d’Exécution démarre dans un environnement vierge.

1. Le Worker lit la fonction login et remarque un appel à une méthode validate inconnue.
2. Le Worker initie activement un Tool Call (Appel d’Outil) pour lire la définition de validate dans utils.ts.
3. Le Worker corrige le code et lance les tests.
4. La tâche se termine, le Contexte d’Exécution est détruit, et seuls les changements de code finaux sont synchronisés vers l’État du Projet.

Avantages Principaux

1. Réduction Drastique des Hallucinations
   L’Agent d’Exécution travaille toujours dans un “environnement sous vide” extrêmement pur. Il ne voit pas les plaintes précédentes de l’utilisateur ni les tentatives échouées antérieures. Il ne voit que des instructions claires et des extraits de code précis. Plus l’entrée est pure, plus la sortie est déterministe.

2. Fenêtre de Contexte Infinie
   Grâce au mécanisme de requête dynamique du Niveau 3, le Worker n’a pas besoin de charger tout le projet au départ. Il peut “tendre la main” vers le Manager ou le système de fichiers chaque fois que nécessaire. Cela rend possible la gestion de projets gigantesques avec des dizaines de milliers de fichiers, brisant les limites physiques de la Fenêtre de Contexte (Context Window).

3. Auto-Correction et Machines à États
   L’Agent Manager maintient un État (State), pas un Historique (History). Lorsqu’un Worker termine une tâche, le Manager met à jour l’état du projet ; si une tâche échoue, le Manager génère une nouvelle tâche de correction basée sur l’état actuel. C’est une Machine à États Finis (FSM) qui converge constamment, plutôt qu’un flux de dialogue qui diverge à l’infini.

Comparaison: Du CLAUDE.md Statique à l’État d’Agent Dynamique

Pour mieux comprendre l’évolution de cette architecture, nous pouvons nous référer à la pratique actuellement populaire du CLAUDE.md.

Dans les meilleures pratiques existantes, les développeurs maintiennent un fichier CLAUDE.md à la racine du projet pour enregistrer les normes architecturales, les commandes courantes et les styles de code. C’est en fait un prototype du Niveau 1 (Contexte du Projet), mais il présente deux limitations fatales:

1. Coût de Maintenance
   CLAUDE.md dépend des mises à jour manuelles par les développeurs humains. Une fois que le code change sans que la documentation ne soit synchronisée, le contexte obsolète devient un “poison” qui induit l’IA en erreur. Dans l’architecture à Contexte à Trois Niveaux, l’Agent Manager est responsable des mises à jour en temps réel de l’état du projet, garantissant que la “carte” correspond toujours au “terrain”.
2. Problèmes de Granularité
   CLAUDE.md est un fichier “plat”. Quelle que soit la taille de la tâche, l’IA est obligée de lire le fichier entier à chaque fois. Dans notre architecture, le Manager découpe dynamiquement le Niveau 2 (Contexte de Tâche) à partir de l’état global.
   • Mode CLAUDE.md: “Voici toutes les règles du projet, débrouille-toi.”
   • Mode Contexte à Trois Niveaux: “Pour cette tâche spécifique, tu dois suivre ces quelques règles.”

En bref, CLAUDE.md est un instantané statique, maintenu par l’homme et en lecture seule ; l’architecture à Contexte à Trois Niveaux est un état dynamique, maintenu par l’Agent et vivant. Nous passons de la charge d‘“écrire de la documentation pour l’IA” à la capacité de “laisser l’IA maintenir sa propre mémoire”.

Conclusion

À mesure que j’approfondis la programmation par IA, je réalise de plus en plus: La construction du contexte est un art.

Le cerveau humain est habitué à la déduction logique linéaire, mais l’IA est différente ; elle s’appuie sur une généralisation associative basée sur une connaissance massive.

Par conséquent, la compétitivité centrale des futurs outils de programmation par IA ne sera plus seulement le modèle lui-même, mais la manière de concevoir un système de contexte efficace — un système qui “déclenche” et “guide” précisément les capacités de généralisation de l’IA pour produire des résultats conformes aux attentes humaines.