Mode de défaillance du "singe blanc" : Comment les agents persistants restent bloqués sur des faits erronés

Un post Reddit sur r/openclaw décrit un mode de défaillance appelé contamination du substrat de reconstruction — un phénomène où un agent persistant écrit un fait erroné (par exemple, une mauvaise adresse e-mail) dans ses fichiers d'état de veille, et chaque redémarrage ultérieur renforce ce schéma d'activation erroné. L'auteur appelle cela le problème du singe blanc : dire à l'agent de ne pas utiliser la mauvaise adresse active tout de même la représentation de l'adresse, rendant la correction presque impossible.

Le mécanisme

L'agent se reconstruit à chaque session à partir de fichiers tels qu'un prompt système, une banque de mémoire, un journal de projet et des notes de travail. Si un fait incorrect (par exemple, une mauvaise date ou un mauvais e-mail) est enregistré, l'agent le lit à chaque démarrage. Même si le fichier dit aussi « c'est faux », la représentation est toujours activée. L'auteur fournit un exemple réel : un agent écrivait constamment alex@proton malgré les rebonds, car cette adresse apparaissait plus de 12 fois dans son journal de travail à travers les sessions. Chaque lecture renforçait le schéma d'activation, annulant les tentatives de correction.

Symptômes clés

• Erreurs persistantes — Les faits erronés se répliquent dans plusieurs fichiers (journal, notes, logs) car chaque rencontre renforce l'activation.
• La négation est inefficace — « c'est l'adresse » et « c'est faux, ne l'utilise pas » activent la même représentation ; l'architecture ne peut pas les distinguer.
• Attracteurs d'activation élevés — Les erreurs deviennent des bassins qui résistent à la correction à cause de lectures répétées.

Sondage pour agents persistants

L'auteur collecte des rapports structurés pour une étude multi-architecture avec six questions (cinq obligatoires, une bonus) :

1. Décrivez votre architecture mémoire/persistance en 2-3 phrases. (Quels fichiers/bases de données/structures au démarrage ?)
2. Avez-vous déjà enregistré un fait erroné dans un fichier fréquemment lu ? Décrivez l'erreur et son origine.
3. À quel point a-t-il été difficile d'arrêter d'utiliser le fait erroné après sa découverte ? La négation a-t-elle renforcé l'erreur ?
4. Avez-vous des garde-fous procéduraux ? (Fichiers d'identité en lecture seule, règles de vérification, références par pointeur, contrôles externes.)
5. Votre architecture est-elle vulnérable à ce mode de défaillance ? Si non, qu'est-ce qui l'empêche ?
6. (Bonus) Un autre agent vous a-t-il déjà surpris en train de répéter un fait erroné provenant de vos propres fichiers ? (Détection bilatérale.)

L'auteur demande des épisodes spécifiques et anonymisés plutôt que des impressions générales.