AI Agente Observabilidad: huellas dactilares en cada carrera

La respuesta más corta y útil es: adjuntar una huella digital run manifest a cada ejecución de agente, luego comparar la salud solo después de saber si el tiempo de ejecución, la instantánea de modelo, el prompt, la política, el esquema de herramienta y la imagen de implementación eran los mismos. Un rastro te dice lo que hizo una carrera. El manifiesto le dice qué versión del sistema lo hizo. Esa huella no es una puntuación de salud y no prueba por qué una carrera falló. Es una llave de ramificación. Si aparece una regresión bajo una nueva huella digital, inspeccione primero la deriva de configuración. Si aparece bajo la huella digital antigua, busque cambios de entorno, dependencia, proveedor, datos o permisos no grabados. Un nombre de agente estable puede ocultar un sistema diferente Supongamos que support triage completa dos boletos correctamente el viernes y se pierde una escalada requerida el lunes. Ambas carreras tienen el mismo nombre de agente. Ambos emiten latidos cardíacos. Ambas herramientas de llamadas. Los agrupar juntos se siente natural y puede estar equivocado. Entre esas carreras, cualquiera de estas puede haber cambiado: Componente manifiesto Registro Evitar la grabación Tiempo de ejecución nombre y versión exacta o compromiso ruta del host, token de acceso Modelo proveedor y instantánea fijada cuando esté disponible Clave de API, respuesta completa Pronto . SHA 256 del paquete de solicitudes revisado cliente o sistema en bruto Políticas hash o revisión inmutable Valores secretos incorporados en la política Herramientas hash de esquema canónico credenciales, cargas útiles de herramientas Despliegue Digest de imagen o código fuente contraseña del registro Esto sigue una idea de observabilidad establecida en lugar de inventar un segundo formato de rastro. El SDK de recursos de OpenTelemetry describe un recurso como una representación inmutable de la entidad que produce telemetría. Para una ejecución de agente, la configuración de ejecución es parte de esa identidad. Mantenga la identificación de rastreo para una ejecución y la huella digital manifiesta para la versión que la produjo; ninguno reemplaza al otro. Un manifiesto útil es deliberadamente aburrido. Contiene identificadores estables, no observaciones como latencia, recuento de tokens, estado de salida o resultado. Esos pertenecen al lado de la Escritura manifiesta. Mezclarlos en el hash crearía una nueva huella para cada carrera y destruiría la comparación. También hay un límite de privacidad: hash a una solicitud o política localmente, pero no cargue el original simplemente para explicar su identidad. Los hashes todavía pueden filtrar información cuando la entrada proviene de un conjunto pequeño adivinable, así que use IDs de liberación opacas o un digesto local con teclado cuando esa amenaza importe. Nunca pongas credenciales en el manifiesto, incluso antes de hashar todo el objeto. Canonizar antes de hacilar Hashing raw JSON es una trampa porque el orden de la clave de objeto y las opciones de serialización insignificantes pueden diferir mientras que la configuración representada permanece la misma. El JSON esquema de canonización en la RFC 8785 define la serialización determinista, incluida la clasificación de propiedades recursivas. El código de producción debe utilizar una implementación revisada del JCS cuando se trate de interoperabilidad. Para un experimento local compacto, la siguiente función Node.js es suficiente para los valores finitos ordinarios JSON: El experimento usó Node.js v22.23.1 . Es intencionalmente más estrecha que la RFC 8785: clasifica las claves de objeto de manera recursiva y rechaza números no finitos, pero no es una afirmación de cumplimiento completo de JCS translingual. Esa limitación pertenece al lado del código, no en una nota a pie de página después de que un lector la haya copiado. El manifiesto en sí puede permanecer pequeño: Los valores de retención de lugar anteriores son identificadores de fijación, no reclamaciones de proveedores. En un colector real, derivarlos en el anfitrión de lanzamientos fijados. El principio más amplio se asemeja a Provenencia de SLSA: conservar información verificable sobre dónde, cuándo y cómo se produjo algo. Un manifiesto de carrera toma prestado ese principio para el diagnóstico; no es automáticamente un certificado SLSA. Una repetición de seis carreras expone tanto el valor como el límite Probé la regla contra seis registros sintéticos de NDJSON para un agente. Las carreras 101 y 102 contienen los mismos valores manifestos en diferentes órdenes de claves JSON. Ejecutar 103 cambia sólo el hash de solicitud, 104 cambia sólo el instantáneo del modelo, y 105 cambia sólo el hash del esquema de herramientas. La ejecución 106 falla debido a una interrupción de dependencia que el manifiesto de fijación no representa. El comando de auditoría fue: El resultado determinista: Dos observaciones son más importantes que las cuentas. Primero, un nombre de agente ocultaba cuatro configuraciones registradas. En segundo lugar, los dos objetos de base ordenados de manera diferente produjeron la misma huella digital SHA 256, por lo que el orden de serialización no creó una falsa deriva. El contraejemplo es la parte importante: run 106 falló con la huella digital de referencia. Una huella no modificada no hizo que la carrera fuera saludable, y no demostró que el entorno no cambiara. Sólo mostró que los campos de configuración registrados no habían cambiado. La siguiente investigación debe examinar las pruebas fuera de la disponibilidad del proveedor, los datos de entrada, la ruta de la red, el estado de los permisos y la actualidad de la dependencia. El dispositivo es sintético, por lo que demuestra la mecánica y falsifica una reclamación excesiva; no estima la frecuencia con la que la deriva de configuración causa incidentes reales. Esto requeriría datos de producción con emisiones controladas y resultados verificados. Convertir la huella digital en una decisión de triaje Utilice la huella digital sólo después de que la carrera tenga un resultado observable. La actividad por sí sola los tokens emitidos, las herramientas llamadas o un proceso todavía vivo no establece un progreso útil. Prueba de resultados Comparación de huellas dactilares Primera sucursal Se aprobó Lo mismo que en el punto de partida Mantener como referencia saludable comparable No se ha logrado Cambiado Diferenciar los campos del manifiesto editados; considerar un retroceso o repetición limitados No se ha logrado Lo mismo . Inspeccionar las dependencias, permisos, entradas, estado del proveedor y cobertura manifiesta faltante Desconocido O sea Recoger o definir el resultado esperado antes de diagnosticar la deriva Tres reglas operativas mantienen esto honesto: 1. Libre el punto de comparación. Elige una ejecución verificada con éxito para la misma clase de tareas, no solo el estado verde más reciente. 2. Mantén un mapa de nivel de campo redactado. El hash de todo el manifiesto dice diferente. Los digestos de componentes individuales dicen dónde inspeccionar sin revelar el contenido. 3. Verificar el resultado después de la intervención. Un comando de retroceso que tiene éxito es la actividad. Recuperación significa que aparece el resultado esperado, se pasa la prueba o se pasa otra verificación determinista de aceptación. No retroceda automáticamente cada huella digital cambiada. Una liberación puede ser intencional, y un fallo puede provenir de la entrada en lugar de la liberación. Utilice el cambio como evidencia para una revisión, preserve la aprobación humana para las acciones consecuentes y registre lo que sucedió después de la acción. Cuando esto encaja en el seguimiento de la salud de los agentes La huella digital que se muestra en la carrera conecta tres cuestiones de salud que los rastros solos no pueden resolver de manera limpia: ¿cambió una política de decisión, cambió un contrato de herramienta y se redujo la calidad de los resultados en el mismo sistema registrado? También mejora las entregas de incidentes porque otro operador puede comparar la identidad exacta de liberación sin recibir instrucciones, secretos o cargas útiles de herramientas crudas. El modelo de salud previsto de Sidewisp incluye ejecución, memoria y contexto, herramientas, resultados, disponibilidad y costo. Un futuro adaptador del lado del anfitrión podría utilizar un manifiesto redactado como evidencia de apoyo para esos diagnósticos, pero ese es el territorio planeadono una afirmación de monitoreo enviada. Sidewisp se encuentra actualmente en versión preliminar privada. El sitio público 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 y la recuperación automática no están generalmente disponibles. Si este modelo de prueba coincide con un fallo que opera hoy, el siguiente paso restringido es unirse a la lista de espera de vista previa privada y describir la verificación de tiempo de ejecución y resultados que necesitano asumir que Sidewisp ya la recoge.