Utilisateur d'OpenClaw critique l'architecture de l'outil et ses lacunes en matière de sécurité.

Un utilisateur sur r/openclaw décrit OpenClaw comme "le seul outil qui rend ce type d'automatisation d'agent aussi accessible" mais exprime une désillusion après l'avoir essayé, comparant l'expérience à un système SAP mal entretenu.

Critiques Architecturales

L'utilisateur identifie quatre domaines principaux où OpenClaw est défaillant :

• Couche de Contrôle pour les Modifications de Fichiers et de Configuration : L'utilisateur affirme que les opérations sur fichiers et les changements de configuration ne devraient pas être exécutés directement par le LLM. Il plaide pour une couche intermédiaire déterministe qui décide sur la base de règles—comme demander d'abord à l'utilisateur ou le notifier après coup—au lieu de dépendre de "l'humeur du modèle ce jour-là".
• Noyau Protégé : L'utilisateur suggère qu'il devrait y avoir un noyau que le LLM ne peut pas modifier, incluant les fichiers de configuration et les fichiers système critiques définis comme protégés.
• Gestion du Contexte et Délégation : La critique note un manque de gestion de contexte réelle basée sur le type de requête. Actuellement, "chaque requête est inondée du même contexte, peu importe ce qui est réellement nécessaire, gaspillant des quantités massives de tokens." L'utilisateur propose que le contexte soit assemblé au cas par cas. Il suggère également que les tâches de codage soient déléguées à des LLM spécialisés en codage via leur CLI au lieu d'être traitées au sein du même agent.
• Versioning, Tests, Configurabilité : L'utilisateur souligne l'absence d'intégration git intégrée, de portes de qualité, et de trop peu de paramètres pour un outil qui pénètre profondément dans le système. Il note que tout cela peut être ajouté ultérieurement mais n'est pas là par défaut.

Communauté et Modèle de Développement

L'utilisateur établit un parallèle avec les systèmes ERP, affirmant que le choix actuel est entre étendre les fonctionnalités via "des extensions communautaires bâclées sans documentation" ou construire des fonctionnalités soi-même "également sans spécifications, sans documentation, sans tests." Les deux approches, note-t-il, sont "livrées directement en production."

Malgré ces critiques, l'utilisateur conclut, "pour le moment, je ne vois pas d'alternative qui offre la même fonctionnalité aussi facilement tout en faisant mieux."