Observabilidad del agente AI: Medir el progreso útil, no sólo la actividad

La observabilidad del agente AI es la capacidad de explicar lo que hizo un agente a partir de evidencia externa: rastros, registros, métricas, eventos de herramientas, llamadas de modelo, latencia, tokens y costo. Esa prueba es necesaria, pero no es un veredicto de salud. Un rastreo puede ser completo mientras el archivo solicitado no esté disponible. Una llamada de herramienta puede tener éxito mientras el agente repite el mismo paso. Una carrera tranquila puede estar correctamente esperando la aprobación. La respuesta práctica es mantener la telemetría y añadir una pequeña capa de decisión por encima de ella. Para cada tarea, observe cinco cosas juntas: accesibilidad, delta de progreso útil, dependencias declaradas, verificaciones deterministas de resultados y costo en la misma ventana. Evaluarlos en ese orden antes de alertar o recuperar algo. Esta guía convierte esa regla en una fijación ejecutable de cinco casos. Es intencionalmente neutro en el tiempo de ejecución: el mismo razonamiento puede estar por encima de los intervalos de OpenTelemetry, los eventos de Claude Code, un registro de ejecución OpenClaw o un agente personalizado. Un rastro prueba lo que salió, no lo que cambió La actual Convenciones semánticas de OpenTelemetry para los espacios de agentes de GenAI define operaciones para crear y invocar agentes, invocando flujos de trabajo, planificación y ejecución de herramientas. El documento está marcado Development , lo que importa cuando se diseña un esquema de larga duración: utilizar las convenciones donde se ajusten, pero aislar los atributos sensibles a la versión detrás de su propia capa de normalización. La telemetría de tiempo de ejecución ya se está detallando. Documentación de seguimiento del Código Claude describe métricas, eventos y rastros distribuidos beta. Su árbol de rastreo puede incluir una interacción, solicitudes de modelo, llamadas a herramientas, tiempo bloqueado en una decisión del usuario y ejecución de herramientas. Los campos documentados incluyen duración, tokens, costo estimado, tamaño del resultado de la herramienta y success . Estos campos responden a preguntas valiosas: ¿Reaccionó el tiempo de ejecución? ¿Qué modelo y herramientas funcionaron? ¿Un cuerpo de herramientas específico devolvió un error? ¿Cuánto tiempo tardó en esperar el permiso y la ejecución? ¿Cuántos tokens y dólares consumió la carrera? No definen el éxito de tu tarea. Un comando de shell que devuelva el código de salida 0 demuestra que el comando se completó bajo su propio contrato. No demuestra que un artículo sea público, que un mapa de sitio contenga su URL, que una solicitud de extracción pase CI o que un registro de clientes haya llegado al sistema previsto. Las aplicaciones pueden agregar esos controles, pero un campo genérico de herramientas de éxito no puede inventarlos. Por lo tanto, la actividad y el progreso pueden avanzar en direcciones opuestas. Diecinueve llamadas de herramienta exitosas sin delta de salida pueden ser un bucle. Dos llamadas de herramientas seguidas de silencio pueden ser una espera saludable para un crítico. Un mensaje final que dice done puede ser un falso éxito si el artefacto prometido está ausente. Construir una ventana de salud de cinco señales Seleccione una ventana de observación específica de la tarea antes de ver el resultado. Cinco minutos pueden adaptarse a una pequeña edición de código; una hora puede ser razonable para un trabajo de investigación programado. Evite un umbral global que etiquete cada operación larga como atascada. Dentro de esa ventana, recoger cinco señales: Signales Evidencias mínimas Lo que impide Accesividad edad de la frecuencia cardíaca, respuesta al proceso/sesión, o recibo de ejecución del programador Tratar un tiempo de ejecución inalcanzable como un fallo de razonamiento Un progreso útil un delta monótono específico de la tarea confundir actividad repetida con movimiento Dependencia el motivo de espera, el propietario y el tiempo de entrega reutilizar un trabajo que necesite legítimamente una persona o un sistema externo El resultado predicado determinista para el resultado prometido aceptación de un mensaje de finalización sin entregable El coste fichas, llamadas, tiempo o dinero en la misma ventana Ignorando costosos retos que no crean progreso Los progresos útiles deben ser concretos. Para un agente de codificación podría ser un resultado de prueba cambiado, un nuevo compromiso o un número reducido de pruebas fallidasno líneas emitidas a una terminal. Para una agencia editorial podría ser un ID de proyecto de CMS, luego una API pública, luego una URL en vivo en el mapa del sitio. Para un agente de soporte podría ser una transición validada del boleto en lugar de otra respuesta modelo. Prefiere un predicado de resultado determinista cuando existe uno: Utilice un evaluador sólo cuando el resultado no pueda ser verificado mecánicamente, y guarde su rúbrica, versión e incertidumbre. No recoja la cadena oculta de pensamiento como un atajo. Las selecciones de herramientas, los planes explícitos, las salidas, los sellos de tiempo y los cambios de estado proporcionan evidencia operativa sin requerir razonamiento privado. El costo pertenece a la ventana, pero el costo por sí solo no es la salud. Se pueden esperar diez dólares que produzcan una migración verificada. Cincuenta centavos gastados repitiendo una búsqueda sin cambios puede ser la anomalía. Una medida derivada útil es: El max evita la división por cero; no hace que el cero progrese saludable. Alerta por separado cuando progress delta == 0 y el costo continúen aumentando. Clasifique el trabajo, la espera, el atrapado, el inalcanzable y el falso éxito La decisión de orden es importante. Compruebe la accesibilidad primero. Entonces honra una dependencia explícita que todavía está dentro de su debido tiempo. Compruebe una finalización reclamada con el predicado de resultados antes de aceptarla. Sólo entonces interpretar el progreso y el tiempo transcurrido. Aquí está una fijación completa de NDJSON. Guarde como health window fixture.ndjson : ejecuta este clasificador con Node.js: Producción esperada: La fijación hace que la tesis sea falsificable. Una regla ingenua como tool calls 0 marca tanto a run stuck como a run false success como activa. Una regla basada únicamente en el silencio marca a run waiting como insalubre. La regla de los cinco signos los separa porque conserva la dependencia y la evidencia del resultado. El ejemplo es un esqueleto de decisión, no un modelo de puntuación universal. El código de producción también necesita frescura, confianza, identidad de origen y una ruta uncertain cuando las señales no están de acuerdo. Mapa de cada estado a una respuesta limitada La clasificación existe para evitar la acción equivocada, no para decorar un tablero. El Estado Se requieren pruebas Respuesta por defecto Trabajo reciente accesibilidad y progreso positivo delta dejarlo en paz; muestra otra vez más tarde Esperando Dependencia tipográfica, propietario y tiempo de vencimiento no expirado notificar a la persona responsable una vez; no vuelva a intentar el paso bloqueado Estoy atrapado. accesible, más allá de su ventana, sin dependencia, sin progreso delta inspeccionar el paso repetitivo; preparar un retiro reversible o empuje dentro de los límites Falso éxito finalización declarada, resultado determinista fallido reabrir la tarea y reportar el predicado faltante; no lo llamen completo No alcanzable latido cardíaco obsoleto o contacto fallido en el tiempo de ejecución verifique la disponibilidad del host/tiempo de ejecución antes de cambiar las instrucciones No está seguro pruebas faltantes o contradictorias Recoger la señal ausente o pedir; no automatizar la recuperación Esta separación tiene un precedente útil fuera de los sistemas AI. Kubernetes distingue las sondas de arranque, vitalidad y preparación porque el proceso existe y el servicio debe recibir tráfico son decisiones diferentes. Su documentación también advierte de que las sondas de vida mal diseñadas pueden causar fallos en cascada a través de reinicios innecesarios. La analogía tiene un límite: un agente AI no es un Pod, y el progreso útil depende de la tarea. La lección transferible es más estrecha. No permita que una señal verde o roja ambigua autorice cada intervención. Para la recuperación activa, adjunta límites a la acción: un retraso, no un ciclo de retraso ilimitado; un tiempo y un coste máximos transcurridos; un paso reversible; un límite explícito de aprobación para acciones destructivas o externas; una verificación posterior a la acción del progreso o del resultado. El cumplimiento del comando no es la recuperación. Solo limpie el incidente después de que el estado esperado cambie. El instrumento del contrato, no cada pensamiento Un registro de salud normalizado compacto puede estar junto a sus datos de rastreo existentes: Mantenga las referencias de la evidencia controladas por el acceso y redacte secretos, instrucciones, cargas útiles de herramientas en bruto y rutas locales absolutas a menos que sean estrictamente requeridas. El expediente médico debe indicar lo que se verificó y dónde pueden inspeccionarlo los operadores autorizados; no debe convertirse en una segunda copia de telemetría sensible. Versión cuatro cosas explícitamente: 1. el adaptador de tiempo de ejecución que normalizó las pruebas; 2. la definición del progreso; 3. el predicado de resultado; 4. las normas y los umbrales del clasificador. Sin esas versiones, un comando de prueba cambiado o un entregable cambiado de nombre puede parecer una repentina regresión del agente. Saber dónde se detiene el método La parte difícil es no recoger otro lapso. Está definiendo los progresos útiles y el resultado prometido con honestidad. Algunas tareas no tienen una medida monótona de progreso. Un agente de investigación puede descartar una hipótesis débil y regresar a una etapa anterior; eso puede ser un trabajo valioso incluso si un contador cae. Algunas dependencias no exponen un tiempo de vencimiento fiable. Algunos resultados requieren un juicio más que una suma de comprobación. En esos casos, preserve las pruebas y informe a uncertain . No fabrique precisión con una puntuación de salud universal. También separar los controles de salud en línea de la evaluación fuera de línea. Los conjuntos de datos fuera de línea pueden revelar si una nueva versión de agente es más precisa en casos conocidos. La ventana de salud en vivo responde a una pregunta diferente: ¿esta carrera en particular es alcanzable, se mueve, espera legítimamente, o se pierde su resultado ahora? Por lo general, necesitas ambas cosas. Comience con un flujo de trabajo consecuente. Definir un delta de progreso y un predicado de resultado determinista. Repite casos conocidos de trabajo, espera, atascado, inaccesible y falso éxito. Sólo después de que las clasificaciones coincidan con la realidad, debe depender de ellas una alerta o una acción de recuperación limitada. Sidewisp se encuentra actualmente en versión preliminar privada. Su sitio público y el sistema de artículos están en vivo, pero la colección de agentes de producción salud, adaptadores de tiempo de ejecución y recuperación generalmente no se envían. La dirección del producto es una capa de salud que hace que las pruebas, la frescura, la confianza y los límites de aprobación sean más fáciles de actuar sin reemplazar el tiempo de ejecución del agente. Referencias primarias OpenTelemetry: Convenciones semánticas para los agentes y los espacios de marco de GenAI obtenido el 24 de julio de 2026; estado del documento: Desarrollo. Código de Claude: Seguimiento campos y configuración oficiales de telemetría, obtenidos el 24 de julio de 2026. Kubernetes: vigilancia, preparación y pruebas de inicio propósitos oficiales de la sonda y las advertencias de recuperación, obtenidas el 24 de julio de 2026.