Funktionsaufrufe in der OpenAI API: Was sie tatsächlich tun und wie man sie richtig nutzt

Sie leiten die Nachricht eines Nutzers an die GPT-API weiter, und statt einer Antwort in natürlicher Sprache liefert das Modell Ihnen ein strukturiertes JSON-Objekt zurück, das genau angibt, welche Funktion aufzurufen ist und mit welchen Argumenten. Das sind Funktionsaufrufe — und sie verändern die Art von Anwendungen, die Sie mit LLMs bauen können.

Die meisten Entwickler hören „Function Calling“ und nehmen an, das Modell führe Code in ihrem Namen aus. Tut es nicht.

Beim Einsatz von Funktionsaufrufen führt das LLM die Funktion selbst nicht aus. Stattdessen identifiziert es die passende Funktion, sammelt alle erforderlichen Parameter und liefert die Informationen in einem strukturierten JSON-Format.

Ihre Anwendung ist weiterhin dafür verantwortlich, die eigentliche Logik auszuführen. Das Modell sagt Ihnen nur, was auszuführen ist und mit welchen Eingaben.

Diese Unterscheidung ist wichtiger, als es klingt, und prägt alles — von der Architektur Ihrer Integration bis hin zu Ihren Sicherheitsüberlegungen.

Was Funktionsaufrufe wirklich sind — und was viele falsch verstehen

Funktionsaufrufe (auch als Tool-Aufrufe bekannt) bieten eine leistungsstarke und flexible Möglichkeit für OpenAI-Modelle, mit externen Systemen zu interagieren und auf Daten außerhalb ihrer Trainingsdaten zuzugreifen.

Schon die Bezeichnung sorgt für Verwirrung. Viele denken, das Modell führe etwas aus. Tut es nicht.

Es gibt viele Namen und Erklärungen für Funktionsaufrufe, doch letztlich läuft alles auf eine Aussage hinaus: „Funktionsaufrufe sind eine Art strukturierte Ausgabefähigkeit eines großen Sprachmodells.“ LLMs rufen keine Funktionen selbst auf; sie schlagen vor, welche Funktion Sie aus einem Satz vordefinierter Funktionen, den Sie dem LLM im Prompt bereitstellen, aufrufen sollten.

Die zweite Verwirrung betrifft die alte API-Oberfläche.

Die Parameter functions und function_call wurden mit der Veröffentlichung der API-Version 2023-12-01-preview als veraltet markiert. Der Ersatz für functions ist der Parameter tools.

Wenn Sie einem Tutorial folgen, das den alten Parameter functions verwendet, arbeiten Sie bereits mit veraltetem Syntax. Verwenden Sie stattdessen tools und tool_choice.

Eine Funktion ist eine spezielle Art von Tool, definiert durch ein JSON-Schema. Eine Funktionsdefinition ermöglicht es dem Modell, Daten an Ihre Anwendung zu übergeben, wo Ihr Code auf Daten zugreifen oder vom Modell vorgeschlagene Aktionen ausführen kann.

Dieses Schema verleiht Funktionsaufrufen ihren Zuverlässigkeitsvorteil gegenüber reinem Prompting — Sie hoffen nicht, dass das Modell das Ausgabeformat korrekt einhält, sondern erzwingen Struktur auf API-Ebene.

Wie Funktionsaufrufe in der OpenAI-API funktionieren — Schritt für Schritt

Tool-Aufrufe sind ein mehrstufiger Dialog zwischen Ihrer Anwendung und einem Modell über die OpenAI-API. Der Tool-Calling-Flow umfasst fünf übergeordnete Schritte: eine Anfrage an das Modell stellen mit Tools, die es aufrufen könnte ...

So sieht jeder dieser Schritte in der Praxis aus.

Schritt 1: Definieren Sie Ihre Funktionsschemata. Sie beschreiben jede verfügbare Funktion als JSON-Objekt innerhalb des Parameters tools. Das Schema umfasst den Funktionsnamen, eine Beschreibung in natürlicher Sprache, anhand derer das Modell entscheidet, wann es sie aufrufen soll, sowie einen Block parameters, der den JSON-Schema-Konventionen folgt.

Je detaillierter Ihre description ist — hinsichtlich der Situationen, in denen die Funktion aufgerufen werden kann und soll —, desto besser. Beachten Sie jedoch, dass Funktionsbeschreibungen Teil des Prompts sind und entsprechend Token verbrauchen.

Schritt 2: Senden Sie die Anfrage. Sie rufen die Chat Completions API mit der Nachricht des Nutzers und Ihrer tools-Liste auf. Das Modell sieht beides.

Schritt 3: Das Modell entscheidet, ob eine Funktion aufgerufen wird.

Ein Funktionsaufruf bezieht sich auf eine spezielle Art von Antwort, die Sie vom Modell erhalten können, wenn es einen Prompt prüft und feststellt, dass es, um den Anweisungen zu folgen, eines der verfügbaren Tools aufrufen muss. Wenn das Modell einen Prompt wie „Wie ist das Wetter in Paris?“ erhält, könnte es mit einem Tool-Aufruf für das Tool get_weather antworten — mit Paris als Argument für den Standort.

Schritt 4: Ihr Code führt die Funktion aus. Sie parsen die Antwort des Modells, extrahieren Funktionsnamen und Argumente und führen den eigentlichen Code in Ihrer Laufzeitumgebung aus. Die API hat strukturiertes JSON zurückgegeben — Sie entscheiden, was Sie damit tun.

Schritt 5: Senden Sie das Ergebnis zurück.

Sie senden dann die gesamte Tooldefinition, den ursprünglichen Prompt, den Tool-Aufruf des Modells und die Ausgabe des Tool-Aufrufs zurück an das Modell, um schließlich eine Textantwort zu erhalten

— etwa „Das Wetter in Paris beträgt heute 25°C.“

Ein Detail, das die meisten Tutorials auslassen:

Wenn Sie strict: true in Ihrer Funktionsdefinition setzen, garantiert Structured Outputs, dass die vom Modell generierten Argumente für einen Funktionsaufruf exakt dem von Ihnen bereitgestellten JSON-Schema entsprechen.

strict auf true zu setzen, stellt sicher, dass Funktionsaufrufe das Funktionsschema zuverlässig einhalten, statt nur bestmöglich. OpenAI empfiehlt, den Strict-Modus immer zu aktivieren.

Immer. Es gibt keinen guten Grund, es nicht zu tun.

Es gibt auch parallele Funktionsaufrufe zu beachten.

Abhängig von der Nutzeranfrage wird das Modell parallele Funktionsaufrufe nutzen, wenn Sie die neuesten Modelle verwenden, die am oder nach dem 6. November 2023 veröffentlicht wurden.

Das bedeutet, dass eine einzelne Anfrage wie „Wie ist das Wetter in London und Tokio?“ zwei gleichzeitige Tool-Aufrufe auslösen kann, statt sie nacheinander zu verketten.

Praxisanwendungen für Funktionsaufrufe

Das Wetterbeispiel ist überall, weil es sauber ist. Reale Produktionsanwendungen sind unordentlicher — und interessanter.

Kundenservice-Pipelines mit Live-Daten

Funktionsaufrufe sind für eine Vielzahl von Anwendungsfällen nützlich — etwa für einen KI-Assistenten, der beim Nutzerwunsch „Was sind meine letzten Bestellungen?“ zunächst die neuesten Kundendaten aus einem internen System abrufen muss, bevor er eine Antwort generieren kann.

Das Modell erkennt die Absicht, extrahiert die Kunden-ID aus dem Kontext und ruft die interne API Ihres CRM auf. Keine fragilen Regex. Keine Prompt-Vorlagen, die an einem fehlenden Komma zerbrechen.

Strukturierte Datenerfassung in großem Maßstab

Eine Datenextraktions-Pipeline, die Rohtext abruft, ihn in strukturierte Daten konvertiert und in einer Datenbank speichert, ist ein weiteres starkes Einsatzszenario. Sie erhalten konsistente Schemata über Tausende von Dokumenten hinweg, ohne Parser-Logik pro Dokumenttyp manuell zu tunen.

Von natürlicher Sprache zur API-Übersetzung

LLM-gestützte Lösungen zum Extrahieren und Taggen von Daten, Anwendungen, die natürliche Sprache in API-Aufrufe oder gültige Datenbankabfragen übersetzen können, und konversationelle Wissensabfragesysteme, die mit einer Wissensbasis interagieren — all diese profitieren von der Formatgarantie durch Funktionsaufrufe. Wenn die Ausgabe nachgelagerte Systeme steuern soll, ist Variabilität nicht tolerierbar.

Agenten-Workflows mit mehreren Tools

Für Entwickler ermöglichen Funktionsaufrufe den Zugriff auf Echtzeitdaten, um Trainings-Cutoffs zu überbrücken, indem Live-Aktienkurse, Wetter oder aktuelle Datenbankeinträge abgerufen werden. Sie ermöglichen zudem die Ausführung von Aktionen — das LLM wird vom passiven Beobachter zum aktiven Teilnehmer, der Zustände verändert, etwa E-Mails versendet, CRMs aktualisiert oder Code deployt.

Der wesentliche Unterschied zu einem einfachen Chatbot: Das Modell generiert nicht nur Text, sondern orchestriert tatsächliche Operationen in Ihren Systemen.

Best Practices für Funktionsaufrufe — was Entwickler oft falsch machen

Das ist der Abschnitt, den die meisten Tutorials völlig auslassen — weshalb Teams sich dann um 2 Uhr morgens mit seltsamen Produktionsfehlern herumschlagen.

Zu vage Beschreibungen. Das Modell nutzt Ihre Funktionsbeschreibung, um zu entscheiden, wann es sie aufrufen soll. Ist Ihre Beschreibung generisch — etwa „verarbeitet Nutzeranfragen“ —, hat das Modell kein verlässliches Signal, um den Aufruf auszulösen. Seien Sie spezifisch in Bezug auf Auslösekriterien und erwartete Eingabeform. Denken Sie an die Beschreibung als Vertrag, nicht als Etikett.

Zu viele Funktionen auf einmal exponieren

Funktionsbeschreibungen können eine erhebliche Anzahl von Token im Eingabeprompt verbrauchen.

Das Laden von Definitionen für 50+ Tools in den System-Prompt erzeugt zwei Probleme: Kosten und Latenz, da Tooldefinitionen Eingabetoken konsumieren; sowie Genauigkeitsverluste, da mit steigender Anzahl von Tooloptionen die Fähigkeit des Modells, das richtige auszuwählen, abnimmt.

Beginnen Sie mit dem kleinsten Satz an Funktionen, den Ihr Anwendungsfall tatsächlich benötigt.

Annehmen, das Modell werde keine Parameter halluzinieren. Wird es.

Das Modell kann Parameter halluzinieren

— insbesondere bei optionalen Feldern, die nicht eindeutig durch ein Enum begrenzt sind. Genau deshalb ist strict: true wichtig: Es nimmt dem Modell die Möglichkeit, Felder außerhalb Ihres Schemas zu erfinden.

Die Multi-Turn-Schleife nicht handhaben. Entwickler bauen oft den Happy Path — Nutzer fragt, Modell ruft Funktion auf, fertig.

Modelle können Funktionsaufrufe generieren, die nicht mit dem von Ihnen definierten Schema übereinstimmen, oder versuchen, eine Funktion aufzurufen, die Sie nicht bereitgestellt haben. Wenn das Modell unerwartete Funktionsaufrufe generiert, fügen Sie eine Anweisung in die Systemnachricht ein, die sagt: „Nutze nur die Funktionen, die dir bereitgestellt wurden.“

Bauen Sie für die Randfälle.

Den Bestätigungsschritt vor Schreiboperationen überspringen.

Seien Sie sich der realen Auswirkungen von Funktionsaufrufen bewusst, die Sie ausführen wollen — insbesondere jenen, die Aktionen auslösen, wie Code ausführen, Datenbanken aktualisieren oder Benachrichtigungen versenden. Für Funktionen, die Aktionen ausführen, ist ein Schritt zur Nutzerbestätigung vor der Ausführung dringend zu empfehlen.

Wenn ein Funktionsaufruf Daten löschen, Geld versenden oder externen Zustand ändern kann, sollte ein Mensch ihn zuerst freigeben.

Sicherheits- und Zuverlässigkeitsaspekte

Funktionsaufrufe erweitern, was ein LLM tun kann. Sie erweitern auch, was ein Angreifer es tun lassen kann.

Die primäre Bedrohung ist Prompt-Injektion.

Die Endziele von Prompt-Injektionen variieren, können aber das Exfiltrieren privater Daten über nachgelagerte Tool-Aufrufe, das Ausführen fehlgeleiteter Aktionen oder anderweitige unbeabsichtigte Verhaltensänderungen des Modells umfassen.

Wenn Ihre Funktionsaufrufe E-Mails versenden, Datenbanken abfragen oder Webhooks auslösen können, ist ein Injektionsangriff nicht nur ein Chatbot, der vom Skript abweicht — es ist ein potenzieller Sicherheitsvorfall.

Wenn KI-Systeme über Chat hinausgehen, Tools aufrufen und Aktionen ausführen, wird Prompt-Injektion zu einem wesentlich ernsteren Problem. Eine bösartige Anweisung, versteckt in einer Webseite, einem Dokument oder einem externen Tool, kann versuchen, Systemverhalten zu überschreiben, sensible Informationen offenzulegen oder Aktionen auszulösen, die das Modell niemals ausführen sollte.

Die Gegenstrategie hat einige konkrete Ebenen.

Gestalten Sie Workflows so, dass untrusted Data niemals direkt das Agentenverhalten steuert. Extrahieren Sie nur spezifische strukturierte Felder — etwa Enums oder validiertes JSON — aus externen Eingaben, um das Risiko zu begrenzen, dass Injektionen zwischen Knoten weitergegeben werden.

Darüber hinaus

verifizieren Sie stets die vom Modell generierten Funktionsaufrufe. Dazu gehört das Prüfen der Parameter, der aufgerufenen Funktion und die Sicherstellung, dass der Aufruf mit der beabsichtigten Aktion übereinstimmt.

Eine unbequeme Wahrheit:

„Prompt-Injektion, ähnlich wie Betrugsmaschen und Social Engineering im Web, wird wohl niemals vollständig ‚gelöst‘ werden.“

Das ist die Einschätzung von OpenAI. Praktisch bedeutet das: Sie sollten agentische Systeme mit Funktionsaufrufen nicht in der Annahme entwerfen, dass sich das Modell immer wie beabsichtigt verhält. Defense-in-Depth — Validierung, granular abgestufte Berechtigungen, Mensch-in-der-Schleife bei destruktiven Operationen — ist die einzig sinnvolle Haltung.

Funktionsaufrufe vs. Prompt Engineering — wann man was einsetzt

Dieser Vergleich taucht ständig auf. Die kurze Antwort: Sie lösen unterschiedliche Probleme, und ihre Vermischung führt zu überengineerten Prompts, wo Funktionsaufrufe ausreichen würden, oder zu fragilen Funktionsschemata, wo ein gut formuliertes System-Prompt einfacher wäre.

Prompt Engineering umfasst das Ausarbeiten von Texteingaben, um das interne Reasoning des LLM zu steuern — etwa indem man es bittet, „Schritt für Schritt zu denken“.

Es prägt, wie das Modell denkt. Funktionsaufrufe hingegen prägen, was das Modell als Output produziert, und leiten es direkt in Ihr System.

Tool-Aufrufe sind die Fähigkeit, die dem LLM die Interaktion mit externen Systemen ermöglicht. Während Sie Prompt Engineering einsetzen, um dem Modell bei der Auswahl des richtigen Tools zu helfen, ist der Tool-Aufruf der Mechanismus, der die Aktion tatsächlich ausführt. Sie benötigen wahrscheinlich beides, aber sie dienen unterschiedlichen Zwecken.

Ein technischer Vorteil von Funktionsaufrufen gegenüber promptbasiert strukturierter Ausgabe:

Tool-Aufrufe sind ein Konzept, das direkt im Modell verankert ist. Es ist nicht nötig, Token und Aufwand darauf zu verwenden, dem Modell zu erklären, dass es ein bestimmtes Format zurückgeben soll.

Wenn Sie einen Prompt formulieren, der sagt „Gib Deine Antwort als JSON mit den Feldern X, Y und Z zurück“, verbrauchen Sie Token für Anweisungen, denen das Modell inkonsistent folgen könnte. Bei Funktionsaufrufen erfolgt die Schemaerzwingung auf API-Ebene.

APIs für Funktionsaufrufe, die mittlerweile nativ in vielen LLM-Plattformen unterstützt werden, bieten eine formale, schemagetriebene Schnittstelle, die strikte Datenvalidierung und Integration in programmatische Workflows ermöglicht.

Das ist der praktische Grund, sich dafür zu entscheiden, wenn Daten in nachgelagerte Systeme fließen müssen: Zuverlässigkeit ist in der Produktion nicht optional.

Die praktische Heuristik: Wenn der Output ein nachgelagertes System steuern soll — ein Datenbank-Write, ein API-Aufruf, ein Entscheidungszweig in Ihrem Code —, verwenden Sie Funktionsaufrufe. Wenn der Output für Menschen gedacht ist, genügt Prompt Engineering in der Regel und ist günstiger.

Wichtigste Erkenntnisse

Wenn Sie mit Funktionsaufrufen über verschiedene Modelle — GPT-5.4, claude opus 4.7, gemini 3.1 pro — experimentieren möchten, ohne für jedes eigene API-Zugangsdaten zu verwalten, bietet CometAPI Ihnen Zugriff auf alle über einen einzigen Endpunkt und Schlüssel, was das Cross-Model-Testing erheblich reibungsloser macht.

CometAPI löst den Infrastruktur-Overhead:

✅ Einheitliche Syntax für Funktionsaufrufe über 15+ Modelle

✅ Einziger API-Schlüssel — keine separaten Accounts für OpenAI/Anthropic/Google

✅ Automatische Schema-Übersetzung — einmal schreiben, überall testen

✅ Integriertes Kosten-Tracking — Tokenverbrauch pro Modell in Echtzeit vergleichen

Mit kostenlosen Credits starten → Zugang erhalten