Beobachtbarkeit mehrerer Agenten: Überprüfen Sie die Koordinationstopologie

Die Beobachtbarkeit mehrerer Agenten sollte eine strengere Frage beantworten als „Wurde jede aufgezeichnete Zeitspanne abgeschlossen?“ Es soll Ihnen Aufschluss darüber geben, ob die tatsächlich beteiligten Agenten und die von ihnen tatsächlich genutzten Routen mit dem für diesen Lauf genehmigten Koordinationsdesign übereinstimmen. Der praktische Standard ist ein versionierter Topologievertrag : ein kleines Manifest zulässiger Agenten, zulässiger gerichteter Kanten und der in der aktuellen Ausführungsphase erwarteten Kanten. Verknüpfen Sie dieses Manifest mit inhaltsfreien Interaktionsbelegen. Eine erfolgreiche Ablaufverfolgung kann dann als funktionierend, wartend, unvollständig, unsicher, mehrdeutig oder falsch vollständig klassifiziert werden, anstatt standardmäßig grün zu werden. Das ist wichtig, weil eine Spur aufzeichnet, was passiert ist. Es darf keine Spanne für eine erforderliche Delegation enthalten, die nie stattgefunden hat. Es kann auch nicht entscheiden, dass eine beobachtete direkte Route verboten war, es sei denn, Sie liefern das beabsichtigte Diagramm. Die gleiche Unterscheidung erscheint in den aktuellen Architekturleitfäden: MicrosoftMultiagenten Referenzarchitekturruft Nachrichtenflüsse und Koordinationsmuster zwischen Agenten als besondere Beobachtbarkeitssignale auf, während dieAzure Architecture Centerwarnt davor, dass die Orchestrierung mit mehreren Agenten den Koordinationsaufwand und neue Fehlermodi erhöht. Verwenden Sie die niedrigste Komplexität, die die Aufgabe zuverlässig erfüllt. Wenn mehrere Agenten gerechtfertigt sind, machen Sie ihre Topologie testbar. Ein Trace kann die beabsichtigte Topologie nicht beweisen Die Tracing API von OpenTelemetrystellt die richtigen Korrelationsprimitive bereit: Trace and Span Identität, Abstammung, Links, Ereignisse, Zeitstempel, Attribute und Status. Diese Grundelemente können einen beobachteten Aufrufbaum oder eine asynchrone Beziehung beschreiben. Sie geben nicht an, welche Agenten zugelassen waren, welche Routenversion aktiv war oder welche Kante hätte erscheinen sollen, aber nicht erschienen ist. Angenommen, ein Orchestrator delegiert die Forschung, der Forscher übergibt Beweise an einen Prüfer und der Prüfer gibt ein Urteil ab. Jedes beobachtete Ereignis kann in mindestens fünf schlechten Situationen status: "ok" haben: der Lauf verwendete die gestrige Routing Richtlinie; Der Forscher rief direkt einen Verlag an und umging die Überprüfung. ein nicht registrierter Agent hat die Grafik betreten; Der Orchestrator hat dieselbe eigene Route zweimal delegiert. Das übergeordnete Element erklärte den Abschluss, bevor der Prüfer zurückkehrte. Bei der Abfrage „Alle Ereignisse in Ordnung“ werden in diesen Datensätzen keine Fehler festgestellt. Bei einer Topologieprüfung werden stattdessen zwei Sätze verglichen: Halten Sie diese Ebene inhaltsfrei. Eine Quittung benötigt stabile Lauf und Agentenidentitäten, den Routentyp, die Topologieversion, die Ereignisidentität, die Beobachtungszeit und den lokalen Status. Es sind keine Eingabeaufforderungen, Antworten, Geheimnisse, Toolargumente oder absolute Dateipfade erforderlich. Der Vertrag ist bewusst von einem Fan out Abschlussquorum getrennt. Ein Quorum fragt, ob erforderliche Zweige zurückgegeben wurden. Ein Wartediagramm fragt, welche Abhängigkeit den Fortschritt blockiert. Eine dauerhafte Übergabebestätigung fragt, ob die Verantwortung eine Warteschlangen oder Neustartgrenze überstanden hat. Die Topologiekonformität stellt eine vorherige Frage: Ist dies überhaupt der Koordinationsgraph, den wir ausführen wollten? Erstellen Sie einen versionierten Koordinationsvertrag Beginnen Sie mit expliziten Identitäten und gerichteten Kanten. Leiten Sie das zulässige Diagramm nicht aus dem ab, was in der letzten Ablaufverfolgung angezeigt wurde. das begünstigt lediglich die nachträgliche Drift. Der zulässige Satz stimmt nicht mit dem erwarteten Satz überein. In einer reinen Recherchephase sind möglicherweise zwei Delegationen und kein Verlagsvorteil zu erwarten. Eine vollständige Veröffentlichungsphase kann die Übergabe der Recherche, die Rückgabe des Prüfers, die Delegation des Herausgebers und die Rückgabe des Herausgebers umfassen. Stecken Sie diesen phasenspezifischen Satz fest, wenn der Lauf beginnt. Andernfalls kann eine optionale Kante mitten in einem Fehler stillschweigend obligatorisch werden, oder eine erforderliche Kante kann aus der Definition verschwinden, bevor es jemand bemerkt. Ein kompakter Klassifikator kann diese Priorität verwenden: 1. veralteter Vertrag – die Ereignisversion unterscheidet sich von der angehefteten Version; 2. unbekannter Agent – einer der Endpunkte liegt außerhalb des genehmigten Identitätssatzes; 3. verbotene Kante – die gerichtete Route und die Interaktionsart sind nicht zulässig; 4. mehrdeutige Route – die gleiche besessene Kante erscheint mehr als einmal ohne eine explizite Multiplizitätsregel; 5. falsch abgeschlossen – einem Terminal Elternteil fehlt ein erwarteter Rand oder ein verifizierter Ergebnisempfang; 6. Warten – eine erwartete Kante fehlt, die benannte Abhängigkeit ist explizit und die Frist ist nicht abgelaufen; 7. unvollständig – eine erwartete Kante fehlt nach Ablauf der Frist immer noch; 8. gesund oder funktionsfähig – der beobachtete Satz stimmt mit dem aktuellen Plan überein, wobei „gesund“ für ein verifiziertes Endergebnis reserviert ist. Bestellen ist wichtig. Wenn ein Schattenagent eine verbotene Route verwendet und der übergeordnete Agent ebenfalls zu spät kommt, ist „unvollständig“ zu schwach: Der Operator muss zunächst eine nicht genehmigte Topologie eindämmen. Umgekehrt ist ein erklärtes Warten vor Ablauf der Frist kein Stillstand. Es handelt sich um einen fehlerfreien Abhängigkeitszustand, der den richtigen Besitzer erreichen sollte, ohne einen destruktiven Reset auszulösen. Dynamisches Routing ist die Haupteinschränkung. Ein System kann zur Laufzeit berechtigterweise zwischen spezialisierten Agenten wählen. Stellen Sie diese Auswahl als begrenzte Kantenklasse dar oder erstellen Sie vor dem Versand den genauen Ausführungsplan. Ein Platzhalter wie orchestrator ist einfach zu verwalten, entfernt jedoch den größten Teil des Diagnosewerts. Versionsänderungen sollten überprüfbar sein und ein Lauf sollte niemals stillschweigend zur Hälfte eine neue Version übernehmen. Die Probenahme ist eine weitere Grenze. Schwere Spuren können abgetastet werden, aber die Belege der kompakten Topologie, die für Gesundheitsentscheidungen verwendet werden, können unter derselben Richtlinie nicht verschwinden. Wenn eine erforderliche Quittung nicht verfügbar ist, melden Sie uncertain oder incomplete ; Grün nicht aus einer Teilspur rekonstruieren. Wiederholen Sie die Drift, bevor Sie der Fertigstellung vertrauen Ich habe neun inhaltsfreie Fälle gegen den oben genannten Vertrag noch einmal durchgespielt. Zu den Merkmalen gehörten ein ordnungsgemäßer Abschluss, aktuelle Arbeit, eine legitime Wartezeit, eine verpasste Kante nach Ablauf der Frist, eine veraltete Topologie, eine verbotene direkte Route, ein unbekannter Agent, doppelter Routeneigentum und ein übergeordnetes Terminal ohne Rücksendebestätigung. Die deterministische Prüfung stimmte mit allen neun erwarteten Zuständen überein. Eine naive Regel – mindestens ein Ereignis existiert, der Status jedes lokalen Ereignisses ist ok und das übergeordnete Ereignis ist nicht fehlgeschlagen – markiert alle neun Fälle grün . Nur einer war gesund. Sechs dieser neun naiven Grüntöne waren unsicher, unvollständig, veraltet, mehrdeutig oder falsch vollständig; Die übrigen beiden arbeiteten und warteten, Zustände, die nicht völlig gesund zusammenbrechen sollten. Fall Alle aufgezeichneten Ereignisse in Ordnung? Topologie Urteil Bedeutung des Operators : Komplettes Diagramm plus Ergebnisbeleg Ja healthy Das geplante Diagramm und das Endergebnis werden überprüft Aktuelle geplante Kanten Ja working Nützliche Arbeit kann fortgesetzt werden; nicht eingreifen Fehlende Rückgabe vor Ablauf der Frist Ja waiting Benachrichtigen oder beobachten Sie die genannte Abhängigkeit Dieselbe Rücksendung fehlt nach Ablauf der Frist Ja incomplete Untersuchen Sie die erste fehlende erwartete Kante Alte Topologieversion Ja stale contract Hören Sie auf, den Lauf mit dem falschen Design zu vergleichen Nicht genehmigte direkte Route Ja forbidden edge Halten Sie die Route ein, bevor Sie die Arbeit wiederholen Unbekannter Teilnehmer Ja unknown agent Überprüfen Sie Identität und Autorität Doppelte eigene Route Ja ambiguous route Bringen Sie Eigentumsverhältnisse und mögliche Doppeleffekte in Einklang Übergeordnetes Terminal, Rückgabe fehlt Ja false complete Öffnen Sie den Lauf erneut. Für die Fertigstellung fehlen die erforderlichen Nachweise Sie können die Entscheidung mit einer kleinen Funktion über normalisierte Kantenschlüssel reproduzieren: Führen Sie die Topologieprüfungen vor der Fortschritts , Qualitäts oder Ergebnisbewertung durch. Halten Sie dann die Urteilsgrenzen explizit: Topologiekonformität beweist nur, dass die genehmigte Koordinationsform eingehalten wurde; working erfordert neue Beweise für eine nützliche Bewegung, nicht nur weitere Ereignisse; waiting erfordert eine benannte Abhängigkeit und Frist; Für den healthy Abschluss ist ein deterministisches Ziel oder eine zu liefernde Quittung erforderlich, sofern eine solche verfügbar ist. unsichere Beweise müssen unsicher bleiben; Jede aktive Wiederherstellung erfordert begrenzte Autorität, Sichtbarkeit und Überprüfung nach der Aktion. Dadurch erhält der Bediener eine eng gefasste Annahmeregel: Vertrauen Sie einem Multi Agent Abschluss nicht, bis die festgelegte Topologie des Laufs, die aktuelle Phase und der Endergebnisempfang übereinstimmen. Ein übereinstimmendes Diagramm ist ein notwendiger Beweis, kein Beweis dafür, dass die Antwort richtig ist. Sidewisp befindet sich derzeit in einer privaten Vorschauphase. Die öffentliche Early Access Site und die interaktive Demonstration sind live, ein Multi Agent Überwachungsadapter für die Produktion, ein Live Health Collector und ein automatisierter Recovery Executor werden jedoch nicht ausgeliefert. Die beabsichtigte Rolle von Sidewisp besteht darin, eine Gesundheitsschicht um bestehende Laufzeiten herum hinzuzufügen und die Überprüfung von Beweisen, Schweregrad, Unsicherheit und der sichersten nächsten Aktion zu erleichtern – und nicht darin, die Laufzeit zu ersetzen oder ohne menschliche Autorität zu handeln.