Architecture d'assistant IA : LLM, mémoire, outils, routage, observabilité

Un assistant IA en production n’est pas « un LLM avec un prompt ». C’est un système qui accepte une intention, maintient un état, décide quand récupérer des données ou agir, et expose suffisamment de détails d’exécution pour déboguer les échecs.

Cette vision au niveau du système est ce que le cluster Systèmes IA explore lorsque les assistants passent au-delà d’une simple invocation de modèle.

OpenAI décrit les agents comme des applications qui planifient, appellent des outils, collaborent et conservent assez d’état pour un travail en plusieurs étapes, tandis qu’Anthropic cadre le même problème comme un harnais géré capable d’exécuter des fichiers, des commandes, un accès web et du code de manière sécurisée.

L’architecture la plus propre divise les responsabilités en cinq couches : LLM, Mémoire, Outils, Routage et Observabilité. Cette division correspond aux capacités exposées par les principales API des fournisseurs, par MCP, par les temps d’exécution auto-hébergés tels que vLLM et llama.cpp, et par de vrais systèmes d’assistants tels que OpenClaw et Hermes.

La mémoire doit être traitée comme plus qu’un « contexte plus long ». Les systèmes de récupération transforment la connaissance externe en mémoire non paramétrique explicite — le même espace de conception couvert en profondeur par la Génération Augmentée par Récupération (RAG) — et à la fois les conseils de contexte d’Anthropic et le papier « Lost in the Middle » avertissent que le simple fait de bourrer plus de jetons dans le contexte ne garantit pas une mémorisation fiable.

L’utilisation d’outils est une frontière contractuelle, pas de la magie. L’appel de fonction d’OpenAI, l’utilisation d’outils d’Anthropic et MCP reposent tous sur le même schéma : le modèle émet une requête structurée, un certain temps d’exécution l’exécute, et le résultat retourne dans la conversation. Si cette frontière est négligente, l’assistant devient négligent.

Mon biais est simple : commencez par l’ennuyeux. Un orchestrateur, un chemin de mémoire durable, une trace par requête, et une politique explicite pour l’exécution des outils. Les graphes multi-agents sont utiles, mais seulement après que vous puissiez expliquer vos cas d’échec d’un agent unique sans deviner.

Ce qu’est un système d’assistant IA

Une définition pratique est celle-ci : un système d’assistant IA est un temps d’exécution qui transforme l’intention de l’utilisateur en une réponse ou une action en combinant une interface de modèle, l’assemblage du contexte, l’exécution d’outils, la gestion d’état et la télémétrie. C’est pourquoi les documents utiles ne sont pas seulement des fiches de modèle. Les documents utiles sont les références API, les contrats d’outils, les guides de récupération, les documents de routage et les documents de traçage. L’API Responses d’OpenAI expose des interactions étatiques, des outils intégrés et l’appel de fonctions. L’API Claude d’Anthropic expose un accès direct aux Messages ainsi que des Agents Gérés. OpenClaw et Hermes vont un pas plus loin et montrent ce qui se passe lorsque vous placez ces capacités derrière des passerelles persistantes, des canaux, des sessions et de la mémoire.

En d’autres termes, un système d’assistant a un contrat plus large qu’une complétion de chat. Un bon contrat interne ressemble à ceci :

AssistantRequest  = intention utilisateur + identité + session + pièces jointes + politique
AssistantResponse = réponse + actions + citations + changements d'état + identifiant de trace

Ce contrat est important car chaque désaccord en production finit par se réduire à l’une de ces questions : quel contexte était visible, quel outil a été exécuté, quel modèle a répondu, quelle mémoire a été lue ou écrite, et où la trace indique que le système a passé du temps. OpenTelemetry définit les traces comme le chemin d’une requête à travers une application, ce qui est exactement l’abstraction dont les assistants sérieux ont besoin. LangSmith et OpenLIT spécialisent ensuite cette idée pour les LLM, les outils, les magasins vectoriels et les flux de travail des agents.

Composants principaux et interfaces

La séparation des composants ci-dessous est celle que je trouve la plus durable. C’est aussi la séparation qui s’aligne le mieux avec les API officielles et les temps d’exécution open-source que les gens exploitent réellement.

Le tableau ci-dessus est dérivé des interfaces officielles des fournisseurs, de MCP, des documents des bases de données vectorielles et des documents d’exécution pour vLLM, llama.cpp, OpenClaw et Hermes.

La couche LLM devrait bien faire trois choses : consommer un contexte de travail actuel, émettre soit une réponse finale soit une requête d’action structurée, et retourner suffisamment de métadonnées pour soutenir les retries et le traçage. L’API Responses d’OpenAI est explicitement conçue pour les interactions étatiques plus les outils intégrés et l’appel de fonctions. L’API Messages d’Anthropic expose la même boucle centrale via les blocs tool_use et les retours tool_result, tandis que les Agents Gérés vous offrent un harnais hébergé si vous ne voulez pas construire la boucle vous-même. Les temps d’exécution auto-hébergés tels que vLLM et llama.cpp sont importants car ils préservent les interfaces de style fournisseur familières tout en vous permettant de placer l’inférence dans votre propre environnement.

La couche Mémoire devrait être divisée mentalement en trois catégories : mémoire de travail, mémoire symbolique durable et mémoire sémantique recherchable. Les embeddings OpenAI retournent des vecteurs qui peuvent être indexés et recherchés ; la Récupération et la Recherche de Fichiers d’OpenAI superposent ensuite la recherche sémantique et par mots-clés sur les magasins vectoriels. Pinecone, Weaviate, pgvector et Milvus représentent quatre formes de stockage courantes : entièrement géré, vectoriel natif open-source, natif Postgres et base de données vectorielle distribuée. Hermes et OpenClaw ajoutent un rappel utile que toute la mémoire n’appartient pas à un magasin vectoriel : les notes basées sur des fichiers, les promotions examinées et les instantanés limités à la session sont souvent le design plus honnête — des schémas détaillés dans Système de Mémoire d’Agent Hermes pour la mémoire centrale bornée et les instantanés de session figés.

La couche Outils est là où un assistant cesse d’être un résumeur et commence à être du logiciel. L’appel de fonction OpenAI traite les outils comme une fonctionnalité définie par schéma que le modèle peut décider d’invoquer. Anthropic dit la même chose plus explicitement : l’utilisation d’outils est un contrat entre votre application et le modèle, et le modèle n’exécute jamais rien par lui-même. MCP généralise ce contrat en un protocole client-serveur où les hôtes se connectent à un ou plusieurs serveurs qui exposent des outils, des prompts et des ressources — la même frontière décrite étape par étape dans Serveur MCP en Go. LangChain et LlamaIndex s’installent confortablement ici comme bibliothèques d’orchestration : LangChain se concentre sur une architecture d’agent préconstruite et des intégrations, tandis que LlamaIndex se concentre sur l’accès aux données augmentées par le contexte, les moteurs de requête et les flux de travail.

La couche Routage existe parce que « quel modèle ? » n’est jamais la seule question. Vous avez aussi besoin de « quel chemin fournisseur, quel locataire, quel budget, quelle classe de latence et quel basculement ? ». LiteLLM est utile car ses documents officiels sont rafraîchissants de concret : le choix pondéré, le moins occupé, le routage basé sur la latence, le routage basé sur le coût et les basculements bornés sont tous des schémas de première classe. OpenClaw étend le routage vers le haut dans l’isolation des canaux et des agents, tandis que Hermes l’étend vers le bas dans des emplacements de modèles pour le travail principal et auxiliaire tel que la compression, la summarisation et le routage d’outils MCP. C’est le bon modèle mental : le routeur choisit plus qu’un modèle, il choisit une voie d’exécution.

La couche Observabilité est ce qui empêche l’architecture de se transformer en folklore. OpenTelemetry vous donne l’abstraction de trace. LangSmith vous donne une visibilité de bout en bout sur les étapes de l’application LLM et prend en charge les formes de déploiement cloud, hybride et auto-hébergé. OpenLIT vous donne une observabilité IA native OpenTelemetry avec des options d’instrumentation sans code et manuelle, y compris le support pour les LLM, les frameworks d’agents, les bases de données vectorielles et les GPU. Pour les métriques de production, les traces et les schémas SLO à travers les flux d’inférence et d’agents, voir Observabilité pour les Systèmes LLM. Si votre assistant n’a pas de trace par requête, pas de span par appel de modèle, et pas d’historique d’événements pour l’exécution d’outils, vous n’avez pas vraiment une architecture encore. Vous avez des vibes.

Capturer, enrichir, répondre

La séquence qui continue d’apparaître dans les vrais systèmes est capturer -> enrichir -> répondre -> enregistrer. Différents frameworks l’enveloppent différemment, mais le flux est assez stable pour être traité comme la colonne vertébrale.

sequenceDiagram
    participant U as Utilisateur ou Canal
    participant G as Passerelle ou UI
    participant R as Routeur
    participant M as Mémoire et Récupération
    participant L as LLM
    participant T as Outils ou MCP
    participant O as Observabilité

    U->>G: message, fichier ou commande
    G->>O: démarrer trace racine
    G->>R: requête + identité + session + politique
    R->>M: charger l'état de session et récupérer le contexte
    M-->>R: notes, fragments, métadonnées
    R->>L: prompt + contexte + schémas d'outils
    L-->>R: réponse ou appel d'outil
    alt appel d'outil
        R->>T: exécuter outil ou action MCP
        T-->>R: résultat d'outil
        R->>L: résultat d'outil + contexte mis à jour
        L-->>R: réponse finale
    end
    R->>M: persister les changements de session et les candidats mémoire
    R->>O: spans, métriques, événements d'évaluation
    G-->>U: réponse

L’étape de capture est souvent plus importante qu’elle n’y paraît. OpenClaw et Hermes placent tous deux une passerelle persistante devant l’assistant car l’ingress n’est pas juste une entrée de texte. Il inclut les métadonnées de canal, les identités, l’autorisation, les limites de session, les messages directs, les groupes, les ticks cron et la sémantique de livraison. Si vous sautez cette couche et vous fiez à une abstraction de widget de chat brut, vous finirez par la boulonner à nouveau comme middleware ad hoc.

L’étape d’enrichissement est là où les systèmes matures divergent des démos jouets. La Récupération et la Recherche de Fichiers d’OpenAI rendent la récupération explicite à travers les magasins vectoriels et les appels de recherche. LlamaIndex formalise le même schéma à travers les connecteurs de données, les index, les moteurs de requête et les flux de travail. Hermes va plus loin en divisant le parc de modèles en emplacements principaux et auxiliaires, déchargeant des travaux tels que la compression, la summarisation et le routage vers des modèles plus petits ou plus spécialisés. C’est un schéma de conception à voler : ne dépensez pas les jetons de votre modèle le plus cher pour des corvées.

L’étape de réponse n’est pas « générer du texte ». C’est « fermer la boucle actuelle ». Si le modèle peut répondre directement, il le fait. S’il a besoin d’un outil, il émet une requête structurée. Le contrat d’utilisation d’outils d’Anthropic et le guide d’appel de fonction d’OpenAI rendent cela explicite. La raison pour laquelle cela a de l’importance architecturalement est que les sorties incluent maintenant à la fois le langage et le flux de contrôle. Votre objet de réponse est en partie prose et en partie plan d’exécution.

L’étape d’enregistrement est là où la sémantique de cohérence apparaît. Pinecone sépare les chemins d’écriture et de lecture et traite les écritures après une acknowledgement durable. La mémoire Hermes est injectée comme un instantané figé par session pour qu’elle puisse préserver les performances du cache de préfixe, ce qui signifie que les nouvelles écritures n’apparaissent pas automatiquement dans le prompt de la session actuelle. Le système Dreaming d’OpenClaw ne promeut que les candidats examinés et ancrés dans MEMORY.md, et c’est une option plutôt que toujours actif. La leçon pratique est que la mémoire est rarement vraiment en lecture après écriture à travers chaque couche. Vous devez concevoir pour une visibilité en étapes.

OpenClaw et Hermes comme systèmes de référence

OpenClaw et Hermes sont des cas de référence utiles car ce ne sont pas juste des wrappers autour d’une API de fournisseur. Tous deux présentent un assistant comme un système à long terme avec des passerelles, des sessions, des outils, de la mémoire et plusieurs backends de modèles.

Ce mapping est ancré dans les documents et dépôts officiels d’OpenClaw et Hermes. OpenClaw documente une architecture de passerelle, un routage multi-agent, un support de fournisseur personnalisé et auto-hébergé y compris vLLM et Ollama, une mémoire active optionnelle et une promotion basée sur Dreaming. Hermes documente une passerelle de messagerie, une boucle centrale AIAgent, des emplacements de modèles principaux et auxiliaires, une mémoire intégrée et une intégration MCP native.

Ma lecture légèrement opinionnée est que les deux systèmes font le même argument architectural dans des accents différents. OpenClaw est fortement passerelle-first. Hermes est fortement agent-loop-first. Mais tous deux rejettent l’idée superficielle qu’un assistant est juste « prompt plus modèle ». Ils modélisent les canaux, les identités, la sémantique de mémoire, les surfaces d’outils et l’hétérogénéité des backends comme des préoccupations de première classe. C’est exactement ce qu’une architecture de production devrait faire.

Une pile hybride pratique inspirée par les deux systèmes ressemble à ceci :

edge:
  gateway: hermes ou openclaw

routing:
  proxy: litellm
  policy: conscient de la latence et du budget
  tenancy: scoped à la session et au canal

llm:
  primary: réponses openai ou messages anthropic
  local_fallback: vllm
  local_dev: ollama ou llama.cpp

memory:
  session: sqlite ou postgres
  semantic: pgvector ou weaviate
  embeddings: embeddings openai ou embeddings ollama

tools:
  contract: outils schéma json plus mcp
  examples: système de fichiers, navigateur, recherche web, API internes

observability:
  traces: opentelemetry
  ai_dashboards: openlit ou langsmith
  evals: evals openai plus ensembles de régression spécifiques à l'application

Cette pile est un schéma de déploiement raisonné plutôt qu’un plan prescrit par un vendeur. Elle fonctionne car les interfaces officielles s’alignent : OpenAI et Anthropic exposent des API orientées outils, vLLM et llama.cpp émulent des points de terminaison de style fournisseur, Ollama gère les modèles locaux et les embeddings, MCP standardise les outils externes, LiteLLM gère le routage et le basculement, et les plateformes compatibles OpenTelemetry peuvent tracer tout le chemin.

Schémas, tableaux et compromis

Il y a quelques schémas d’assistant répétables qu’il vaut la peine de nommer. Un assistant géré garde la majeure partie du temps d’exécution à l’intérieur des API du fournisseur. Un assistant retrieval-first traite la mémoire et la recherche comme le principal différenciateur. Un assistant tool-first se comporte plus comme un opérateur qu’un chatbot. Un assistant passerelle privilégie l’accès toujours-en via des surfaces de messagerie. Un maillage spécialisé décompose le travail en plusieurs agents ou routes. Les documents officiels à travers OpenAI, Anthropic, LlamaIndex, LiteLLM, OpenClaw et Hermes supportent tous des versions de ces schémas, même s’ils les nomment différemment.

Ce tableau de schémas est une synthèse des documents des fournisseurs, des documents des frameworks et des systèmes de référence plutôt qu’une affirmation d’un seul vendeur.

Notes du tableau : La Recherche de Fichiers hébergée d’OpenAI est un outil géré, Anthropic offre un harnais géré, Pinecone est un service vectoriel géré, tandis que vLLM, llama.cpp, Ollama, pgvector, Weaviate, Milvus, LangSmith auto-hébergé et OpenLIT supportent tous une opération auto-gérée ou hybride à divers degrés.

Notes du tableau : Pinecone documente un plan de contrôle géré et des plans de données régionaux. Weaviate documente les vecteurs et les index inversés avec plusieurs types d’index vectoriels. pgvector ajoute la recherche exacte et approximative du plus proche voisin à Postgres. Milvus se positionne comme une base de données vectorielle open-source haute performance et évolutive, avec Zilliz Cloud comme option gérée.

Notes du tableau : OpenAI documente Responses comme son interface avancée pour les réponses étatiques et les outils intégrés. Anthropic documente l’API Messages et le contrat d’utilisation d’outils séparément des Agents Gérés. vLLM expose un serveur compatible OpenAI plus le support de l’API Messages Anthropic. Ollama documente les flux de travail d’embedding et de modèle locaux. llama.cpp documente les routes de chat, de réponses et d’embeddings compatibles OpenAI, plus les complétions de chat compatibles Anthropic.

Cette matrice de compromis est une inférence architecturale des documents officiels, pas un benchmark vendeur. La ligne de cohérence est plus importante que de nombreux posts de blog ne l’admettent : Pinecone sépare les chemins d’écriture et de lecture, Hermes fige la mémoire dans les prompts de début de session, et OpenClaw promeut la mémoire durable à travers un examen en étapes. Cela signifie que « mémoire mise à jour » et « mémoire visible pour la réponse actuelle » sont souvent des vérités différentes.

Modes de défaillance et atténuations

La plupart des assistants ne échouent pas parce que le modèle de base est « mauvais ». Ils échouent parce que le système environnant ment au modèle, l’étouffe du bon contexte, laisse les outils dériver, ou rend le débogage impossible.

La base de preuves pour ce tableau est large mais cohérente. Les documents d’outils d’Anthropic rendent clair que l’utilisation d’outils est une frontière contractuelle. Les Guardrails d’OpenAI incluent la détection d’hallucination contre une base de connaissances de référence via la Recherche de Fichiers. SelfCheckGPT montre que la cohérence auto à travers les échantillons peut aider à détecter les affirmations non soutenues. Les résultats « Lost in the Middle » et les conseils de contexte d’Anthropic renforcent tous deux la même leçon opérationnelle : plus de jetons ne retirent pas le besoin de curation de contexte.

La pile d’atténuation préférée pourrait être ennuyeuse et répétitive : tracer chaque requête, versionner les prompts, évaluer la récupération indépendamment, garder les outils idempotents, et exécuter des evals de régression avant de changer les routes ou la politique de mémoire. Les documents et le dépôt d’Evals d’OpenAI sont brutaux sur pourquoi : sans evals, il est difficile et chronophage de comprendre comment les changements de modèle ou de prompt affectent votre cas d’utilisation. Cela s’applique tout autant aux routeurs et à la récupération qu’aux prompts.

Plus de lecture

Si vous voulez approfondir, il y a les sources primaires les plus utiles à garder ouvertes pendant la conception ou la révision d’une architecture d’assistant.

• OpenAI : Vue d’ensemble des Réponses, Appel de Fonction, Utilisation d’Outils, Récupération, Recherche de Fichiers, Evals, et MCP pour les serveurs d’outils distants.

• Anthropic : Vue d’ensemble de l’API, Utilisation d’Outils, le contrat d’utilisation d’outils, Agents Gérés, Fenêtres de Contexte, et le connecteur MCP.

• MCP lui-même : la Vue d’ensemble de l’Architecture et la Spécification valent la peine d’être lues directement, car elles expliquent les hôtes, clients, serveurs, outils, prompts, ressources, transports et négociation de capacités proprement.

• Frameworks et routage : Vue d’ensemble LangChain, documents d’augmentation de contexte LlamaIndex, documents de routage LiteLLM, documents d’observabilité LangSmith.

• Temps d’exécution auto-hébergés et systèmes d’assistant : vLLM, serveur llama.cpp, embeddings Ollama, documents et dépôt OpenClaw, documents et dépôt Hermes.

• Stockage et observabilité : Pinecone, Weaviate, pgvector, Milvus, OpenTelemetry, OpenLIT.

• Papiers de recherche : Génération Augmentée par Récupération pour les Tâches NLP Intensives en Connaissance, Lost in the Middle, et SelfCheckGPT.