AI Panel de control de agentes: Seis señales que revelan la salud operativa

Un tablero de control de agentes AI debe responder a una pregunta operativa antes de dibujar un gráfico de tokens: ¿Necesita atención ahora esta ejecución? La fila más pequeña útil combina seis señalesfrescura del colector, puntualidad del horario, actividad cardíaca, progreso útil, una dependencia explícita de la espera y verificación de resultados. Aplicarlas en orden fijo para que una espera tranquila de aprobación no se confunda con un puesto y un ciclo de retoma ocupado no se confunda con un trabajo saludable. Mantenga la latencia, las llamadas de modelo, las llamadas de herramientas, tokens, costos y rastros. Son valiosas pruebas de diagnóstico. No demuestran por sí solos que se ha iniciado una carrera programada, que se ha cambiado un informe, que está pendiente una aprobación o que existe el producto prometido. Comience con una fila de estados, no una pared de gráficos El defecto razonable para un panel de control de aplicaciones LLM es la telemetría de servicio. El panel oficial de AI Agents de Sentry, por ejemplo, incluye ejecuciones de agentes, llamadas LLM, duración, uso del modelo, tokens, llamadas a herramientas, errores y detalles de rastreo. Esos paneles ayudan a responder ¿qué pasó dentro de esta ejecución? y ¿qué dependencia se volvió lenta o costosa? Un operador que enfrente veinte carreras autónomas o programadas tiene una decisión previa: ¿cuál abrir? Una fila de estado compacto puede responder: El campo Ejemplo Decisión que apoya Agente y flujo de trabajo researcher / weekly brief ¿Qué trabajo se ve afectado? El Estado waiting:human approval ¿Requiere intervención, ruta o paciencia? Edad de la evidencia collector 14s ago ¿El veredicto se basa en datos nuevos? Últimos avances útiles 3 sources added, 4m ago ¿El resultado se mueve, no sólo el proceso? El próximo evento esperado approval by owner ¿Qué debería pasar después? Verificación de resultados brief.md schema: pending ¿Qué debe ser cierto antes de que sea creíble? El estado es un veredicto derivado de la evidencia, no una copia de la última cadena de estado de la carrera. Deja las pruebas decisivas a su lado. Stuck sin una ventana de progreso es una opinión; No hay cambio en la fuente durante 13 minutos mientras los latidos cardíacos permanecen frescos es inspectable. Esta separación tiene un precedente útil en los sistemas de agentes externos. Kubernetes no desmorona la inicialización, la vitalidad y la preparación en una sonda porque la respuesta correcta es diferente: esperar a la inicialización, reiniciar después de un fallo de vitalidad real, o detener el tráfico de enrutamiento cuando una carga de trabajo no está lista. Su documentación también advierte de que una sonda de vida mal diseñada puede crear fallas en cascada. Un panel de control de agentes tiene el mismo problema de control: una etiqueta es segura sólo cuando implica la siguiente acción correcta. Recoge seis señales con frescura explícita Las seis señales a continuación forman un contrato de salud compacto. Pueden almacenarse como campos en un registro de ejecución o calcularse a partir de eventos de tiempo de ejecución. Cada uno necesita un sello de tiempo, fuente y estado no disponible. 1. Frescura del colector Registrar cuándo el panel alcanzó el tiempo de ejecución o recibió un evento de confianza. Si el colector está obsoleto, clasifique la carrera como unreachable o uncertain antes de interpretar los latidos y el progreso cardíacos más viejos. De lo contrario, un anfitrión desconectado puede parecer pacíficamente ocioso. Utilice un umbral vinculado a la cadencia de recogida. Un límite de frescura de 120 segundos es razonable para un encuestador de un minuto en un ejemplo; es una tontería para un trabajo que se sincroniza cada hora. Muestre tanto la edad observada como el límite configurado. 2. Rápido calendario Almacenar el inicio esperado, inicio real, zona horaria, ventana de gracia y política de cronograma. "No correr" significa poco sin esos campos. Un programador puede ser suspendido, una política de superposición puede omitir intencionalmente un inicio, o una ventana de retraso puede posponer el trabajo perdido. La documentación Temporal's Schedule hace estas distinciones concretas: los horarios se pueden pausar; las políticas de superposición pueden saltar, amortiguar, cancelar, terminar o permitir ejecuciones simultáneas; las ventanas de recuperación deciden qué acciones perdidas se ejecutan después de un apagón. Otros tiempos de ejecución utilizan nombres diferentes, pero el tablero de control todavía necesita conservar la política que explica la brecha. 3. Actividad cardíaca Un latido cardíaco demuestra una actividad reciente de contacto o ejecución. Es útil para separar un tiempo de ejecución inaccesible de un proceso en vivo. No debería adelantar el reloj de progreso. Hacer el evento estrecho: heartbeat at , source , y tal vez una secuencia monótona cada vez mayor. No llames a la carrera saludable simplemente porque esa secuencia continúa cambiando. 4. Un progreso útil Definir un delta específico de la tarea. Un agente codificador puede cambiar la digestión del parche o aumentar el número de pruebas de aprobación. Un agente de investigación puede agregar una fuente primaria accesible o mover un breve de esquema inválido a esquema válido. Un agente de apoyo podría crear el boleto prometido. El registro de progreso necesita last progress at , una pequeña descripción del delta y una versión verificadora. Evite contadores vagos como pasos completados a menos que cada paso haga un mapa del resultado. 5. Dependencia de espera Representan explícitamente la espera legítima: human approval , credential , rate limit , external job , u otra dependencia nombrada. Añadir un propietario, acción solicitada y fecha límite cuando se sepa. Este campo cambia la acción. Una carrera que espera la aprobación necesita un enrutamiento a la persona autorizada, no un reinicio. Es posible que una espera limitada requiera paciencia. Una credencial faltante necesita a un humano que pueda suministrarla sin exponer el secreto al tablero. 6. Verificación de resultados Escribe el predicado de finalización antes de que comience la carrera. Los ejemplos incluyen: report exists, parses, and contains two reachable primary sources ; pull request exists and named checks pass ; ticket ID was returned and can be fetched ; scheduled export contains the expected date partition . Guarde declared complete por separado de outcome verified . El segundo debe ser true , false o unavailable , con el verificador y el tiempo de verificación. Un comando exitoso es la actividad. El artefacto previsto es el resultado. Aplicar un orden de prioridad El tablero no debe apilar todas las advertencias posibles en la misma fila. Evaluar primero el estado más seguro y más explicativo: 1. el colector antiguo → unreachable ; 2. el inicio esperado más allá de su ventana de gracia → missed schedule ; 3. la dependencia denominada → waiting:<dependency ; 4. declarado completo sin un resultado verificado → false success ; 5. la frecuencia cardíaca fresca más la obsoleta, el progreso cero → stuck ; 6. resultado verificado → complete ; 7. delta del progreso positivo → working ; 8. pruebas insuficientes o contradictorias → uncertain . Ese pedido es una decisión de producto, no una ley de la naturaleza. Es aún mejor que permitir que tres alertas independientes afirmen que la misma carrera desconectada está atrapada, tardada y carece de resultado simultáneamente. Conservar las señales subyacentes para la investigación, pero dar al operador un estado primario y una acción siguiente. El dispositivo de acompañamiento prueba seis casos contra límites de ejemplos explícitos: frescura del colector de 120 segundos, gracia del cronograma de 300 segundos, frescura del latido cardíaco de 60 segundos y un tiempo de progreso de 600 segundos. Ejecutarlo con Node.js 20 o más reciente: La salida exacta es: El par más importante es approval wait frente a retry loop . Ambos tienen latidos de corazón frescos, ningún delta de progreso, y el progreso viejo. La dependencia nombrada hace que la primera espera sea legítima; la ausencia de una dependencia hace que la segunda sea un candidato atrapado después de su tiempo. El caso false success tiene un progreso reciente y una reclamación de finalización, pero el verificador de resultados es falso, por lo que la afirmación de finalización no gana confianza. Pon el diagnóstico detrás del veredicto Una vez que la fila de estado identifica una carrera que vale la pena abrir, la vista de detalles puede explicar por qué. Organice alrededor de la transición que falló en lugar de alrededor de cualquiera de las fuentes de telemetría es más fácil de trazar. Para missed schedule , muestre la expresión del horario, la zona horaria, el estado habilitado, los arranques esperados y reales, la política de superposición y el historial de ejecución reciente. Para waiting , indique la dependencia, el propietario, la autoridad solicitada, la edad y una acción de recordatorio limitada. Para stuck , muestre la cadencia cardíaca junto con pruebas de progreso y firmas de herramientas repetidas. Para false success , indique la declaración de finalización junto a la predicada fallida. Luego añadir rastreo, latencia, token, costo, modelo y paneles de herramientas. Se puede ejecutar un picón simbólico adjunto a una carrera atascada; el mismo picón adjunto a un resultado verificado puede ser un elemento de revisión de costes en lugar de un incidente. La repetición de la llamada de herramienta puede explicar un estancamiento, pero las llamadas idénticas no son prueba de un bucle hasta que la evidencia del progreso de la tarea también deje de cambiar. Utilice una línea de tiempo para la causalidad: Este punto de vista hace que los períodos de silencio sean comprensibles. También da a cada alerta una edad de evidencia. Si un adaptador deja de informar después de las 12:03, el tablero de control debe pasar a unreachable o uncertain en lugar de mantener un estado verde para siempre. Tratar los umbrales y la recopilación de datos como límites del producto La fijación es un conjunto de contraejemplos, no un índice de referencia de producción. Diez minutos sin un cambio de archivo pueden ser normales para un análisis profundo y desastrosos para un trabajador de una cola de un minuto. Calibra ventanas por flujo de trabajo, luego graba la configuración junto al veredicto. El progreso es la señal más difícil. Prefiere evidencia determinista como un digesto, recuento de filas, código de estado, resultado de prueba o comprobación de esquemas. Cuando el resultado es cualitativo, un evaluador versionado puede aportar evidencia, pero su puntuación tiene incertidumbre. Mantenga unavailable como un estado real; no convierta la evidencia faltante en algo saludable. Recoger el mínimo necesario para establecer la salud. Una fila de estados generalmente no necesita instrucciones, respuestas, secretos, cargas útiles de herramientas primas o caminos locales absolutos. Un identificador de ejecución opaco, sellos de tiempo, pequeños contadores, resultados de verificación y clases de dependencia redactadas pueden impulsar la primera decisión. Las huellas más ricas pueden tener reglas separadas de retención y acceso. Por último, no conecte el estado primario directamente a la automatización irreversible. La advertencia de vida de Kubernetes es relevante aquí: una prueba de salud demasiado segura puede empeorar la recuperación. Un panel de control puede recomendar un retiro limitado, una pausa o un recordatorio, pero la acción debe respetar la autoridad, el retiro, el tiempo y los límites de costosy el problema solo debe aclararse después de que se observe un progreso útil o el resultado esperado. Donde encaja Sidewisp La dirección del producto de Sidewisp es una visión de salud en torno a los agentes que las personas ya ejecutan: accesibilidad, progreso útil, acceso a la memoria y las herramientas, evidencia de resultados, señales de costos y recuperación controlada con límites de aprobación explícitos. No está destinado a reemplazar el sistema de seguimiento de tiempo de ejecución, programador, modelo de entrada o sistema de rastreo en bruto. Dicha descripción es la dirección del producto y no una afirmación de un seguimiento generalmente disponible. Sidewisp se encuentra actualmente en versión preliminar privada. El sitio público, la demostración interactiva y el sistema de artículos están en vivo; la recopilación de agentes de producción y salud, los adaptadores de tiempo de ejecución, la recuperación automática, la gestión cron y el análisis de costos de tokens generalmente no se envían. Únete a la vista previa privada si este contrato de panel de seis señales coincide con el problema operativo que necesitas resolver. Fuentes primarias Centinela AI Panel de control de agentes campos oficiales para ejecuciones, LLM llamadas, duración, modelos, tokens, herramientas, errores y rastros. La vitalidad, la preparación y la puesta en marcha de las sondas de Kubernetes separación oficial de los controles de salud, reacciones, umbrales y advertencias de falla. Horarios temporales horario oficial, pausa, superposición, recuperación y semántica de la política de fallas.