Function Calling / Tool Use

Redaktion ·

Was Function Calling eigentlich ist

Function Calling — oft auch Tool Use genannt, beides meint dasselbe — heißt erst mal nur: Du gibst dem Sprachmodell eine Liste von Werkzeugen mit, die es benutzen darf. Eine Wetter-Abfrage, eine Datenbanksuche, ein Rechner, ein Mail-Versand. Das Modell schreibt diese Werkzeuge nicht selbst aus, und es ruft sie auch nicht direkt auf. Es sagt dir nur: „Ich würde jetzt gern das Werkzeug get_wetter mit der Stadt Berlin benutzen.” Den eigentlichen Aufruf machst dann du in deinem Code.

Das klingt nach einem kleinen Detail, ist aber der entscheidende Schritt. Ohne Tools kann ein LLM nur Text produzieren — es weiß nichts über die Welt nach seinem Trainingsstand, kann nichts nachschlagen, nichts auslösen. Mit Tools wird aus dem Text-Generator etwas, das handeln kann. Und genau da macht es klick: Das Modell entscheidet was getan werden soll, dein System tut es tatsächlich.

Der Ablauf in drei Schritten

Der ganze Mechanismus ist ein kleiner Kreislauf zwischen deinem Code und dem Modell. Er sieht immer gleich aus:

  1. Du beschreibst die Tools. Bei jedem Aufruf schickst du dem Modell nicht nur die Frage des Nutzers, sondern auch eine Liste verfügbarer Werkzeuge — jedes mit Name, kurzer Beschreibung und seinen Parametern. Diese Beschreibung ist ein sogenanntes JSON-Schema, also eine strukturierte Angabe, welche Felder das Tool erwartet und welchen Typ sie haben.
  2. Das Modell wählt. Statt einer Textantwort liefert das Modell jetzt eine strukturierte Anweisung zurück: Es will Tool X aufrufen, und zwar mit diesen Argumenten. Zum Beispiel get_wetter({ stadt: "Berlin", einheit: "celsius" }). Das Modell rät dabei nicht, es füllt die Felder aus dem Schema, das du ihm vorgegeben hast.
  3. Du führst aus und gibst zurück. Dein Code ruft die echte Funktion auf, holt das Ergebnis und schickt es als neue Nachricht zurück ins Gespräch. Das Modell liest dieses Ergebnis und formuliert daraus die endgültige Antwort — oder fordert direkt das nächste Tool an.

Wichtig ist der Punkt, an dem viele zuerst stolpern: Das Modell führt nichts selbst aus. Es ist eine reine Empfehlung, die dein System annehmen oder ablehnen kann. Die Kontrolle bleibt bei dir.

Warum das JSON-Schema so wichtig ist

Die Tool-Beschreibung ist nicht bloß Beiwerk, sie ist der Kern der Sache. Das Modell entscheidet allein anhand des Namens und der Beschreibung, ob und wann es ein Werkzeug nimmt. Heißt eine Funktion nichtssagend func1 und hat keine Beschreibung, rät das Modell — und rät oft falsch. Steht dagegen klar da „Holt die aktuelle Wettervorhersage für eine angegebene Stadt”, trifft es die richtige Wahl viel zuverlässiger.

Das Schema legt außerdem die Parameter fest: welche Felder es gibt, welchen Typ sie haben, welche Pflicht sind. Genau daran hält sich das Modell, wenn es die Argumente ausfüllt. Gute Tool-Definitionen sind deshalb halbe Miete — eine unklare Beschreibung produziert mehr Fehlaufrufe als ein schwaches Modell.

Der Grundbaustein jeder Agenten-Orchestrierung

Function Calling ist der Punkt, an dem aus einem Chat-Modell ein Agent wird. Ein KI-Agent ist im Kern nichts anderes als dieser Kreislauf, wiederholt: Das Modell wählt ein Tool, dein System führt es aus, das Ergebnis geht zurück, das Modell wählt das nächste — so lange, bis die Aufgabe erledigt ist. Ohne Tool Use gäbe es keine Agenten, nur Textantworten.

Auch Multi-Agent-Orchestrierung und Pipeline-Frameworks bauen direkt darauf auf. Jeder einzelne Agent in so einem System nutzt Function Calling, um auf seine Werkzeuge zuzugreifen. Und der verwandte Ansatz RAG lässt sich genauso umsetzen — die Suche in der Wissensbasis wird einfach als Tool angeboten, das das Modell bei Bedarf zieht.

Die großen Anbieter unterstützen das alle, wenn auch mit leicht unterschiedlicher Notation: OpenAI über einen tools-Parameter, Anthropic über tool_use-Blöcke, Google über function_declarations. Das Prinzip ist überall dasselbe — du beschreibst, das Modell wählt, du führst aus. Wer tiefer in die API-Mechanik einsteigen will, findet den passenden Einstieg im Eintrag zur Arbeit mit der LLM-API.

Wo es in der Praxis hakt

Function Calling ist mächtig, aber kein Selbstläufer. Drei Dinge gehen erfahrungsgemäß als Erstes schief. Erstens: Das Modell ruft ein Tool gar nicht oder das falsche auf — fast immer ein Beschreibungsproblem, kein Modellproblem. Zweitens: Es füllt ein Argument mit Unsinn, etwa eine Stadt, nach der niemand gefragt hat. Dagegen hilft ein Schema mit klaren Pflichtfeldern und ein Check im Code, bevor du den Aufruf tatsächlich ausführst.

Drittens, und das ist sicherheitsrelevant: Ein Tool-Ergebnis landet zurück im Kontext und kann selbst Anweisungen enthalten. Holt ein Tool fremden Text aus dem Web, kann darin ein versteckter Befehl stecken, den das Modell brav befolgt. Deshalb gilt: Tool-Ergebnisse sind Daten, keine Befehle — wie du das absicherst, steht im Eintrag zur Prompt-Sicherheit. Führe nie blind aus, was das Modell vorschlägt, gerade wenn ein Tool etwas Unwiderrufliches tut wie löschen oder versenden.

FAQ

Ruft das LLM die Funktion selbst auf?
Nein. Das Modell liefert nur eine strukturierte Empfehlung zurück — welches Tool mit welchen Argumenten. Den echten Aufruf macht dein Code. Du kannst die Empfehlung annehmen, prüfen oder ablehnen, die Kontrolle bleibt komplett bei dir.
Was ist der Unterschied zwischen Function Calling und Tool Use?
Keiner im Kern — es sind zwei Namen für dieselbe Sache. OpenAI prägte „Function Calling", Anthropic spricht von „Tool Use". Beide meinen: dem Modell Werkzeuge mitgeben, die es per strukturierter Anweisung anfordern kann.
Wozu brauche ich ein JSON-Schema für die Tools?
Das Schema sagt dem Modell, welche Werkzeuge es gibt, wann es sie nutzen soll und welche Parameter sie erwarten. Das Modell entscheidet allein anhand von Name und Beschreibung — ein klares Schema ist deshalb der größte Hebel für zuverlässige Aufrufe.
Was hat Function Calling mit KI-Agenten zu tun?
Function Calling ist der Grundbaustein. Ein Agent ist im Kern dieser Kreislauf, wiederholt: Tool wählen, ausführen, Ergebnis zurück, nächstes Tool. Ohne Tool Use kann ein Modell nur Text produzieren, nicht handeln.
Welche Sicherheitsrisiken bringt Tool Use mit?
Vor allem zwei: falsche oder erfundene Argumente und Anweisungen, die über ein Tool-Ergebnis in den Kontext gelangen (Prompt Injection). Behandle Tool-Ergebnisse als Daten, nicht als Befehle, und prüfe jeden Aufruf, der etwas Unwiderrufliches tut.