Observabilidad de los agentes: atrapar el falso éxito con un contrato de resultado

La observabilidad del agente debe responder a una pregunta más difícil que ¿ finalizó la carrera?: ¿existe el resultado esperado, pertenece a esta carrera y pasa su verificación de aceptación? El defecto práctico es definir ese resultado antes de la ejecución, observarlo fuera del propio mensaje de finalización del agente y registrar un recibo de resultado compacto. Un evento terminal puede desencadenar la verificación; no puede sustituir la verificación. Esta distinción alcanza un falso éxito sin requerir que un segundo modelo vuelva a leer toda la transcripción. También evita el error opuesto: tratar una aprobación legítima de esperar como una carrera rota. El recibo descrito a continuación registra un identificador opaco del artefacto, la frescura, una digestión del contenido cuando sea apropiado y un resultado de validación determinista. Las pruebas faltantes siguen siendo unverified o un estado de falla específico en lugar de ser redondeadas hasta estar sanas. Un evento terminal es evidencia de ejecución, no entrega Las huellas son el lugar adecuado para entender cómo funcionaba el trabajo. No son una prueba automática de que el estado externo solicitado exista ahora. El Convenciones semánticas de OpenTelemetry para los espacios de agentes de GenAI actual describe operaciones como invoke agent , plan y execute tool , además de los atributos de agente, proveedor, modelo, tiempo y error. El documento está explícitamente marcado Desarrollo. Esas señales pueden mostrar que se ha producido una operación y si se ha reportado un error. No pueden saber que su factura en particular fue almacenada, que su solicitud de retiro contiene el cambio solicitado o que su informe coincide con un esquema aprobado. Esa regla de aceptación pertenece a la solicitud. El Referencia de seguimiento de SDK OpenAI Agents hace el mismo hormigón límite. Su rastro predeterminado puede incluir generaciones de modelos, llamadas de funciones, barandillas, entregas y extensiones personalizadas. Esta es una rica evidencia de ejecución. El SDK también advierte de que los intervalos de generación y función pueden contener entradas y salidas sensibles, y permite a los operadores desactivar esa captura. Por lo tanto, un recibo de resultado puede ser a la vez más estrecho y más decisivo: conservar la prueba necesaria para juzgar el producto entregado, no una segunda copia de cada carga útil de información y herramientas. Un buen modelo operativo utiliza ambas cosas: el rastro explica la trayectoria, los retos, las herramientas y la ubicación del fallo; el recibo del resultado demuestra el resultado previsto o nombra la prueba ausente; una señal de espera registra una dependencia o aprobación conocida, en lugar de pretender que la tarea se haya completado; una señal de progreso muestra un movimiento útil mientras el trabajo está todavía activo. Mezclar estas señales crea malas alertas. La actividad no es un progreso útil. Un evento terminal limpio no es un resultado verificado. Una espera declarada no es una parada. Escriba el contrato final antes de la carrera Un contrato final es lo suficientemente pequeño como para revisar en la creación de tareas y lo suficientemente estricto como para evaluar sin preguntar al agente lo que significaba. Comience con la verificación determinista más barata que coincida con el resultado real. El campo Propósito Ejemplo artifact id Nombra el resultado esperado sin exponer un camino secreto o absoluto monthly report run started at Establece el límite de frescura 2026 07 25T14:00:00Z observed at Muestra cuándo se recogieron las pruebas 2026 07 25T14:08:12Z modified at Rechaza un artefacto dejado por una carrera anterior 2026 07 25T14:07:55Z expected sha256 Pins bytes exactos cuando el byte importa la identidad una digestión de 64 caracteres validator Nombros del cheque de aceptación report schema v3 validator exit code Registra el veredicto determinista 0 evidence source Dice de dónde vino la observación local file stat No requiere cada campo para cada trabajo. Una migración de base de datos puede necesitar una consulta de esquema en lugar de una digestión de archivos. Una página desplegada puede necesitar el estado HTTP, contenido canónico y una afirmación del navegador. Una tarea de aprobación humana debe permanecer waiting hasta que llegue el evento de autoridad. El contrato debe representar el resultado, no obligar a cada carga de trabajo a un modelo en forma de archivo. La orden de clasificación por defecto es importante. Compruebe primero la ausencia de evidencia, luego la identidad, la frescura, la digestión y el resultado de la validación. Esto produce estados accionables: 1. missing no se han observado artefactos; 2. wrong artifact la observación pertenece a un objetivo diferente; 3. stale el artefacto es anterior a la carrera; 4. hash mismatch se requirieron bytes exactos y difieren; 5. validator failed el artefacto existe pero no cumple los criterios de aceptación; 6. unverified la verificación requerida no se realizó o no hay pruebas disponibles; 7. verified todas las condiciones requeridas pasadas. Mantenga el recibo de privacidad mínimo. Los identificadores opacos son más seguros que los nombres de clientes o las rutas del sistema de archivos. Un digesto puede probar la identidad de byte, pero un hash simple no oculta un secreto predecible de la enumeración. Utilice un HMAC con teclado cuando el valor sea sensible y con baja entropía, o evite conservar el valor por completo. La recogida de pruebas debe tener lugar cerca del artefacto para que el contenido crudo no tenga que abandonar el anfitrión. Realizar la prueba de falso éxito de seis casos Probé la regla contra un dispositivo sintético de seis carreras. Cada carrera lleva el mismo estado terminal de tiempo de ejecución: completed . Dos observaciones son nuevas y válidas. Cuatro representan un modo diferente de falso éxito: ningún artefacto, un artefacto más antiguo que la carrera, una incompatibilidad de contenido y un fallo del validador. El clasificador es deliberadamente aburrido. Evalúa los hechos en orden fijo: El funcionamiento del dispositivo incluido produce: La afirmación falsificable es estrecha: para este dispositivo suministrado, una regla de estado terminal acepta seis carreras, mientras que el contrato final verifica dos y rechaza cuatro con estados de evidencia específicos. Esta no es una tasa de fallas de producción medida. Se trata de una prueba de límites que muestra que los mismos estados terminales pueden ocultar resultados materialmente diferentes. La métrica útil no es el percentual de las carreras que dijeron completas. Es verified outcomes / runs expected to deliver an outcome , reportado junto a la cobertura de los cheques. Si sólo la mitad de sus tipos de tareas tienen validadores deterministas, muestre esa limitación. No clasifique silenciosamente a la mitad sin instrumentos como saludable. Anexar la verificación en el límite de finalización El recibo funciona mejor cuando el tiempo de ejecución expone un límite de finalización pero el cheque en sí permanece independiente. En ese límite, recoger pruebas, ejecutar el validador, persistir en el recibo, y sólo después actualizar el estado operativo. El Código de Claude proporciona un punto concreto de aplicación. Su referencias de ganchos actual dice que TaskCompleted se ejecuta cuando una tarea está siendo marcada completa. Un gancho de comando puede salir con el código 2 para evitar la finalización y devolver retroalimentación cuando fallan las pruebas u otras comprobaciones de aceptación. Esto hace posible una puerta determinista sin confiar en una afirmación en prosa. Es un mecanismo específico del código de Claude, no un estándar de agente universal, y un gancho que funcionó con éxito todavía necesita probar el artefacto correcto. Para los tiempos de ejecución sin un gancho de finalización de bloqueo, utilice una transición de estado de dos etapas: No vuelva a probar automáticamente todos los estados no verificados. missing después de un retraso conocido en la carga puede necesitar una ventana de observación limitada corta. validator failed podrá justificar un intento de reparación reversible si el usuario ya lo ha autorizado. unverified significa que el canal de pruebas falló; no demuestra que el producto entregado sea malo. Una tarea en espera de una decisión irreversible pertenece a waiting o needs human , no a un ciclo de recuperación. También separar el éxito del comando del éxito del resultado. Un proceso de validador que sale de 0 sólo prueba lo que ese validador realmente verifica. Versión del nombre del validador, registro de su fuente de evidencia y tiempo de observación, y revisar el contrato cuando el entregable cambie. Una regla de aceptación obsoleta puede producir un falso positivo perfectamente documentado. Escala la incertidumbre; no fabrica el éxito Un contrato final es tan completo como sus expectativas declaradas. Puede perder un artefacto no incluido en la lista, aceptar un validador débil, o leer de una fuente de evidencia obsoleta. Esas son razones para exponer la cobertura y la confianza, no razones para añadir un juez modelo por defecto. Utilice una evaluación de LLM sólo para criterios que no pueden ser verificados deterministicamente, mantenga su rúbrica y su versión visibles y evite que el mismo agente produzca y califique de manera concluyente su propio trabajo. Cuando las pruebas sean en conflicto, prefiera uncertain y solicite autoridad antes de cambiar el estado externo. Sidewisp se encuentra actualmente en versión preliminar privada. El sitio público y la biblioteca de artículos están en vivo; la recopilación de agentes de producción salud, los adaptadores de tiempo de ejecución y la recuperación generalmente no se envían. El Sidewisp está destinado a ser una capa de salud junto con los tiempos de ejecución existentes, no a ser un dispositivo de reposición de los tiempos de ejecución o de fijación autónoma. La regla de funcionamiento es simple: deja que el evento terminal de tiempo de ejecución inicie la verificación, deja que la evidencia externa decida el resultado, y deja que la evidencia que falta permanezca desconocida. Si ese modelo de salud coincide con la forma en que ejecutas agentes, el registro en la vista previa privada es el siguiente paso apropiado.