Agente AI Observabilidad para el fan-out: prueba el quórum de finalización

En una carrera de agentes de fan out, un padre terminado no es prueba de que el trabajo está completo. El padre puede haber recogido la rama más rápida, ignorado una revisión requerida, fusionado un resultado obsoleto, o contado la misma rama dos veces. La observabilidad del agente AI necesita un quórum de finalización: una lista congelada de las sucursales esperadas más recibos frescos, únicos y verificados por resultados para cada sucursales requeridas y el número declarado de sucursales opcionales. El defecto práctico es estricto. Congelar el manifiesto de la sucursal antes de su envío, identificar el trabajo requerido y opcional, fijar un plazo, y dejar que sólo los recibos verificados satisfagan el quórum. Antes de la fecha límite, la cobertura faltante puede ser waiting . Después de la fecha límite es incomplete . Si la empresa matriz informa de éxito sin cobertura, etiquetearla con false complete en lugar de dar verde a la bandera de la terminal conveniente. Las huellas muestran el ventilador, pero no definen la finalización El Documentación de seguimiento de SDK de OpenAI Agents registra generaciones, llamadas de herramientas, barandillas, entregas, eventos personalizados, ID de período de padres y sellos de tiempo. El OpenTelemetry Convenciones de extensión de agentes de GenAI, actualmente marcado Desarrollo, describe operaciones que incluyen la invocación de agentes, la planificación y la ejecución de herramientas. Esos registros son una evidencia útil de actividad. No saben qué ramas requería el operador ni qué resultado observable debía cada rama. Un rastro puede contener cuatro espacios de niños exitosos mientras que la quinta rama sin espinar nunca aparece la revisión de seguridad, la verificación de destino o la fuente de datos regionales. Mirar sólo las distancias emitidas crea un problema de selección: el trabajo faltante no deja espacio para inspeccionar. Los sistemas generales de lotes hacen que el conjunto esperado sea explícito. El Documentación de trabajo de Kubernetes distingue el trabajo paralelo con un número de finalizaciones fijo de los trabajos en cola de trabajo. Para los trabajos indexados, la finalización requiere un Pod exitoso para cada índice; la documentación también advierte que más de un Pod puede comenzar para el mismo índice y solo cuenta la primera finalización exitosa. El fan out de agentes no es un trabajo de Kubernetes, sino que la lección operativa se transfiere: la identidad y la cobertura esperada son importantes, no sólo un número total de eventos de éxito. Para el trabajo de agente, el padre debe congelar un manifiesto como este antes de delegar: El congelamiento importa. Si el progenitor puede retirar silenciosamente una rama lenta requerida después del envío, el denominador cambia para adaptarse al resultado observado. Una revisión manifiesta puede ser legítima, pero necesita una nueva versión, razón y límite de aprobación en lugar de una edición en su lugar. Haga que cada recibo sea un resultado Un recibo de sucursal necesita más de status: succeeded . Dale la identidad congelada de la rama, el tiempo de observación, una digestión de la evidencia, y un resultado de una verificación de resultados independiente: El documento debe cubrir una proyección canónica y no secreta del resultado prometido. Para una rama de prueba, eso podría incluir el commit, el comando de prueba, el estado de salida y el resumen de prueba normalizado. Para la investigación, podría cubrir las URLs de origen seleccionadas, los tiempos de recuperación y el libro mayor de reclamaciones. Para una rama de entrega, utilice la identidad del objeto de destino y un resultado de verificación en el lado de lectura. No hagas uso de las instrucciones cruas, las credenciales o las cargas útiles sensibles sólo para que el recibo parezca riguroso. Evaluar los recibos en un orden que preserve la incertidumbre: 1. Rechazar un manifiesto inválido, una identificación de sucursal desconocida o recibos duplicados contradictorios como uncertain . 2. Retorna incomplete cuando una rama requerida falla explícitamente. 3. Regresar unverified cuando el éxito requerido está obsoleto, carece de una digestión de pruebas o no tiene una verificación de resultados independiente. 4. La cobertura de contabilidad solo se aplicará cuando cada rama requerida tenga un éxito verificado reciente y los éxitos verificados opcionales cumplan el quórum declarado. 5. Regreso complete sólo cuando se cumpla la cobertura y el padre es terminal; de lo contrario, devuelva ready to finalize . 6. Si la cobertura no está disponible, devuelva el waiting solo mientras el plazo permanezca abierto. 7. Cuando la fecha límite expire primero, devuelva false complete o incomplete . Los duplicados en conflicto merecen un trato especial. Dos recibos para la misma rama con diferentes pruebas pueden indicar un nuevo intento, un cerebro dividido o una salida no determinista. La aceptación arbitraria del resultado más reciente oculta el conflicto. Mantenga el estado uncertain hasta que una política específica de la rama identifique el intento autorizado. Reproduce siete estados completos El artefacto que acompaña tiene un clasificador determinista en siete casos de ventilación sintética: La repetición producida: research 42 ha verificado los recibos de las dos sucursales requeridas y de una de las dos sucursales opcionales, cumpliendo exactamente su quórum opcional. Debido a que su padre es terminal, es complete . merge 17 tiene la cobertura requerida completa, pero sigue siendo ready to finalize porque la ejecución matriz aún está abierta. Los casos de fallas en pareja exponen por qué un solo campo running/completed es inadecuado. approval 09 carece de un recibo requerido pero permanece dentro de su plazo, por lo que es waiting . early parent 08 tiene la misma brecha de cobertura, pero una madre terminal, por lo que se convierte en false complete inmediatamente. El clasificador no espera el plazo para admitir que la alegación de éxito no está respaldada. unchecked 24 incluye un recibo de verificación de destino exitoso cuyo campo outcomeVerified es falso. Es unverified , no completo. conflict 15 presenta dos registros diferentes para la misma rama y, por lo tanto, sigue siendo uncertain . El artefacto trata la falta de evidencia y la evidencia contradictoria como diferentes problemas operacionales. Esta es una regla de decisión falsificable, no una medición de la frecuencia de fallas de producción. Siete casos construidos demuestran cobertura de sucursales y ordenamiento estatal; no pueden establecer plazos universales ni mostrar la frecuencia con la que los agentes reales pierden el trabajo de ventilación. Calibra el quórum sin hacerlo cosmético Comience con la semántica de las ramas. Por lo general, se requiere una revisión de seguridad, aprobación de acciones destructivas o verificación de destino incluso si varias ramas de enriquecimiento opcionales tienen éxito. Nunca permita que un quórum numérico opcional supere una rama requerida nombrada. Si dos de las tres fuentes es aceptable, codifique las tres como opcionales con quórum dos y preserve sus identidades. Establezca la fecha límite desde la clase de tareas, no desde un tiempo de agencia global. Una revisión interactiva del código y un rastreo regional nocturno tienen diferentes expectativas saludables. Registrar el tiempo del colector y el tiempo de la fuente; rechazar los recibos observados antes del congelamiento manifiesto o improbablemente después del tiempo de observación. Si no se puede confiar en los relojes, superfija uncertain en lugar de adivinar la frescura. Persiste el manifiesto y los recibos duraderamente lo suficiente como para sobrevivir a los reinicios de los padres. Una lista reconstruida basada únicamente en los niños actualmente visibles puede omitir una rama que falló antes de que la telemetría se enrojeciera. Almacenar una versión de manifiesto, la identificación de ejecución de los padres, la identidad de la sucursal, la identidad del intento de recibo y la razón final de clasificación. Si es posible duplicar la ejecución, haga explícita la regla de la autoridad en lugar de confiar en la orden de llegada. Por último, separar el diagnóstico de la intervención. Un recibo faltante puede justificar notificar a un propietario, solicitar pruebas o preparar una nueva prueba limitada. No autoriza el gasto repetido, la eliminación, el cambio de credenciales o la caída silenciosa de la sucursal. Después de un nuevo intento aprobado, requiere un nuevo recibo y vuelve a hacer la verificación del quórum. El límite es importante: un quórum de finalización demuestra la cobertura declarada, no que el manifiesto contenía todos los requisitos reales. Una debilidad de la rama también puede verificar el artefacto equivocado. Revise el diseño del manifiesto y las verificaciones de resultados con la misma atención que el código del clasificador. Sidewisp se encuentra actualmente en versión preliminar privada. Su sitio público y su biblioteca 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. El Sidewisp está destinado a ayudar a hacer visibles las pruebas, espera, completos falsos y límites de aprobación junto con los tiempos de ejecución existentes, no para reemplazar el tiempo de ejecución o actuar como un fijaje autónomo. Si los quórums de finalización coinciden con un fallo que necesita inspeccionar, puede unirse al acceso anticipado sin tratar la vista previa como una reclamación de monitoreo desplegada.