Les composants d'un harnais d'agent en production (et ce que ça change pour un Beelink)

Écrit par Alexandre BEDELEK
Tags : IA agentique, Architecture, llama.cpp, Local

Suite de l’analyse du harnais d’agent. Ici, on entre dans la mécanique : les composants qui transforment un LLM sans état en un agent fiable, puis ce que cela implique sur une machine locale à mémoire unifiée.

1. La boucle d’orchestration

C’est le cœur battant. Elle met en œuvre le cycle Pensée-Action-Observation (TAO), aussi appelé boucle ReAct : assembler le prompt, appeler le LLM, analyser la sortie, exécuter les éventuels appels d’outils, réinjecter les résultats, puis recommencer jusqu’à la fin. Mécaniquement, c’est souvent une simple boucle while. La complexité réside dans tout ce que la boucle gère, pas dans la boucle elle-même. Le runtime d’Anthropic est décrit comme une « boucle idiote » où toute l’intelligence réside dans le modèle : le harnais se contente de gérer les tours.

2. Les outils

Les outils sont les mains de l’agent. Ils sont définis sous forme de schémas (nom, description, types de paramètres) injectés dans le contexte du LLM pour que le modèle sache ce qui est disponible. La couche d’outils gère l’enregistrement, la validation des schémas, l’extraction des arguments, l’exécution en bac à sable, la capture des résultats et leur formatage en observations lisibles par le LLM. Claude Code répartit ses outils en six catégories (opérations sur les fichiers, recherche, exécution, accès web, intelligence de code, instanciation de sous-agents). Le SDK Agents d’OpenAI distingue les outils de fonction, les outils hébergés et les outils de serveurs MCP.

3. La mémoire

La mémoire opère sur plusieurs échelles de temps. La mémoire à court terme est l’historique de conversation au sein d’une même session. La mémoire à long terme persiste d’une session à l’autre : fichiers de projet et fichiers MEMORY.md générés automatiquement chez Anthropic, magasins JSON organisés par espaces de noms chez LangGraph, sessions adossées à SQLite ou Redis chez OpenAI. Claude Code met en œuvre une hiérarchie à trois niveaux : un index léger (toujours chargé), des fichiers de sujets détaillés chargés à la demande, et des transcriptions brutes accessibles uniquement par recherche. Un principe de conception critique : l’agent traite sa propre mémoire comme un indice, et vérifie l’état réel avant d’agir.

4. La gestion du contexte

C’est là que beaucoup d’agents échouent silencieusement. Le problème central est la dégradation du contexte : les performances chutent de plus de 30 % lorsque le contenu clé se trouve au milieu de la fenêtre (c’est le phénomène « Lost in the Middle »). Même les fenêtres d’un million de tokens subissent une dégradation du suivi des instructions à mesure que le contexte grandit. Les stratégies de production incluent :

  • La compaction : résumer l’historique à l’approche des limites, en préservant les décisions architecturales et les bugs non résolus tout en éliminant les sorties d’outils redondantes.
  • Le masquage des observations : masquer les anciennes sorties d’outils tout en gardant les appels d’outils visibles.
  • La récupération just-in-time : maintenir des identifiants légers et charger les données dynamiquement (grep, glob, head, tail plutôt que des fichiers entiers).
  • La délégation à des sous-agents : chaque sous-agent explore en profondeur mais ne renvoie que des résumés condensés de 1 000 à 2 000 tokens.

5. La construction du prompt

C’est l’assemblage de ce que le modèle voit réellement à chaque étape, de façon hiérarchique : prompt système, définitions d’outils, fichiers de mémoire, historique de conversation, message actuel de l’utilisateur. Le Codex d’OpenAI utilise une pile de priorité stricte : message système contrôlé par le serveur (priorité maximale), définitions d’outils, instructions développeur, instructions utilisateur (fichiers en cascade, limités), puis historique.

6. L’analyse des sorties

Les harnais modernes s’appuient sur l’appel d’outils natif : le modèle renvoie des objets structurés plutôt que du texte brut à analyser. Le harnais vérifie : y a-t-il des appels d’outils ? On les exécute et on boucle. Pas d’appels d’outils ? C’est la réponse finale. Pour les sorties structurées, les réponses sont contraintes par schéma (modèles Pydantic).

7. La gestion de l’état

LangGraph modélise l’état sous forme de dictionnaires typés circulant dans les nœuds d’un graphe, avec des réducteurs fusionnant les mises à jour. La pose de points de contrôle s’effectue aux frontières des super-étapes, permettant la reprise après interruption et le débogage temporel. Claude Code adopte une approche différente : les commits Git comme points de contrôle, et les fichiers de progression comme blocs-notes structurés.

8. La gestion des erreurs

Les erreurs se cumulent vite : un processus en dix étapes avec un taux de réussite de 99 % par étape n’a plus qu’un taux global d’environ 90,4 %. LangGraph distingue quatre types d’erreurs : transitoires (nouvel essai avec délai exponentiel), récupérables par le LLM (renvoi de l’erreur comme message d’outil pour ajustement), corrigeables par l’utilisateur (interruption pour intervention humaine) et inattendues (remontée pour débogage).

9. Garde-fous et sécurité

Le SDK d’OpenAI met en œuvre trois niveaux : garde-fous d’entrée, de sortie et d’outil, avec un mécanisme de déclenchement d’urgence qui arrête immédiatement l’agent en cas de besoin. Anthropic sépare architecturalement l’application des permissions du raisonnement du modèle : le modèle décide de ce qu’il veut tenter, le système d’outils décide de ce qui est autorisé.

10. Les boucles de vérification

C’est ce qui sépare les jouets de démonstration des agents de production. Trois approches complémentaires : la rétroaction basée sur des règles (tests, linters, analyseurs statiques), la rétroaction visuelle (captures d’écran pour les tâches d’interface) et le LLM-en-tant-que-juge.

11. L’orchestration de sous-agents

Claude Code prend en charge trois modèles d’exécution : la bifurcation, le coéquipier et l’arbre de travail. Le SDK d’OpenAI prend en charge les agents-en-tant-qu’outils et les transferts. C’est l’échelon qui permet de paralléliser l’exploration tout en gardant un contexte principal propre.

Retour d’expérience : ce que ça change sur une machine à mémoire unifiée

Ces composants ne sont pas qu’un catalogue théorique. Sur une architecture matérielle à mémoire unifiée — comme le Beelink GTR9 Pro équipé d’un APU Strix Halo, où le CPU et le GPU partagent la même RAM — la notion de harnais éclaire un choix décisif : la qualité du harnais prime sur le simple choix des poids du modèle.

Deux illustrations concrètes :

Le KV cache, talon d’Achille. Sur une machine unifiée, la fenêtre de contexte et le KV cache vivent dans la même mémoire physique. Un harnais mal configuré sature le KV cache par des redondances de prompts — il réinjecte les mêmes définitions d’outils et le même prompt système à chaque tour, gaspillant une mémoire précieuse qui pourrait servir au raisonnement. Un harnais bien architecturé, lui, factorise ces blocs statiques et ne fait circuler que le strict nécessaire. La différence ne se voit pas sur les poids : elle se voit sur la stabilité et la longueur de session qu’on peut tenir avant saturation.

La gestion du contexte comme enjeu matériel. Quand la RAM est partagée, la compaction et le masquage des observations ne sont plus de simples optimisations de coût : ce sont des conditions de survie. Une fenêtre qui se remplit de bruit force soit à élaguer brutalement (perte d’information), soit à saturer la mémoire (chute de performances). D’où l’intérêt de s’appuyer sur des protocoles ouverts comme le MCP et des flux d’exécution agnostiques, qui garantissent la reproductibilité des tâches d’automatisation locale sans dépendre d’un framework particulier.

La leçon, au final, est simple et vaut pour n’importe quel déploiement local : on ne choisit pas seulement un modèle, on choisit — ou on construit — le système d’exploitation qui le fait tourner. Et c’est là, bien plus que dans le benchmark des poids, que se joue la différence entre un agent qui tient une session entière et un chatbot qui s’effondre au bout de trois tours.