Kimi K3 Tool Calls Schleife: Stopp-Anleitung 2026

Kimi K3 Tool Calls Schleife: Erst stoppen, dann reparieren

Symptom: Ihr AI Agent ruft dieselbe Funktion erneut auf, obwohl das Werkzeug bereits ein Ergebnis geliefert hat.
Schnellste Lösung: Speichern Sie sofort die vollständige Nachrichtenkette, prüfen Sie assistant, tool_call_id, Tool-Ergebnis und Streaming-Argumente und aktivieren Sie bis zur Klärung einen sicheren Lesemodus.

Die offizielle Kimi-Fehlerbehebung nennt bei identischen Tool-Aufrufen drei aufeinanderfolgende Wiederholungen als Anlass für eine erste Erinnerung, fünf als Anlass für eine stärkere Warnung und acht als erneuten Eskalationspunkt. Diese Werte sind dokumentierte Hinweise für die Erkennung, aber keine allgemeingültigen Produktionslimits für jeden Agenten. (Kimi-API-Fehlerbehebung)

Sie sollten daher nicht mit einem neuen Prompt beginnen. Bei einer Kimi K3 Tool Calls Schleife ist zuerst zu klären, ob das Modell tatsächlich wiederholt entscheidet oder ob Ihr Client dieselbe Antwort erneut verarbeitet.

Diese Anleitung ist für drei Gruppen gedacht:

• Entwickler, die mit der Kimi K3 API einen Tool-basierten AI Agent bauen.
• Plattformteams, die unbeaufsichtigte Workflows mit kontrollierter Wiederaufnahme betreiben.
• Teams, deren Tools E-Mails versenden, Bestellungen anlegen, Zahlungen auslösen oder Daten verändern.

Wichtiger Stopp: Werkzeuge mit Schreibzugriff, Versand oder Zahlung werden bis zur Beweisaufnahme auf einen Lesemodus, eine Sandbox oder eine simulierte Ausführung umgestellt. Ein Prompt kann eine Schleife beeinflussen, aber keine doppelte Buchung zurückholen.

Meilenstein 0: Beweiskette sichern

Bevor Sie Code ändern, speichern Sie einen vollständigen, datenschutzkonformen Ablauf. Entfernen oder maskieren Sie API-Schlüssel, personenbezogene Daten, Kundennummern, interne URLs und echte Geschäfts-IDs. Für die spätere Analyse brauchen Sie trotzdem eine stabile Korrelation zwischen API-Anfrage, Modellantwort und Werkzeugausführung.

Erfassen Sie mindestens:

• die gesendete messages-Liste in der tatsächlich übertragenen Reihenfolge,
• den Modellnamen und die verwendeten Tool-Definitionen,
• finish_reason,
• jede tool_call_id,
• function.name,
• den vollständigen function.arguments-String,
• das Ergebnis des Werkzeugs,
• eine interne Werkzeug-Ausführungs-ID,
• request_id und API-Nutzungsdaten, soweit Ihr Client sie erhält.

Die zentrale Unterscheidung lautet: Sehen Sie eine doppelte Darstellung im Frontend, einen SDK- oder Netzwerk-Wiederholungsversuch oder eine echte neue Modellantwort mit demselben Tool und denselben Argumenten? Ohne diese Trennung kann eine vermeintliche Kimi K3 Tool Calls Schleife an der falschen Stelle repariert werden.

Ein sinnvoller Beleg sieht beispielsweise so aus:

request_id=req_<PLACEHOLDER>
assistant.finish_reason=tool_calls
assistant.tool_calls[0].id=call_<PLACEHOLDER>
assistant.tool_calls[0].function.name=lookup_order
assistant.tool_calls[0].function.arguments={"order_id":"<PLACEHOLDER>"}

tool.tool_call_id=call_<PLACEHOLDER>
tool.name=lookup_order
tool.content={"status":"pending","progress_token":"<PLACEHOLDER>"}

assistant.finish_reason=tool_calls
assistant.tool_calls[0].function.name=lookup_order
assistant.tool_calls[0].function.arguments={"order_id":"<PLACEHOLDER>"}

Wenn die zweite Antwort nur im Benutzerinterface erscheint, aber keine zweite API-Anfrage existiert, liegt der Fehler nicht im Modelllauf. Wenn zwei API-Anfragen existieren, vergleichen Sie Retry-Header, Timeout-Handler und Worker-Logs. Besonders gefährlich ist ein Client, der eine unklare Netzwerkantwort erneut sendet, obwohl der Server die erste Tool-Ausführung bereits abgeschlossen hat.

Die offizielle Kimi-Fehlerbehebung empfiehlt außerdem, die vollständige zurückgegebene choice.message in den Nachrichtenverlauf zu übernehmen. Genau diese Nachricht enthält die vom Modell erzeugten tool_calls. (Kimi-Dokumentation zur Fehleranalyse)

Meilenstein 1: Nachrichtenkette isolieren

Die erste technische Prüfung gilt nicht dem Prompt, sondern der Nachrichtenstruktur. Wenn Kimi finish_reason=tool_calls zurückgibt, fügen Sie die vollständige assistant-Nachricht unverändert zu messages hinzu. Erst danach hängen Sie für jeden Aufruf eine passende Nachricht mit role=tool an.

Die erwartete Reihenfolge ist:

system
user
assistant mit tool_calls
tool mit passender tool_call_id
assistant mit nächster Antwort

Bei parallelen Aufrufen kann eine assistant-Nachricht mehrere tool_calls enthalten. Dann benötigt jeder einzelne Aufruf ein eigenes Tool-Ergebnis. Der Toolname und die ID dürfen nicht aus einer neu erzeugten lokalen ID stammen. Verwenden Sie die Werte aus der Modellantwort.

Die Kimi-Dokumentation beschreibt ausdrücklich, dass die Anzahl der role=tool-Nachrichten zur Anzahl der Tool-Aufrufe passen muss und jede ID zugeordnet werden können muss. (Anleitung für Kimi-Tool-Calls)

Für die Minimalprüfung entfernen Sie zunächst Streaming, parallele Werkzeuge, Retry-Logik und jede eigene Agentenabstraktion. Senden Sie einen kleinen, nicht schreibenden Tool-Aufruf. Wenn der nicht-streamende Ablauf korrekt endet, ist die Wahrscheinlichkeit hoch, dass Ihre Streaming-Verarbeitung oder Client-Schicht die Nachrichten verändert.

Achten Sie außerdem auf eine häufige Verkürzung:

messages.append({
    "role": "assistant",
    "content": response.choices[0].message.content
})

Das reicht bei Tool Calls nicht aus. Für den nächsten API-Aufruf muss die assistant-Nachricht die relevanten tool_calls vollständig enthalten. In einer produktiven Implementierung ist es sicherer, das vom SDK gelieferte Nachrichtenobjekt strukturerhaltend zu übernehmen und erst bei der Protokollierung zu anonymisieren.

Meilenstein 2: Streaming-Fragmente zusammensetzen

Wenn der nicht-streamende Test funktioniert, aktivieren Sie Streaming wieder. Bei gestreamten Tool Calls kommen Funktionsname und Argumente häufig über mehrere Fragmente. Ein Parser, der jedes Fragment separat als JSON behandelt, kann einen unvollständigen Aufruf erzeugen. Ein Parser, der fehlende Zeichen still ergänzt, kann dagegen einen falschen, aber ausführbaren Auftrag herstellen.

Speichern Sie deshalb zwei Versionen:

1. jedes empfangene Fragment im Original,
2. das daraus gebildete Ergebnis pro Tool-Call.

Gruppieren Sie die Fragmente nach Auswahlindex und Tool-Call-Index. Führen Sie den Funktionsnamen und den Argument-String nur in der Reihenfolge zusammen, in der der Client sie empfängt. Starten Sie die Funktion erst, wenn der gesamte Argument-String erfolgreich als JSON validiert wurde.

buffers = {}

for chunk in stream:
    for delta in extract_tool_deltas(chunk):
        key = (delta.choice_index, delta.tool_index)
        state = buffers.setdefault(key, {
            "name": "",
            "arguments": "",
            "raw": []
        })

        state["raw"].append(delta.raw_fragment)

        if delta.name:
            state["name"] += delta.name

        if delta.arguments:
            state["arguments"] += delta.arguments

for state in buffers.values():
    arguments = json.loads(state["arguments"])
    execute_tool_after_validation(state["name"], arguments)

Das Beispiel ist bewusst generisch. Die Feldnamen Ihres SDK können abweichen. Entscheidend sind die Eigenschaften: keine Ausführung vor vollständigem JSON, keine stille Reparatur und ein unveränderter Rohbeleg für jede Analyse.

Die Kimi-Anleitung für Tool Calls weist besonders auf die korrekte Zusammensetzung von function.arguments bei Streaming hin. Sie beschreibt außerdem, dass tool_calls mehrere Werkzeuge enthalten können und die jeweiligen Ergebnisse anschließend mit passender ID zurückgesendet werden.

Prüfen Sie neben den Argumenten auch den Index. Wenn zwei parallele Tool Calls dieselbe Pufferposition verwenden, kann der zweite Funktionsname in die Argumente des ersten Aufrufs gelangen. Das führt zu scheinbar zufälligen Wiederholungen, obwohl der Fehler vor der Modellentscheidung liegt.

Meilenstein 3: Wiederholung mit Fortschritt abgleichen

Erst wenn die Nachrichtenkette und Streaming-Verarbeitung stimmen, bauen Sie die eigentliche Erkennung ein. Ein identischer Toolname allein genügt nicht. Auch identische Argumente allein sind kein Beweis für eine Schleife, weil ein Werkzeug mehrfach denselben Status abfragen kann.

Verwenden Sie mindestens diese Vergleichswerte:

• normalisierter Toolname,
• kanonisch serialisierte Argumente,
• sichtbarer Fortschritt im Tool-Ergebnis,
• Status oder Versionsnummer des Geschäftsobjekts,
• interne Werkzeug-Ausführungs-ID.

Bei der Normalisierung sortieren Sie Objektfelder, entfernen nicht relevante Diagnosefelder und behandeln nur ausdrücklich definierte Werte als gleich. Ändern Sie nicht heimlich Geschäftsparameter. Ein anderer Zeitstempel darf nicht automatisch als Fortschritt gelten, wenn der fachliche Status unverändert bleibt.

Eine robuste Bedingung lautet:

gleicher Toolname
+ gleiche normalisierte Argumente
+ gleiche fachliche Ergebnislage
+ keine neue Fortschrittsmarke
= möglicher Stillstand

Die offizielle Empfehlung verwendet Erinnerungen im Systemkontext als weiche Intervention bei wiederholten, identischen und fortschrittslosen Aufrufen. Sie nennt dabei die Schwellen von drei, fünf und acht aufeinanderfolgenden Wiederholungen. Diese Hinweise sollten Sie als Diagnose- und Eskalationssignal behandeln, nicht als Ersatz für eine technische Sperre. (Offizielle Hinweise zu wiederholten Tool-Aufrufen)

Bei erkanntem Stillstand senden Sie keine fingierte Erfolgsmeldung. Geben Sie einen klaren internen Status zurück, zum Beispiel:

{
  "status": "blocked_no_progress",
  "reason": "repeated_tool_call",
  "tool": "<TOOL_NAME>",
  "requires_review": true
}

Damit kann die Anwendung entscheiden, ob ein Mensch übernimmt, ein sicherer Wiederaufnahmeversuch startet oder der Auftrag beendet wird. Ein künstliches success=true verschleiert den Fehler und kann nachgelagerte Systeme zu weiteren Schreibaktionen veranlassen.

Meilenstein 4: Entscheidung über den richtigen Schutz

Für die operative Auswahl brauchen Sie eine Bedingungsliste statt eines einzigen Grenzwerts.

• Wenn das Werkzeug nur liest, der Status messbar fortschreitet und ein Wiederholungsaufruf keine Nebenwirkung besitzt, dann erlauben Sie eine begrenzte weitere Runde und protokollieren Sie den Grund.
• Wenn Toolname und normalisierte Argumente gleich bleiben, aber das Ergebnis keinen neuen fachlichen Fortschritt zeigt, dann unterbrechen Sie den Agenten und setzen Sie einen Prüfstatus.
• Wenn das Werkzeug schreibt, versendet oder bezahlt, dann verlangen Sie zusätzlich einen Idempotenzschlüssel und eine serverseitige Statusprüfung.
• Wenn nur die Streaming-Daten fehlerhaft sind, dann wechseln Sie vorübergehend auf einen nicht-streamenden Kontrollpfad.
• Wenn ein Netzwerk-Timeout keine eindeutige Ausführungslage hinterlässt, dann wiederholen Sie nicht blind, sondern fragen Sie zuerst den Status über eine sichere Abfrage ab.
• Wenn Ihr Auftrag lange laufen soll, aber keine sichere Wiederaufnahme besitzt, dann stoppen Sie den unbeaufsichtigten Betrieb und bauen Sie zunächst Checkpoints ein.

Die folgende Tabelle trennt Diagnosemaßnahmen von Produktionsschutz:

Erster Tag: Nebenwirkungen und Wiederaufnahme

Am ersten Betriebstag sollten Sie jedes riskante Werkzeug als eigenes Sicherheitsproblem behandeln. Eine allgemeine Agentengrenze reicht nicht aus, wenn ein einzelner Aufruf eine E-Mail versendet oder einen Datensatz verändert.

Für jedes Schreibwerkzeug definieren Sie:

1. einen Idempotenzschlüssel, der dieselbe Geschäftsaktion eindeutig repräsentiert;
2. eine Prüfung, ob diese Aktion bereits erfolgreich oder noch offen ist;
3. eine dauerhafte Ausführungs-ID;
4. eine klare Transaktionsgrenze;
5. einen sicheren Zustand für Teilfehler;
6. einen manuellen Übernahmepunkt.

Der Schlüssel sollte nicht allein aus der zufälligen Modell- oder Anfrage-ID bestehen. Bei einem Client-Retry würde sonst dieselbe fachliche Aktion einen neuen Schlüssel erhalten. Besser ist eine Kombination aus Auftrag, Aktionstyp und stabiler Geschäftsreferenz, wobei sensible Werte nur gehasht oder pseudonymisiert gespeichert werden.

Bei Zahlungen, Bestellungen und Datenänderungen muss der Server die letzte Autorität behalten. Das Modell darf einen Vorschlag erzeugen, aber nicht entscheiden, ob eine bereits ausgeführte Aktion erneut stattfinden darf. Für E-Mails kann eine Versandtabelle mit Status „angelegt“, „gesendet“ und „bestätigt“ verhindern, dass ein Agent einen Timeout als Nichterfolg interpretiert.

Datenschutz gehört ebenfalls in diese Schicht. Logs sollten nur die für die Fehleranalyse erforderlichen Argumente enthalten. Für eine DSGVO-konforme Betriebsführung können Sie die Datenschutzhinweise von Kvmkit als Ausgangspunkt für Aufbewahrung, Zugriff und Löschung Ihrer Test- und Betriebsprotokolle heranziehen.

Erste Woche: Produktionsabnahme

Die Abnahme darf nicht nur einen erfolgreichen Tool-Aufruf zeigen. Erstellen Sie vier getrennte Testgruppen:

• normale Ausführung mit gültigem Ergebnis,
• gleiche Funktion mit geänderten Argumenten,
• identische Funktion ohne fachlichen Fortschritt,
• Netzwerk-Wiederholung nach unklarer Antwort.

Für jede Gruppe dokumentieren Sie, welche Nachricht an das Modell zurückging, ob ein weiterer Tool-Aufruf erlaubt wurde und welcher Status am Ende gespeichert war. Prüfen Sie nach jeder ausgelösten Sperre, ob im Hintergrund weitere Worker, Warteschlangen-Nachrichten oder Retries laufen.

Die Audit-Kette sollte mindestens diese Verbindungen abbilden:

request_id
  -> Modellantwort
  -> tool_call_id
  -> Werkzeug-Ausführungs-ID
  -> Geschäftsaktion
  -> Tool-Ergebnis
  -> nächster Agentenstatus

Achten Sie bei der Abnahme auch auf parallele Tool Calls. Die offizielle Dokumentation beschreibt, dass mehrere Werkzeuge in einer Modellantwort vorkommen können. Ihre Anwendung muss deshalb jedes Ergebnis separat zuordnen und darf nicht nach dem ersten Werkzeug automatisch den gesamten Agentenzyklus als abgeschlossen markieren. (Dokumentation zu parallelen Kimi-Tool-Calls)

Verifizieren Sie außerdem, ob die Antwort wirklich mit finish_reason=stop endet oder ob der Client nur den sichtbaren Text ausgibt, während der Agent intern weiterarbeitet. Für die Kimi K3 API sollten Sie Endpoint, Modellbezeichnung, SDK-Version und Tool-Format gemeinsam versionieren. Die Kimi-API-Übersicht beschreibt die API-Grundstruktur und den empfohlenen API-Zugriff; bei Änderungen am Tool-Format, an finish_reason oder an Streaming-Feldern muss Ihre Prüfung erneut laufen.

Wenn Ihre Regressionstests über längere Zeit unbeaufsichtigt laufen sollen, ist nicht nur der API-Client entscheidend. Auch die Ausführungsumgebung muss erreichbar bleiben, Logs dauerhaft speichern und eine Wiederaufnahme nach Verbindungsabbrüchen ermöglichen. Für regionale Remote-Tests können Sie beispielsweise eine Mac-mini-Umgebung an der US-Ostküste mieten, sofern dieser Standort zu Ihren Latenz- und Datenschutzanforderungen passt.

Last updated und Prüfstand

Zuletzt aktualisiert: 03.08.2026. Die technischen Aussagen zu Nachrichtenreihenfolge, tool_call_id, finish_reason, Streaming-Argumenten und den dokumentierten Wiederholungshinweisen wurden anhand der offiziellen Kimi-API-Fehlerbehebung und der Tool-Call-Dokumentation geprüft. (Kimi-Tool-Call-Dokumentation)

Die genannten Wiederholungswerte von drei, fünf und acht stammen aus der offiziellen Fehlerbehebung. Ihre tatsächlichen Produktionslimits müssen Sie anhand von Werkzeugrisiko, Antwortverhalten, Zeitbudget und Kostenmodell festlegen. Sie sind keine pauschale Empfehlung für jeden AI Agent.

FAQ zur Kimi K3 Tool Calls Schleife

Warum ruft Kimi K3 immer wieder dieselbe Funktion auf?

Eine Wiederholung ist nicht automatisch ein Modellfehler. Häufig fehlen die vollständige assistant-Nachricht, das passende role=tool-Ergebnis oder ein unveränderter Tool-Status wird erneut übertragen. Prüfen Sie zuerst Toolname, normalisierte Argumente, tool_call_id und den tatsächlichen Fortschritt des Ergebnisses. Erst wenn diese Werte korrekt sind, sollten Sie von einer echten Kimi K3 Tool Calls Schleife ausgehen.

Kann eine falsche tool_call_id eine Tool-Schleife auslösen?

Ja, eine falsche oder nicht zurückgesendete tool_call_id kann die Nachrichtenkette ungültig machen. Der nächste Modellaufruf erhält dann kein eindeutig zugeordnetes Werkzeugergebnis. Je nach Client sehen Sie einen direkten Fehler, einen erneuten Aufruf oder einen scheinbar endlosen Agentenlauf. Die ID muss exakt der ID aus der vorherigen assistant-Nachricht entsprechen.

Wie werden Streaming-Tool-Calls korrekt zusammengesetzt?

Speichern Sie jedes Streaming-Fragment unverändert und gruppieren Sie es nach Auswahlindex und Tool-Call-Index. Führen Sie Funktionsname und arguments-String in Empfangsreihenfolge zusammen. Führen Sie das Werkzeug erst aus, wenn der vollständige String als JSON geparst werden kann. Ein stilles Reparieren fehlender Klammern oder abgeschnittener Zeichen macht spätere Wiederholungen schwer beweisbar.

Wie verhindern Sie doppelte Tools mit Seiteneffekten?

Schützen Sie Schreibwerkzeuge nicht nur durch einen Prompt. Verwenden Sie einen Idempotenzschlüssel pro Geschäftsaktion, prüfen Sie den Status vor der Ausführung und speichern Sie die Ausführungs-ID dauerhaft. Für Nachrichten, Zahlungen, Bestellungen und Datenänderungen sollten Sie zusätzlich eine Bestätigung oder eine Transaktionsgrenze einbauen. Bei Unsicherheit muss der Agent an einen Menschen übergeben.

Wie viele Tool-Runden sind für einen Kimi K3 Agenten sinnvoll?

Es gibt keinen universellen Produktionswert. Die passende Grenze hängt von Werkzeugtyp, Antwortzeit, Kosten und Risiko der Nebenwirkung ab. Legen Sie zunächst ein enges Limit für einen einzelnen Auftrag fest, messen Sie normale und mehrstufige Fälle und erhöhen Sie die Grenze nur mit Belegen. Unabhängig davon brauchen Sie zusätzlich Zeit-, Kosten- und Nebenwirkungsgrenzen.

Wenn Sie die Schleife zuerst in einer Sandbox nachstellen, können Sie die Nachrichtenkette und die Schutzlogik prüfen, ohne reale Geschäftsaktionen zu riskieren. Für längere Regressionstests ist eine dauerhaft erreichbare Umgebung mit stabiler Protokollspeicherung oft verlässlicher als ein lokaler Rechner, der in den Ruhezustand wechselt oder Netzwerkverbindungen verliert. Ein gemieteter Mac von Kvmkit kann dafür sinnvoll sein, wenn Sie eine kontinuierlich laufende Testumgebung mit nachvollziehbaren Logs benötigen. Die Entscheidung bleibt abhängig von Ihrem Bedarf: Für kurze lokale Tests genügt Ihr eigener Rechner; für unbeaufsichtigte, wiederholbare Agentenläufe sind Stabilität, Fernzugriff und eine klar getrennte Testumgebung wichtiger als ein weiterer Prompt-Versuch.

FAQ