Observabilidad del agente AI para los ensayos de repetición: captura efectos duplicados

Un agente no debe volver a intentar una llamada de herramienta simplemente porque su rastreo termina en un tiempo. Puede que la solicitud haya llegado al proveedor, haya cambiado el estado real y haya perdido sólo la respuesta. Un segundo intento puede entonces enviar el mensaje dos veces, crear dos boletos o proporcionar dos recursos mientras ambos rastros parecen razonables individualmente. La regla de salud útil es más estricta: la operación lógica de one no debe producir más de un efecto verificado . Dar a la operación una identidad estable, mantener esa identidad a través de los intentos, registrar recibos de efectos del proveedor, y bloquear la reutilización automática cuando el efecto no se puede buscar de manera segura. El conteo de intentos y el estado HTTP todavía ayudan con el diagnóstico, pero ninguno demuestra el resultado. Este artículo construye esa regla en un pequeño libro mayor de efectos y lo prueba contra cuatro operaciones. El dispositivo contiene ocho intentos y cuatro observaciones del proveedor. Una política de solo intentos vería tiempos de espera y seguir intentando tres operaciones de nuevo. La auditoría consciente de los efectos en cambio encuentra una repetición saludable, un incidente de efecto duplicado, un conflicto clave de impotencia y una operación honestamente incierta. Una pausa no es prueba de que nada sucedió. La ventana peligrosa se encuentra entre la ejecución remota y el reconocimiento local. Un proveedor puede cometer un efecto y luego perder la respuesta en el camino de regreso. Desde el lado del agente, estas dos historias son observacionalmente similares: 1. la solicitud nunca llegó al proveedor; 2. la solicitud se completó, pero la respuesta no llegó al agente. Sólo la primera historia es segura para repetir sin otra protección. El segundo crea un duplicado cuando la operación no es naturalmente idempotente. La semántica HTTP proporciona un límite útil. La RFC 9110 define un método idempotente como uno cuyo efecto de servidor previsto sea el mismo después de múltiples solicitudes idénticas que después de una sola solicitud. Permite repetición automática después de un fallo de comunicación para métodos idempotentes, pero dice que un cliente no debe volver a intentar automáticamente una solicitud no idempotente a menos que sepa que la operación es efectivamente idempotente o pueda detectar que el original nunca se aplicó. Esa distinción pertenece a la salud de los agentes. Un PUT que reemplaza un registro conocido y un POST que envía un correo electrónico pueden ambos tiempo fuera, sin embargo no tienen el mismo límite de retoma. Una política genérica timeout → retry borra el hecho semántico que más importa. El apoyo del proveedor ayuda, pero el contrato debe leerse con precisión. Documentos de las bandas que almacena el código de estado y el cuerpo para la primera solicitud realizada con una clave de idempotency, luego devuelve ese resultado a solicitudes posteriores con la misma clave. También compara parámetros y rechaza el reutilización con diferentes parámetros. Por lo tanto, la clave no es una etiqueta aleatoria adjunta a cada intento. Representa una operación lógica estable. Documentos de Amazon EC2 un patrón similar de token de cliente: una nueva prueba exitosa con el mismo token y parámetros no realiza ninguna acción adicional, mientras que los parámetros cambiados pueden producir IdempotentParameterMismatch . La EC2 también abarca algunas garantías a nivel regional o regional. Tiene un token no es suficiente; el registro de salud necesita el alcance del token, la identidad de la carga útil, la ventana de retención y el comportamiento del proveedor. El defecto razonable es: reutilizar una identidad de operación en todos los intentos; reutilizar la clave de idempotencia del proveedor únicamente para la misma carga útil canónica; después de un resultado ambigüo, consulta por esa identidad antes de volver a intentarlo; si el proveedor no ofrece ninguna indemnización ni búsqueda, requieren una decisión humana para efectos consecuentes. El retroceso reduce la presión sobre un servicio fallido. No convierte una acción no idempotente en una idempotente. Los efectos registrados, no sólo los intentos Un rastro ordinario responde ¿Qué intentó el agente? Un libro mayor de efectos responde a la pregunta diferente ¿qué cambio duradero podemos probar? Mantenga los dos registros vinculados, porque los intentos siguen siendo pruebas útiles, pero no trate el lapso terminal de un intento como el resultado comercial. Un libro mayor mínimo necesita estos campos: El campo Propósito El mal de salud que expone operationId Identidad estable para la operación prevista por el usuario Una nueva identificación generada para cada nuevo intento attemptId Identidad de un intento de transporte Intentos perdidos o superpuestos idempotencyKey Identidad de deduplicación del proveedor, cuando sea compatible Cambios clave en los retos payloadHash Hash de una carga útil canónica, editada La misma llave reutilizada para diferentes propósitos effectRef Identidad del proveedor o del destino del efecto real Más de un efecto duradero result Observación de transporte como timeout o success Reconocimiento ambigüo observedAt El tiempo en que se recogieron las pruebas Pruebas obsoletas confundidas con el estado actual No ponga secretos, direcciones de correo electrónico, instrucciones completas o cargas útiles de herramientas en estos campos. Hash una representación canónica después de eliminar los valores volátiles. Mantenga la materia prima sensible en el origen cuando la investigación lo requiera. La identidad de la operación debe ser acuñada cuando la intención se vuelva duradera, no dentro del bucle de repetición. Por ejemplo: El fragmento es incompleto por diseño: capturar una excepción y continuar no es prueba de seguridad. El solicitante también debe conservar la identificación del objeto devuelto del proveedor o consultar al proveedor con la misma identidad de negocio después de una respuesta ambigua. Cuenta efectos únicos, no respuestas exitosas. Dos respuestas exitosas que ambos nombran ticket 908 describen un efecto. Un tiempo de espera seguido de un éxito que nombra delivery a y delivery b describe dos efectos. Por el contrario, los recibos cero no demuestran efectos cero cuando el canal de búsqueda no está disponible. Ese estado es uncertain , no saludable y no se atasca automáticamente. La identidad de la carga útil es una puerta separada. Si dos intentos comparten una clave de idempotencia pero tienen diferentes hashes de carga útil canónica, deténgase antes de interpretar el recuento de efectos. El solicitante puede haber reutilizado accidentalmente una clave después de cambiar la región, destinatario, cantidad o forma del recurso solicitado. Los errores de desajuste de parámetros del proveedor son una prueba útil de este error exacto. Realizar una auditoría de los efectos de las cuatro operaciones El dispositivo inspectable utilizado para este artículo es NDJSON. Cada línea es una observación attempt o una observación effect . El artefacto local completo contiene cuatro operaciones lógicas: op ticket 42 : dos intentos comparten una clave y una carga útil; ambas observaciones apuntan a ticket 908 ; op webhook 77 : dos intentos no tienen clave de idempotencia y revelan delivery a más delivery b ; op vm 5 : dos intentos de reutilización de una clave con diferentes hashes de carga útil; op email 3 : dos intentos de tiempo fuera, no hay recibo de efecto disponible, y el proveedor no tiene ruta de búsqueda. Los grupos de auditoría registran por operationId , rechazan la deriva de la carga útil antes de contar los efectos y cuentan valores effectRef distintos en lugar de filas de observación de efectos: Ejecutando el artefacto del repositorio: Produce: Tres observaciones cambian la decisión operativa. Primero, op ticket 42 tiene dos registros de intentos y dos observaciones de efectos, pero ambas observaciones se resuelven a un objeto proveedor. La advertencia en las filas de efecto 1 sería falsa positiva. La referencia de proveedor estable es lo que prueba la deduplicación. En segundo lugar, op webhook 77 incluye un segundo intento exitoso. Un panel de control sólo para transporte podría cerrar el incidente. Las dos referencias de efecto demuestran que la recuperación creó una segunda entrega, por lo que el estado correcto es duplicado y la siguiente tarea es la reconciliación, no otro intento. En tercer lugar, op vm 5 no tiene efecto duplicado en el dispositivo, pero sigue siendo inseguro. La llave reutilizada cubre dos hashes de carga útil diferentes. Esperar hasta que aparezca un segundo recurso detectaría el problema demasiado tarde; el conflicto clave es una falla preventiva en la salud. La auditoría tiene una importante limitación: sólo puede clasificar las pruebas aportadas. Para op email 3 , ningún recibo y ninguna ruta de búsqueda hacen que el resultado sea desconocido. El libro mayor no puede fabricar certeza. El volver a intentarlo podría completar el trabajo faltante o duplicar el trabajo terminado, por lo que la respuesta limitada es hacer surface la ambigüedad y pedir autoridad. Convierta el resultado en un límite de nuevo intento Utilice la clasificación para controlar la siguiente acción, no sólo colorear un panel: Clasificación Pruebas Default seguro healthy Una identidad de carga útil y exactamente un efecto único Dejar de volver a probar; verificar el producto entregado previsto duplicate Más de un efecto único para una operación Pruebas por bloque; conciliar o compensar con la aprobación key conflict Una clave adjunta a múltiples hashes de carga útil Ejecución de bloques; realizar una nueva operación sólo después de revisar la intención uncertain Ninguna prueba de efecto y ninguna prueba de ausencia confiable Preguntar otra vez, esperar nuevas pruebas, o preguntar a un humano Aún es necesario un límite de tiempo. Los registros de idempotencia del proveedor pueden caducar, los índices de búsqueda pueden retrasarse y un destino puede estar fuera de los límites de la transacción del proveedor. Almacenar la conservación documentada y el alcance junto a la llave. Después de que ese límite expire, la misma solicitud puede dejar de ser segura incluso si el camino del código original no ha cambiado. La verificación de recuperación debe alcanzar el resultado original. Un objeto de un solo proveedor puede estar equivocado: un ticket puede existir con el proyecto equivocado, o un recurso puede ser creado pero nunca estar listo. La invariante de efecto único evita la duplicación; un contrato de resultado separado verifica que el efecto superviviente es el que el usuario pretendía. Para obtener una visión de la salud operativa, informe cinco hechos en conjunto: 1. la operación lógica y la huella digital de la carga útil; 2. los intentos y los resultados de su transporte; 3. el alcance y la frescura de la incapacidad del proveedor; 4. los distintos efectos duraderos observados; 5. el límite de autoridad para retomar el intento, la compensación o la reconciliación. Eso hace que el retiro sea una prueba más que un veredicto. El veredicto más saludable es que existe un efecto previsto y se ha verificado, o, cuando la evidencia es incompleta, el efecto es incierto; se bloquea la reutilización automática. Sidewisp se encuentra actualmente en versión preliminar privada. Su sistema de artículos públicos y la demostración de productos interactivos son en vivo, pero la colección de agentes de producción salud, adaptadores de tiempo de ejecución, administración cron, análisis de costos de tokens y recuperación generalmente no se envían. Los ejemplos anteriores son un patrón de funcionamiento, no una afirmación de que Sidewisp actualmente inspecciona o repara agentes en vivo. Sidewisp no es un tiempo de ejecución de reemplazo, una puerta de entrada obligatoria, un producto de rastreo bruto, un avión de control empresarial o un fijaje autónomo. Si una regla de salud del libro de efectos le ayudaría a operar agentes existentes, considere unirse a la vista previa privada. Mantenga la ejecución donde ya se ejecuta; haga que los retos ganen su seguridad a través de la evidencia.