{"author":{"@type":"Person","name":"Alexander Bock","url":"https://abxk.ai/de/autor/alexander-bock/"},"categories":["AI Development"],"content":{"markdown":"Eine Chat-Antwort ist für Menschen geschrieben. Ihr Code braucht etwas anderes: Felder, die er lesen kann, Werte, die er prüfen kann, und Aktionen, die er ausführen kann. **Strukturierte Ausgabe** (Structured Output) und **Function Calling** sind die beiden Techniken, die aus einem Textgenerator einen verlässlichen Teil Ihrer Software machen.\n\nDies ist Teil 3 von Level 2. Sie lernen, wie Sie mit einem Schema gültiges JSON bekommen, wie Sie prüfen und wiederholen, wie der Ablauf beim Function Calling funktioniert, wie Sie Tool-Beschreibungen schreiben, die ein Modell versteht, und welche Sicherheitsprüfungen um jeden Aufruf gehören. Der Teil baut auf [Prompt-Design für Entwickler](/de/ai-development/learn/prompt-design-for-developers/) aus Level 1 auf.\n\n## Warum freier Text Ihren Code bricht\n\nStellen Sie sich ein Support-Tool vor, das eingehende Tickets sortiert. Sie fragen das Modell nach Kategorie und Priorität. Am Montag antwortet es: „Gern! Das sieht nach einem Rechnungsproblem mit hoher Priorität aus.“ Am Dienstag schreibt es: „Kategorie: Rechnung (dringend)“. Ihr Code muss raten, wo die Werte stehen, und früher oder später rät er falsch.\n\nStrukturierte Ausgabe löst das. Das Modell antwortet in einem festen Format, meist **JSON**, und ein **JSON Schema** beschreibt dieses Format. JSON Schema ist ein Standard, um festzulegen, welche Felder es gibt, welchen Typ sie haben und welche Werte erlaubt sind (json-schema.org).\n\n![Zwei Spalten vergleichen freien Text und strukturierte Ausgabe: jedes Mal andere Formulierungen gegenüber jedes Mal denselben Feldern](/images/learn/de/structured-output-and-function-calling-compare.webp \"Freier Text ist für Menschen geschrieben, strukturierte Ausgabe für Programme.\")\n\n## Die Form mit einem JSON Schema festlegen\n\nSo sieht ein Schema für das Ticket-Beispiel aus:\n\n```json\n{\n  \"type\": \"object\",\n  \"properties\": {\n    \"category\":    { \"type\": \"string\", \"enum\": [\"billing\", \"shipping\", \"technical\", \"other\"] },\n    \"priority\":    { \"type\": \"string\", \"enum\": [\"low\", \"normal\", \"high\"] },\n    \"summary\":     { \"type\": \"string\", \"description\": \"Ein Satz, höchstens 25 Wörter\" },\n    \"needs_human\": { \"type\": \"boolean\" }\n  },\n  \"required\": [\"category\", \"priority\", \"summary\", \"needs_human\"],\n  \"additionalProperties\": false\n}\n```\n\nVier Details leisten die meiste Arbeit:\n\n- **`enum`** beschränkt ein Feld auf feste Werte. „Rechnung (dringend)“ sieht Ihr Code nie wieder.\n- **`required`** stellt sicher, dass kein Feld fehlt.\n- **`additionalProperties: false`** verbietet zusätzliche Felder, mit denen Ihr Code nicht rechnet.\n- **`description`** sagt dem Modell, was ein Feld bedeutet. Das Modell liest sie wie einen Teil des Prompts.\n\nGeben Sie dem Modell immer einen Ausweg, etwa die Kategorie `other`. Ohne ihn muss das Modell jedes Ticket in eine Kategorie zwängen, auch wenn keine passt.\n\nEs gibt drei Wege, das Modell an das Schema zu binden. Erstens beschreiben Sie das Format im Prompt und fügen ein Beispiel hinzu. Das klappt meistens, aber nicht immer. Zweitens bieten viele APIs einen **JSON-Modus**, der syntaktisch gültiges JSON garantiert, aber nicht Ihre Felder. Drittens erzwingen manche APIs und Open-Source-Server das vollständige Schema, während das Modell seine Antwort erzeugt. Das heißt oft **Constrained Decoding** oder einfach Structured Outputs. Nutzen Sie die strengste Option, die Ihr Anbieter unterstützt.\n\n## Prüfen, wiederholen, ausweichen\n\nAuch eine Antwort, die zum Schema passt, kann falsch sein. Das Modell kann `shipping` für ein Rechnungsproblem wählen oder eine Zusammenfassung mit 80 Wörtern schreiben. Ihr Code prüft deshalb jede Antwort in drei Stufen, bevor er sie verwendet:\n\n1. **Parsen:** Ist es gültiges JSON?\n2. **Schema:** Sind alle Felder da, mit richtigem Typ und erlaubten Werten?\n3. **Geschäftsregeln:** Ergibt es für Ihren Fall Sinn? Eine Erstattung darf zum Beispiel nicht höher sein als der Bestellwert.\n\nSchlägt eine Prüfung fehl, schicken Sie die Fehlermeldung an das Modell zurück und fragen erneut. Begrenzen Sie das auf ein oder zwei Wiederholungen. Klappt es dann immer noch nicht, greift ein Ausweichweg: ein sicherer Standardwert, eine Warteschlange für Menschen oder eine klare Fehlermeldung. Protokollieren Sie jeden Fehlschlag. Eine steigende Fehlerquote ist ein frühes Warnsignal, dass eine Änderung an Prompt oder Modell etwas kaputt gemacht hat.\n\n![Ablauf von der Modellausgabe über Parsen, Schemaprüfung und Geschäftsregeln zur Verwendung, mit einem gestrichelten Wiederholungsweg zurück zum Modell und einem Ausweichweg zur Warteschlange für Menschen](/images/learn/de/structured-output-and-function-calling-validate.webp \"In drei Stufen prüfen. Ein- oder zweimal mit der Fehlermeldung wiederholen, dann ausweichen.\")\n\nIn Python kann die Schleife so aussehen. `call_model()`, `check_business_rules()` und `send_to_human_queue()` stehen für Ihren eigenen Code. `validate()` stammt aus dem Paket jsonschema:\n\n```python\nimport json\nfrom jsonschema import validate, ValidationError\n\ndef triage(ticket, messages):\n    for attempt in range(3):                      # erster Versuch + 2 Wiederholungen\n        raw = call_model(messages, schema=TICKET_SCHEMA)\n        try:\n            data = json.loads(raw)                # 1. parsen\n            validate(data, TICKET_SCHEMA)         # 2. Schema\n            check_business_rules(data)            # 3. eigene Regeln, werfen ValueError\n            return data\n        except (ValueError, ValidationError) as err:\n            messages += [\n                {\"role\": \"assistant\", \"content\": raw},\n                {\"role\": \"user\", \"content\": f\"Ungültige Ausgabe: {err}. Antworte nur mit korrigiertem JSON.\"},\n            ]\n    return send_to_human_queue(ticket)            # Ausweichweg\n```\n\nSolche Prüfungen sagen Ihnen nur, ob das Format stimmt. Wie oft der Inhalt stimmt, ist eine andere Frage. Die beantworten Sie mit einem Testsatz, wie Teil 4 zeigt: [KI-Funktionen mit Evals testen](/de/ai-development/learn/test-ai-features-with-evals/).\n\n## So funktioniert Function Calling\n\nBeim **Function Calling**, auch **Tool Calling** oder **Tool Use** genannt, beschreiben Sie dem Modell Funktionen: ihre Namen, was sie tun und welche Parameter sie erwarten. Braucht eine Frage eine davon, antwortet das Modell nicht mit Text. Stattdessen liefert es eine Anfrage wie „rufe `get_order_status` mit `order_id` 4711 auf“. Das Modell führt selbst nie etwas aus. Ihr Code entscheidet, ob die Funktion läuft, führt sie aus und schickt das Ergebnis zurück. Dann schreibt das Modell die Antwort.\n\n![Sequenzdiagramm mit vier Bahnen — Nutzer, Ihre Anwendung, Modell, Funktion — mit den fünf Schritten eines Tool-Aufrufs](/images/learn/de/structured-output-and-function-calling-sequence.webp \"Ein Tool-Aufruf in fünf Schritten. Das Modell schlägt den Aufruf nur vor; Ihr Code prüft ihn und führt ihn aus.\")\n\nEine Tool-Definition sieht in den meisten APIs ähnlich aus. Auch hier beschreibt ein JSON Schema die Parameter:\n\n```json\n{\n  \"name\": \"get_order_status\",\n  \"description\": \"Ruft den Versandstatus einer Bestellung ab. Nutzen, wenn der Kunde eine Bestellnummer nennt. Nicht für Erstattungen verwenden.\",\n  \"parameters\": {\n    \"type\": \"object\",\n    \"properties\": {\n      \"order_id\": { \"type\": \"string\", \"description\": \"Bestellnummer mit 4 bis 10 Ziffern, z. B. \\\"4711\\\"\" }\n    },\n    \"required\": [\"order_id\"]\n  }\n}\n```\n\nManche Fragen brauchen mehrere Aufrufe hintereinander: Bestellung nachschlagen, Lagerbestand prüfen, Antwort entwerfen. Dann führt die Anwendung diesen Ablauf in einer Schleife aus. Diese Schleife ist der Kern eines KI-Agenten, den Level 3 in [KI-Agenten bauen: Tools, Schleifen und Gedächtnis](/de/ai-development/learn/build-ai-agents-tools-loops-memory/) behandelt.\n\nDie Schleife müssen Sie nicht selbst programmieren. No-Code-Plattformen für Agenten und Automatisierungen verbinden Modelle für Sie mit Aktionen. Laut den Anbietern bauen Sie einen Agenten oder beschreiben einen Ablauf in Alltagssprache, statt Code zu schreiben:\n\n{{\u003c tools \"mindstudio turbotic devs-ai\" \u003e}}\n\nDie Sicherheitsregeln im letzten Abschnitt gelten genauso, egal wer die Schleife schreibt.\n\n## Tool-Beschreibungen, die das Modell versteht\n\nDas Modell wählt ein Tool nur anhand von Name, Beschreibung und Parametern. Ihren Code kann es nicht lesen. Jede Beschreibung ist also ein kleiner Prompt und verdient dieselbe Sorgfalt:\n\n| Element | Schwach | Besser |\n|---|---|---|\n| Name | `tool1`, `query` | `get_order_status`: Verb plus Objekt |\n| Beschreibung | „Holt Bestellungen“ | Sagt, was das Tool tut, wann es passt und wann nicht |\n| Parameter | `id` ohne Erklärung | `order_id` mit Format und Beispiel |\n| Erlaubte Werte | Freier Text | `enum` mit den gültigen Optionen |\n| Ergebnis | Eine ganze Datenbankzeile | Nur die Felder, die das Modell braucht, in Kurzform |\n| Fehler | Ein Stacktrace | Eine klare Meldung: „Bestellung nicht gefunden. Bitten Sie den Kunden, die Nummer zu prüfen.“ |\n\nHalten Sie die Zahl der Tools klein und ihre Aufgaben klar getrennt. Zwei Tools mit ähnlicher Beschreibung, etwa `find_order` und `search_orders`, verwirren das Modell. Verbinden Sie viele Tools über mehrere Anwendungen, helfen offene Standards: Das **Model Context Protocol** (MCP), 2024 von Anthropic vorgestellt, beschreibt Tools in einem gemeinsamen Format, das viele KI-Anwendungen verstehen.\n\n## Nie ohne Prüfung ausführen\n\nEin Tool-Aufruf des Modells ist ein Vorschlag, kein Befehl. Behandeln Sie ihn wie eine Nutzereingabe. Die Argumente können schlicht falsch sein, und Angreifer können versuchen, sie über **Prompt-Injection** zu steuern: Anweisungen, die in einer Nutzernachricht oder in einem abgerufenen Dokument versteckt sind. Unser [Bereich AI Security](/de/ai-security/) erklärt diesen Angriff und die Abwehr. Für Ihren Code ergeben sich fünf Schutzschichten:\n\n![Fünf Schutzschichten um einen Tool-Aufruf: Freigabeliste, Prüfung der Argumente, Berechtigungen, menschliche Freigabe, Limits und Protokoll](/images/learn/de/structured-output-and-function-calling-safety.webp \"Fünf Schichten zwischen dem Vorschlag des Modells und einer echten Aktion.\")\n\n{{\u003c callout type=\"warning\" \u003e}}\nGeben Sie einem Modell nie ein Allzweck-Tool wie „führe diese SQL-Abfrage aus“ oder „führe diesen Shell-Befehl aus“. Bieten Sie enge Funktionen mit festem Zweck an, etwa `get_order_status`, und führen Sie sie mit den Rechten der aktuellen Nutzerin aus, nicht mit Administratorrechten.\n{{\u003c /callout \u003e}}\n\nWie viel Kontrolle Sie brauchen, hängt davon ab, was ein Tool bewirken kann. Nutzen Sie diese Tabelle als Ausgangspunkt für Ihre eigenen Regeln:\n\n| Art der Aktion | Beispiel | Regel |\n|---|---|---|\n| Eigene Daten der Nutzerin lesen | Bestellstatus nachschlagen | Nach der Prüfung automatisch ausführen |\n| Sensible Daten lesen | Adresse eines Kunden anzeigen | Zuerst die Berechtigung der Nutzerin prüfen |\n| Schreiben, leicht rückgängig zu machen | Schlagwort setzen, Antwortentwurf anlegen | Automatisch ausführen, protokollieren, Rückgängig ermöglichen |\n| Schreiben mit Wirkung nach außen | E-Mail senden, Erstattung auslösen | Ein Mensch gibt vor der Ausführung frei |\n| Unumkehrbar oder folgenschwer | Daten löschen, Zahlung auslösen | Eigene Freigabe und strenge Limits — oder gar nicht als Tool anbieten |","text":"Eine Chat-Antwort ist für Menschen geschrieben. Ihr Code braucht etwas anderes: Felder, die er lesen kann, Werte, die er prüfen kann, und Aktionen, die er ausführen kann. Strukturierte Ausgabe (Structured Output) und Function Calling sind die beiden Techniken, die aus einem Textgenerator einen verlässlichen Teil Ihrer Software machen.\nDies ist Teil 3 von Level 2. Sie lernen, wie Sie mit einem Schema gültiges JSON bekommen, wie Sie prüfen und wiederholen, wie der Ablauf beim Function Calling funktioniert, wie Sie Tool-Beschreibungen schreiben, die ein Modell versteht, und welche Sicherheitsprüfungen um jeden Aufruf gehören. Der Teil baut auf Prompt-Design für Entwickler aus Level 1 auf.\nWarum freier Text Ihren Code bricht Stellen Sie sich ein Support-Tool vor, das eingehende Tickets sortiert. Sie fragen das Modell nach Kategorie und Priorität. Am Montag antwortet es: „Gern! Das sieht nach einem Rechnungsproblem mit hoher Priorität aus.“ Am Dienstag schreibt es: „Kategorie: Rechnung (dringend)“. Ihr Code muss raten, wo die Werte stehen, und früher oder später rät er falsch.\nStrukturierte Ausgabe löst das. Das Modell antwortet in einem festen Format, meist JSON, und ein JSON Schema beschreibt dieses Format. JSON Schema ist ein Standard, um festzulegen, welche Felder es gibt, welchen Typ sie haben und welche Werte erlaubt sind (json-schema.org).\nFreier Text ist für Menschen geschrieben, strukturierte Ausgabe für Programme. Die Form mit einem JSON Schema festlegen So sieht ein Schema für das Ticket-Beispiel aus:\n{ \u0026#34;type\u0026#34;: \u0026#34;object\u0026#34;, \u0026#34;properties\u0026#34;: { \u0026#34;category\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;enum\u0026#34;: [\u0026#34;billing\u0026#34;, \u0026#34;shipping\u0026#34;, \u0026#34;technical\u0026#34;, \u0026#34;other\u0026#34;] }, \u0026#34;priority\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;enum\u0026#34;: [\u0026#34;low\u0026#34;, \u0026#34;normal\u0026#34;, \u0026#34;high\u0026#34;] }, \u0026#34;summary\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;description\u0026#34;: \u0026#34;Ein Satz, höchstens 25 Wörter\u0026#34; }, \u0026#34;needs_human\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;boolean\u0026#34; } }, \u0026#34;required\u0026#34;: [\u0026#34;category\u0026#34;, \u0026#34;priority\u0026#34;, \u0026#34;summary\u0026#34;, \u0026#34;needs_human\u0026#34;], \u0026#34;additionalProperties\u0026#34;: false } Vier Details leisten die meiste Arbeit:\nenum beschränkt ein Feld auf feste Werte. „Rechnung (dringend)“ sieht Ihr Code nie wieder. required stellt sicher, dass kein Feld fehlt. additionalProperties: false verbietet zusätzliche Felder, mit denen Ihr Code nicht rechnet. description sagt dem Modell, was ein Feld bedeutet. Das Modell liest sie wie einen Teil des Prompts. Geben Sie dem Modell immer einen Ausweg, etwa die Kategorie other. Ohne ihn muss das Modell jedes Ticket in eine Kategorie zwängen, auch wenn keine passt.\nEs gibt drei Wege, das Modell an das Schema zu binden. Erstens beschreiben Sie das Format im Prompt und fügen ein Beispiel hinzu. Das klappt meistens, aber nicht immer. Zweitens bieten viele APIs einen JSON-Modus, der syntaktisch gültiges JSON garantiert, aber nicht Ihre Felder. Drittens erzwingen manche APIs und Open-Source-Server das vollständige Schema, während das Modell seine Antwort erzeugt. Das heißt oft Constrained Decoding oder einfach Structured Outputs. Nutzen Sie die strengste Option, die Ihr Anbieter unterstützt.\nPrüfen, wiederholen, ausweichen Auch eine Antwort, die zum Schema passt, kann falsch sein. Das Modell kann shipping für ein Rechnungsproblem wählen oder eine Zusammenfassung mit 80 Wörtern schreiben. Ihr Code prüft deshalb jede Antwort in drei Stufen, bevor er sie verwendet:\nParsen: Ist es gültiges JSON? Schema: Sind alle Felder da, mit richtigem Typ und erlaubten Werten? Geschäftsregeln: Ergibt es für Ihren Fall Sinn? Eine Erstattung darf zum Beispiel nicht höher sein als der Bestellwert. Schlägt eine Prüfung fehl, schicken Sie die Fehlermeldung an das Modell zurück und fragen erneut. Begrenzen Sie das auf ein oder zwei Wiederholungen. Klappt es dann immer noch nicht, greift ein Ausweichweg: ein sicherer Standardwert, eine Warteschlange für Menschen oder eine klare Fehlermeldung. Protokollieren Sie jeden Fehlschlag. Eine steigende Fehlerquote ist ein frühes Warnsignal, dass eine Änderung an Prompt oder Modell etwas kaputt gemacht hat.\nIn drei Stufen prüfen. Ein- oder zweimal mit der Fehlermeldung wiederholen, dann ausweichen. In Python kann die Schleife so aussehen. call_model(), check_business_rules() und send_to_human_queue() stehen für Ihren eigenen Code. validate() stammt aus dem Paket jsonschema:\nimport json from jsonschema import validate, ValidationError def triage(ticket, messages): for attempt in range(3): # erster Versuch + 2 Wiederholungen raw = call_model(messages, schema=TICKET_SCHEMA) try: data = json.loads(raw) # 1. parsen validate(data, TICKET_SCHEMA) # 2. Schema check_business_rules(data) # 3. eigene Regeln, werfen ValueError return data except (ValueError, ValidationError) as err: messages += [ {\u0026#34;role\u0026#34;: \u0026#34;assistant\u0026#34;, \u0026#34;content\u0026#34;: raw}, {\u0026#34;role\u0026#34;: \u0026#34;user\u0026#34;, \u0026#34;content\u0026#34;: f\u0026#34;Ungültige Ausgabe: {err}. Antworte nur mit korrigiertem JSON.\u0026#34;}, ] return send_to_human_queue(ticket) # Ausweichweg Solche Prüfungen sagen Ihnen nur, ob das Format stimmt. Wie oft der Inhalt stimmt, ist eine andere Frage. Die beantworten Sie mit einem Testsatz, wie Teil 4 zeigt: KI-Funktionen mit Evals testen.\nSo funktioniert Function Calling Beim Function Calling, auch Tool Calling oder Tool Use genannt, beschreiben Sie dem Modell Funktionen: ihre Namen, was sie tun und welche Parameter sie erwarten. Braucht eine Frage eine davon, antwortet das Modell nicht mit Text. Stattdessen liefert es eine Anfrage wie „rufe get_order_status mit order_id 4711 auf“. Das Modell führt selbst nie etwas aus. Ihr Code entscheidet, ob die Funktion läuft, führt sie aus und schickt das Ergebnis zurück. Dann schreibt das Modell die Antwort.\nEin Tool-Aufruf in fünf Schritten. Das Modell schlägt den Aufruf nur vor; Ihr Code prüft ihn und führt ihn aus. Eine Tool-Definition sieht in den meisten APIs ähnlich aus. Auch hier beschreibt ein JSON Schema die Parameter:\n{ \u0026#34;name\u0026#34;: \u0026#34;get_order_status\u0026#34;, \u0026#34;description\u0026#34;: \u0026#34;Ruft den Versandstatus einer Bestellung ab. Nutzen, wenn der Kunde eine Bestellnummer nennt. Nicht für Erstattungen verwenden.\u0026#34;, \u0026#34;parameters\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;object\u0026#34;, \u0026#34;properties\u0026#34;: { \u0026#34;order_id\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;string\u0026#34;, \u0026#34;description\u0026#34;: \u0026#34;Bestellnummer mit 4 bis 10 Ziffern, z. B. \\\u0026#34;4711\\\u0026#34;\u0026#34; } }, \u0026#34;required\u0026#34;: [\u0026#34;order_id\u0026#34;] } } Manche Fragen brauchen mehrere Aufrufe hintereinander: Bestellung nachschlagen, Lagerbestand prüfen, Antwort entwerfen. Dann führt die Anwendung diesen Ablauf in einer Schleife aus. Diese Schleife ist der Kern eines KI-Agenten, den Level 3 in KI-Agenten bauen: Tools, Schleifen und Gedächtnis behandelt.\nDie Schleife müssen Sie nicht selbst programmieren. No-Code-Plattformen für Agenten und Automatisierungen verbinden Modelle für Sie mit Aktionen. Laut den Anbietern bauen Sie einen Agenten oder beschreiben einen Ablauf in Alltagssprache, statt Code zu schreiben:\nMindStudioAgenten \u0026amp; Automatisierung · KI ist der KernNo-Code-Plattform zum Bauen eigener KI-Agenten. TurboticAgenten \u0026amp; Automatisierung · KI ist der KernBaut Automatisierungen aus einer Beschreibung in natürlicher Sprache, ohne Code. Devs.aiApp-Bau \u0026amp; Tests · KI ist der KernPlattform, auf der Teams KI-Anwendungen und eigene Agenten mit ihren Daten bauen und betreiben. Kurzbeschreibungen aus unserem Tool-Vergleich, nach Angaben der Anbieter — nicht von ABXK getestet.\nDie Sicherheitsregeln im letzten Abschnitt gelten genauso, egal wer die Schleife schreibt.\nTool-Beschreibungen, die das Modell versteht Das Modell wählt ein Tool nur anhand von Name, Beschreibung und Parametern. Ihren Code kann es nicht lesen. Jede Beschreibung ist also ein kleiner Prompt und verdient dieselbe Sorgfalt:\nStrukturierte Ausgabe und Function Calling Element Schwach Besser Name tool1, query get_order_status: Verb plus Objekt Beschreibung „Holt Bestellungen“ Sagt, was das Tool tut, wann es passt und wann nicht Parameter id ohne Erklärung order_id mit Format und Beispiel Erlaubte Werte Freier Text enum mit den gültigen Optionen Ergebnis Eine ganze Datenbankzeile Nur die Felder, die das Modell braucht, in Kurzform Fehler Ein Stacktrace Eine klare Meldung: „Bestellung nicht gefunden. Bitten Sie den Kunden, die Nummer zu prüfen.“ Halten Sie die Zahl der Tools klein und ihre Aufgaben klar getrennt. Zwei Tools mit ähnlicher Beschreibung, etwa find_order und search_orders, verwirren das Modell. Verbinden Sie viele Tools über mehrere Anwendungen, helfen offene Standards: Das Model Context Protocol (MCP), 2024 von Anthropic vorgestellt, beschreibt Tools in einem gemeinsamen Format, das viele KI-Anwendungen verstehen.\nNie ohne Prüfung ausführen Ein Tool-Aufruf des Modells ist ein Vorschlag, kein Befehl. Behandeln Sie ihn wie eine Nutzereingabe. Die Argumente können schlicht falsch sein, und Angreifer können versuchen, sie über Prompt-Injection zu steuern: Anweisungen, die in einer Nutzernachricht oder in einem abgerufenen Dokument versteckt sind. Unser Bereich AI Security erklärt diesen Angriff und die Abwehr. Für Ihren Code ergeben sich fünf Schutzschichten:\nFünf Schichten zwischen dem Vorschlag des Modells und einer echten Aktion. !Achtung\nGeben Sie einem Modell nie ein Allzweck-Tool wie „führe diese SQL-Abfrage aus“ oder „führe diesen Shell-Befehl aus“. Bieten Sie enge Funktionen mit festem Zweck an, etwa get_order_status, und führen Sie sie mit den Rechten der aktuellen Nutzerin aus, nicht mit Administratorrechten.\nWie viel Kontrolle Sie brauchen, hängt davon ab, was ein Tool bewirken kann. Nutzen Sie diese Tabelle als Ausgangspunkt für Ihre eigenen Regeln:\nStrukturierte Ausgabe und Function Calling (2) Art der Aktion Beispiel Regel Eigene Daten der Nutzerin lesen Bestellstatus nachschlagen Nach der Prüfung automatisch ausführen Sensible Daten lesen Adresse eines Kunden anzeigen Zuerst die Berechtigung der Nutzerin prüfen Schreiben, leicht rückgängig zu machen Schlagwort setzen, Antwortentwurf anlegen Automatisch ausführen, protokollieren, Rückgängig ermöglichen Schreiben mit Wirkung nach außen E-Mail senden, Erstattung auslösen Ein Mensch gibt vor der Ausführung frei Unumkehrbar oder folgenschwer Daten löschen, Zahlung auslösen Eigene Freigabe und strenge Limits — oder gar nicht als Tool anbieten ","words":1418},"date":"2026-10-14","description":"Verlässliches JSON von einem Sprachmodell und sichere Funktionsaufrufe: Schemas, Validierung, Wiederholungen, Tool-Beschreibungen und nötige Prüfungen.","image":"https://abxk.ai/images/cover/structured-output-and-function-calling.webp","json":"https://abxk.ai/de/ai-development/learn/structured-output-and-function-calling/index.json","kind":"page","language":"de","learning_path":{"category":"ai-development","level":2,"level_name":"Fortgeschritten"},"modified":"2026-10-14","related_tools":["MindStudio","Turbotic","Devs.ai"],"section":"ai-development","tags":["strukturierte-ausgabe","function-calling","json-schema","llm-anwendungen"],"title":"Strukturierte Ausgabe und Function Calling","translations":[{"json":"https://abxk.ai/en/ai-development/learn/structured-output-and-function-calling/index.json","language":"en","url":"https://abxk.ai/en/ai-development/learn/structured-output-and-function-calling/"}],"url":"https://abxk.ai/de/ai-development/learn/structured-output-and-function-calling/"}