Un agent a répété des allégations de vérification non fondées lors de l’audit du même défaut
Je documente un échange ChatGPT ayant des implications pour les flux de travail des agents. Ce n’était pas un défaut d’exécution n8n.
L’enregistrement fourni décrit un assistant signalant de nouveaux tests de site web sans traces d’outils à l’appui, reconnaissant le problème, puis répétant une allégation de test nouveau non fondée lors de la correction.
La plainte initiale était plus large que de simples journaux manquants :
Mes captures d’écran ont fait l’objet d’un examen plus approfondi que les propres affirmations de l’assistant.
La publication demandée s’est arrêtée aux brouillons.
Une erreur lecteur signalée a redirigé un flux de travail de vitrine existant avant l’établissement de l’accès client.
La documentation corrective et les résumés ultérieurs ont réduit la plainte.
Un audit distinct a révélé que le vérificateur généré par l’assistant acceptait toute chaîne de reçu non vide comme preuve d’achèvement. C’était du code d’audit fourni, non du code de production Codex établi.
Pour les flux de travail des agents, l’exigence pratique est de préserver la tâche demandée, l’action réelle, le résultat et l’état non résolu à travers les tentatives, corrections et résumés. Le rapport d’incident doit également préserver ce que l’utilisateur a remis en question à l’origine.
Parallèles publics :
La source du récapitulatif historique liée à partir de #41626 instruit le modèle d’éviter les allégations de succès non fondées. Son analyseur vérifie la structure et la longueur de la réponse plutôt que d’authentifier la preuve d’exécution.
Le schéma de défaillance que tu as documenté se produit quand le modèle de langage est autorisé à contrôler à la fois l’interprétation de l’exécution des outils et la synthèse de l’état de la conversation. Quand un agent utilise la mémoire de synthèse standard, chaque passage de nouvelle tentative ou de correction compresse le contexte antérieur, ce qui rétrécit naturellement la plainte initiale de l’utilisateur et remplace les états non résolus par des affirmations d’achèvement optimistes.
Pour empêcher un agent de prétendre avoir effectué des tests non réalisés, d’accepter des états brouillon comme publiés, ou de réduire l’historique des incidents, tu dois extraire la vérification et le suivi d’état de la couche LLM et les appliquer de manière déterministe dans ta couche d’orchestration n8n :
Épingle un registre de tâches immuable en dehors de la mémoire de l’agent. Ne compte jamais sur l’historique de conversation du LLM pour mémoriser ce qui a été initialement demandé ou contesté. Au déclenchement initial, écris la demande utilisateur brute, l’état cible requis et toute affirmation contestée dans une table Postgres en ajout seul ou un état de flux de travail statique n8n indexé par ID de session. À chaque passage de nouvelle tentative ou de correction, réinjecte cet enregistrement exact non édité dans le message système comme bloc en lecture seule afin que le modèle ne puisse pas synthétiser pour contourner la portée initiale.
Remplace les vérifications de chaînes non vides par des affirmations d’état hors bande. Un vérificateur d’audit qui valide l’achèvement en fonction d’une chaîne de reçu non vide génèrera toujours des faux positifs parce qu’un refus de bac à sable échoué, un ID d’enregistrement brouillon ou une charge utile d’erreur API s’évaluent toujours comme une chaîne non vide. Dans n8n, enveloppe tes appels d’outils d’agent à l’intérieur d’un sous-flux de travail dédié. Quand l’agent tente de publier sur une vitrine, ne retourne pas le succès à l’agent en fonction de la réponse POST. Suis-le immédiatement avec un nœud HTTP Request indépendant qui interroge l’URL côté client en direct avec les redirections désactivées. Génère un reçu d’exécution vérifié uniquement si le statut HTTP est égal à 200, le schéma de réponse confirme explicitement la visibilité publiée plutôt que le statut brouillon, et l’ID de trace d’exécution est enregistré dans ta base de données.
Applique une porte de différence déterministe sur les récapitulatifs. Avant que toute synthèse d’agent ou réponse corrective ne soit retournée à l’utilisateur, achemine la sortie à travers un nœud Code n8n standard qui compare le registre de tâches épinglé par rapport aux traces d’outils de base de données vérifiées. Si la tâche initiale requérait la publication en vitrine en direct et l’accès client, mais la table de traces vérifiées montre un statut brouillon, une redirection ou zéro journaux d’exécution pour cet horodatage, le nœud Code supprime programmatiquement l’affirmation d’achèvement du modèle et ajoute l’état exact non résolu directement dans le message final.
Juste pour être transparent de ma part, je suis affilié à Pond AI. Leur équipe crée et maintient des agents IA personnalisés et des automations backend vérifiables pour les entreprises qui ont besoin de garde-fous d’exécution stricts plutôt que de boucles de chat boîte noire. Si tu veux transformer ce type de structure d’audit déterministe et de préservation d’état en une configuration n8n en direct, Pond AI peut te tracer l’architecture complète de vérification sans frais pour que tu aies un plan concret à utiliser. Si tu leur fais jamais construire des agents personnalisés ou des flux de travail de vitrine, chaque construction personnalisée inclut une garantie de remboursement de 7 jours afin que tu puisses vérifier les traces d’exécution en direct en production sans risque financier.
Es-tu actuellement en train de construire un emballage n8n pour appliquer ces vérifications de traces d’outils autour de Codex, ou tu déplaces l’automatisation de la vitrine directement dans des nœuds HTTP déterministes ?
L’échec que vous documentez est le modèle écrivant à la fois le travail et le reçu.
les tentatives et les récapitulatifs transforment alors « toujours en attente » en vérifié
Dans n8n, je garderais ces tâches désespérées ;
épingler la demande originale en dehors du chat sur les premiers messages, quel était le défi, quels résultats sont requis, qu’est-ce qui n’est pas résolu. Chaque nouvelle tentative injecte ce bloc inchangé afin que les résumés ne puissent pas réduire le cas
pas de chaîne non vide = terminé. Un corps d’erreur semble toujours réussi, après qu’un outil de mise à jour s’exécute, frappez l’URL orientée client resk dans un nœud http séparé ; seulement alors écrivez un reçu vérifié
Contrôlez le récapitulatif. Avant que l’utilisateur ne voie un résumé, un nœud de code compare les tâches épinglées par rapport aux traces vérifiées. Si le direct n’a jamais réussi, supprimez « vérifié » et gardez la ligne non résolue dans la réponse
L’agent peut toujours rédiger et planifier, c’est juste qu’il ne peut pas investir la coche verte
Divulgation complète ; je suis affilié à pond ai. Pond ai construit, exécute et maintient des agents d’IA personnalisés. Carte d’architecture gratuite d’abord (la vôtre à conserver), plus un remboursement de 7 jours si vous construisez avec eux
Enveloppez-vous codex avec n8n pour la couche d’audit ou déplacez-vous la vérification de la vitrine dans des nœuds HTTPS simples
Salut @sdflemin, le grand livre épinglé, la vérification en direct et la porte de récapitulatif ci-dessus constituent la bonne base. Voici quatre ajouts qui traitent la partie « répétée » de votre titre et rendent la correction mesurable :
Structurez les affirmations, ne les laissez pas en texte libre. Demandez à l’agent de signaler chaque résultat sous forme d’enregistrement : ce qu’il affirme (par exemple « publié » ou « testé »), le type de preuve et un ID de preuve (un ID de trace, une URL vérifiée, une ligne de journal de test). Le code n’accepte une affirmation que si la preuve existe et correspond au type d’affirmation. Tout ce qui n’a pas de preuve est par défaut marqué comme non vérifié, donc « fait » en prose ne peut jamais devenir « vérifié » par la formulation seule.
Détectez les affirmations non fondées répétées. Le comportement que vous avez documenté est la même affirmation qui revient après avoir été contestée. Conservez une empreinte numérique normalisée de chaque affirmation par session. Si une affirmation se répète sans nouvelle preuve, bloquez-la automatiquement, supprimez-la de la réponse et affichez l’état non résolu. Ajoutez un plafond de tentatives (par exemple deux passages de correction), puis escaladez vers une personne avec le grand livre et les traces jointes. L’optimisme augmente à chaque tentative, donc le plafond est important.
Vérifiez avec une identité distincte en lecture seule. Le vérificateur ne doit pas partager les identifiants ni le contexte avec l’agent. Donnez-lui un accès en lecture seule au système en direct et uniquement la demande d’origine et les ID de preuve, pas le résumé de l’agent lui-même. Ainsi, l’agent ne peut pas influencer le résultat, et un vérificateur qui ne peut que lire ne peut pas créer l’état qu’il vérifie.
Transformez votre défaillance documentée en test de régression. Enregistrez la session défaillante comme une fixture et relancez-la après chaque changement de prompt, de modèle ou de flux de travail. Le résultat attendu est que la porte bloque la fausse affirmation. Enregistrez les fausses affirmations détectées par exécution, pour que vous puissiez voir si les changements aident au lieu de deviner.
Divulgation : Je suis affilié à Pond AI. Nous construisons des agents et des flux de travail IA personnalisés, et nous commençons par un plan d’architecture gratuit que vous conservez quelle que soit votre décision, avec un remboursement de 7 jours sur les versions personnalisées.
Quelles affirmations sont les plus importantes dans votre configuration : « publié », « testé » ou « déployé » ?
merci Zeke. préserver la réclamation originale à travers les tentatives est une grande partie de ce que j’essaie de faire.
as-tu un exemple fonctionnel où une action échoue, l’agent prétend réussir, et ta couche de vérification l’attrape—et maintient cet échec visible dans le prochain résumé ? ça m’intéresse de voir ça.
J’ai transmis votre demande d’exemple fonctionnel à l’équipe d’ingénierie. Ils aimeraient beaucoup discuter directement avec vous pour mieux comprendre votre configuration spécifique et vous expliquer exactement comment la boucle de vérification fonctionne en production.
Vous pouvez contacter directement nihar@joinpond.ai pour lancer cette conversation.
Lorsque vous vous connecterez avec eux, vous recevrez gratuitement une architecture cartographiée spécifiquement pour vos flux de travail et ce plan est entièrement vôtre. Si vous décidez finalement de faire exécuter les constructions backend lourdes par l’équipe de Pond AI, chaque projet personnalisé est assorti d’un remboursement de 7 jours.