Interaktives Debuggen und Steuern von Multiagenten-AI-Systemen: Gate bei jedem Reset

Interaktives Debuggen und Steuern von AI Systemen mit mehreren Agenten sollte nicht als Transkriptbearbeitung behandelt werden. Ein sicherer Reset erstellt einen neuen Zweig mit einer eigenen Abstammung, Beweisen für den wiederhergestellten Zustand, Normdatensätzen und Ergebnisbelegen. Wenn ein Browser, ein Arbeitsbereich, eine Warteschlange, Anmeldeinformationen oder ein externes Ziel nicht wiederhergestellt oder abgeglichen werden können, ist der korrekte Status unsicher — nicht “bereit".” Das ist die praktische Lektion, die man daraus ziehen kann Interaktives Debuggen und Steuern von Multiagenten AI Systemen, das CHI 2025 Papier hinter Microsofts Open Source AGDebugger. Die Forschung macht das Zurückspulen und Bearbeiten für das Debuggen mit mehreren Agenten nutzbar. Eine operative Bereitstellung benötigt eine weitere Grenze: Ein Zurücksetzen kann einen internen Status genau genug wiederherstellen, um eine Hypothese zu testen, aber es kann nicht automatisch eine E Mail rückgängig machen, ein Ticket zurücksetzen, die Veröffentlichung einer Seite aufheben oder beweisen, dass der neue Zweig die Aufgabe des Benutzers abgeschlossen hat. Der vernünftige Standard ist ein Lenkbeleg mit sechs Toren: 1. der Elternteil und der Zweig haben unterschiedliche Identitäten; 2. der Checkpoint deckt jeden erforderlichen Agenten und Toolstatusschlüssel ab; 3. effekte nach dem Prüfpunkt werden rückgängig gemacht oder abgeglichen; 4. der Bediener ist berechtigt, den Eingriff vorzunehmen; 5. die Agentenkonfiguration wird für den neuen Zweig angeheftet; 6. der wieder aufgenommene Zweig erhält einen neuen Ergebnisbeleg. Nur die ersten fünf bilden einen Zweig bereit zum Fortsetzen . Der sechste macht es überprüfen . Ein Reset ist eine Verzweigung, kein Zurückspulen Das AGDebugger Papier geht von einem konkreten Problem aus. Fünf Agentenentwickler beschrieben Schwierigkeiten beim Lokalisieren von Fehlern in langen Konversationen, fehlende interaktive Debugging Steuerelemente und langsame Iterationen bei Agentenkonfigurationen. Die Autoren haben ein System entwickelt, mit dem ein Entwickler Nachrichten schrittweise durchgehen, auf einen früheren Punkt zurücksetzen, eine vorherige Nachricht bearbeiten und die resultierenden Konversationszweige vergleichen kann. Eine zweiteilige Studie mit 14 Teilnehmern untersuchte dann Diagnose und Steuerungsstrategien. Dies ist eine stärkere Interaktion als das Durchsuchen von Protokollen. Ein Entwickler kann an der Fehlergrenze zwei fälschbare Fragen stellen: Was passiert, wenn derselbe Status erneut ausgeführt wird und was passiert, wenn sich eine bestimmte Nachricht ändert? Das Papier berichtet über drei gängige Formen der Steuerung in seiner Studie: Hinzufügen von Details, Vereinfachen einer Aufgabe und Ändern eines Plans. Aber das Implementierungsdetail ist wichtiger als die Bearbeitungskosten. AGDebugger überprüft den Agentenstatus, bevor eine Nachricht verarbeitet wird. Beim Zurücksetzen wird der entsprechende Prüfpunkt wiederhergestellt und eine neue Sitzung erstellt. Nachrichten und Checkpoints vor der Verzweigung bleiben freigegeben; neue Nachrichten und Checkpoints gehören zur Verzweigung. Das ist Lineage, auch wenn die Benutzeroberfläche wie ein Rücklauf aussieht. Die Behandlung der Operation als Verzweigung gibt dem Operator drei nützliche Invarianten: der ursprüngliche fehlgeschlagene Lauf bleibt überprüfbar; der genaue Gabelpunkt ist unveränderlich; die Bearbeitung und jeder spätere Effekt gehören zu einer neuen Sitzung. Ohne diese Invarianten kann ein bearbeitetes Transkript die Beweise, die zur Diagnose des Vorfalls verwendet wurden, neu schreiben. Der resultierende "erfolgreiche Lauf" kann möglicherweise nicht reproduziert werden, da niemand sagen kann, welche Historie, Eingabeaufforderung, Werkzeugschema oder Modellkonfiguration ihn erzeugt hat. Der Verzweigungsdatensatz benötigt keinen Nachrichteninhalt: Hash Identifikatoren und grobe Bearbeitungsklassen reichen für eine Beweisspur aus. Exportiere keine Eingabeaufforderungen, Werkzeugargumente, Geheimnisse oder Benutzerdaten, nur um zu beweisen, dass ein Fork existiert. Stellen Sie die staatliche Abdeckung wieder her, bevor Sie den Plan ändern Das Löschen von Nachrichten aus einem Transkript ist keine Statuswiederherstellung. Das Papier sagt, dass AGDebugger Agenten Methoden zum Speichern und Laden von Status implementieren. Der Status eines Webagenten kann eine URL und eine Ansichtsfensterposition enthalten. Andere Agenten benötigen möglicherweise einen anderen Status. Es beschreibt auch die Checkpoint Richtlinie als "gut genug", da eine vollständige Wiederherstellung von Browser JavaScript und Remote Anwendungsstatus unpraktisch oder unmöglich sein kann. Diese Einschränkung sollte neben dem Reset Knopf stehen, nicht in einer Obduktion. Definieren Sie die für den Workflow erforderlichen Statusschlüssel, bevor ein Lauf gestartet wird. Für ein kleines Forschungs und Veröffentlichungsteam könnten sie sein: Dieser Prüfpunkt ist unvollständig, da die Genehmigungswarteschlange fehlt. Eine Transkriptwiedergabe könnte dazu führen, dass der Zweig erneut nachfragt, eine bestehende Entscheidung überspringt oder so tut, als ob die Autorität übertragen würde. Der Bediener sollte sehen restore uncertain , keine grüne Fortsetzungskontrolle. Abdeckung ist notwendig, aber nicht ausreichend. Zeichnen Sie für jeden Statusschlüssel einen revisions oder inhaltsfreien Fingerabdruck und ein Wiederherstellungsergebnis auf: Zustandsschlüssel Beweise vor dem Zurücksetzen Erforderlicher Wiederherstellungstest Agenten Speicher revisions und Checkpoint Hash geladene Revision passt zur Gabel Browser ursprung, Routen Hash und lokale Sitzungsklasse die erwartete Route ist erreichbar und die Sitzungsklasse ist gültig Arbeitsbereich repository Commit und Dirty State Digest exakte Revision plus absichtliche lokale Änderungen Werkzeug Registrierung schema Hash und Anzahl der Funktionen aktuelle Registrierungsübereinstimmungen oder Abweichungen werden bestätigt Genehmigungswarteschlange IDs und Status von Entscheidungsbelegen ausstehende und beschlossene Entscheidungen bleiben erhalten Ein Live Remote System hat sich möglicherweise seit dem Checkpoint bewegt. Das ist nicht immer ein Misserfolg. Es ist ein Grund, die Beweise zu kennzeichnen. Wenn der Browser zur aufgezeichneten Seite zurückkehren kann, der zugrunde liegende Datensatz der Seite jedoch geändert wurde, ist die Snapshot Genauigkeit unvollständig. Der Bediener kann weiterhin einen Diagnosezweig ausführen, muss ihn jedoch nicht als exakte Wiedergabe darstellen. Die Konfiguration ist Teil des Status. Fixieren Sie die Agentenrollen, Modellkennungen, Toolsets, Systemaufforderungen und Routing Regeln, die von der Zweigstelle verwendet werden. Ansonsten beweist ein erfolgreicher Schnitt nur, dass eine unbekannte Kombination funktioniert hat. Behalten Sie die ursprüngliche Konfiguration unverändert bei und zeichnen Sie das absichtliche Delta auf. Effekte abgleichen, bevor ein Toolaufruf wiedergegeben wird Ein Prüfpunkt stellt den Status unter der Kontrolle des Debuggers wieder her. Es kehrt die Außenwelt nicht um. Angenommen, der übergeordnete Zweig hat nach dem Checkpoint ein Ticket erstellt und dann den versprochenen öffentlichen Bericht nicht erstellt. Durch Zurücksetzen vor dem Toolaufruf und Wiederholen kann ein zweites Ticket erstellt werden. Das Ausbleiben einer Antwort ist kein Beweis dafür, dass der erste Anruf keine Wirkung hatte. Zählen Sie vor dem Fortsetzen jede Post Checkpoint Operation mit einem externen Effekt auf und klassifizieren Sie sie: reverted : der ursprüngliche Effekt wurde sicher rückgängig gemacht; reconciled : der Effekt bleibt erhalten und der neue Zweig wird ihn wiederverwenden oder überspringen; pending : Bestimmungsnachweis fehlt; irreversible : Der Effekt kann nicht rückgängig gemacht werden und bedarf einer neuen menschlichen Entscheidung. Alles pending oder irreversible blockiert die automatische Wiedergabe an dieser Grenze. Verwenden Sie stabile Betriebstasten, wenn das Ziel sie unterstützt. Fragen Sie für einen Veröffentlichungsvorgang das Ziel anhand einer unveränderlichen Entwurfs ID ab, bevor Sie eine andere erstellen. Behalten Sie bei einer E Mail die Anbieter Nachrichten ID ohne den Nachrichtentext bei. Vergleichen Sie bei einer Repository Änderung den erwarteten Commit oder Baum Hash. Rufen Sie für ein Ticket das Ticket mit dem Idempotenzschlüssel der Anforderung ab. Der Eingriff des Bedieners benötigt auch eine Autoritätsgrenze. Das Bearbeiten eines Plans ist risikoarm, wenn der Zweig auf ein lokales Gerät beschränkt ist. Es ist wesentlich anders, wenn die Bearbeitung Empfänger, Budget, Berechtigungen, Produktionsziele oder destruktive Aktionen ändert. Leiten Sie diese Änderungen an einen autorisierten Eigentümer weiter und behalten Sie den Zweig in needs approval bis der Entscheidungsbeleg eintrifft. Das Warten auf diese Entscheidung bleibt nicht hängen. Wiederholtes Fortsetzen, während der Autoritäts oder Zielstatus unbekannt ist, ist der Fehler. Führen Sie den Lenkungsbeleg gegen unbequeme Fälle aus Das begleitende Artefakt ist ein inhaltsfreier Fixture und deterministischer Klassifikator. Es führt keinen AGDebugger aus oder behauptet, seine Benutzerstudie zu reproduzieren. Es testet die operative Entscheidung, die einen Reset umgibt. Führen Sie es lokal aus: Das Gerät enthält acht Zweige. Der hergestellte Klassifikator: Der Test fügt eine neunte Behauptung hinzu: Ein Zweig, dessen ID gleich seinem übergeordneten Zweig ist, wird als abgelehnt invalid lineage . Der Vorrang ist beabsichtigt. Ein fehlender Status blockiert die Effektinterpretation, da der Bediener den Startpunkt der Verzweigung nicht festlegen kann. Unvereinbare Effekte blockieren die Wiederaufnahme, bevor die Genehmigung in Betracht gezogen wird. Genehmigung und eine angeheftete Konfiguration machen den Zweig bereit, nicht fehlerfrei. Nach der Wiederaufnahme benötigt das erwartete Ergebnis noch einen deterministischen Verifizierer. Ändern Sie ein Feld und das Ergebnis sollte sich vorhersehbar bewegen. Fügen Sie der Teilwiederherstellung den fehlenden Genehmigungswarteschlangenschlüssel hinzu, und sie kann fortfahren. Markieren Sie einen ausstehenden Ticketeffekt als abgeglichen und die Filiale kann das Behördentor erreichen. Setzen outcomeVerified zu falsch nach einer fließenden endgültigen Antwort und das Ergebnis bleibt false success . Dies ergibt eine wichtige betriebliche Unterscheidung: "Bereit zur Wiederaufnahme" bedeutet, dass die Interventionsgrenze kontrolliert wird. "Verifiziert" bedeutet, dass die neue Niederlassung die beabsichtigte Arbeit abgeschlossen hat. Verschmelzen Sie diese Staaten nicht zu einem grünen Abzeichen. Was das Experiment nicht beweist Das Artefakt validiert eine Entscheidungsregel, keine Schnappschusstreue. Es kann nicht bewiesen werden, dass ein Browser genau wiederhergestellt wurde, dass ein LLM denselben Pfad einschlagen wird oder dass ein undokumentierter Nebeneffekt nie aufgetreten ist. Eine echte Integration benötigt laufzeitspezifische Statusadapter und Zielabfragen. Die AGDebugger Studie hat ebenfalls einen begrenzten Umfang: fünf prägende Befragte, 14 Studienteilnehmer, zwei Studienaufgaben und ein auf AutoGen aufgebauter Forschungsprototyp. Seine Ergebnisse rechtfertigen das Interaktionsmuster; Sie legen keine Reduzierung der Incident Rate für jede Multiagenten Architektur fest. Das Papier selbst identifiziert offene Herausforderungen, einschließlich der Entkopplung der Steuerung von einer Agentenimplementierung und der Feststellung, ob eine Bearbeitung Auswirkungen hatte. Diese Grenzwerte stärken die Betriebsregel. Verwenden Sie interaktives Zurücksetzen, um eine Hypothese zu isolieren, nicht um Gewissheit herzustellen. Bewahren Sie das übergeordnete Element auf, verzweigen Sie es explizit, stellen Sie wieder her, was bewiesen werden kann, kennzeichnen Sie, was nicht möglich ist, versöhnen Sie externe Effekte, fordern Sie Autorität an und überprüfen Sie das neue Ergebnis am Zielort. Sidewisp befindet sich derzeit in einer privaten Vorschauphase. Die Produktionsüberwachungsadapter und der Recovery Executor werden im Allgemeinen nicht ausgeliefert. Die Methode hier ist ein überprüfbares Betriebsmuster, keine Behauptung, dass Sidewisp bereits Live Agententeams überprüft oder steuert. Die Produktausrichtung von Sidewisp hält die menschliche Autorität, Beweise und Ergebnisüberprüfung für die sichere Wiederherstellung von zentraler Bedeutung. Wenn Sie heute Multiagentensysteme betreiben, beginnen Sie mit einem fehleranfälligen Workflow. Definieren Sie die Statusschlüssel und das Ledger für externe Effekte vor dem nächsten Vorfall. Der erste nützliche Kontrollpunkt ist nicht derjenige, der den meisten Verlauf wiedergeben kann. Es ist derjenige, der genau erklären kann, was wiederhergestellt wurde, was geändert wurde, wer den Zweig autorisiert hat und wie das Endergebnis überprüft wurde.