Les agents IA échouent rarement parce que la démo était mauvaise. Ils échouent lorsque le même workflow doit s'exécuter pour de nombreux utilisateurs, sur de nombreux outils, derrière de véritables équilibreurs de charge, avec des journaux, des tentatives, une authentification et des limites de coûts. C’est là qu’un petit serveur MCP fonctionnant sur un seul ordinateur portable peut se transformer en un goulot d’étranglement de production.
Le changement important : MCP passe d'une conception « un client parle à un serveur mémorisé » vers une conception plus Web native. Si vous créez des intégrations d'agents, c'est votre chance d'éviter les sessions persistantes, l'état fragile de la mémoire et les appels d'outils qui disparaissent au redémarrage d'un conteneur.
Ce guide présente une architecture de session MCP pratique pour les constructeurs qui souhaitent que les flux de travail des agents évoluent sans devenir ingouvernables.
Model Context Protocol, ou MCP, offre aux agents IA un moyen standard d'accéder aux outils, fichiers, bases de données, API et systèmes internes. Au lieu que chaque équipe invente un modèle de connecteur personnalisé, MCP offre aux clients et aux serveurs un protocole partagé.
Cette standardisation est utile, mais elle expose également à un problème de mise à l’échelle.
Un serveur MCP local peut conserver l'état en mémoire. Un serveur MCP de production ne le peut généralement pas. Une fois que vous avez ajouté plusieurs instances, le routage régional, la mise à l'échelle automatique, les redémarrages de conteneurs et les workflows d'agent de longue durée, vous avez besoin d'une réponse claire à une question simple :
Lorsque le prochain appel d’outil arrive, qui se souvient de ce qui s’est passé auparavant ?
Les récentes discussions de l'industrie autour de MCP se sont concentrées sur la nécessité de rendre les identifiants de session plus faciles à utiliser à grande échelle. La conclusion pratique pour les constructeurs n’est pas « les sessions sont terminées ». C'est ceci :
Ne faites pas d’un processus le seul endroit où réside la vérité du workflow.
Une configuration MCP de base ressemble souvent à ceci :
Client agent -> Processus serveur MCP -> Outil/API interneC'est très bien pour le développement local. Le serveur peut stocker les métadonnées de session en mémoire :
const sessions = new Map(); function createSession(clientId) { const sessionId = crypto.randomUUID(); sessions.set(sessionId, { clientId, createAt : Date.now(), toolBudget : 100, lastToolCall : null }); renvoie l'ID de session ; }Cela échoue lorsque vous déployez plusieurs instances de serveur :
+----------------+ Client agent -> | Équilibreur de charge | +-------+--------+ | +-------------+-------------+ | | | MCP A MCP B MCP C a une session pas de session pas de sessionSi la première requête arrive sur MCP A et que la suivante arrive sur MCP B, l'état de session en mémoire disparaît. Vous pouvez forcer des sessions persistantes, mais ce...
[Courte citation de 8% de l'article original]