AI Observabilidad: Construir un contrato de señal de cuatro capas

La observabilidad de AI no es una categoría de tablero de instrumentos. Es la capacidad de responder a cuatro preguntas diferentes con pruebas: ¿Se esperaba el trabajo? ¿Qué fue realmente? ¿Está esperando una dependencia legítima? ¿Existió el resultado previsto y se superó la verificación? Una pila que responde sólo a la segunda pregunta puede producir hermosos rastros mientras que un agente programado nunca comienza, una aprobación humana se queda desapercibida, o una carrera exitosa no deja ningún resultado. Por lo tanto, el defecto práctico es un contrato de señal de cuatro capas: agenda, ejecución, dependencia y resultado . Mantenga la latencia del modelo, tokens, errores, llamadas a herramientas y períodos, pero no los confundan con todo el contrato. Este artículo prueba las reglas de un pequeño dispositivo NDJSON y le da una auditoría que puede adaptar antes de comprar o utilizar otra plataforma. Tratar la observabilidad de AI como un problema de cobertura Los resultados de búsqueda de la observabilidad de AI mezclan varias preocupaciones legítimas: calidad del modelo, deriva de datos, rendimiento de la GPU y la aplicación, rastros de agentes, seguridad, gobernanza y costo. Esa amplitud es la razón por la que tenemos observabilidad es difícil de evaluar. Dos equipos pueden usar la misma frase mientras recopilan evidencia desarticulada. Para un agente que realice un trabajo programado o delegado, utilice el trabajo previsto como unidad de análisis. Luego requiere una capa para cada pregunta que pueda cambiar el veredicto operativo. Capa Evidencias mínimas El fracaso que puede exponer Programación tiempo esperado, fecha límite, hora de inicio, identidad del horario La carrera nunca comenzó. Ejecución ID de ejecución, paso o período, resultado de la herramienta, estado del terminal, clase de error la carrera estancada, en bucle, retomada o fallida Dependencia Estado de espera explícito, tipo de dependencia, aprobación o referencia del sistema externo la espera legítima fue etiquetada erróneamente como atascada El resultado Identidad del artefacto o efecto secundario, control determinístico, tiempo de verificación La ejecución dijo éxito pero el trabajo estaba ausente o incorrecto Estas capas no son cuatro productos de los vendedores. Son cuatro juntas alrededor de una identificación de ejecución estable. Un backend de rastro puede contener la mayoría de los eventos de ejecución. Un programador puede tener las horas esperadas. Un sistema de aprobación puede poseer pruebas de espera. El destino en sí mismo almacenamiento de objetos, un repositorio, una API de venta de entradas, una base de datos por lo general posee la mayor verificación de resultados. Este marco también mantiene el seguimiento y la evaluación separados sin forzarlos a separarse. Una puntuación de calidad basada en rubricas puede ser un verificador de resultados cuando no existe una verificación determinista. No debe reemplazar silenciosamente un hash de archivo, resultado de prueba, recuento de filas o recibo de API cuando uno de ellos esté disponible. ¿Por qué un rastro completo puede perder el incidente? Los estándares de rastreo están mejorando rápidamente. En el caso de los compromisos de 74fd2e0 , el modelo de cobertura y las extensiones de agentes de Convenciones semánticas generativas de OpenTelemetry AI, las métricas, los eventos, las excepciones, las convenciones específicas del proveedor y el MCP. El documento marca las convenciones de GenAI como Development , un límite de versión importante cuando se diseñan esquemas de larga duración. La especificación de la gama de agentes define operaciones como create agent , invoke agent , invoke workflow , plan y execute tool . También contiene atributos útiles como gen ai.operation.name , gen ai.agent.name y error.type requerido condicionalmente; ver el Fuente de extensión del agente fijado. Eso es una fuerte evidencia de ejecución. Indica al investigador qué operación ocurrió, cómo se relacionan los períodos, cuánto tiempo tardaron y si un error reportado terminó la operación. El seguimiento de marcos puede ser aún más rico. El Documentación de seguimiento de SDK de OpenAI Agents dice que su rastro predeterminado cubre las invocaciones de corredores, las distancias de tareas y giras, los agentes, las generaciones, las herramientas de funciones, las barandillas y las entregas. También admite extensiones personalizadas y procesadores. Eso hace posible adjuntar pruebas comerciales faltantes. Sin embargo, ni un período terminado ni un terminal ok establecen que se esperaba una carrera programada en primer lugar. Tampoco demuestra que weekly report.pdf exista, que tenga el nuevo período de presentación de informes y que haya pasado por un analizador. La ausencia no es un defecto en el rastreo. Se trata de un límite entre la telemetría de ejecución y la evidencia de resultados operacionales. Ese límite es falsificable: tomar dos carreras con eventos de ejecución idénticos y exitosos, añadir un evento outcome verified a sólo uno, y el veredicto operativo debe diferir. Si su alerta actual da a ambas carreras el mismo estado verde, no puede detectar el falso éxito. Realizar una auditoría de cuatro capas en un dispositivo fijo El dispositivo de acompañamiento contiene cuatro carreras observadas en 2026 07 25T02:42:00Z : run alpha inicia, llama su herramienta de informe, termina y registra un artefacto verificado; run beta tiene la misma forma de ejecución exitosa, pero ningún resultado verificado; run gamma espera explícitamente la aprobación de approve 42 ; run delta superará su plazo previsto sin un evento de inicio. Ejecutar la auditoría con Node.js 20 o más reciente: El clasificador devuelve una carrera en cada estado: El código utiliza una orden de decisión aburrida deliberadamente. Un resultado verificado gana. Una espera explícita con una razón y una referencia de aprobación está esperando, no atrapado. Una carrera que nunca comenzó antes de su fecha límite se pierde. Una carrera terminada sin pruebas de resultado es un falso éxito. Una carrera iniciada más allá de su fecha límite está atascada. Todo lo demás sigue funcionando en lugar de ser promovido a ser saludable. Este es un experimento, no un punto de referencia. Cuatro casos hechos a mano no pueden estimar las tasas de error de producción, y un clasificador real necesita manejo de eventos duplicados, tolerancias a la desviación del reloj, resultados de llegada tardía y plazos por trabajo. La fijación es útil porque cada veredicto es inspectable y cambiar un evento cambia un resultado. Preserva la espera como su propio estado Un campo binario sano/no sano destruye la información en el momento en que el operador la necesita. Considere run gamma : el proceso no está progresando, sin embargo, reiniciarlo sería el error por defecto. Tiene una dependencia explícita de la aprobación. La acción correcta es presentar la solicitud a la persona adecuada, manteniendo su alcance, edad y límites de autoridad. Almacenar al menos: Utilice el mismo enfoque para los tiempos de restablecimiento de los límites de tasa, las identificaciones de trabajo externas, las ventanas de mantenimiento y las llegadas de datos upstream. Un mensaje de texto libre como still waiting es una prueba débil: es difícil de encaminar, expirar o correlacionar. Una dependencia de tipografía más una referencia opaca admite una respuesta limitada sin copiar el contenido secreto, rápido o de aprobación en telemetría. La actividad es igualmente fácil de sobrevalorar. Las llamadas repetidas a las herramientas muestran que un proceso está ocupado; sólo los deltas en estado o resultado muestran un progreso útil. Por lo tanto, un contador de repetición pertenece al lado del último tiempo de cambio significativo, no al lado de un sello de tiempo genérico last event que un bucle puede actualizar para siempre. Hacer que el resultado de la verificación sea nativo del destino El verificador más fuerte vive donde el trabajo debería haber aterrizado. Para un archivo, graba una clave de objeto estable, tamaño, digestación y resultado del parser. Para una solicitud de extracción, registre el repositorio, el número de relaciones públicas, la rama objetivo y la conclusión de la verificación requerida. Para una actualización del CRM, registre la identificación de entidad no secreta, la transición de campo esperada y el resultado de lectura después de escritura. No ponga el producto crudo en cada rastro. Almacenar la menor evidencia necesaria para repetir el chequeo. La documentación de OpenAI Agents SDK advierte que los intervalos de generación y función pueden contener entradas y salidas sensibles, y describe los controles para desactivar esa captura. Aplique el mismo principio a sus eventos personalizados: los identificadores y digestos suelen ser más seguros que las instrucciones, respuestas, credenciales, caminos locales absolutos o contenido del cliente. La verificación de los resultados también requiere frescura. Un archivo dejado por la carrera de ayer no es prueba de que la carrera de hoy haya tenido éxito. Unirse al artefacto a la ejecución actual a través de un ID de ejecución, un período de informes esperado, una ventana de creación o un digesto calculado después del tiempo de inicio actual. Hay una compensación. Los controles nativos de destino añaden trabajo de integración y pueden fallar de forma independiente. Tratar un verificador no disponible como unknown , no saludable y no falló automáticamente. Superfície las pruebas faltantes, su última comprobación exitosa, y la confianza del veredicto resultante. Herramientas de auditoría contra el contrato antes de comparar características Una evaluación útil del producto comienza con cuatro filas, no una cuadrícula de logotipo. Para cada pila de candidatos, pregunte dónde se origina cada capa, cómo se une a la carrera, cuánto tiempo se retiene y qué consulta prueba cobertura. 1. ¿Puede importar o derivar las rutas esperadas, incluidos el fuso horario y la fecha límite? 2. ¿Puede rastrear el modelo, la herramienta, la entrega, la repetición y los eventos de error sin requerir captura de carga útil sensible? 3. ¿Puede representar la espera con una dependencia tipificada y un objetivo de escalada? 4. ¿Puede ingerir o vincular recibos deterministas de resultados del destino? 5. ¿Puede distinguir entre evidencia no disponible y un resultado saludable? 6. ¿Puedes exportar los datos a través de un formato abierto o API si la herramienta cambia? No rechace una herramienta de rastreo enfocada porque carece de cronograma o semántica de resultados. Combínalo con las fuentes que faltan si las articulaciones son confiables. Rechace la arquitectura cuando no pueda representar la distinción que necesita, oculte los datos faltantes detrás del estado verde o requiera contenido sensible en bruto para controles de salud rutinarios. El contrato de cuatro capas resuelve la pregunta original: la observabilidad de AI para los agentes operativos es completa solo cuando puede explicar la expectativa, la ejecución, la dependencia y el resultado verificado por separado. Las huellas son evidencia esencial, pero son una sola capa. Sidewisp se encuentra actualmente en versión preliminar privada. Su papel previsto es una capa de salud junto con los tiempos de ejecución existentes, con pruebas y límites de autoridad humana; los adaptadores de monitoreo de producción y recuperación generalmente no se envían hoy en día. Si este contrato de señal coincide con los fallos que necesita para detectar, puede unirse a la lista de acceso temprano sin reemplazar su tiempo de ejecución o modelo de puerta de enlace.