Das Modell ruft nichts auf
Hier ist der Punkt, der alles andere ordnet: Wenn ein Modell „eine Funktion aufruft“, führt es keinen Code aus. Es erzeugt ein Stück strukturierten Text — ein JSON-Objekt, das eines der Tools benennt, die Sie ihm angeboten haben, und die Argumente füllt. Das ist der gesamte Vorgang. Das Modell erzeugt eine Anfrage. Ihr Code liest diese Anfrage, entscheidet, ob er sie zulässt, führt die echte Funktion selbst aus und reicht das Ergebnis im nächsten Schritt an das Modell zurück.
„Function Calling“ ist also eine leichte Fehlbezeichnung. Das Modell schlägt vor; Ihre Laufzeitumgebung verfügt. Alles Folgenreiche — ob der Aufruf überhaupt läuft, mit welchen Rechten, gegen welche Datenbank, nach welchen Prüfungen — geschieht in Code, den Sie geschrieben haben, nicht im Modell. Das ist keine pedantische Unterscheidung. Sie ist der Grund, warum die gesamte Frage nach Verlässlichkeit und Sicherheit auf Ihrer Seite der Grenze liegt — und warum „die KI hat den Datensatz gelöscht“ nie ganz stimmt: Die KI hat gefragt, und Ihr Code hat gelöscht, weil Sie die Anfrage ungeprüft durchgereicht haben.
Die Schleife aus Anfrage und Ausführung
Eine Tool-Use-Interaktion ist eine kurze Schleife, und es hilft, die vier Züge der Reihe nach zu sehen. Sie schicken dem Modell die Nachricht des Nutzers plus eine Liste verfügbarer Tools — jedes beschrieben durch einen Namen, einen Zweck und ein Schema für seine Argumente. Das Modell antwortet entweder mit einer normalen Antwort oder mit einer Tool-Anfrage. Ist es eine Anfrage, prüft Ihr Code sie, führt die eigentliche Funktion aus und hängt das Ergebnis an das Gespräch an. Dann macht das Modell weiter — oft mit einem weiteren Tool, manchmal mehreren nacheinander, bis es genug hat, um im Klartext zu antworten.
Aus dieser Form folgen zwei Dinge. Erstens kann das Modell verketten: Eine Serviceanfrage kann eine Suche auslösen, dann anhand des ersten Ergebnisses eine zweite Suche, dann einen Antwortentwurf — eine kleine Agenten-Schleife, ganz aus Tool-Aufrufen gebaut. Zweitens ist jedes Tool-Ergebnis nur weiterer Text, den das Modell liest. Deshalb zählt, was Sie aus einem Tool zurückgeben, genauso viel wie das, was Sie es tun lassen — dazu gleich mehr.
Ein Tool ist ein Prompt, keine bloße API
Der Reflex ist, ein Tool wie eine normale Funktion zu behandeln, die man zufällig einem Modell zugänglich macht. Genau dieser Reflex erzeugt Tools, die ein LLM nicht gut nutzen kann. Der Unterschied: Ihr Kollege kann die Doku lesen, nachfragen und den umliegenden Code sehen. Das Modell sieht nur den Namen des Tools, seine Beschreibung und das Argument-Schema — und es entscheidet allein daraus, zu welchem Tool es greift und wie es dieses füllt. Das Schema ist keine Verkabelung. Es ist Anweisung, die das Modell genau in dem Moment liest, in dem es entscheidet, was zu tun ist.
Benennen und beschreiben für einen Leser, der nicht nachfragen kann
Ein Tool namens get_data(type, filter) zwingt das Modell zu raten, was type akzeptiert und wie ein gültiger filter aussieht — und unter Last rät es falsch. Teilen Sie es in find_customer_by_email(email) und get_open_invoices(customer_id), und die Wahl wird schon aus den Namen offensichtlich. Schreiben Sie die Beschreibung für den Aufrufer, nicht für den Wartenden: wofür das Tool da ist, wann man es statt eines Nachbarn nimmt und was es nicht tut. „Gibt die letzten 10 Bestellungen des Kunden zurück. Nur verwenden, wenn Sie eine customer_id aus find_customer haben. Stornierte Bestellungen sind nicht enthalten.“ ist mehr wert als jede Feinjustierung im System-Prompt.
Einen falschen Aufruf unausdrückbar machen
Der stärkste Hebel ist, den Raum der Aufrufe zu verkleinern, die das Modell überhaupt bilden kann. Ein generisches update_record(table, field, value) kann alles auf alles setzen — eine per Prompt Injection eingeschleuste Anweisung könnte es dorthin schreiben lassen, wo es nicht darf. Ersetzen Sie es durch move_ticket_to_stage(ticket_id, stage), wobei stage ein Enum der vier zulässigen Stufen ist, und eine ganze Klasse falscher oder bösartiger Aufrufe lässt sich schlicht nicht mehr darstellen. Bevorzugen Sie Enums vor freien Strings, IDs vor Namen, ein enges Verb vor einem flexiblen Setter. Jede Einschränkung, die Sie ins Schema schieben, ist ein Fehler, den das Modell nicht machen kann, und eine Prüfung, die Sie nicht mehr schreiben müssen.
Fehlermeldungen schreiben, aus denen das Modell sich erholen kann
Wenn ein Tool fehlschlägt, ist die Fehlermeldung, die Sie zurückgeben, der nächste Prompt des Modells. Geben Sie Fehler 500 zurück, hat das Modell nichts in der Hand; es wiederholt blind oder gibt auf. Geben Sie Kein Kunde zu ID 4711 gefunden. IDs sind sechsstellig — wenn Sie nur einen Namen haben, rufen Sie zuerst find_customer_by_email auf. zurück, kann das Modell sich im nächsten Schritt ohne Mensch korrigieren. Gute Tool-Fehler lenken, sie protokollieren nicht nur: Sie benennen, was falsch war, und weisen auf den nächsten, erholbaren Schritt. Das ist einer der wirksamsten und am häufigsten übersprungenen Teile des Tool-Entwurfs.
An der Grenze entsteht die Sicherheit
Weil die Ausgabe des Modells nicht vertrauenswürdig ist — und erst recht, sobald ein Teil seiner Eingabe aus Dokumenten, E-Mails oder Webseiten stammt, die ein Angreifer beeinflussen kann — ist ein Tool-Aufruf Eingabe aus dem Internet, und Sie prüfen ihn wie eine solche. Drei Gewohnheiten erledigen den Großteil der Arbeit.
Prüfen vor dem Ausführen. Kontrollieren Sie die Argumente gegen das Schema und dann gegen Ihre eigenen Regeln, bevor die Funktion läuft. Geben Sie den String eines Modells nie direkt in SQL, eine Shell, einen Dateipfad oder ein eval. Das Schema erzwingt die Form; Ihr Code erzwingt die Bedeutung — dass diese customer_id zu einem Kunden gehört, den dieser Nutzer sehen darf.
Rechte am Tool, nicht am Prompt. „Nur erstatten, wenn der Kunde anspruchsberechtigt ist“ im System-Prompt ist ein Vorschlag, den das Modell ignorieren oder aus dem es sich herausreden lässt. Dieselbe Regel im Tool issue_refund erzwungen — das die Berechtigung selbst prüft und sonst ablehnt — ist eine Kontrolle. Alles, worauf Sie sich wirklich verlassen, gehört in Code rund um das Tool, wo es hält, egal wozu das Modell überredet wurde.
Das Unumkehrbare absichern. Lesezugriffe sind billig, wenn sie schiefgehen; Schreibvorgänge, Zahlungen und Löschungen nicht. Trennen Sie beides: Lassen Sie das Modell lesende Tools frei aufrufen, und leiten Sie alles, was die Welt verändert oder Geld ausgibt, über eine menschliche Freigabe oder eine harte Bestätigung. Das ist derselbe Instinkt, der hinter dem Absichern von LLM-Anwendungen allgemein steht — den Wirkungsradius des einen Aufrufs verengen, der Ihnen schaden kann.
Warum Tool-Entwurf mehr zählt als Prompt-Formulierung
Teams verbringen Tage mit dem Feilen an Prompt-Formulierungen und Minuten mit Tool-Definitionen — und das Verhältnis ist verkehrt. Die Prompt-Formulierung stupst das Verhalten an; der Tool-Entwurf bestimmt, was möglich ist. Ein Modell mit einem sauberen, gut benannten Satz enger Tools und ehrlichen Fehlermeldungen verhält sich unter einem mittelmäßigen Prompt gut. Ein Modell mit einem überladenen do_everything-Tool verhält sich unter einem wunderschön geschriebenen Prompt schlecht, weil Sie ihm eine Schnittstelle gegeben haben, an der der falsche Zug leicht zu machen und schwer zu fangen ist.
Deshalb ist Tool-Use oft der Sprung von einer Demo, die redet, zu einem System, das arbeitet — und deshalb sind die Fehler leiser, als man erwartet. Wenn das Tool die Suche ist, gelten dieselben Entwurfsregeln, weshalb eine RAG-Pipeline in Wahrheit ein Such-Tool mit einem guten Schema ist. Und wenn Sie das System evaluieren, testen Sie gezielt die Tool-Schicht: Wählt das Modell das richtige Tool, füllt es korrekt und erholt es sich von einem schlechten Ergebnis? Genau diese Fälle sollte ein ordentliches Evaluationsset abdecken, denn sie scheitern auf eine Art, die eine flüchtige Demo nie zeigt.
Wo Tippel ins Spiel kommt
Der meiste ingenieurtechnische Wert einer LLM-Funktion steckt in dieser Schicht: der Satz an Tools, ihre Schemata, die Prüf- und Rechtekontrollen darum herum und die Fehlermeldungen, die dem Modell die Selbstkorrektur ermöglichen. Das ist unspektakulär, taucht in der Demo selten auf und ist die Stelle, an der ein System entweder im Betrieb hält oder Ihnen peinlich wird. Wenn wir Agenten und LLM-Systeme bauen, geht ein großer Teil der Sorgfalt genau hierhin — die Grenze so zu entwerfen, dass das Modell nützliche Arbeit tun kann, ohne Schaden anrichten zu können.
Wenn Sie eine KI-Funktion abwägen, die Ihre echten Systeme berühren muss, und eine ehrliche Einschätzung wollen, wie diese Grenze zu ziehen ist, ist genau das der Zweck des KI-Readiness-Checks — oder Sie nehmen einfach Kontakt auf.