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

Un assistant IA de 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 informations ou agir, et expose suffisamment de détails d’exécution pour déboguer les échecs.

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

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

L’architecture la plus propre répartit les responsabilités en cinq couches : LLM, Mémoire, Outils, Routage et Observabilité. Cette répartition correspond aux capacités exposées par les API des principaux fournisseurs, par MCP, par les runtimes auto-hébergés tels que vLLM et llama.cpp, et par des systèmes d’assistants réels tels que OpenClaw et Hermes.

La mémoire doit être traitée comme plus que « un contexte plus long ». Les systèmes de récupération transforment les connaissances externes en mémoire non paramétrique explicite — le même espace de conception couvert en profondeur par Retrieval-Augmented Generation (RAG) — et à la fois les conseils sur le contexte d’Anthropic et l’article “Lost in the Middle” mettent en garde contre le fait que bourrer plus de jetons dans le contexte ne garantit pas une rappel fiable.

L’utilisation des outils est une limite de contrat, 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 runtime l’exécute, et le résultat s’écoule dans la conversation. Si cette limite est négligée, l’assistant devient négligent.

Mon biais est simple : commencer 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 ayez pu expliquer les cas d’échec de votre agent unique sans deviner.

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

Une définition pratique est la suivante : un système d’assistant IA est un runtime 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 de l’état et la télémétrie. C’est pourquoi les documents utiles ne sont pas seulement des fiches de modèles. 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 l’accès direct aux Messages ainsi que les 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 se réduit éventuellement à 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 répartition des composants ci-dessous est celle que je trouve la plus durable. C’est aussi celle qui s’aligne le mieux avec les API officielles et les runtimes open source que les gens exploitent réellement.

Le tableau ci-dessus est dérivé des interfaces officielles des fournisseurs, de MCP, des documents de bases de données vectorielles et des documents de runtime 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 rejets et le traçage. L’API Responses d’OpenAI est explicitement conçue pour les interactions étatiques ainsi que les outils intégrés et l’appel de fonctions. L’API Messages d’Anthropic expose la même boucle principale via les blocs tool_use et les retours tool_result, tandis que Managed Agents vous offre un harnais hébergé si vous ne souhaitez pas construire la boucle vous-même. Les runtimes auto-hébergés tels que vLLM et llama.cpp sont importants car ils préservent des interfaces de style fournisseur familières tout en vous permettant de placer l’inférence à l’intérieur de 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 consultable. Les embeddings OpenAI retournent des vecteurs qui peuvent être indexés et recherchés ; OpenAI Retrieval et File Search superposent ensuite la recherche sémantique et par mots-clés sur des 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 : 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 une conception plus honnête. Memory Systems in AI Assistants cartographie le modèle inter-framework ; Hermes Agent Memory System détaille la mémoire centrale bornée et les instantanés de session figés dans un produit.

La couche Outils est là où un assistant cesse d’être un résumeur et commence à être un 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 seul. 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 limite décrite étape par étape dans MCP Server in Go. LangChain et LlamaIndex s’y trouvent confortablement en tant que bibliothèques d’orchestration : LangChain se concentre sur une architecture d’agent préconstruite et les 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 également besoin de « quel chemin de 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 ou le coût, et les basculements bornés sont tous des modèles de premier ordre. OpenClaw étend le routage vers le haut dans l’isolation des canaux et des agents, tandis qu’Hermes l’étend vers le bas dans les slots de modèles pour le travail principal et auxiliaire tel que la résumation, la compression de contexte et le routage des 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 des applications 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 modèles SLO à travers les flux d’inférence et d’agents, voir Observability for LLM Systems. 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 des outils, vous n’avez pas vraiment une architecture. Vous avez des vibes.

Capturer, enrichir, répondre

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

L’étape de capture est généralement 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 seulement 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 réattacher comme middleware ad hoc de toute façon.

L’étape d’enrichissement est là où les systèmes matures divergent des démos jouets. OpenAI Retrieval et File Search rendent la récupération explicite via des magasins vectoriels et des appels de recherche. LlamaIndex formalise le même modèle via des connecteurs de données, des index, des moteurs de requête et des flux de travail. Hermes va plus loin en divisant le parc de modèles en slots principaux et auxiliaires, déchargeant des travaux tels que la compression, la résumation et le routage vers des modèles plus petits ou plus spécialisés. C’est un modèle 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 une importance architecturale est que les sorties incluent désormais à la fois le langage et le flux de contrôle. Votre objet réponse est partiellement en prose et partiellement un plan d’exécution.

L’étape d’enregistrement est là où les sémantiques de cohérence apparaissent. 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 fondés dans MEMORY.md, et c’est une option facultative plutôt que toujours active. La leçon pratique est que la mémoire est rarement vraiment lecture-après-écriture à travers chaque couche. Vous devez concevoir pour une visibilité échelonnée.

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 simplement des enveloppes autour d’une API de fournisseur. Les 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èle.

Cette cartographie est ancrée 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é incluant vLLM et Ollama, une mémoire active optionnelle et une promotion basée sur Dreaming. Hermes documente une passerelle de messagerie, une boucle AIAgent centrale, des slots de modèles principaux et auxiliaires, une mémoire intégrée et une intégration MCP native.

Ma lecture légèrement opinée est que les deux systèmes font le même argument architectural avec des accents différents. OpenClaw est fortement orienté passerelle-d’abord. Hermes est fortement orienté boucle-agent-d’abord. Mais les deux rejettent l’idée superficielle qu’un assistant est juste « prompt plus modèle ». Ils modélisent les canaux, les identités, les sémantiques de mémoire, les surfaces d’outils et l’hétérogénéité des backends comme des préoccupations de premier ordre. 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: limité à 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: évals openai plus ensembles de régression spécifiques à l'application

Cette pile est un modèle de déploiement raisonné plutôt qu’un plan bleu prescrit par un vendeur. Elle fonctionne parce que 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.

Modèles, tableaux et compromis

Il y a quelques modèles d’assistant répétables qu’il vaut la peine de nommer. Un assistant géré maintient la plupart du runtime à l’intérieur des API du fournisseur. Un assistant orienté récupération traite la mémoire et la recherche comme le principal différenciateur. Un assistant orienté outils se comporte plus comme un opérateur que comme un chatbot. Un assistant de passerelle priorise l’accès toujours actif via des surfaces de messagerie. Un maillage de spécialistes décompose le travail en plusieurs agents ou routes. Les documents officiels à travers OpenAI, Anthropic, LlamaIndex, LiteLLM, OpenClaw et Hermes soutiennent tous des versions de ces modèles, même s’ils les nomment différemment.

Le modèle de maillage de spécialistes se développe en une discipline d’ingénierie distincte à mesure que le nombre d’agents augmente. Pour les six modèles de coordination canoniques — orchestrateur-travailleur, pipeline séquentiel, éventail, hiérarchique, essaim et maillage — avec des modes de défaillance spécifiques et un cadre de décision de production, voir Multi-Agent Orchestration Patterns.

Ce tableau de modèles 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 : OpenAI File Search hébergé 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 prennent tous en charge une opération auto-gérée ou hybride dans des degrés variés.

Notes du tableau : Pinecone documente un plan de contrôle géré et des plans de données régionaux. Weaviate documente des vecteurs et des index inversés avec plusieurs types d’index vectoriels. pgvector ajoute la recherche de voisins exacts et approximatifs à 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’embedding compatibles OpenAI, plus les complétions de chat compatibles Anthropic.

Cette matrice de compromis est une inférence architecturale à partir des documents officiels, pas un benchmark de vendeur. La ligne de cohérence importe plus que ne l’admettent de nombreux articles de blog : 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 via un examen échelonné. 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, le prive 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 font comprendre que l’utilisation d’outils est une limite de contrat. OpenAI Guardrails inclut la détection d’hallucination contre une base de connaissances de référence via File Search. SelfCheckGPT montre que la cohérence auto à travers les échantillons peut aider à détecter les allégations 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 suppriment 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 évals de régression avant de changer les routes ou la politique de mémoire. Les documents et le dépôt Evals d’OpenAI sont brutaux sur pourquoi : sans évals, 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.

Lecture supplémentaire

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

• OpenAI : Vue d’ensemble Responses, Appel de Fonction, Utilisation d’Outils, Récupération, File Search, Evals, et MCP pour les serveurs d’outils distants.

• Anthropic : Vue d’ensemble 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 d’Architecture et la Spécification valent la peine d’être lues directement, car elles expliquent proprement les hôtes, les clients, les serveurs, les outils, les prompts, les ressources, les transports et la négociation de capacité. Pour une comparaison pratique de MCP avec le protocole Agent2Agent et quand un système multi-agent a besoin des deux couches, voir A2A vs MCP: Do AI Agents Really Need Both Protocols? et pour les concepts A2A eux-mêmes — Cartes d’Agent, cycle de vie des tâches, messages, parties et artefacts — voir What Is the A2A Protocol? Agent Cards and Tasks Explained.

• Assistants d’arrière-plan et proactifs : la couche d’outils n’est qu’une partie de la façon dont les assistants agissent. Pour savoir comment faire en sorte qu’un assistant regarde, décide et agisse par lui-même — planificateurs, travailleurs basés sur des files d’attente, protocoles de réclamation, flux de travail durables et interrogations sémantiques — voir Polling Agents in AI Assistants: 11 Implementation Patterns.

• Protocole A2A et adoption : une fois que les agents sont déployés indépendamment et ont besoin de collaborer à travers les limites de propriété, A2A devient pertinent. Pour une vue pratique 2026 de là où A2A a réellement de la traction, les questions de sécurité qu’il soulève, et un cadre de décision pour quand l’adopter, voir Google A2A Protocol in 2026: Adoption, Hype, and Reality. Lorsque ces agents échangent des tâches à long terme plutôt que des tours de chat uniques, A2A Streaming and Async Tasks for Long-Running Agent Workflows couvre SSE, push, et la conception input_required à la limite du protocole.

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

• Runtimes auto-hébergés et systèmes d’assistants : 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.

• Papers de recherche : Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, Lost in the Middle, et SelfCheckGPT.