Akshay analyse l’architecture à 6 couches du code Claude : le modèle n’est qu’un nœud dans une boucle

L’ingénieur IA Akshay Pachaar a publié le 10 mai sur X un schéma complet de l’architecture de Claude Code, en décomposant l’ensemble du système en 6 niveaux et en soulignant que « le modèle n’est qu’un nœud parmi d’autres dans la boucle ». Le post de Pachaar cite son long essai du 6 avril, « The Anatomy of an Agent Harness », dont l’idée centrale est la suivante : si Claude Code « ressemble à de la magie », ce n’est pas le modèle en lui-même, mais la conception méticuleuse du harness.

6 niveaux d’architecture : le modèle n’est qu’un nœud

Les 6 niveaux de Claude Code listés par Pachaar :

Input Layer (couche d’entrée) : gère la gestion des sessions, le contrôle des autorisations et des niveaux de confiance définis via YAML. Tout ordre qui entre dans le modèle passe d’abord par cette couche.

Knowledge Layer (couche de connaissance) : inclut un skill registry, un context compressor (3 niveaux de compression, déclenchement avec un seuil à 92 %), un task graph et un stockage de mémoire inter-session. C’est l’endroit où « l’intelligence » du harness existe, en dehors des poids du modèle.

Execution Layer (couche d’exécution) : délègue l’appel d’outils via un typed registry ; chaque outil a un handler—bash, read, write, grep, glob, revert. Le runtime de streaming prend en charge l’exécution parallèle : le prompt cache réutilise les préfixes stables, et les coûts descendent à 10 %.

Integration Layer (couche d’intégration) : le MCP runtime connecte des serveurs externes (filesystem, git, outils personnalisés). Les outils s’enregistrent vers l’intérieur, tandis que la mémoire est écrite vers l’extérieur dans agent_memory.md.

Multi-Agent Layer (couche multi-agents) : contient un subagent spawner, des teammate mailboxes communiquant via redis pub/sub, un protocole de machine à états finis (IDLE→REQUEST→WAIT→RESPOND), un autonomous board à verrous atomiques, et l’isolation par worktree (chaque tâche dans un git branch indépendant).

Observability Layer (couche d’observabilité) : enveloppe tous les étages avec un bus d’événements et des lifecycle hooks ; un exécuteur en arrière-plan fonctionne de façon non bloquante via un daemon thread.

Au centre se trouve la « master agent loop » (boucle du maître) : perception → action → observation. Anthropic positionne cette boucle elle-même comme un « dumb loop »—toute l’intelligence se fait dans l’inférence du modèle, tandis que le harness ne fait que la planification.

Conception clé : context compressor et isolation worktree

Quelques détails de conception à surveiller :

Context compressor : 3 niveaux de compression, seuil à 92 % : lorsque le contexte se rapproche de 92 % de la capacité, déclenchement d’un résumé et d’une compression, en conservant les décisions d’architecture et les bugs non résolus, et en supprimant les sorties d’outils répétées. Cela fait écho aux « recommandations de context engineering » publiées par Anthropic : constituer le plus petit ensemble de token à plus forte densité d’information, et maximiser la probabilité d’atteindre l’objectif.

Isolation worktree : chaque subagent travaille sur un worktree git distinct et sur une branche indépendante ; lors de la fusion, détection de conflits. Ce design rend possible la modification parallèle de la même base de code par plusieurs agents sans qu’ils se marchent dessus. Parmi les trois modes d’exécution de sous-agents « Fork / Teammate / Worktree » de Claude Code, Worktree est le niveau d’isolation le plus fort.

Prompt cache : coût de 10 % : grâce au cache des préfixes stables (system prompt, définitions d’outils, CLAUDE.md), les appels répétés avec les mêmes préfixes ne coûtent que 10 % des frais standard en token. C’est la clé pour maintenir des coûts maîtrisés sur des tâches de longue durée.

Pourquoi cette analyse a résonné dans la communauté

Le post de Pachaar a obtenu 522 likes et 115 retweets ; dans les commentaires, on voit des retours du type « je croyais que c’était juste un outil CLI », « je pensais que Claude Code = model + accès terminal, je ne savais pas qu’il y avait autant de choses dans la multi-agent layer » et autres. Cela reflète le fait que, pour la plupart des développeurs, la compréhension de Claude Code reste au niveau « une couche CLI emballant l’API Claude », en sous-estimant la complexité du harness engineering.

Pachaar cite la phrase de Vivek Trivedy (de LangChain) comme argument central : « si tu n’es pas le modèle, alors tu es le harness ». Les tests de LangChain sur TerminalBench 2.0—preuve avec les mêmes poids de modèle, en modifiant seulement le harness externe—montrent que le classement passe de la 30e place à la 5e.

Pour les lecteurs d’abmedia, cette analyse fournit un point de référence concret : lorsque vous voyez les différences entre des produits d’agents comme Claude Code, Codex, Gemini Code Assist, la plupart des différences ne viennent pas du modèle lui-même, mais du design du harness : stratégies de gestion du contexte, étendue des outils, boucles de validation, et modes de collaboration multi-agents. La version du modèle une fois mise à niveau, les choix du harness engineering déterminent le niveau de l’expérience produit.

Cet article où Akshay analyse l’architecture en 6 couches de Claude Code : le modèle n’est qu’un nœud de la boucle apparaît pour la première fois sur 鏈新聞 ABMedia.