MWS ramène le démarrage d'un agent IA de 37,6 à 16,8 secondes : analyse du harnais

Pendant que certains développeurs configurent un harnais local sur leur ordinateur portable, d'autres le déploient déjà en production pour des milliers d'utilisateurs. Un auteur de Habr s'est rendu au meetup de MWS « Russkoe tekhno 2 » et a noté ce qui se passe quand il faut mettre à l'échelle l'enveloppe qui entoure le modèle. Voici l'essentiel, avec une réserve : les chiffres sont rapportés d'après les intervenants et ne peuvent pas être vérifiés de l'extérieur.

Le harnais, c'est presque tout sauf le modèle

Un LLM brut est une boîte noire : il reçoit du texte et renvoie du texte. Il n'a ni mémoire, ni calcul exact, ni autovérification. Selon les intervenants, un agent égale modèle plus harnais. Le harnais comprend le prompt, le contexte et la mémoire, les outils, la boucle d'actions, les vérifications, les contraintes et l'orchestration.

Comment cette différence se voit-elle en pratique ? Un architecte de MWS a confié à Opus la revue du code d'un tiers et obtenu trois petites remarques. La même tâche sur DeepSeek avec un harnais a donné environ 50 remarques, dont 25 méritaient l'attention. Autrement dit, un modèle « moyen » bien harnaché a battu un modèle puissant utilisé sans harnais.

Quelques leçons de l'intervention :

• Le contexte est essentiel. Le modèle relit toute la conversation à chaque fois, et plus elle est longue, plus les réponses se dégradent. Solution : compresser l'historique, charger le nécessaire via des sous-agents ou déporter les données dans des fichiers.
• Plus d'outils ne veut pas dire mieux. Chez Vercel, l'agent doté de 17 outils se trompait sur une tâche sur cinq. Après réduction à quatre outils utiles, les tâches réussissaient à 100 %.
• Les erreurs s'accumulent. Avec une précision de 99 % par étape, une chaîne de 10 étapes passe sans faute dans 90 % des cas, et une chaîne de 50 étapes dans seulement 60 %. D'où la nécessité de tests après chaque modification et d'une spécification adaptée à la tâche, par exemple dans OpenSpec.

La tendance de 2026 : un harnais qui se corrige tout seul. Un configurateur lit les journaux de sessions, repère les défaillances récurrentes et complète les règles. Dans l'exemple de MWS, l'agent rendait son travail sans tests dans trois sessions sur six. Le configurateur a ajouté un hook « pas de rendu sans tests », et le lendemain les six sessions se sont terminées avec des tests.

Où partent les 37,6 secondes

Le projet « Tsifrovoï sotroudnik » (« Employé numérique ») est un agent-concierge personnel dans Telegram et Max, doté de plus de 30 compétences. En coulisses, chaque utilisateur dispose de son propre pod dans Kubernetes avec OpenClaw ou Hermes. La première réponse mettait en moyenne 37,6 secondes, alors que la réponse du modèle ne prenait que 2,3 à 4,5 secondes.

Le temps était consommé par l'infrastructure :

• 4 s : l'opérateur déploie le manifeste de l'agent dans Kubernetes ;
• 10 s : attachement du disque au nœud ;
• 5 s : montage du disque dans le pod ;
• 5 s : initialisation des conteneurs ;
• 9,5 s : chargement du Gateway de l'agent ;
• 3,1 s : contrôle de disponibilité ;
• 1 s : livraison des fichiers.

L'équipe a retenu une architecture de slots préchauffés : la préparation lourde se fait en amont, et l'utilisateur n'attend que le lancement. MWS a écarté les alternatives : un pod par utilisateur démarre trop lentement, une MicroVM par session est complexe à exploiter, et un répartiteur commun fait tomber tout le monde en cas de panne.

La chaîne d'optimisations a donné ceci :

1. Le démarrage du pod et la livraison des clés ont été déplacés dans les slots : moins 4 s, il reste 33,6 s.
2. Passage des disques bloc au stockage partagé CephFS : moins 15 s, il reste 18,6 s.
3. Préchauffage des conteneurs et des modules de l'agent : gain de seulement 1,8 s, car il a fallu ajouter l'assignation du slot et le réveil de l'agent.

Résultat : 16,8 secondes. L'objectif est de 6 à 8, mais il faudra pour cela entrer dans le code de l'agent et, peut-être, le forker.

Le prix de la vitesse

Chaque étape a compliqué le système. Il faut un registre de slots sur PostgreSQL, des événements Kafka et la garantie que le slot d'un utilisateur A parti ne soit pas attribué à B. Le principal problème est le disque partagé : dans la version actuelle, les slots voient une racine commune et, à cause des droits, un utilisateur pourrait théoriquement voir ses voisins. La solution consiste à monter un subvolume par clé, mais cela exigera un service dédié.

Les fichiers du workspace de l'agent ont été répartis en cinq zones : managed (selon le registre), protected (profils, ne pas toucher), runtime, user-owned et seed (livrés une seule fois). La règle est simple : on ne peut mettre à jour et supprimer que ce qui est à soi.

Autre difficulté : quand endormir l'agent. Actuellement, selon le temps : 30 à 35 minutes après la dernière activité de l'utilisateur, ou 5 minutes si le slot a été lancé par Cron. Sans accès au runtime, impossible de distinguer « parti » de « réfléchit à une réponse ». L'équipe teste l'hypothèse d'un modèle rapide qui tranche en 0,5 seconde.

Ce qu'il faut en retenir

Si vous construisez des agents pour de nombreux utilisateurs, mesurez le temps avant la première réponse séparément du temps de travail du modèle. Il est probable que votre problème vienne de l'infrastructure, pas du LLM. Ne gonflez pas l'ensemble d'outils et placez des vérifications à l'intérieur de la boucle. Réfléchissez à l'avance à l'isolation des données : le stockage partagé accélère le démarrage, mais fait des droits d'accès le principal risque.

Limite du matériau : le texte s'interrompt sur l'intervention consacrée à l'adoption de l'IA dans les organisations et à l'évaluation de l'effet business, il n'y a donc rien à dire ici sur la mesure du retour sur investissement. Certaines thèses (par exemple sur Google Research Harness 2) sont données sans sources et sont à prendre comme des déclarations des intervenants.