AI SDK Agent Loop: Beweisen Sie, warum es gestoppt wurde

EinAI SDKDie Agentenschleife ist nicht fehlerfrei, nur weil sie zurückgekehrt ist. Eine Rückgabe beweist, dass ein Kontrollflusspfad beendet wurde: Das Modell wurde ohne einen weiteren Tool Aufruf beendet, ein Tool konnte nicht ausgeführt werden, eine Genehmigung war erforderlich oder eine konfigurierte Stoppbedingung wurde ausgelöst. Keine dieser Tatsachen beweist, dass die Rechnung erstellt, das Ticket aktualisiert wurde oder der Bericht sein Ziel erreicht hat. Die praktische Standardeinstellung besteht darin, die begrenzte Schleife des SDK beizubehalten, eine explizite Stoppursache aufzuzeichnen und das beabsichtigte externe Ergebnis separat zu überprüfen. Behandeln Sie eine Genehmigungsanfrage als Warten, einen Schritt oder eine Budgetobergrenze als begrenzten Stopp und ein natürliches Ende ohne Ergebnisbeleg als falschen Abschluss. Dieser Leitfaden ordnet das Verhalten dem Release zu [email protected] Paket undNode.js22.23.1. Die begleitende inhaltsfreie Wiedergabe übte die tatsächlich exportierten Stoppbedingungsfunktionen in elf Betriebsfällen aus. Alle elf Klassifizierungen und vier direkte SDK Behauptungen wurden bestanden. Das SDK kann aus mehreren legitimen Gründen gestoppt werden DerAI SDK Loop Control Leitfadennennt vier Terminierungsrouten: 1. Das Modell gibt einen anderen Endgrund als zurück tool calls ; 2. ein aufgerufenes Werkzeug hat keine execute Funktion; 3. ein Tool Aufruf muss genehmigt werden; 4. Eine konfigurierte Stoppbedingung gibt „true“ zurück. Diese Routen sollten nicht zu einer einzigen zusammenfallen completed: true Feld. Sie implizieren unterschiedliche Bedienhandlungen. Ein natürliches Finish ohne Werkzeug kann für eine Forschungsantwort durchaus gültig sein, für einen Workflow, dessen Vertrag eine Datei im Objektspeicher erfordert, jedoch unvollständig. Ein Werkzeug ohne execute kann bewusst strukturiert wirken done Signal, aber das Signal enthält, was das Modell behauptete – keinen unabhängigen Beweis dafür, dass eine Nebenwirkung erfolgreich war. Eine Genehmigungsanfrage ist eine absichtliche Pause. Eine Stufenobergrenze bedeutet, dass die Sicherheitsgrenze funktioniert hat, nicht, dass die Aufgabe fehlgeschlagen oder erfolgreich war. Die aktuelle Dokumentation sagt ToolLoopAgent Standardmäßig ist isStepCount(20) . Ersetzen Sie es durch isLoopFinished() Entfernt diese Bedingung zum Stoppen der Schrittzählung. Das kann für ein streng kontrolliertes lokales Experiment sinnvoll sein, aber es beseitigt auch eine einfache Grenze für Modellaufrufe und Kosten. Wenn der Antrag seine unabhängigen Frist , Budget und Stornierungskontrollen nicht erklären kann, ist die Beibehaltung der Standardobergrenze die sicherere Entscheidung. Drei kleine Implementierungsdetails ändern die Diagnose Die angeheftete VersionStoppbedingungsquelleist kurz genug, um direkt geprüft zu werden: isStepCount(n) ist wahr, wenn steps.length === n , nicht, wenn die Anzahl größer oder gleich ist n . hasToolCall(name) prüft Werkzeugaufrufe im zuletzt abgeschlossenen Schritt. isLoopFinished() Gibt als Stoppbedingung immer „false“ zurück und lässt eine natürliche Beendigung, ein nicht ausgeführtes Werkzeug oder die Genehmigung zum Beenden der Schleife zurück. Diese Semantik ist bei der Rekonstruktion eines Vorfalls von Bedeutung. Angenommen, eine Anwendung behält nur den endgültigen Text und die Gesamtschrittzahl bei. Ein Drei Schritte Lauf, der rief done im zweiten Schritt kann das später nicht mehr bewiesen werden hasToolCall("done") verursachte einen Abbruch, da die entsprechende Bedingung den letzten Schritt prüft. Auch eine Beobachtung von 21 Schritten zeigt dies nicht isStepCount(20) gefeuert; Dies ist ein Beweis dafür, dass die konfigurierte Richtlinie, die aufgezeichnete Anzahl oder die Laufgrenze von der Annahme abweicht. Behalten Sie die Bedingungseingaben und die ausgewählte Richtlinienversion beim Lauf bei. Schliessen Sie sie nicht im Nachhinein aus einem Dashboard ab. Erstellen Sie einen Stoppbeleg, bevor Sie einen Gesundheitszustand auswählen Eine nützliche Quittung ist klein. Es sind keine Eingabeaufforderungen, Modellantworten oder Rohtool Nutzlasten erforderlich: Der stopCause sollte aus der Integrationsgrenze stammen und nicht aus einer Vermutung auf der Grundlage endgültiger Prosa. Zeichnen Sie auf, ob der Lauf ein Nicht Werkzeug Ende erreicht hat, eine benannte Stoppbedingung erfüllt hat, eine Genehmigungsanforderung ausgegeben hat, ein nicht ausgeführtes Abschlusswerkzeug aufgerufen hat, abgebrochen wurde, eine Zeitüberschreitung hatte oder bei der Ausführung des Werkzeugs fehlgeschlagen ist. Wenden Sie dann eine Vorrangregel an: Beweis Zustand Betreiberentscheidung Die Ausführung des Tools ist fehlgeschlagen FAILED Diagnostizieren Sie die Werkzeuggrenze. Versuchen Sie es nicht blindlings mit einer unsicheren Nebenwirkung. Die Genehmigung mit Eigentümer, Frist und Lebenslauf Token steht noch aus WAITING Leiten Sie die Entscheidung weiter und bewahren Sie die Wiederaufnahmefähigkeit. Die Genehmigung steht ohne Routingdaten aus WAITING UNROUTED Fügen Sie einen Besitzer und einen Eskalationspfad hinzu, bevor die Wartezeit unsichtbar wird. Die Zeitüberschreitung ist ohne sinnvollen Fortschritt abgelaufen STUCK Überprüfen Sie den letzten dauerhaften Fortschritt und wählen Sie eine begrenzte Wiederherstellung aus. Schritt , Token oder Benutzerabbruchgrenze ausgelöst BOUNDED STOP Teilarbeit bewahren; Entscheiden Sie, ob ein neuer begrenzter Lauf gerechtfertigt ist. Natürliches Finish oder explizit done plus Ergebnisquittung VERIFIED COMPLETE Schließen Sie den Lauf. Natürliches Finish oder explizit done ohne Ergebnisquittung FALSE COMPLETE Überprüfen Sie das Ziel oder öffnen Sie die Aufgabe erneut. Signale stimmen nicht überein oder die Ursache wurde nicht erfasst UNCERTAIN Fragen Sie, bevor Sie handeln. Ordnung ist wichtig. Eine Zeitüberschreitung beim vierten Schritt bleibt auch dann eine Zeitüberschreitung, wenn die Schrittanzahl zufällig vier beträgt. Eine Genehmigungsanfrage sollte warten und nicht in einen allgemeinen unvollständigen Zustand versetzt werden. Ein natürliches Finish ohne Ergebnisse sollte auch dann falsch vollständig bleiben, wenn der Text selbstbewusst klingt. Wiederholen Sie die Richtlinie, ohne ein Modell aufzurufen Das Audit importierte die freigegebenen isStepCount , hasToolCall , Und isLoopFinished Funktionen. Es übergab inhaltsfreie Arrays abgeschlossener Schrittdatensätze und verknüpfte deren Ausgabe mit dem Empfangsklassifikator. Es war kein Modellaufruf, keine Eingabeaufforderung, kein Geheimnis oder kein externer Tooleffekt erforderlich. Vier Behauptungen legten die SDK Grenze fest: Das Spiel mit elf Fällen umfasste dann ein natürliches Ende mit und ohne Ergebnis. done mit und ohne Ergebnis, Schrittobergrenze, Token Budget, weitergeleitete und nicht weitergeleitete Genehmigung, Toolfehler, Zeitüberschreitung und Benutzerabbruch. Die aufschlussreichen Paare waren keine exotischen Fehlschläge. Beide Einbauten mit natürlichem Finish hatten identische Kontrollflussursachen; Nur derjenige, der eine Empfangsquittung trug, wurde VERIFIED COMPLETE . Die gleiche Spaltung trat für auf done Werkzeug. Das ist das zentrale falsifizierbare Ergebnis: Wenn sich allein die Schleifenbeendigung als sinnvolle Vervollständigung erwiesen hätte, hätten diese gepaarten Spielpaarungen das gleiche gesunde Urteil erhalten müssen. Das taten sie nicht. Überprüfen Sie das Ziel, nachdem der Kontrollfluss gestoppt wurde DerToolLoopAgent Referenzmacht abgeschlossene Schritte für das generierte Ergebnis verfügbar und akzeptiert abortSignal und Timeout Kontrollen. Diese Felder sind nützliche Beweise, aber die Anwendung definiert immer noch den Erfolg. Wählen Sie die günstigste deterministische Prüfung, die die tatsächliche Anfrage des Benutzers beantwortet: Überprüfen Sie für eine Datei den erwarteten Pfad oder Objektschlüssel, den Inhaltstyp, die Mindestgröße und einen aufgabenspezifischen Hash oder ein Schema. Lesen Sie bei einer Datenbankmutation den Zieldatensatz und vergleichen Sie die vorgesehenen Felder. Behalten Sie für eine Nachricht den Anbieterempfang und die Zielidentität bei. Überprüfen Sie für eine Bereitstellung die unveränderliche Version, die öffentliche Gesundheitsreaktion und die Route für den Benutzer. Überprüfen Sie für eine Analyse die erforderlichen Abschnitte, die Quellenabdeckung und die maschinenlesbare Ausgabe, bevor Sie Prosa akzeptieren. Machen Sie den Ergebnisbeleg nicht zu einer zweiten Kopie der Aussage des Modells. {"status":"done"} von derselben Schleife ausgegeben wird, ist keine unabhängige Überprüfung. Die Quittung sollte vom Ziel, einem deterministischen Prüfer oder einer menschlichen Entscheidung stammen, wenn das Ergebnis nicht sicher per Code überprüft werden kann. Auch für die Genehmigung ist eine gesonderte Grenze erforderlich. Die SDK Dokumentation zeigt, dass eine Genehmigungsanfrage gesammelt, als Genehmigungsantwort an die Konversation angehängt und an einen nachfolgenden Anruf weitergeleitet werden kann. Operativ bedeutet das, dass beim Warten genügend Kontext erhalten bleiben muss, um dieselbe Entscheidung fortzusetzen. Ein Besitzer ohne Lebenslauf Token erstellt manuelle Rekonstruktionsarbeiten; Ein Token ohne Besitzer erstellt eine unsichtbare Warteschlange. Was diese Wiederholung nicht beweist Das Experiment hat kein Anbietermodell aufgerufen, keine Teilausgabe gestreamt oder ein externes Tool ausgeführt. Es werden daher kein anbieterspezifisches Endgrundverhalten, Netzwerkabbruchzeitpunkt oder Nebeneffekt Idempotenz ermittelt. Diese gehören zu Integrationstests rund um das eigentliche Modell, die Tools und das Ziel. Es wird auch kein universeller Schritt oder ein Token Limit empfohlen. Eine vierstufige Suche und eine vierzigstufige Migration haben unterschiedliche Umschläge. Die betriebliche Anforderung besteht darin, dass die ausgewählten Grenzen explizit sind, aufgezeichnet und bei Erreichen an eine sichere Aktion gebunden sind. Die Regel ist enger und dauerhafter: Behalten Sie bei, warum die Schleife gestoppt wurde, halten Sie legitime Wartezeiten von Fehlern fern und fordern Sie einen Zielnachweis, bevor ein sinnvoller Abschluss erklärt wird. Sidewispist eine KI Agenten Gesundheitsplattform, die die Überprüfung von Beweisen, Wartezuständen, begrenzter Wiederherstellung und Ergebnisüberprüfung über bestehende Laufzeiten hinweg erleichtern soll. Erfassung der Gesundheit des Produktionsagenten undAI SDKÜberwachung werden heute in der Regel nicht ausgeliefert. Sidewisp befindet sich derzeit in einer privaten Vorschauphase. Wenn diese Beendigungsbestätigung mit einem Fehlermodus in Ihren eigenen Agenten übereinstimmt, ist die Warteliste für die private Vorschau der geeignete Ort, um die benötigte Laufzeit und Beweisgrenze freizugeben.