LLMs greifen nicht in Ihren Code ein – sie übergeben Ihnen eine Anfrage, und Sie führen die Funktion aus. Diese einfache Tatsache widerlegt den Mythos, dass „das Modell magisch meine Python-Routine aufruft“, und zwingt Entwickler dazu, Debugging und Sicherheit neu zu überdenken.

Die Dispatch-Schleife, Schritt für Schritt

Wenn ein Large Language Model (LLM) ein Tool benötigt, folgt es einer deterministischen Sequenz:

  1. Planung – das Modell entscheidet, dass eine Aktion erforderlich ist (z. B. „eine Zahlung erstatten“).
  2. Erstellung einer Anfrage – es gibt strukturierten Text aus – meist JSON –, der das Tool benennt und Argumente liefert.
  3. Parsing – Ihre App oder ein unterstützendes Framework liest diesen Text.
  4. Matching – das Framework sucht den Namen im Register der echten Funktionen nach, die Sie bereitgestellt haben.
  5. Validierung – es wird geprüft, ob die Argumente dem Schema der Funktion entsprechen und ob der Aufrufer autorisiert ist.
  6. Ausführung – die passende Funktion wird in Ihrer Umgebung ausgeführt und erledigt die Arbeit.
  7. Rückgabe – das Ergebnis wird verpackt und zur weiteren Argumentation an das Modell zurückgesendet.

Betrachten Sie das LLM als Planer, das Framework als Dispatcher und die Funktion als den Arbeiter, der tatsächlich Daten oder Geld bewegt.

Warum der „Magie“-Mythos fortbesteht

Die meisten Entwickler sehen eine einzige Zeile der Modellausgabe, die wie ein Funktionsaufruf aussieht, und nehmen an, dass das Modell die Operation selbst durchgeführt hat. Der Begriff „tool calling“ in der Dokumentation der Anbieter klingt so, als würde das Modell Code direkt aufrufen.

In Wirklichkeit erzeugt das Modell nur Text, der einen Aufruf beschreibt. Ihr Prozess übernimmt die eigentliche Arbeit – das Nachschlagen, die Typüberprüfung, die Durchsetzung von Berechtigungen und die Fehlerbehandlung.

Frameworks, die die Infrastruktur verbergen

Bibliotheken wie PydanticAI und LangChain abstrahieren die Schleife, sodass Sie sich auf die Geschäftslogik konzentrieren können. Sie übernehmen automatisch:

  • Validierung der Argumente gegen ein Schema (z. B. ein Pydantic-Modell).
  • Durchsetzung von Berechtigungen, um sicherzustellen, dass der Benutzer das Tool auslösen darf.
  • Wiederholungsversuche bei Fehlern, indem bei einem Fehler des Tools die Schleife zum Modell zurückgeführt wird.
  • Schutz vor Endlosschleifen, indem die Anzahl aufeinanderfolgender Tool-Aufrufe begrenzt wird.
  • Aufrechterhaltung des Gesprächszustands, indem die Tool-Ergebnisse in den Dialog eingeflochten werden.

Selbst mit diesen Helfern bleibt das Muster gleich: Das Modell führt niemals Code aus.

Nativer Tool-Calling-Support von Anbietern

Einige Anbieter liefern eine „native“ Tool-Calling-Schnittstelle aus, die Tool-Definitionen und Anfrageformate standardisiert. Dies erleichtert die Integration, entfernt aber nicht den Dispatch-Schritt. Sie schreiben (oder importieren) immer noch den Code, der die angeforderte Operation tatsächlich ausführt.

Debugging wird einfacher, wenn man das Problem neu benennt

Anstatt einem „verwirrten Agenten“ die Schuld zu geben, sagen Sie lieber: „Die Modellantwort enthielt keine Tool-Aufrufe.“ Die Unterscheidung ist wichtig:

  • Kein Tool-Aufruf – das Modell hat direkt geantwortet oder es ist nicht gelungen, eine korrekt formatierte Anfrage zu generieren.
  • Fehlerhafte Anfrage – das JSON ist syntaktisch falsch oder es fehlen erforderliche Felder, sodass der Dispatcher sie ablehnt.
  • Validierungsfehler – die Argumente entsprechen nicht dem Schema, was einen Fehler vor der Ausführung auslöst.

Durch die Kategorisierung von Fehlern können Sie jede Phase der Schleife protokollieren und genau bestimmen, an welcher Stelle etwas schiefgelaufen ist.

Praktische Tipps für eine zuverlässige Pipeline

  • Behandeln Sie die Modellausgabe als nicht vertrauenswürdige Eingabe. Führen Sie jede Anfrage durch eine deterministische Validierung, bevor Sie Code mit Nebenwirkungen aufrufen.
  • Protokollieren Sie die Rohanfrage und das Ergebnis jedes Validierungsschritts. Dies schafft einen reproduzierbaren Pfad, wenn etwas schiefgeht.
  • Setzen Sie explizite Limits für aufeinanderfolgende Tool-Aufrufe; eine Endlosschleife kann Ressourcen erschöpfen oder Rate-Limits erreichen.
  • Umschließen Sie jede Funktion mit einem try/except-Block, der ein strukturiertes Fehlerobjekt zurückgibt, das das Modell verstehen kann, um einen erneuten Versuch oder einen sanften Fallback auszulösen.
  • Trennen Sie Berechtigungsprüfungen von der Geschäftslogik. Überprüfen Sie die Rechte des Aufrufers, bevor die Funktion ausgeführt wird, insbesondere bei privilegierten Aktionen wie „Benutzer löschen“.
  • Verwenden Sie schema-gesteuerte Definitionen (z. B. Pydantic-Modelle), damit das Framework das JSON-Schema, dem das Modell folgen muss, automatisch generieren kann.

Worauf Sie als Nächstes achten sollten

Da die Anbieter die nativen Tool-Calling-APIs verfeinern, ist mit strengeren Vorgaben für Anfrageformate und detaillierteren Fehlercodes zu rechnen. Diese Änderungen werden die Validierung erleichtern und es Entwicklern ermöglichen, strengere Sicherheitsbarrieren aufzubauen. Behalten Sie Library-Updates im Auge – viele fügen bereits integrierten Support für die neuesten Funktionen der Anbieter hinzu.

Fazit

Das LLM ist ein hochentwickelter Textgenerator, kein Ausführer. Ihr Code bleibt die alleinige Instanz, die Aktionen ausführt, und der Dispatcher, den Sie bauen (oder importieren), ist der Gatekeeper, der diese Aktionen validiert, autorisiert und ausführt. Eine Neuausrichtung des Workflows beseitigt den Mythos der „Magie“, macht das Debugging präziser und erzwingt die Sicherheitsdisziplin, die jedes Produktionssystem benötigt.