Einen KI-Agent mit Claude Tool-Use bauen

Tool-Use macht aus einem Chat-Modell einen Agenten, der echte Aktionen ausführt: Datenbanken abfragen, APIs aufrufen, Termine anlegen. Wir zeigen die Tool-Definition, den Agent-Loop und wann sich der Aufwand gegenüber einem simplen Prompt überhaupt lohnt.

Was Tool-Use eigentlich ist

Ein Sprachmodell allein produziert Text. Es kann nichts abfragen, nichts speichern, nichts auslösen. Es hat keinen Zugriff auf deine Datenbank, kennt den heutigen Lagerbestand nicht und kann keine E-Mail verschicken. Tool-Use ändert das. Du beschreibst dem Modell eine Reihe von Funktionen, und wenn das Modell merkt, dass es eine davon braucht, antwortet es nicht mit Fließtext, sondern mit einer strukturierten Anweisung: ruf Funktion X mit diesen Argumenten auf.

Wichtig ist, dass das Modell die Funktion nicht selbst ausführt. Es sagt dir nur, dass und wie. Den tatsächlichen Aufruf machst du in deinem Code. Das Ergebnis gibst du zurück ins Gespräch, und das Modell arbeitet damit weiter. Diese saubere Trennung ist der Grund, warum Tool-Use sicher kontrollierbar ist: Du sitzt zwischen Entscheidung und Ausführung. Das Modell schlägt vor, dein Code entscheidet, ob und wie er den Vorschlag umsetzt.

Aus dieser Mechanik entsteht alles, was Leute heute Agent nennen. Ein Agent ist im Kern nichts anderes als ein Sprachmodell, das in einer Schleife Tools vorschlagen darf, bis die Aufgabe erledigt ist. Kein Zauber, sondern eine klare Architektur, die du komplett verstehen und kontrollieren kannst.

Die Tool-Definition

Ein Tool ist im Kern ein JSON-Schema. Es hat einen Namen, eine Beschreibung und eine Liste von Parametern mit Typen. Die Beschreibung ist kein Beiwerk, sondern der entscheidende Teil. Das Modell wählt anhand der Beschreibung aus, wann es das Tool benutzt. Eine vage Beschreibung führt zu falschen Aufrufen, eine präzise zu treffsicheren.

Ein Beispiel für ein Tool, das Termine prüft: Name check_verfuegbarkeit, Beschreibung "Prüft freie Termine in einem Datumsbereich. Nutze dies, sobald der Nutzer nach Verfügbarkeit fragt oder einen Termin buchen will." Parameter: von (Datum, Pflicht), bis (Datum, Pflicht). Je präziser du beschreibst, wann ein Tool gilt und wann nicht, desto weniger Fehlgriffe.

Die Parametertypen sind dein erstes Sicherheitsnetz. Wenn du einen Parameter als Enum mit den Werten "offen", "gewonnen", "verloren" definierst, kann das Modell keinen vierten Status erfinden. Pflichtfelder erzwingst du im Schema, sodass das Modell nicht mit halben Argumenten aufruft. Das Schema ist also nicht nur Dokumentation, sondern Vertrag.

Faustregel: Schreibe Tool-Beschreibungen so, als würdest du einem neuen Kollegen erklären, wann er welches Werkzeug aus dem Schrank holt. Nenne Auslöser, nenne Grenzen, nenne was nicht hineingehört. Lieber drei klare Tools als ein universelles, das alles kann und nichts richtig.

Der Agent-Loop

Ein Agent ist kein einzelner Aufruf, sondern eine Schleife. Sie läuft so: Du schickst die Nutzeranfrage plus die Tool-Definitionen an das Modell. Das Modell antwortet entweder mit Text (fertig) oder mit einem oder mehreren Tool-Aufrufen. Bei Tool-Aufrufen führst du sie aus, hängst die Ergebnisse an das Gespräch an und schickst alles erneut ans Modell. Das wiederholt sich, bis das Modell eine finale Antwort gibt.

In Pseudocode: Solange das Modell stop_reason: tool_use liefert, führe die Tools aus und gib die Resultate zurück. Sobald stop_reason: end_turn kommt, bist du fertig. Genau diese Schleife ist der ganze Kern eines Agenten. Alles andere ist Drumherum: Logging, Limits, Fehlerbehandlung.

Ein realistischer Ablauf sieht so aus. Der Nutzer fragt: "Hat Firma Meyer noch offene Rechnungen, und wenn ja, schick eine Erinnerung." Das Modell ruft zuerst finde_offene_rechnungen mit dem Kundennamen auf. Dein Code liefert zwei Rechnungen zurück. Das Modell ruft daraufhin sende_erinnerung auf. Erst danach formuliert es die finale Antwort an den Nutzer. Zwei Tool-Schritte, eine geplante Reihenfolge, die das Modell selbst gewählt hat.

Der häufigste Anfängerfehler ist, die Schleife nicht zu begrenzen. Ein Modell, das in einer Sackgasse steckt, ruft sonst dasselbe Tool immer wieder auf. Deshalb gehört ein harter Zähler hinein, der nach einer festen Zahl an Durchläufen abbricht und sauber meldet, dass keine Lösung gefunden wurde.

Agent oder einfacher Prompt

Nicht jede Aufgabe braucht einen Agenten. Wenn die Antwort allein aus dem Modellwissen oder aus einem mitgelieferten Textstück kommt, reicht ein einzelner Prompt. Das ist billiger, schneller und kaum fehleranfällig. Eine E-Mail zusammenfassen, einen Text umformulieren, eine Frage zu einem mitgegebenen Dokument beantworten: alles kein Agentenfall.

Einen Agenten brauchst du, wenn drei Dinge zusammenkommen: Das Modell muss auf Daten zugreifen, die es nicht hat. Es muss mehrere Schritte in unbekannter Reihenfolge planen. Und es muss echte Seiteneffekte auslösen, etwa etwas in ein System schreiben. Fehlt eines davon, ist der Agent oft überdimensioniert und du baust dir unnötige Komplexität ein.

Wir bei adsbird bauen lieber zwei klare Module als einen Agenten, der alles können soll. Wenn ein fester Ablauf reicht (erst dies, dann das, dann jenes), verdrahten wir ihn fest im Code. Das ist robuster und nachvollziehbarer als ein Modell, das die Reihenfolge jedes Mal neu erfindet. Den teuren, flexiblen Agent-Loop setzen wir nur dort ein, wo die Reihenfolge wirklich von der Anfrage abhängt und sich nicht vorab festlegen lässt. Mehr dazu unter KI-Agents.

Kosten und Guardrails

Jeder Schleifendurchlauf schickt das komplette bisherige Gespräch erneut ans Modell. Bei langen Tool-Ketten wächst der Kontext schnell, und damit die Token-Kosten. Ein Agent, der zehn Mal durch die Schleife läuft, bezahlt den ersten Schritt zehnmal mit. Drei Hebel helfen: Begrenze die Anzahl der Iterationen hart. Kürze alte Tool-Ergebnisse, die nicht mehr gebraucht werden. Und nutze Prompt-Caching für den unveränderlichen Teil, etwa die Tool-Definitionen und das System-Prompt.

Guardrails sind kein Nice-to-have, sondern Pflicht. Schreibende Tools (löschen, versenden, bezahlen) bekommen ein Bestätigungs- oder Dry-Run-Flag, sodass im Testbetrieb nichts wirklich passiert. Jeder Tool-Aufruf wird geloggt, damit du nachvollziehen kannst, was der Agent getan hat und warum. Und du validierst die Argumente, die das Modell liefert, bevor du sie ausführst. Das Modell ist gut, aber es ist nicht dein Sicherheitsnetz. Wenn es eine Kundennummer halluziniert, muss dein Code das abfangen, nicht das Vertrauen ins Modell.

Ein eigener Punkt ist die Berechtigung. Ein Tool sollte nie mehr dürfen als nötig. Ein Lese-Tool liest, ein Schreib-Tool schreibt genau einen klar umrissenen Datensatz. So bleibt der Schaden begrenzt, falls das Modell sich verrennt oder jemand versucht, es über manipulierte Eingaben zu missbrauchen.

Wie wir das umsetzen

Wir bauen den Agent-Loop schlank und beobachtbar. Jedes Tool ist eine eigene, testbare Funktion mit klarem Schema. Limits, Logging und Bestätigungen sind von Anfang an drin, nicht nachträglich draufgeklebt. Der Code bleibt dein Eigentum, du bist an keinen Anbieter gebunden, und du kannst die Tools jederzeit erweitern oder austauschen.

Wir arbeiten zum Festpreis pro Modul, kein laufender Retainer. Ein klar abgegrenzter Agent, der etwa Anfragen aufnimmt, deine Datenbank abfragt und einen Termin anlegt, ist ein solches Modul mit klarem Umfang und klarem Preis. Wenn du wissen willst, ob dein Anwendungsfall einen Agenten braucht oder mit einem festen Ablauf günstiger fährt, schau dir unsere Preise an oder buch direkt ein Gespräch über Kontakt. Wir sagen dir ehrlich, wenn ein simpler Prompt reicht.