Observabilidad del agente AI: huellas de muestras, conservación de pruebas de salud

La observabilidad del agente AI no debe requerir la retención de todos los rastros, pero nunca debe permitir que la toma de muestras de rastros decida si existe un evento de salud crítico. Muestre el camino de diagnóstico pesado cuando el volumen o el costo lo exija. Enviar recibos de salud compactos y tipografados fallas de resultados, espera de aprobación, fallas de herramientas, tiempo de ejecución inaccesible y falta de entrega a través de una ruta separada con sus propios controles de entrega y frescura. Esa división resuelve un problema específico. Un rastro es una excelente evidencia de por qué una carrera se comportó como lo hizo. No es el único lugar del que un operador puede saber que falta el trabajo esperado. Un tiempo de ejecución que no se pueda alcanzar no puede emitir ningún rastro. Una sesión que espera correctamente la aprobación puede no tener un lapso de error. Una ejecución puede terminar con extensas OK mientras que un verificador externo encuentra que el archivo solicitado no existe. Por lo tanto, la imposición razonable es dos políticas de retención, no una muestra inteligente: aplicar muestras de cabeza o cola a los rastros de diagnóstico, y conservar todos los recibos médicos obligatorios durante un período más corto y claramente limitado. Únete a los dos registros con una identificación de ejecución estable cuando haya un rastro disponible. No almacenes las instrucciones crudas o las cargas útiles de herramientas sin restricciones sólo para mantener el veredicto de salud. Trazas de muestras; guardar recibos de salud Documentación de muestreo de OpenTelemetry utiliza una definición estrecha y útil: un rastro recogido en la muestra es procesado y exportado; un rastro no recogido en la muestra no es procesado ni exportado. El muestreo de la cabeza se decide temprano, generalmente a partir de una identificación de rastro y el porcentaje deseado, sin inspeccionar todo el rastro. El muestreo de cola espera por más o toda la pista y puede mantener las huellas por error, latencia, atributos u otros criterios. Esos mecanismos optimizan una población de huellas. Una política de salud de los agentes responde a una pregunta diferente: ¿qué observaciones se requieren para decidir si el trabajo es saludable, espera, atascado, inaccesible o falsamente completo? Registro Propósito Muestreo por defecto Ejemplos de pruebas Traza de diagnóstico Explicar la ejecución y el defecto de una ejecución seleccionada Muestra justificada por volumen y coste Duración, duración de la herramienta, llamadas de modelo, trayectoria de error Recibo de salud Preservar un hecho operativo que cambie el estado Mantenga todas las clases obligatorias el predicado de resultado falló, se requiere aprobación, el latido del corazón se perdió Métrica agregada Las tasas de medición y la capacidad Cuando sea posible, agregado antes del almacenamiento tasa de retiro, profundidad de la cola, pérdida de recibo Carga útil sensible Reproducir contenido sólo bajo una autoridad independiente No cobrar por defecto Pronto, argumentos de herramientas, respuesta en bruto La distinción no hace que el muestreo de cola sea inútil. Una regla de cola que siempre mantenga huellas que contienen un ERROR es valiosa. Todavía no puede mantener un rastro que nunca llegó, y no puede inferir que un rastro que parezca exitoso no haya logrado una verificación externa de entregabilidad. La documentación del procesador de muestreo de cola del colector es explícita sobre un requisito previo importante: todos los espacios de un rastro deben llegar a la misma instancia del colector para una decisión efectiva. Trata ese requisito previo como un límite, no como un defecto. El muestreo de rastro se realiza después de que exista evidencia de rastro. Los recibos de salud también deben cubrir las fallas fuera de ese camino. Definir el contrato de salud sin muestra Mantenga el recibo lo suficientemente pequeño como para que retener todo tipo obligatorio sea ordinario, no heroico. Un registro útil necesita identidad, semántica, frescura de la evidencia y fuenteno una transcripción: Los dos relojes importan. El estable Modelo de datos de registros de OpenTelemetry define a Timestamp como el momento en que ocurrió un evento en la fuente y a ObservedTimestamp como el momento en que el sistema de recogida lo observó. Guarde ambas semánticas en un recibo de salud. Un recibo retrasado puede describir aún un fallo real, pero su retraso en la entrega y la edad de prueba deben permanecer visibles. Utilice un registro corto de tipo obligatorio propiedad del flujo de trabajo, no del proveedor de almacenamiento. Un conjunto de comienzos para las operaciones de agentes podría ser: outcome failed : un verificador específico de la tarea rechazó el resultado prometido; approval wait : la carrera tiene una dependencia humana tipificada y un propietario; tool error : una operación requerida de la herramienta falló después de su política de retoma limitada; runtime unreachable : un observador externo no pudo alcanzar el tiempo de ejecución en el plazo previsto; missing deliverable : la carrera declarada terminada pero el artefacto esperado ausente. El productor es parte del contrato. Un verificador de resultados puede emitir outcome failed ; un adaptador de tiempo de ejecución puede emitir approval wait ; un programador externo o un observador del ritmo cardíaco deben emitir runtime unreachable . Requerir un tiempo de ejecución inaccesible para informar su propia inaccesividad es un diseño circular. Para cada recibo, se aplican cuatro controles antes de que cambie la salud: 1. Desduplicar por receipt id o una clave de evento estable. 2. Valida el schema version , el kind , el run id y la autoridad del productor. 3. Compare occurred at y observed at con los límites de frescura por especie. 4. Actualizar la salud por prioridad explícita, preservando el unknown cuando faltan las pruebas requeridas. No permita que un recibo autorice una acción irreversible. Puede abrir un número, dirigir una espera o preparar una respuesta limitada. La recuperación todavía necesita el límite de aprobación pertinente y una nueva observación que demuestre un progreso útil o el resultado esperado. Reproduzca la decisión de retención El dispositivo conservado contiene cuarenta carreras sintéticas y cinco casos críticos deliberadamente diferentes. Determinista diez por ciento de muestreo de cabeza hashes cada identificación de rastro. La política de cola mantiene rastros cuyo estado de extensión es ERROR . La tercera póliza retiene todos los recibos de salud registrados. Ejecutar con: El resultado fijo es: La muestra de cabeza mantiene 1, 3, 10, 25, 39 . La carrera 25 es el caso de error de herramienta, así que otros cuatro casos críticos están ausentes de su muestra. La regla de cola solo ERROR también mantiene el error de la herramienta. Se pierde un fallo de resultado llevado por un rastro OK , una espera de aprobación llevado por un rastro UNSET , un producto de entrega perdido llevado por un rastro OK , y el tiempo de ejecución inaccesible que no produjo rastro. Este es un test de política, no un resultado estadístico. Las cinco carreras críticas se distribuyeron deliberadamente por lo que la repetición contiene tanto un caso retenido como casos perdidos. No afirma que el muestreo del diez por ciento generalmente capture una quinta parte de los incidentes, ni que estos cinco tipos de eventos tengan la misma frecuencia. Cambia las identificaciones de rastreo, la regla de muestreo o el accesorio y los recuentos pueden cambiar. Lo que no debe cambiar es el criterio de aceptación: todo tipo de recibo obligatorio debe sobrevivir a la trayectoria de salud, incluido un caso sin rastro. Añadir un nuevo veredicto operativo sólo después de añadir su productor, esquema, fijación, regla de retención y monitor de pérdidas. Monitorear el camino de recepción y la retención de la conexión Un canal sin muestras aún puede fallar. El desbordamiento de colas, el rechazo de esquemas, las credenciales vencidas, errores de reloj, errores de productor y interrupciones de almacenamiento pueden hacer desaparecer la evidencia de salud. Monitorear el canal con señales que no dependen únicamente del canal en sí: cuentas de recepción esperadas por productor y por espacio de flujo de trabajo; la frecuencia cardíaca del productor y el último tiempo de entrega exitoso; Contadores de recepción rechazados, duplicados y retrasados; capacidad de cola de recogedores y contadores de goteo; canarios periódicos de extremo a extremo con una identificación de recibo conocida; la conciliación entre las carreras programadas, las finalizaciones declaradas y los resultados recibidos. La ausencia no debe volverse verde. Si un verificador de resultados no ha informado de una carrera que lo requiera, marque la señal de resultado no disponible o incierta. Si el propio observador externo está obsoleto, no pretenda que el tiempo de ejecución sea alcanzable. Una capa de salud debe exponer brechas en sus propias pruebas. Mantener cada recibo de salud tampoco significa conservarlo para siempre. Elegir la retención de la decisión de operación: el tiempo suficiente para investigar, reconciliar pruebas tardías y auditar una intervención aprobada. Cuentan más antiguos cuando ya no se necesitan registros individuales. Eliminar o hashar las rutas locales, el contenido del usuario, el texto de llamada, las cargas útiles de herramientas y el material de credenciales antes de exportar. Almacenar una clase de error digest o delimitado cuando apoya la decisión. La compensación es explícita. Un canal obligatorio compacto cuesta ingeniería adicional y duplica una pequeña cantidad de metadatos de rastro. A cambio, los controles de volumen de rastro no pueden borrar silenciosamente los hechos que conducen a la salud. El muestreo de cola sigue siendo útil para seleccionar detalles de diagnóstico en torno a errores conocidos; un recibo obligatorio le da el incidente incluso cuando el estado de rastreo es exitoso, incompleto o ausente. Antes de adoptar el patrón, reproduce casos reales desinfectados de un flujo de trabajo: finalización saludable, falso éxito, espera de aprobación, falla de herramienta, latido cardíaco perdido y apagón del colector. Verifique ambos lados. La política de seguimiento debe cumplir con su objetivo de costes, y la política de recepción debe conservar todos los veredictos requeridos sin recoger cargas útiles sensibles. La dirección del producto de Sidewisp es una capa de salud en torno a los tiempos de funcionamiento de los agentes existentes: evidencia, frescura, progreso útil, estados de espera, resultados verificados y límites de aprobación explícitos. No es un tiempo de ejecución de reemplazo, puerta de entrada obligatoria, producto de rastreo crudo o fijación autónoma. Sidewisp se encuentra actualmente en versión preliminar privada. El sitio público y el sistema de artículos están en vivo, mientras que la recopilación de agentes de producción salud, adaptadores de tiempo de ejecución, administración de cron, análisis de costos de tokens y recuperación generalmente no se envían. Si este límite de retención de pruebas coincide con los modos de falla que necesita para operar, puede unirse a la vista previa privada y describir los tipos de tiempo de ejecución y recibo que importan. Referencias primarias Telemetría abierta: muestreo terminología de muestreo de rastro, muestreo de cabeza y cola y compensaciones operativas; revisado el 26 de julio de 2026. OpenTelemetry Collector Contrib: Procesador de muestreo de cola agrupación de rastros, tipos de políticas, afinidad del colector, rastros caídos y períodos tardíos; revisado el 26 de julio de 2026. OpenTelemetry: Modelo de datos de registros semántica estable Timestamp y ObservedTimestamp ; revisado el 26 de julio de 2026.