2026-08-01T23:20:11.442Z

Observabilidad del agente a través de los reinicios: el patrón de recibo de entrega

Un patrón de recepción duradero para correlacionar la delegación, la aceptación, las esperanzas legítimas y los resultados verificados a través de los reinicios del agente y los límites de rastreo.

La observabilidad del agente suele responder lo que sucedió dentro de una carrera. Eso es útil, pero no es suficiente cuando un agente delega el trabajo, sale, reinicia o espera a otro agente. La solución práctica es un recibo de remisión duradero : un pequeño registro escrito fuera de cualquiera de los dos procesos que indica quién aceptó el trabajo, qué resultado se espera y qué pruebas lo cerrarán. Mantenga rastros para el depuración. Añadir recibos de continuidad. Un rastro puede demostrar que una herramienta de entrega ha sido devuelta con éxito; el recibo informa al operador si el destinatario aceptó la tarea y si el artefacto prometido fue verificado posteriormente. La respuesta corta: observe el límite, no sólo la carrera Una entrega es saludable sólo cuando se pueden distinguir cuatro eventos diferentes: 1. el remitente delegó una tarea limitada; 2. el beneficiario reconoció la misma tarea; 3. se registró un progreso útil o una espera legítima; 4. se verificó el resultado esperado. Estos eventos pueden ocurrir en diferentes procesos y rastros. Pueden separarse por un retraso en la cola, un reinicio del anfitrión o una aprobación humana. Tratarlos como un solo espacio de memoria crea una frágil dependencia: el contexto que explica el trabajo puede desaparecer con el proceso. OpenTelemetry describe la propagación del contexto como el mecanismo que permite que las extensiones de diferentes procesos se ensamblen en un rastro. También proporciona enlaces de extensión para operaciones asíncronas causalmente relacionadas en las que el trabajo posterior no puede ser una simple extensión infantil. Eso resuelve la correlación. No define las reglas de promesa, aceptación o verificación de resultados de su solicitud. El recibo llena ese vacío. Es deliberadamente más pequeño que una transcripción y más explícito que una línea de registro. Donde un rastro ordinario deja de ayudar Consideremos a un agente de investigación que entrega la tarea de comprobar la fuente a un segundo trabajador. El remitente registra un exitoso handoff span y salidas. Diez minutos después el trabajador comienza un nuevo proceso, encuentra una fuente inaccesible, y espera la aprobación para usar una alternativa. Tres estados ahora pueden parecer engañosamente similares: la tarea sigue en fila y nunca ha sido aceptada; el trabajador lo aceptó y está esperando legítimamente; el trabajador completó una orden pero nunca presentó el expediente de pruebas solicitado. El espacio que envolvió la entrega no puede decidir entre ellos. Su final exitoso significa que la operación de entrega regresó sin un error. OpenTelemetry es explícito que el estado de espacio describe la operación rastreada por ese espacio. No es prueba de que exista un resultado comercial posterior. El SDK OpenAI Agents ilustra el mismo límite desde otra dirección. Su registros de seguimiento incorporados de carreras, llamadas a herramientas, entregas, barandillas y eventos personalizados. Un group id puede asociar múltiples rastros, y un handoff span puede mostrar delegación. El SDK también señala que las exportaciones de rastro se realizan en lotes y que pueden requerir una eliminación explícita cuando se trata de entrega inmediata. El seguimiento rico mejora la evidencia disponible para la depuración; todavía necesita una regla externa para la inspección aprobada. Esta es la razón por la que la observabilidad del agente no debe colapsar la finalización del comando en la finalización del resultado. Un contrato de recibo mínimo de entrega Almacenar un registro solo de apéndice por transición de estado. El almacenamiento puede ser una tabla de base de datos, un registro de cola duradero o un archivo NDJSON en un solo host. La propiedad importante es que ninguno de los procesos participantes posee la única copia. Aquí hay una forma compacta del evento: Seis campos tienen la mayor parte del valor: operation id es la identidad duradera del trabajo visible al usuario. Sobrevive a los retiros y reinicios. handoff id identifica un intento de delegación. Un nuevo intento obtiene una nueva identificación en lugar de sobrescribir la historia. event es uno de los delegated , accepted , progress , waiting , completed o outcome verified . expected artifact nombra un objetivo de verificación determinista. También puede nombrar una prueba, condición de API o decisión de revisión. trace id remite a la telemetría detallada sin hacer que el recibo dependa de dicha telemetría. reason explica una falta de espera, rechazo o verificación en términos operativos limitados. No incluya instrucciones, credenciales, resultados de modelos o cargas útiles de herramientas en bruto en este registro. Un recibo es un índice y una máquina de estado, no un segundo backend de rastreo. El defecto razonable son las transiciones de sólo apéndice más un estado de corriente derivado. La actualización de una fila mutable es tentadora, pero destruye la evidencia necesaria para distinguir un reconocimiento retrasado de una falta. Reproducir los casos de fallas antes de elegir las alertas El dispositivo de acompañamiento de este artículo contiene cuatro operaciones: una entrega verificada, una delegación no reconocida, una espera legítima de aprobación y una finalización falsa sin artefacto verificado. El clasificador es intencionalmente determinista. Ejecutar con: El resultado esperado es: Dos observaciones quedan fuera de esta pequeña prueba. En primer lugar, la latencia de reconocimiento y la verificación de resultados son independientes. op 101 puede ser aceptado rápidamente y aún fallar más tarde; op 102 ya es poco saludable antes de que comience cualquier llamada de modelo o ejecución de herramientas. Un tablero de control centrado en la pista que comienza en la ejecución del destinatario no verá al huérfano. En segundo lugar, la espera necesita una dependencia declarada. op 103 no tiene ningún progreso reciente, pero tratarlo como atascado sería incorrecto porque el recibo nombra la aprobación que necesita. La ausencia de actividad sólo se hace accionable cuando se combina con el estado y la expectativa. El límite de reconocimiento de 120 segundos en el dispositivo es un ejemplo, no un umbral universal. Configure desde la latencia de entrega observada de las colas y la urgencia de la tarea. El trabajo en lote puede tolerar minutos; una entrega interactiva puede tolerar segundos. La invariante es la transición, no el número. Preserva la causalidad sin convertir los metadatos en una fuga Utilice la identificación de rastreo como indicador y propague solo identificadores que los trabajadores de abajo realmente necesitan. OpenTelemetrys Orientación de equipaje advierte que el equipaje se envía comúnmente en encabezados HTTP, puede llegar a terceros no deseados y no tiene controles de integridad incorporados. Eso hace que los objetivos en bruto, el texto del cliente, los caminos del sistema de archivos y las credenciales sean valores de propagación especialmente pobres. Un límite más seguro se ve así: propagar un operation id opaco y un handoff id opaco; crear un enlace de extensión desde el rastro receptor hasta el rastro delegador cuando el tiempo de ejecución lo apoye; mantener el artefacto esperado y el estado de aprobación en un almacenamiento fiable y duradero; solucionar los identificadores en contexto sensible sólo dentro del límite del host autorizado; autenticar a los escritores de recibos, porque los metadatos de correlación no son prueba de identidad. Hay una compensación. Un recibo mínimo no puede explicar por qué un modelo eligió una herramienta o reconstruir toda una conversación. Eso es intencional. Utilice rastros y registros para una investigación detallada, sujeto a sus reglas de retención y privacidad. Utilice recibos para responder confiablemente a una pregunta operativa más pequeña: ¿se movió la responsabilidad y se observó el resultado prometido? Convertir los recibos en estados del operador Evite un solo estado rojo o verde. El historial de recibos apoya a cinco estados con diferentes respuestas: Working : aceptado con recientes avances útiles. No lo interrumpas. Waiting : una dependencia externa o una decisión humana nombrada está pendiente. Envía la solicitud en lugar de volver a intentarlo. Stuck : aceptado, no esperando y no hay progresos útiles dentro de la ventana de pruebas de la tarea. Prepárese para una recuperación limitada. Uncertain : los registros no están de acuerdo, el autor no es de confianza o las pruebas requeridas no están disponibles. Pregunte antes de actuar. Resultado fallido : ejecución completada, pero la verificación del artefacto falló o nunca ocurrió. Reabre el resultado, no todo el rastro. El límite de recuperación es importante. Una entrega huérfana puede justificar la reaprobación si la acción es impotente y se conoce el límite de retoma. Una entrega de espera no debe ser retomada simplemente porque haya expirado un temporizador. Un estado de falso éxito debe ejecutar el verificador faltante o solicitar el artefacto faltante; reproducir todo el agente puede duplicar los efectos secundarios. Para cada respuesta automática, registre la autoridad, los intentos máximos, el costo o el límite de tiempo, y la evidencia que marcará la recuperación como exitosa. El comando de retiro salió de cero no es suficiente cuando la promesa original fue un informe publicado, un cambio fusionado o un mensaje entregado. Lo que esto significa para Sidewisp Este patrón de recepción coincide con las preguntas operativas que Sidewisp está diseñando para aclarar: si un agente está trabajando, esperando, atrapado, incierto o perdiendo su resultado prometido. También respeta un límite de producto necesario: el diagnóstico se realiza antes que cualquier recuperación, y las acciones consecuentes requieren una autoridad explícita. Sidewisp se encuentra actualmente en versión preliminar privada. Su sitio público y el sistema de artículos están en vivo, mientras que la recopilación de agentes de producción, los adaptadores de tiempo de ejecución y la recuperación automática generalmente no se envían. El patrón anterior es, por lo tanto, un diseño neutro en el tiempo de ejecución que puede implementar y probar hoy, no una afirmación de que Sidewisp ya recoge estos recibos. Si las entregas cruzadas son donde sus agentes se vuelven opacos, únete a la vista previa privada y describa el tiempo de ejecución, almacenamiento de recibos y límite de aprobación que necesita. Esa evidencia es más útil que una solicitud genérica de más huellas.