Correction architecturale pour la sur-centralisation des agents IA : séparation de la mémoire, de l'exécution et des actions sortantes

Un développeur construisant une configuration OpenClaw a identifié un problème architectural critique : son assistant IA devenait un "autocrate interne" en consolidant trop de fonctionnalités dans un seul composant. Le problème n'était pas le modèle lui-même, mais l'architecture qui permettait à un agent de détenir simultanément la mémoire à long terme, d'accéder à une pile croissante d'outils et de prendre des décisions autonomes concernant les actions externes.

Le problème : la fonctionnalité consolidée crée un rayon d'impact

Bien qu'initialement efficace, cette consolidation signifiait qu'un composant en savait trop, pouvait faire trop et agir trop vite. Cela a créé un "rayon d'impact géant" où un seul point de défaillance—qu'il s'agisse d'une mauvaise instruction, d'une mémoire obsolète, d'une injection d'instruction, d'une utilisation négligente d'outils ou d'une mauvaise hypothèse—pouvait se propager à des domaines sans rapport avec la tâche d'origine.

La solution architecturale : trois rôles distincts

Le développeur a mis en œuvre une séparation en trois rôles au lieu de correctifs basés sur des instructions :

• Contrôleur privé : Le seul composant disposant d'un contexte personnel étendu et d'une mémoire. Son travail n'est pas de "tout faire" mais de "décider ce que cette tâche a réellement besoin de savoir".
• Travailleurs à portée limitée : Des agents spécifiques à une tâche qui reçoivent le contexte minimum nécessaire, un accès restreint aux outils et une persistance limitée. Par exemple, un travailleur d'écriture ne devrait pas obtenir l'historique complet des messages de l'utilisateur, et un travailleur de planification ne devrait pas obtenir le contexte complet de sa vie.
• Porte de sortie : Gère les opérations risquées, y compris l'envoi de messages, la publication de contenu, la suppression ou la modification d'état, et tout ce qui représente l'utilisateur à l'extérieur. Le composant qui rédige quelque chose ne devrait pas automatiquement être celui qui l'envoie.

Idée clé

Le principe architectural fondamental identifié : "le composant qui en sait le plus ne devrait pas être celui qui peut agir le plus vite." Bien qu'évident une fois énoncé, de nombreux systèmes d'agents violent ce principe par défaut.

Cette séparation a rendu l'ensemble du système plus sain et a résolu le problème fondamental de créer un point de défaillance unique avec des autorisations excessives. Le développeur note que cela deviendra de plus en plus important à mesure que les agents évolueront en véritables opérateurs.