# Wie testen Sie Streaming- und Tool-Kompatibilität vor einem Wechsel der LLM-API? > Testen Sie eine LLM-API-Migration mit aufgezeichneten Vertragsfällen statt mit einer Chat-Demo. Prüfen Sie Text-Streaming, ein erzwungenes Tool, fragmentierte Argumente, mehrere Aufrufe, Fortsetzung nach Ergebnissen, Abbruch, Fehler und Nutzungsdaten, bevor Sie echte Coding-Arbeit senden. Ein zehnminütiger Chattest kann wichtige Fehler übersehen: doppelte Aufrufe nach einer Wiederholung, JSON-Ausführung vor dem letzten Ereignis, Tool-Ergebnisse in der falschen Rolle oder ein Abbruch, der eine Schreibaktion weiterlaufen lässt. Eine gute Migrationsschranke sendet feste Anfragen durch den echten Parser und Executor und bewertet strukturelle Invarianten. Die erste Suite sollte klein, deterministisch und zwischen Modellen vergleichbar sein. Sie bewertet nicht Intelligenz, sondern belegt, dass die neue API die bestehende Agent-Schleife sicher steuern kann. ## Den benötigten Vertrag definieren Beschreiben Sie das genaue Verhalten des Clients, bevor Sie den Anbieter testen. Vermeiden Sie vage Aussagen wie „OpenAI-kompatibel“. | Bereich | Erforderliche Invariante | Aufzubewahrender Nachweis | |---|---|---| | Authentifizierung | Der erwartete Endpoint akzeptiert den Schlüssel | Status und Request-ID | | Text-Stream | Deltas ergeben eine finale Nachricht | Geordnete Rohereignisse | | Tool-Stream | Aufruf endet vor der Ausführung | Puffer und finales Ereignis | | Korrelation | Ergebnis gehört zum richtigen Aufruf | ID-Zuordnung | | Wiederholung | Jeder Aufruf läuft höchstens einmal | Idempotenzprotokoll | | Nutzung | Zähler sind vorhanden oder als nicht verfügbar markiert | Finale Metadaten | Die Unterstützung ist modellspezifisch. Atlas Cloud bietet mehrere Formate; prüfen Sie die aktuelle [`supported_apis`-Dokumentation](https://www.atlascloud.ai/docs/llm-protocols?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=test-streaming-tool-call-compatibility-before-changing-llm-apis), bevor Sie eine Route wählen. ## Vier deterministische Tools erstellen Verwenden Sie Fälle, die unterschiedliche Fehler sichtbar machen: * `echo_json`: gibt validierte Argumente unverändert zurück. * `read_fixture`: liest eine bekannte Datei aus der Sandbox. * `delayed_value`: endet nach einer kontrollierten Verzögerung. * `always_error`: liefert einen stabilen strukturierten Fehler. Nutzen Sie strikte Schemas mit `additionalProperties: false` und einer eindeutigen ID für doppelte Ausführungen. Kein Fall sollte von Wetter, Suche oder einem veränderlichen Repository abhängen. ## Eine stufenweise Matrix ausführen Testen Sie ohne Streaming vor Streaming und einen Aufruf vor mehreren. | Stufe | Verhalten | Bestehensbedingung | |---|---|---| | A | Text zurückgeben | Finaler Text und Stop-Status treffen ein | | B | `echo_json` erzwingen | Name und gültige Argumente treffen ein | | C | `echo_json` streamen | Fragmente werden einmal zusammengesetzt | | D | Zwei Lese-Tools aufrufen | Beide Ergebnisse werden korrekt zugeordnet | | E | Einen Fehler empfangen | Modell repariert oder beendet sauber | | F | Im Stream abbrechen | Keine späte Tool-Ausführung | Behalten Sie Schema und Absicht für alle Kandidaten bei. Erfordert das native Protokoll eine andere Hülle, passen Sie nur die Netzwerkdarstellung an. ## Ereignisse unterhalb des SDK erfassen High-Level-Objekte sind praktisch, können Unterschiede aber verbergen. Ergänzen Sie einen Debug-Transport, der jedes Ereignis mit Sequenznummer, Response-ID, Output-Index, Call-ID, Typ und Länge des ausgeblendeten Payloads protokolliert. Streaming-Argumente sind inkrementell. Setzen Sie sie pro Aufruf zusammen und warten Sie auf das finale Ereignis. Diese Zustandsmaschine ist sicherer als die Analyse jedes Fragments: ```text START -> CALL_OPEN -> ARGUMENT_DELTAS -> CALL_DONE -> VALIDATED -> EXECUTED | | +-> CANCELLED <---+ ``` Verwerfen Sie rückwärts laufende Übergänge und doppelte Ausführungen. Bricht die Verbindung nach `EXECUTED`, aber vor der Ergebnisübergabe ab, verwenden Sie einen Idempotenzschlüssel statt eine Schreibaktion zu wiederholen. ## Den vollständigen Rückweg testen Ein gültiger Aufruf ist nur die Hälfte des Vertrags. Geben Sie das Ergebnis im erwarteten Nachrichtentyp zurück und verlangen Sie eine finale Antwort, die ein bekanntes Feld daraus verwendet. Testen Sie große und leere Ergebnisse, Unicode und strukturierte Fehler. Begrenzen Sie die Größe vor der Rückgabe in den Kontext; die Migration kann korrekt wirken, bis ein Tool eine Adapterannahme überschreitet. ## Invarianten statt Formulierungen vergleichen Lassen Sie den Test nicht scheitern, weil zwei Modelle unterschiedlich schreiben. Prüfen Sie beobachtbare Eigenschaften: * Das erwartete Tool wurde ausgewählt. * Argumente bestanden JSON Schema. * Alle IDs waren eindeutig und zugeordnet. * Jedes Tool lief wie vorgesehen null- oder einmal. * Die Schleife endete innerhalb des Budgets. * Die finale Antwort nutzte das Testergebnis. Bewahren Sie kandidatspezifische Snapshots nur zur Diagnose auf und halten Sie die Kriterien anbieterneutral. ## Fehler- und Abbruchfälle hinzufügen Trennen Sie nach dem ersten Fragment, nach dem Aufrufabschluss und nach der Ausführung. Injizieren Sie 429, Timeout, ungültiges JSON und unbekannte Tool-Namen. Prüfen Sie, ob der Client sicher wiederholt, fortsetzt oder mit hilfreichem Fehler stoppt. Am gefährlichsten ist eine mehrdeutige Wiederholung, die eine zustandsändernde Aktion erneut ausführt. Verlangen Sie explizite Idempotenz und lassen Sie den Test scheitern, wenn die Ausführungsidentität unbekannt ist. ## Die Suite als Release-Schranke nutzen Behalten Sie einen schnellen Test für jede Konfigurationsänderung und eine vollständige Matrix für SDK- oder Gateway-Updates. Speichern Sie Modell, Protokoll, Base URL, Schema-Hash, Streaming-Flag, Clientversion und Zeitpunkt. Atlas Cloud unterstützt Anfragen mit und ohne Streaming und zeigt Kandidaten in einem [Modellkatalog](https://www.atlascloud.ai/llm-models?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=test-streaming-tool-call-compatibility-before-changing-llm-apis). Führen Sie dieselbe Schranke für jedes Modell aus, denn gemeinsamer Zugriff bedeutet keine identischen Fähigkeiten. ## Fazit Testen Sie eine LLM-Migration als zustandsbehaftete Protokolländerung. Verwenden Sie deterministische Tools, protokollieren Sie Rohereignisse, setzen Sie Argumente erst am Ende zusammen, prüfen Sie den Rückweg und injizieren Sie Wiederholungen und Abbrüche. Aktivieren Sie das neue Modell erst nach bestandenem Vertragstest. ## FAQ ### Was sollte der erste Kompatibilitätstest abdecken? Beginnen Sie mit einer Textanfrage ohne Streaming und einem erzwungenen Read-only-Aufruf. Damit isolieren Sie Endpoint-, Authentifizierungs-, Schema- und grundlegende Antwortprobleme. ### Warum sollten rohe Streaming-Ereignisse protokolliert werden? SDK-Helfer können Reihenfolge und Feldunterschiede verbergen. Rohe Ereignisse zeigen, wie IDs, Fragmente, Abschlussmarker, Fehler und Nutzung tatsächlich eintreffen. ### Kann ich Anbieter anhand identischer Texte vergleichen? Meist nicht. Vergleichen Sie strukturelle Invarianten wie gültige Aufrufe, Pflichtfelder, Ausführungszahl, Endstatus und Aufgabenergebnis. ### Wie teste ich fehlerhafte Tool-Argumente? Geben Sie einen strukturierten Validierungsfehler zurück und prüfen Sie, ob die Schleife innerhalb eines festen Budgets repariert oder beendet, ohne unsichere Eingaben auszuführen. ### Sollte die Suite Schreib-Tools verwenden? Beginnen Sie mit deterministischen Read-only-Tools. Fügen Sie einen isolierten Schreibfall erst hinzu, wenn Montage, Validierung, Deduplizierung und Fehlerbehandlung bestehen. ### Wie oft sollten die Tests laufen? Führen Sie vor jedem Modell- oder Protokollwechsel eine kleine Auswahl aus und bei Änderungen an SDK, Schema, Gateway oder Parser die vollständige Suite.