Observabilidad multiagente: audite la topología de coordinación

La observabilidad de múltiples agentes debería responder a una pregunta más estricta que "¿terminó cada lapso registrado?" Debería indicarle si los agentes que realmente participaron y las rutas que realmente utilizaron coinciden con el diseño de coordinación aprobado para esta ejecución. El valor predeterminado práctico es un contrato de topología versionado : un pequeño manifiesto de los agentes permitidos, los bordes dirigidos permitidos y los bordes esperados en la fase de ejecución actual. Únase a ese manifiesto con recibos de interacción sin contenido. Un seguimiento exitoso se puede clasificar como en funcionamiento, en espera, incompleto, inseguro, ambiguo o falso completo en lugar de volverse verde de forma predeterminada. Esto es importante porque un rastro registra lo que sucedió. No puede contener un intervalo para una delegación requerida que nunca ocurrió. Tampoco puede decidir que una ruta directa observada estaba prohibida a menos que usted proporcione el gráfico previsto. La misma distinción aparece en la guía de arquitectura actual: Microsoftarquitectura de referencia multiagenteseñala flujos de mensajes entre agentes y patrones de coordinación como señales especiales de observabilidad, mientras que elAzure Architecture Centeradvierte que la orquestación de múltiples agentes agrega una sobrecarga de coordinación y nuevos modos de falla. Utilice la complejidad más baja que satisfaga de manera confiable la tarea; cuando se justifiquen múltiples agentes, haga que su topología sea comprobable. Un rastro no puede probar la topología prevista API de seguimiento de OpenTelemetryproporciona las primitivas de correlación correctas: rastrear y abarcar identidad, parentesco, enlaces, eventos, marcas de tiempo, atributos y estado. Esas primitivas pueden describir un árbol de llamadas observado o una relación asincrónica. No declaran qué agentes estaban permitidos, qué versión de ruta estaba activa o qué borde debería haber aparecido pero no apareció. Supongamos que un orquestador delega la investigación, el investigador entrega la evidencia a un verificador y el verificador emite un veredicto. Cada evento observado puede tener status: "ok" en al menos cinco situaciones malas: la ejecución utilizó la política de enrutamiento de ayer; el investigador llamó directamente a un editor, sin pasar por la revisión; un agente no registrado ingresó al gráfico; el orquestador delegó dos veces la misma ruta de su propiedad; el padre declaró la finalización antes de que regresara el verificador. Una consulta de "todos los eventos correctos" no encuentra ningún error en esos registros. En su lugar, una auditoría de topología compara dos conjuntos: Mantenga esta capa libre de contenido. Un recibo necesita identidades de agente y ejecución estables, el tipo de ruta, la versión de la topología, la identidad del evento, el tiempo de observación y el estado local. No necesita indicaciones, respuestas, secretos, argumentos de herramientas ni rutas absolutas de archivos. El contrato está deliberadamente separado del quórum de finalización de distribución. Un quórum pregunta si se devolvieron las ramas requeridas. Un gráfico de espera pregunta qué dependencia está bloqueando el progreso. Un recibo de transferencia duradero pregunta si la responsabilidad sobrevivió a una cola o a un límite de reinicio. La conformidad topológica plantea una pregunta previa: ¿es este incluso el gráfico de coordinación que pretendíamos ejecutar? Construir un contrato de coordinación versionado Comience con identidades explícitas y aristas dirigidas. No infieras el gráfico permitido a partir de lo que apareció en el último rastro; eso simplemente bendice la deriva después del hecho. El conjunto permitido no es el mismo que el conjunto esperado. Una fase exclusivamente de investigación podría esperar dos delegaciones y ninguna ventaja editorial. Una fase de publicación completa podría incluir la transferencia de la investigación, el regreso del verificador, la delegación del editor y el regreso del editor. Fija ese conjunto específico de fase cuando comience la ejecución. De lo contrario, una ventaja opcional puede convertirse silenciosamente en obligatoria a mitad de una falla, o una ventaja requerida puede desaparecer de la definición antes de que alguien se dé cuenta. Un clasificador compacto puede utilizar esta precedencia: 1. contrato obsoleto : la versión del evento difiere de la versión fijada; 2. agente desconocido : cualquiera de los puntos finales está fuera del conjunto de identidades aprobado; 3. borde prohibido : la ruta dirigida y el tipo de interacción no están permitidos; 4. ruta ambigua : el mismo borde de propiedad aparece más de una vez sin una regla de multiplicidad explícita; 5. falso completo : un padre terminal carece de una ventaja esperada o de un recibo de resultado verificado; 6. esperando : falta una ventaja esperada, la dependencia nombrada es explícita y la fecha límite no ha pasado; 7. incompleto : una ventaja esperada sigue ausente después de su fecha límite; 8. saludable o en funcionamiento : el conjunto observado coincide con el plan actual, con "saludable" reservado para un resultado final verificado. Hacer pedidos es importante. Si un agente oculto utiliza una ruta prohibida y el padre también llega tarde, "incompleto" es demasiado débil: el operador primero debe contener una topología no aprobada. Por el contrario, una espera declarada antes de la fecha límite no es un estancamiento. Es un estado de dependencia saludable que debería llegar al propietario correcto sin desencadenar un reinicio destructivo. El enrutamiento dinámico es la principal limitación. Un sistema puede elegir legítimamente entre agentes especializados en tiempo de ejecución. Representa esa elección como una clase de borde acotada o genera el plan de ejecución exacto antes del envío. Un comodín como orchestrator es fácil de mantener pero elimina la mayor parte del valor de diagnóstico. Los cambios de versión deben ser auditables y una ejecución nunca debe adoptar silenciosamente una nueva versión a mitad de camino. El muestreo es otro límite. Se pueden muestrear rastros pesados, pero los recibos de topología compacta utilizados para decisiones de salud no pueden desaparecer bajo la misma política. Si el recibo requerido no está disponible, informe uncertain o incomplete ; no reconstruya el verde a partir de un rastro parcial. Vuelva a reproducir la deriva antes de confiar en la finalización Reproduje nueve casos sin contenido contra el contrato anterior. El acuerdo incluía una finalización saludable, trabajo actual, una espera legítima, una ventaja perdida después de la fecha límite, una topología obsoleta, una ruta directa prohibida, un agente desconocido, propiedad de ruta duplicada y una terminal principal sin acuse de recibo. La auditoría determinista coincidió con los nueve estados esperados. Una regla ingenua (existe al menos un evento, el estado de cada evento local es ok y el padre no ha fallado) marcada los nueve casos en verde . Sólo uno estaba sano. Seis de esos nueve verdes ingenuos eran inseguros, incompletos, obsoletos, ambiguos o falsos completos; los dos restantes estaban trabajando y esperando, estados que no deberían colapsar hasta alcanzar una salud completa. Caso ¿Todos los eventos grabados están bien? Veredicto de topología Significado del operador : Gráfico completo más recibo de resultados. Sí healthy Se verifica el gráfico planificado y el resultado final. Bordes planificados actuales Sí working El trabajo útil puede continuar; no intervengas Falta devolución antes de plazo Sí waiting Notificar u observar la dependencia nombrada Falta la misma devolución después de la fecha límite Sí incomplete Investigar la primera ventaja esperada ausente Versión de topología antigua Sí stale contract Deja de comparar la ejecución con el diseño incorrecto Ruta directa no aprobada Sí forbidden edge Contenga la ruta antes de volver a intentar trabajar. Participante desconocido Sí unknown agent Verificar identidad y autoridad. Ruta de propiedad duplicada Sí ambiguous route Conciliar la propiedad y los posibles efectos duplicados Terminal de padres, regreso ausente Sí false complete Reabrir la carrera; la finalización carece de la evidencia requerida Puede reproducir la decisión con una pequeña función sobre teclas de borde normalizadas: Ejecute las comprobaciones de topología antes de calificar el progreso, la calidad o los resultados. Luego mantenga explícitos los límites del veredicto: la conformidad topológica prueba únicamente que se observó la forma de coordinación aprobada; working requiere nueva evidencia de movimiento útil, no simplemente más eventos; waiting requiere una dependencia con nombre y una fecha límite; La finalización de healthy requiere un destino determinista o un recibo de entrega cuando esté disponible; la evidencia incierta debe seguir siendo incierta; cualquier recuperación activa necesita autoridad limitada, visibilidad y verificación posterior a la acción. Esto le da al operador una regla de adopción limitada: no confíe en una finalización de múltiples agentes hasta que la topología fijada de la ejecución, la fase actual y la recepción del resultado final estén de acuerdo. Un gráfico coincidente es una evidencia necesaria, no una prueba de que la respuesta es correcta. Sidewisp se encuentra actualmente en versión preliminar privada. Su sitio público de acceso temprano y su demostración interactiva están en vivo, pero no se envían un adaptador de monitoreo de múltiples agentes de producción, un recopilador de estado en vivo y un ejecutor de recuperación automatizado. La función prevista de Sidewisp es agregar una capa de salud alrededor de los tiempos de ejecución existentes y hacer que la evidencia, la gravedad, la incertidumbre y la siguiente acción más segura sean más fáciles de inspeccionar, no reemplazar el tiempo de ejecución ni actuar sin autoridad humana.