DeepSeek V3.2 mit Tools: So prüfen Sie den Reasoning-Zustand, bevor Sie einen Agenten weiterbetreiben oder migrieren

Die operative Frage: Bewahrt die Integration den richtigen Zustand?

DeepSeek V3.2 erhielt laut der Ankündigung des Anbieters und dessen Tool-Dokumentation Unterstützung für Tool-Aufrufe im Thinking-Modus. Daraus ergibt sich eine konkrete technische Frage: Wenn der Assistent ein Tool anfordert, die Anwendung es ausführt und das Ergebnis an das Modell zurückgibt – wird der von der API benötigte Zustand in der nächsten Anfrage erhalten? Die Antwort lässt sich weder am Modellnamen noch anhand einer einzelnen Demo ablesen. Geprüft werden müssen der Nachrichtenvertrag und die Antworten, die die Anwendung tatsächlich verarbeitet.

Diese Analyse hat einen eng umrissenen Zweck: eine bestehende Integration zu prüfen oder festzustellen, welche Nachweise fehlen, bevor das Team sie weiterbetreibt oder einen Wechsel plant. Es geht weder darum, die allgemeine Intelligenz des Modells zu messen, noch darum, Benchmarks zu vergleichen oder Rückschlüsse auf seine internen Denkprozesse zu ziehen. Ein Tool-Aufruf, der in einem manuellen Test korrekt aussieht, beweist nicht, dass der Dienst auch Wiederholungsversuche, Streaming, unerwartete Ergebnisse oder den nächsten Nutzerturn zuverlässig verarbeitet.

Laut der DeepSeek-Dokumentation muss bei Tool-Nutzung im Thinking-Modus in den einschlägigen Folgeanfragen desselben Turns das Feld `reasoning_content` zusammen mit dem relevanten Zustand zurückgegeben werden. Der Anbieter dokumentiert außerdem, dass das Weglassen dieses Feldes unter den beschriebenen Bedingungen einen 400-Fehler auslösen kann. Das ist praktisch bedeutsam: Eine Middleware, die den Gesprächsverlauf neu zusammensetzt, Felder herausfiltert oder Formate konvertiert, kann die Abfolge beschädigen, obwohl die erste Anfrage funktioniert.

Ob eine Modellkennung verfügbar ist, ist eine andere Frage als die Korrektheit des Ablaufs. DeepSeek stellt einen Endpunkt bereit, über den verfügbare Modelle abgefragt werden können. Das Ergebnis sollte am Datum des Tests und in der konkreten Umgebung geprüft werden; es lässt sich weder aus einem statischen Beispiel noch aus dem Namen einer Dokumentationsseite ableiten. Ebenso belegt ein Verweis auf V4 im Transparency Center nicht, dass eine bestimmte Kennung für ein Konto freigeschaltet ist oder dass eine Integration ohne Anpassungen auf sie wechseln kann.

Den Ablauf rekonstruieren, ohne Nachrichten zu verlieren

Ein belastbarer Test beginnt damit, den Ablauf als explizite Sequenz darzustellen. Die Anwendung sendet Nachrichten an das Modell; dieses kann eine Tool-Anforderung zurückgeben; die Anwendung führt den freigegebenen Vorgang aus und ergänzt das Ergebnis als Tool-Nachricht; anschließend sendet sie die Fortsetzung an das Modell. Bei einer Interaktion mit Thinking-Modus und Tools verlangt die DeepSeek-Anleitung zusätzlich, `reasoning_content` in den einschlägigen Folgeanfragen zu erhalten. Die genauen Details hängen vom API-Format und der Form der Antwort ab. Prüfen Sie daher die Dokumentation des Endpunkts, den die Integration tatsächlich verwendet.

Reduzieren Sie den Verlauf nicht auf eine Aussage wie „Das Modell wollte suchen“. Bewahren Sie in den Testprotokollen die Rollenfolge, gegebenenfalls die Aufrufkennungen, die ausgegebenen Argumente, das jedem Aufruf zugeordnete Ergebnis und die Felder auf, welche die Integration weitergegeben hat. Wenn das Produkt die Antwort vor dem Speichern umformt, protokollieren Sie auch diese Transformation oder einen vergleichbaren Fingerabdruck. So lässt sich unterscheiden, ob ein Fehler vom Modell, von einer durch Middleware entfernten Nachricht, einer falsch zugeordneten Anfrage oder einem Ergebnis stammt, das die nächste Anfrage nie erreicht hat.

Chat Completions darf nicht mit anderen von DeepSeek dokumentierten Formaten verwechselt werden. Die Tool-Anleitung unterscheidet, wie Aufrufe in Chat Completions, der Anthropic API und der Responses API eingefügt werden. Wer das Format wechselt, sollte nicht annehmen, dass ein bloßes Umbenennen von Feldern genügt. Reihenfolge, Darstellung der Aufrufe und die Art, wie die jeweilige Schnittstelle eine Fortsetzung ausdrückt, müssen überprüft werden.

Die Anforderung, Zustand zu erhalten, bedeutet auch nicht, dass in jedem beliebigen Turn auf unbestimmte Zeit alle generierten Inhalte erneut gesendet werden müssen. Die Dokumentation zum Thinking-Modus unterscheidet Anfragen mit Tools von Gesprächen ohne Tools. Deshalb sollte das Testprotokoll eine Fortsetzung im selben Turn und einen neuen Nutzerturn getrennt prüfen. Inhalte sollten weder aus dem Bauch heraus gelöscht noch pauschal beibehalten werden: Maßgeblich sind das dokumentierte Format und kontrollierte Anfragen.

Ein reproduzierbares Testprotokoll mit simulierten Tools

Bevor Sie echte Tools testen, richten Sie kontrollierte Test-Doubles ein, die bekannte Ergebnisse zurückgeben. Ein simuliertes Tool verringert das Risiko, Daten zu verändern, externe Dienste aufzurufen oder eine veränderliche Antwort mit einer Regression zu verwechseln. Legen Sie vorab fest, was als bestanden gilt: etwa, dass die Anwendung einen gültigen Aufruf genau einmal ausführt, das Ergebnis diesem Aufruf zuordnet und die Fortsetzung mit den erforderlichen Feldern übermittelt. Die genaue Vorgabe hängt vom Produkt ab und sollte vor dem Test schriftlich feststehen.

Beginnen Sie mit einem einzelnen Tool und einer einfachen Anfrage. Prüfen Sie, ob die Anwendung den Aufruf erkennt, Name und Argumente validiert, den simulierten Vorgang ausführt und die entsprechende Antwort ergänzt. Kontrollieren Sie anschließend, ob die nächste Anfrage den erforderlichen Zustand bewahrt und das Modell auf Grundlage des Ergebnisses antwortet. Eine plausible Endantwort allein reicht nicht aus: Vergleichen Sie die aufgezeichnete Sequenz mit der Sequenz, die die Anwendung tatsächlich senden sollte.

Verketten Sie danach zwei Tools: Das erste liefert einen Wert, den das zweite benötigt. Dieser Fall zeigt, ob die Anwendung den Turn zu früh beendet, ein veraltetes Ergebnis erneut sendet oder einen bereits ausgeführten Aufruf fälschlich als neu behandelt. Gehen Sie nicht davon aus, dass das Modell stets die gewünschte Reihenfolge wählt. Entscheidend ist, dass der Orchestrator die eingehenden Anforderungen sicher verarbeitet und jeder Aufruf eindeutig seinem Ergebnis zugeordnet bleibt.

Testen Sie auch den Streaming-Modus. Die DeepSeek-Dokumentation enthält Beispiele für Streaming im Thinking-Modus; dennoch muss eine Integration ihren eigenen Ereignis-Parser prüfen. Eine unvollständige Antwort ist nicht zwangsläufig ein vollständiger und ausführbarer Tool-Aufruf. Sammeln und analysieren Sie die Ausgabe gemäß dem dokumentierten Format. Führen Sie ein Tool erst aus, wenn die erforderliche Struktur vollständig empfangen und validiert wurde. Protokollieren Sie Fragmente und das relevante Abschlussevent, ohne anzunehmen, dass der in der Benutzeroberfläche angezeigte Text allein den Protokollzustand abbildet.

Fehlerhafte Argumente müssen als nicht vertrauenswürdige Eingaben behandelt werden – auch dann, wenn das Modell sie erzeugt hat. Testen Sie fehlende Felder, unerwartete Typen, Werte außerhalb des zulässigen Bereichs und unbekannte Tool-Namen. Die Anwendung sollte Eingaben, die dem eigenen Schema nicht entsprechen, kontrolliert ablehnen oder weiterleiten. Die Modellausgabe erteilt keine Berechtigungen: Autorisierung, Grenzen und Validierung liegen in der Verantwortung der Anwendung.

Nehmen Sie leere Ergebnisse, simulierte Fehler und widersprüchliche Antworten in die Tests auf. Der Agent sollte keinen erfolgreichen Vorgang behaupten, wenn das Tool einen Fehler gemeldet hat, und keine Aktion mit Nebenwirkungen ohne eine festgelegte Idempotenzregel wiederholen. Legen Sie für widersprüchliche Ergebnisse fest, welche Quelle Vorrang hat und ob eine Rückfrage oder ein Eingreifen durch Menschen nötig ist. Das sind Produktentscheidungen, keine Eigenschaften, die durch das Vorhandensein von `reasoning_content` garantiert werden.

Fehler, die die Anwendung erkennen können muss

Der erste Fehler besteht darin, beim Erstellen einer Fortsetzung den erforderlichen Zustand wegzulassen. Die Anleitung zum Thinking-Modus dokumentiert für den Tool-Fall einen 400-Fehler, wenn `reasoning_content` unter den dort beschriebenen Bedingungen fehlt. Protokollieren Sie den Antwortcode und die bereinigte ausgehende Anfrage; wiederholen Sie die Anfrage nicht unverändert in einer Schleife. Die Korrektur muss sich aus der tatsächlich gesendeten Nachrichtenstruktur und der aktuellen Spezifikation ergeben.

Ein zweiter Fehler ist, denselben Vorgang zweimal auszuführen. Das kann passieren, wenn die Anwendung nach einem Verbindungsabbruch wiederholt, ohne zu wissen, ob das Tool bereits Nebenwirkungen ausgelöst hat, oder wenn sie Streaming-Fragmente als unabhängige Anforderungen interpretiert. Die Gegenmaßnahme hängt von der Art des Tools ab: Verwenden Sie bei Bedarf Operationskennungen, Deduplizierung oder eine Bestätigung durch Menschen. Für ein Tool, das nur liest, und eine Geldüberweisung gelten nicht zwangsläufig dieselben Regeln.

Suchen Sie außerdem nach Schleifen: Das Modell fordert erneut eine gleichwertige Aktion an, das Tool-Ergebnis wird nicht übernommen oder der Orchestrator hält an einem veralteten Zustand fest. Definieren Sie Obergrenzen für Iterationen und Laufzeit und stellen Sie einen kontrollierten Abbruch bereit, wenn sie erreicht sind. Eine Grenze garantiert keine korrekte Antwort, verringert aber das Risiko, dass ein Integrationsfehler zu unbegrenztem Verbrauch oder wiederholten Nebenwirkungen führt.

Eine vierte Fehlerklasse entsteht, wenn Argumente und Ergebnisse nur auf der Modellseite validiert werden. Der Client muss Schema, Tool-Namen, Nutzerberechtigungen und Umfang des Vorgangs prüfen. Ebenso muss er mit partiellen, leeren oder nicht zum erwarteten Format passenden Ergebnissen umgehen. Das Modell kann bei der Interpretation der Informationen helfen, aber die Anwendung bleibt dafür verantwortlich, welche Aktionen sie ausführt.

Unterscheiden Sie schließlich einen API-Fehler von einem Geschäftsfehler. Bei einem 400-Fehler, der die Form der Anfrage betrifft, muss der übermittelte Vertrag geprüft werden; ein Tool-Fehler kann auf Berechtigungen, Konnektivität oder Daten zurückgehen. Protokollieren Sie in beiden Fällen die Kategorie und die Stelle im Ablauf, an der der Fehler auftrat. Stellen Sie keine Ursache als bestätigt dar, wenn die Aufzeichnungen keine eindeutige Unterscheidung zulassen.

Was protokolliert und was eingeschränkt werden sollte

Damit eine andere Person einen Fehler reproduzieren kann, protokollieren Sie Datum, Umgebung, angeforderte Modellkennung, Modus, API-Format, relevante Optionen und Nachrichtenfolge. Ergänzen Sie Tool-Anfragen und -Antworten, Fehler, Dauer und Token, sofern die API-Antwort diese Angaben bereitstellt. Vermerken Sie außerdem, ob Streaming verwendet wurde und wie der Client die Antwort zusammengesetzt hat. Ein Protokoll, aus dem nicht hervorgeht, an welcher Stelle ein Feld verloren ging oder verändert wurde, kann genau den Fehler verbergen, den Sie suchen.

Minimieren Sie personenbezogene Daten und Geheimnisse. Schwärzen Sie Zugangsdaten, sensible Kennungen und Inhalte, die für die Diagnose des Ablaufs nicht erforderlich sind. Verwenden Sie nach Möglichkeit simulierte Tools zur Reproduktion. Legen Sie entsprechend den Richtlinien des Teams Zugriffskontrollen und Aufbewahrungsfristen fest. Speichern Sie nicht pauschal den gesamten Verlauf aus der Produktion, nur weil dies eine einzelne Fehlersuche erleichtern könnte.

Behandeln Sie `reasoning_content` mit besonderer Vorsicht. Die Dokumentation benennt es als relevantes Feld für den API-Austausch in bestimmten Abläufen. Dadurch wird es jedoch nicht zu einem zuverlässigen Nachweis dafür, dass das Modell einer vollständigen oder zutreffenden Gedankenkette gefolgt ist. Sein Inhalt kann sensibel sein und sollte nicht ohne Weiteres angezeigt oder gespeichert und nicht wie ein Audit des internen Prozesses als Bewertung einer Erklärung verwendet werden. Wenn Sie das Verhalten prüfen müssen, verwenden Sie kontrollierte Eingaben, beobachtbare Aufrufe, Ergebnisse und Abnahmekriterien.

Trennen Sie in den Protokollen Beobachtungen von Deutungen. „Die gesendete Fortsetzungsanfrage enthielt das Feld nicht“ ist eine überprüfbare Beobachtung, sofern das entsprechende Protokoll vorliegt. „Das Modell hat vergessen, was es dachte“ ist dagegen eine spekulative und anthropomorphisierende Erklärung. Diese Trennung verhindert, dass eine Hypothese ohne ausreichende Belege zu einer betrieblichen Diagnose wird.

Weiterbetreiben, korrigieren oder eine Migration vorbereiten

Eine Entscheidung über den Weiterbetrieb sollte sich auf Belege aus der tatsächlichen Umgebung stützen. Fragen Sie den offiziellen Modell-Listen-Endpunkt mit den Zugangsdaten und Berechtigungen ab, die die Anwendung verwenden wird, protokollieren Sie die zurückgegebene Kennung und wiederholen Sie die Abfrage in der Deployment-Umgebung. Die Spezifikationsseite beschreibt den Endpunkt, ersetzt aber keine aktuelle Abfrage: Ein Beispiel oder ein historischer Verweis bestätigt nicht die Verfügbarkeit für ein bestimmtes Konto. Prüfen Sie außerdem den konfigurierten Alias im Vergleich zu einer festgelegten Version und dokumentieren Sie, welches Verhalten die Integration erwartet.

Die öffentliche Chronologie kann die Untersuchung unterstützen, aber nicht allein entscheiden. DeepSeeks Transparency Center führt V3.2 und V4 mit Veröffentlichungsinformationen auf; im Änderungsprotokoll lassen sich Änderungen an Aliasnamen und angekündigte Einstellungen nachlesen. Prüfen Sie vor einer Migration in diesen Quellen, welche Kennung verfügbar ist und welche Änderung angekündigt wurde, und bestätigen Sie das Ergebnis mit der API Ihres Kontos. Die vorliegenden Dokumentationsangaben rechtfertigen weder die Annahme eines automatischen Migrationspfads noch eine Behauptung funktionaler Gleichwertigkeit zwischen Modellen.

Die Tool-Anleitung erläutert Unterschiede zwischen Schnittstellen. Auch ein Formatwechsel muss deshalb als Integrationsänderung behandelt werden. Führen Sie dieselbe Regressionsbatterie auf dem bestehenden und dem vorgesehenen Pfad aus: einzelner Aufruf, verkettete Aufrufe, Streaming, ungültige Eingaben, Tool-Fehler und Fortsetzung in einem neuen Turn. Vergleichen Sie produktspezifische Kriterien statt eines allgemeinen Eindrucks. Prüfen Sie Berechtigungen, Latenz, Fehler und Kosten anhand der für Ihre Organisation relevanten Maßstäbe; verwechseln Sie syntaktische Kompatibilität nicht mit gleichwertigem Verhalten.

Wenn die Integration die Tests besteht und die Modellkennung weiterhin verfügbar ist, kann ein Weiterbetrieb vertretbar sein – abhängig von der Supportpolitik und dem akzeptablen Risiko des Teams. Scheitert sie wegen eines Zustandsverlusts, beheben Sie den Fehler und führen Sie die Tests erneut aus, bevor Sie über das Modell entscheiden. Wird eine Migration vorbereitet, halten Sie einen erprobten Rückweg bereit, begrenzen Sie die erste Ausrollung und definieren Sie Signale, die den Wechsel stoppen. Das sind Empfehlungen für den Betrieb, keine Zusicherungen des Anbieters.

Die hilfreiche Schlussfolgerung lautet nicht, dass `reasoning_content` den Agenten „erklärt“, sondern dass es unter den dokumentierten Bedingungen Teil eines Vertrags ist, der ausdrücklich getestet werden sollte. Ein Team kann fundierter entscheiden, wenn es über eine reproduzierbare Sequenz, vorab festgelegte Kriterien, minimierte Protokolle und eine aktuelle Verfügbarkeitsprüfung verfügt. Fehlt einer dieser Nachweise, sollte die verbleibende Unsicherheit in der Entscheidung festgehalten werden.

Weiter entdecken

Korrekturen und Transparenz

Wenn du falsche oder veraltete Angaben findest, sende uns die Seite und die zu prüfende Quelle.