Skip to content
Zum Glossar
KI

Tool Calling

Tool Calling ist der Mechanismus, mit dem ein Sprachmodell eine Aktion von der umgebenden Software anfordert: Es gibt einen strukturierten Aufruf mit Werkzeugname und Argumenten aus, die Anwendung führt ihn aus und liefert das Ergebnis zurück.

Tool Calling, auch Function Calling genannt, ist der Mechanismus, mit dem ein Sprachmodell die umgebende Software bittet, etwas zu tun. Statt in Prosa zu antworten, gibt das Modell eine strukturierte Anfrage aus, die ein Werkzeug und seine Argumente benennt. Die Anwendung führt das Werkzeug aus, liefert das Ergebnis zurück, und das Modell macht weiter. Das Modell selbst führt nie etwas aus.

Wie funktioniert Tool Calling?

Die Anwendung teilt dem Modell mit, welche Werkzeuge es gibt. Jedes Werkzeug kommt mit Name, Beschreibung und einem Schema seiner Argumente, etwa lookup_customer mit einem Pflichtfeld email.

Entscheidet das Modell, dass ein Werkzeug gebraucht wird, gibt es statt einer Antwort einen Aufruf aus: den Werkzeugnamen und die Argumentwerte als strukturierte Daten. Die Anwendung prüft den Aufruf, führt die echte Funktion gegen euer System aus und hängt das Ergebnis an das Gespräch an.

Das Modell liest das Ergebnis und ruft entweder ein weiteres Werkzeug auf oder schreibt seine Antwort. Diese Schleife, wiederholt bis die Aufgabe erledigt ist, macht aus einem Modell einen KI-Agenten. Die Werkzeugbeschreibungen und den Transport zwischen Anwendung und Werkzeugen standardisiert das Model Context Protocol.

Was trennt einen Chatbot von einem Agenten?

Zugriff. Ein Chatbot ohne Werkzeuge kann nur reden. Ein Modell mit Werkzeugen kann euer CRM lesen, ein Ticket anlegen, eine Buchung erzeugen, eine E-Mail verschicken.

Das ist der ganze Unterschied und zugleich das ganze Risiko. Alles, was ein Agent falsch machen kann, macht er über einen Werkzeugaufruf. Die Entscheidungen, die zählen, liegen deshalb in der Werkzeugschicht: welche Werkzeuge es gibt, mit welchen Rechten sie laufen und welche Prüfungen vor der Ausführung stattfinden.

Was muss entworfen werden?

Zuschnitt. „Lege ein Ticket in Warteschlange X an" ist ein besseres Werkzeug als „führe beliebiges SQL aus". Je enger das Werkzeug, desto weniger kann ein Fehlurteil des Modells anrichten.

Rechte. Ein Werkzeug läuft unter einem Dienstkonto. Was dieses Konto darf, darf ab jetzt das Modell. Eine Werkzeugschicht mit Administratorrechten gibt Administratorrechte an das Modell weiter.

Bestätigung. Manche Aufrufe laufen sofort. Andere sollten auf einen Menschen warten. Human-in-the-Loop wird genau so umgesetzt: als Werkzeugaufruf, der pausiert, bis jemand freigibt, typischerweise an einem unumkehrbaren Schritt wie Senden, Zahlen oder Löschen.

Protokollierung. Jeder Aufruf mit Argumenten und Ergebnis, verknüpft mit dem Vorgang, der ihn ausgelöst hat. Das ist die Prüfspur, und sie existiert nur, wenn sie gebaut wurde.

Kosten. Jede Werkzeugrunde ist ein weiterer Modellaufruf. Ein Agent, der viele Aufrufe pro Vorgang macht, bezahlt jeden davon in Geld und in Wartezeit. Das ist ein Grund, deterministische Arbeit in Code zu legen, statt das Modell Schritt für Schritt darum zu bitten.

Beispiel: ein Agent zur Rechnungsprüfung

Der Agent bekommt Lieferantenrechnungen und prüft sie gegen Bestellungen. Seine Werkzeuge sind get_order, das eine Bestellung per Nummer holt, extract_lines, das das Rechnungs-PDF in eine Tabelle liest, compare_lines, gewöhnlicher Code, der zwei Tabellen vergleicht, und flag_for_review, das einen Grund entgegennimmt.

Die Aufgabe des Modells ist Urteil: herausfinden, auf welche Bestellung sich die Rechnung bezieht, den Vergleich aufrufen, die Unterschiede lesen, entscheiden, ob eine Abweichung in der Toleranz liegt oder markiert werden muss. Das Rechnen liegt im Code. Das Modell addiert nie eine Spalte.

Wo Tool Calling scheitert

Modelle rufen Werkzeuge gelegentlich mit falschen Argumenten auf oder rufen ein Werkzeug auf, das es nicht gibt. Die Schemaprüfung fängt das Erste ab. Eine feste Werkzeugliste ohne freie Rückfalloption fängt das Zweite ab.

Fehlermeldungen zählen mehr, als es scheint. Ein Werkzeug, das auf einen schlechten Aufruf mit „erwartet eine Bestellnummer im Format A-12345" antwortet, führt zu einem korrigierten zweiten Versuch. Ein Werkzeug, das nur scheitert, führt zu einer erfundenen Antwort. Ist ein Agent als Agent-Graph gebaut, lässt sich jeder Werkzeugknoten mit genau diesen schlechten Eingaben einzeln testen.

Die Werkzeugschicht ist der Ort, an dem der größte Teil der Ingenieursarbeit in einem Agentenprojekt tatsächlich stattfindet. Sie ist gemeint, wenn wir sagen, dass ein Agent in den Stack eines Kunden gebaut wird und nicht daneben gestellt, siehe Softwareentwicklung.

Welche Arbeit können Agenten eurem Team abnehmen?

Bringt einen wiederkehrenden Ablauf oder eine Produktidee mit. 30 Minuten, eine ehrliche Einschätzung, ein klarer nächster Schritt.