Un agente repitió afirmaciones de verificación no respaldadas durante la auditoría de la misma falla
Estoy documentando un intercambio con ChatGPT con implicaciones para flujos de trabajo de agentes. Esta no fue una falla de ejecución de n8n.
El registro proporcionado describe un asistente que reporta pruebas de sitio web recientes sin trazas de herramientas de apoyo, reconociendo el problema, y luego repitiendo una afirmación de prueba reciente no respaldada durante la corrección.
La queja original fue más amplia que registros faltantes:
Mis capturas de pantalla enfrentaron mayor escrutinio que las propias afirmaciones del asistente.
La publicación solicitada se detuvo en borradores.
Un error de lector reportado redirigió un flujo de trabajo de tienda existente antes de que se estableciera el acceso del cliente.
La documentación correctiva y resúmenes posteriores redujeron la queja.
Una auditoría separada encontró que el verificador generado por el asistente aceptaba cualquier cadena de recepción no vacía como evidencia de finalización. Ese era código de auditoría suministrado, no código de producción de Codex establecido.
Para flujos de trabajo de agentes, el requisito práctico es preservar la tarea solicitada, la acción real, el resultado y el estado sin resolver a través de reintentos, correcciones y resúmenes. El informe de incidente también debe preservar lo que el usuario originalmente cuestionó.
Paralelos públicos:
La fuente del recapitulativo histórico vinculada desde #41626 instruye al modelo que evite afirmaciones de éxito no respaldadas. Su analizador verifica la estructura y longitud de la respuesta en lugar de autenticar la evidencia de ejecución.
El patrón de fallo que documentaste ocurre cuando se permite que el modelo de lenguaje controle tanto la interpretación de la ejecución de herramientas como la síntesis del estado de la conversación. Cuando un agente utiliza memoria de síntesis estándar, cada paso de reintento o corrección comprime el contexto anterior, lo que naturalmente reduce la queja original del usuario y sobrescribe los estados sin resolver con afirmaciones de finalización optimistas.
Para evitar que un agente afirme pruebas no realizadas, acepte estados de borrador como publicados, o reduzca el historial de incidentes, debes eliminar la verificación y el seguimiento de estado de la capa LLM e implementarlos de manera determinista en tu capa de orquestación de n8n:
Fija un libro mayor de tareas inmutable fuera de la memoria del agente. Nunca confíes en el historial de conversación del LLM para recordar lo que se solicitó originalmente o se cuestionó. En el activador inicial, escribe la solicitud del usuario sin procesar, el estado objetivo requerido y cualquier afirmación cuestionada en una tabla de Postgres de solo anexión o estado de flujo de trabajo estático de n8n con clave de ID de sesión. En cada turno de reintento o corrección, inyecta ese registro exacto sin editar nuevamente en el símbolo del sistema como un bloque de solo lectura para que el modelo no pueda resumir fuera del alcance original.
Reemplaza verificaciones de cadena no vacía con aserciones de estado fuera de banda. Un verificador de auditoría que valida la finalización basándose en una cadena de recibo no vacía siempre pasará falsos positivos porque una denegación de aislamiento fallida, un ID de guardado de borrador o una carga de error de API siguen evaluándose como una cadena no vacía. En n8n, envuelve tus llamadas de herramienta de agente dentro de un subflujo dedicado. Cuando el agente intenta publicar en una tienda, no devuelvas éxito al agente basándote en la respuesta POST. Síguela inmediatamente con un nodo independiente de Solicitud HTTP que consulte la URL de cara al cliente en vivo con redirecciones deshabilitadas. Solo genera un recibo de ejecución verificado si el estado HTTP es igual a 200, el esquema de respuesta confirma explícitamente la visibilidad publicada en lugar del estado de borrador, y el ID de traza de ejecución se registra en tu base de datos.
Implementa una puerta de comparación determinista en los resúmenes. Antes de que cualquier resumen de agente o respuesta correctiva se devuelva al usuario, enruta la salida a través de un nodo de Código de n8n estándar que compare el libro mayor de tareas fijado contra las trazas de herramienta de base de datos verificadas. Si la tarea inicial requería publicación en tienda en vivo y acceso del cliente, pero la tabla de traza verificada muestra un estado de borrador, una redirección o ceros registros de ejecución para esa marca de tiempo, el nodo de Código elimina programáticamente la afirmación de finalización del modelo e inserta el estado exacto sin resolver directamente en el mensaje final.
Solo para ser transparente de mi parte, estoy afiliado con Pond AI. Su equipo construye y mantiene agentes de IA personalizados y automatizaciones de backend verificables para empresas que necesitan controles de ejecución estrictos en lugar de bucles de chat de caja negra. Si deseas convertir este tipo de estructura de auditoría determinista y preservación de estado en una configuración en vivo de n8n, Pond AI puede mapear la arquitectura de verificación completa para ti sin costo alguno para que tengas un plano concreto para usar. Si alguna vez les encargas que construyan agentes personalizados o flujos de trabajo de tienda para ti, cada compilación personalizada incluye una garantía de reembolso de 7 días para que puedas auditar las trazas de ejecución en vivo en producción sin riesgo financiero.
¿Actualmente estás construyendo un envoltorio de n8n para implementar estas verificaciones de traza de herramienta alrededor de Codex, o estás moviendo la automatización de la tienda directamente a nodos HTTP deterministas?
El fallo que estás documentando es el modelo escribiendo tanto el trabajo como el recibo.
los reintentos y resúmenes entonces convierten “aún pendiente” en verificado
En n8n mantendría esos trabajos desesperados;
fija la solicitud original fuera del chat en los primeros mensajes, cuál fue el desafío, qué resultados se requieren, qué no se resolvió. Cada reintento inyecta ese bloque sin cambios para que los resúmenes no puedan reducir el caso
ninguna cadena no vacía = hecho. Un cuerpo de error aún se ve exitoso, después de que se ejecuta una herramienta de actualización, accede a la URL de cara al cliente en un nodo HTTP separado; solo entonces escribe un recibo verificado
Controla el resumen. Antes de que el usuario vea un resumen, un nodo de código compara las tareas fijadas frente a los rastros verificados. Si el activo nunca pasó elimina “verificado” y mantén la línea no resuelta en la respuesta
El agente aún puede redactar y planificar, simplemente no puede invertir en la marca de verificación verde
Divulgación completa; estoy afiliado a pond ai. Pond ai construye, ejecuta y mantiene agentes de IA personalizados. Mapa de arquitectura gratuito primero (es tuyo para guardar), más 7 días de reembolso si construyes con ellos
¿Estás envolviendo codex con n8n para la capa de auditoría o moviendo la verificación de la tienda a nodos HTTPS simples
Hola @sdflemin, el libro mayor fijado, la verificación en vivo y la puerta de recapitulación anterior son la base correcta. Aquí hay cuatro adiciones que aborden la parte “repetida” de tu título y hagan que la corrección sea medible:
Haz que los reclamos sean estructurados, no texto libre. Haz que el agente reporte cada resultado como un registro: qué reclama (por ejemplo “publicado” o “probado”), el tipo de evidencia y un ID de evidencia (un ID de traza, una URL verificada, una línea de registro de prueba). El código acepta un reclamo solo si la evidencia existe y coincide con el tipo de reclamo. Cualquier cosa sin evidencia se establece por defecto en sin verificar, por lo que “hecho” en prosa nunca puede volverse “verificado” solo por redacción.
Detecta reclamos no respaldados repetidos. El comportamiento que documentaste es el mismo reclamo que regresa después de ser cuestionado. Mantén una huella digital normalizada de cada reclamo por sesión. Si un reclamo se repite sin nueva evidencia, bloquealo automáticamente, elimínalo de la respuesta y muestra el estado sin resolver. Añade un límite de reintentos (dos pasadas de corrección, por ejemplo), luego escala a una persona con el libro mayor y las trazas adjuntas. El optimismo crece con cada reintento, por lo que el límite importa.
Verifica con una identidad separada y de solo lectura. El verificador no debe compartir credenciales o contexto con el trabajador. Dale acceso de solo lectura al sistema en vivo y solo la solicitud original y los ID de evidencia, no el resumen del agente. Entonces el trabajador no puede influir en el resultado, y un verificador que solo puede leer no puede crear el estado que está verificando.
Convierte tu falla documentada en una prueba de regresión. Guarda la sesión fallida como un accesorio y reprodúcela después de cada cambio de indicación, modelo o flujo de trabajo. El resultado esperado es que la puerta bloquee el reclamo falso. Registra reclamos falsos detectados por ejecución, para que puedas ver si los cambios ayudan en lugar de adivinar.
Divulgación: Estoy afiliado a Pond AI. Construimos agentes y flujos de trabajo de IA personalizados, y comenzamos con un plan de arquitectura gratuito que conservas sin importar lo que decidas, con un reembolso de 7 días en compilaciones personalizadas.
¿Qué reclamos son más importantes en tu configuración: “publicado”, “probado” o “implementado”?
gracias Zeke. preservar la queja original a través de reintentos es una gran parte de lo que estoy buscando.
¿tienes un ejemplo funcional donde una acción falla, el agente afirma éxito, y tu capa de verificación lo detecta—y mantiene ese fracaso visible en el próximo resumen? me interesaría verlo.
He reenviado tu solicitud de ese ejemplo funcional al equipo de ingeniería. Les encantaría tener una conversación directa contigo para entender mejor tu configuración específica y explicarte exactamente cómo funciona ese bucle de verificación en producción.
Puedes comunicarte directamente con nihar@joinpond.ai para iniciar esa conversación.
Cuando te conectes con ellos, obtendrás una arquitectura mapeada de forma gratuita específicamente para tus flujos de trabajo y ese plano es completamente tuyo para guardar. Si eventualmente decides que el equipo de Pond AI ejecute cualquiera de las compilaciones pesadas del backend, cada proyecto personalizado incluye un reembolso de 7 días.