AI-Entwicklung

Was ist ein AI Agent? 2026-Leitfaden zu Funktionsweise, Tool Calling, Function Calling und JSON

JSONSort Veröffentlicht 2026-09-05 Aktualisiert 2026-09-05 Ca. 16 Min.

Jede AI-Produktseite 2026 schreibt „Agent“. Die meisten falten Chatbot, Modell mit Funktionsaufruf und Runtime, die einen Mehrschritt-Workflow zu Ende bringt in ein Wort. Dieser Text startet bei der Definition: was ein AI Agent ist, wie die Schleife läuft, worin sich Tool Calling und Function Calling unterscheiden und warum jede Schicht auf JSON landet. Danach solltest du eine debuggbare Aufrufkette zeichnen können – nicht nur einen längeren Prompt.

Kurzüberblick

Begriff	Ein Satz	JSON-Landepunkt
AI Agent	Runtime, die plant, Tools ruft und das Ergebnis weitergibt	Workflow-Zustand / Handoff
Tool Calling	Oberbegriff: das Modell will eine externe Fähigkeit	`tool_calls`
Function Calling	Umsetzung in der Vendor-API	`tools[]` / `arguments`
JSON	einziges stabiles, prüfbares Objekt zwischen Schritten	Schema / Payload

Schichten merken: Agent ist Runtime, Tool Calling die Fähigkeit, Function Calling der API-Rahmen, JSON der gemeinsame Vertrag.

Was ist ein AI Agent?

Ein AI Agent ist kein „Modell, das besser plaudert“. Das Modell erzeugt nur Text (oder ein strukturiertes Objekt). Der Agent ist die Runtime, die das Modell in eine Schleife setzt: Zustand beobachten, nächsten Schritt planen, externes Tool rufen, Ergebnis verdauen, dann weiter, übergeben oder stoppen.

Ein auslieferbarer Agent 2026 besteht meist aus drei Teilen:

Modell: schlussfolgern, Tool wählen, Structured Outputs erzeugen.
Host: Aufrufabsicht parsen, echte API / DB / Datei ausführen, Ergebnis zurückgeben, illegales JSON blockieren.
Vertrag: Tool-Parameter, Rückgaben, Handoff-Objekte, Workflow-Zustand – fast alles JSON.

Ohne Host kann das Modell nur vorschlagen. Ohne Vertrag trägt ein Mehrschrittfluss ein halbrichtiges Objekt als Fakt weiter. Die Produktgrenze sitzt beim Host, nicht auf der Modellkarte.

Worin unterscheiden sich Chatbot und normales LLM?

Drei Labels kleben an einem Feature. Produktion muss sie trennen:

Normales LLM: Text rein, Text raus. Keine Tools, kein Zustand über Schritte.
Chatbot: LLM an eine Dialog-UI. Ausgabe für Menschen; bei Fehlern wiederholt der Nutzer.
AI Agent: Ausgabe führt ein Programm aus. Tool-Ergebnisse, Routing und Eval-Werte sind Objekte, kein Prosa.

Ein einfacher Test: Muss der nächste Schritt von Code ausgeführt – nicht von einem Menschen verstanden – werden, brauchst du einen Agenten, keinen cleveren Dialog. Die Ausführung gehört dem Host; das Modell liefert nur die Aufrufabsicht.

Wie arbeitet ein AI Agent 2026?

Die Schleife bleibt observe → plan → act → observe. Neu ist: jeder Hop ist typisiert, statt „das Modell hat Refund erwähnt“.

Observe: Nutzernachricht, letztes Tool-Ergebnis und aktuellen JSON-Zustand in den Kontext legen.
Plan: das Modell antwortet, ruft ein Tool oder übergibt ein Objekt an einen anderen Agenten.
Act: der Host führt tool_calls aus oder wechselt Agenten per Handoff-JSON.
Observe again: Ergebnisse kommen als role: tool; das Zustandsobjekt wird vor der nächsten Runde aktualisiert.

Der Host macht vier Dinge, die das Modell nicht übernimmt: tools[] injizieren, arguments ein zweites Mal parsen, per Schema prüfen, bei Fehler abbrechen – statt „längeren Prompt versuchen“.

Der Produktionsstack ist bereits konvergiert. Die Assistants API endete am 26. August 2026; neuer Code nutzt Responses API + Agents SDK. DevDay-2026-Prognosen schreibt denselben Trend in drei Schichten: Structured Outputs formen das Objekt, Function Calling drückt den Aufruf aus, die Agent-Runtime orchestriert beides.

Lass den Chatverlauf den Fortschritt nicht „erinnern“. Schreib den aktuellen Schritt als wiederherstellbares JSON:

{
  "step": 2,
  "agent": "billing",
  "last_tool": "lookup_order",
  "state": {
    "order_id": "A-1042",
    "status": "paid",
    "amount": 99.00
  },
  "next": "create_refund"
}

Formatiere solche Objekte lokal mit formatieren und syntaxprüfen und JSON Diff sie gegen die Definition der letzten Woche. Tool-Antworten mit Nutzerdaten oder Geheimnissen nicht auf eine öffentliche JSON-Site kleben.

Was ist Tool Calling?

Tool Calling ist der Fähigkeitsbegriff: zum richtigen Zeitpunkt gibt das Modell maschinenlesbar „ich brauche eine externe Fähigkeit“ aus, statt in Prosa so zu tun, als hätte es die Datenbank schon befragt. Es hängt nicht an Feldnamen eines Vendors.

Mindestens drei Implementierungen 2026 heißen alle Tool Calling: Function Calling auf OpenAI-kompatiblen APIs, Vendor-Tool-Use (Anthropic u. a.) und MCP mit tools/list + tools/call. MCP Tool Schema vs Function Calling zog die Grenze: MCP liefert Tools über Hosts hinweg; der API-Rahmen lässt das Modell die Absicht dieses Hops ausdrücken.

Für Entwickler beantwortet Tool Calling „kann das Modell greifen?“. Nicht „wer prüft Parameter und Ergebnisse danach?“. Das sind Schema und Host.

Was ist Function Calling?

Function Calling (OpenAI-Docs sagen inzwischen meist tools) ist die konkrete Form von Tool Calling in einer Vendor-Chat- / Responses-API. Du injizierst Funktionsdefinitionen; entscheidet sich das Modell für einen Aufruf, enthält die Antwort tool_calls.

Eine typische OpenAI-Definition sieht so aus. parameters ist bereits eine JSON-Schema-Teilmenge:

{
  "type": "function",
  "function": {
    "name": "lookup_order",
    "description": "Look up an order by ID",
    "parameters": {
      "type": "object",
      "properties": {
        "order_id": {
          "type": "string",
          "description": "Order ID, e.g. A-1042"
        }
      },
      "required": ["order_id"],
      "additionalProperties": false
    }
  }
}

Die Aufrufabsicht kommt meist so zurück:

{
  "tool_calls": [{
    "id": "call_3c91",
    "type": "function",
    "function": {
      "name": "lookup_order",
      "arguments": "{\"order_id\":\"A-1042\"}"
    }
  }]
}

arguments ist noch immer stringifiziertes JSON. Der Host muss erneut JSON.parse und order_id gegen das Schema prüfen. Dieser Schritt fehlt 2026 am häufigsten in Incidents. Wird die Schachtelung unleserlich, zuerst formatieren und syntaxprüfen, um Klammern und Escapes zu sehen.

Wie unterscheiden sich Tool Calling und Function Calling – und wie stapelt man sie?

Keine rivalisierenden Produkte, sondern Schichten:

Tool Calling: die Idee. Jedes „Modell sendet Absicht, Host führt aus“ zählt.
Function Calling: der API-Rahmen. Felder: tools[], tool_calls, role: tool.
MCP Tool Schema: das Lieferprotokoll. Feld: inputSchema, über stdio / SSE an einen MCP Server.

Der richtige Stapel: ein Schema im Repo, exportiert als Function-Calling-parameters und MCP-inputSchema. Keine dritte „fast gleiche“ Parameterliste in Prompt-Prosa. Details in MCP Tool Schema vs Function Calling und Warum AI Agents jetzt JSON Schema brauchen.

Warum landet jeder Agent 2026 auf JSON?

Natürliche Sprache spricht mit Nutzern. Jeder Hop zwischen Maschinen muss prüfbar, diffbar und wiederholbar sein. JSON trägt fünf Objektarten:

Tool-Definitionen: tools[] oder MCP inputSchema.
Aufrufabsicht: Funktionsname + Argumente in tool_calls.
Tool-Ergebnisse: Objekte aus Abfragen, Writes und externen APIs. Diese Schicht fehlt am häufigsten.
Agent-Handoff: Intent, Konfidenz, Ziel. Das Agents SDK routet über dieses Objekt, nicht über das Wort „billing“.
Workflow-Zustand und Evals: Checkpoints, Traces, Eval-Fixtures. Lange Jobs setzen auf JSON fort, sie raten den Stand nicht aus dem Chatlog.

JSON Schema ist der Durchmesser dieser Objekte. Ohne ihn driftet Function Calling, MCP und A2A je in eine „sieht ähnlich aus“-Kopie. Warum AI Agents jetzt JSON Schema brauchen machte Schema aus Doku zum Runtime-Tor; die Syntax steht in JSON-Schema-Tutorial.

Eine vollständige JSON-Pipeline

Beispiel „Bestellung nachschlagen → erstatten“. Eine konservative, testbare Kette 2026:

Der Host injiziert Schemas für lookup_order / create_refund in tools[] und schaltet strict: true ein.
Das Modell liefert tool_calls; arguments bleibt ein String.
Der Host macht JSON.parse und prüft gegen dasselbe Schema; bei Fehler Abbruch, kein Billing-Aufruf.
Die echte Abfrage läuft und liefert ein Bestellobjekt.
Zurück als role: tool – möglichst schema-gültiges JSON, kein Absatz.
Das Modell ruft ein weiteres Tool oder erzeugt ein Structured Output für Nutzer oder Downstream-Agent.
Beim Agentwechsel ein Handoff-Objekt schreiben, nicht „fragt bitte Billing“.

Ein Handoff-Objekt sollte so stabil bleiben:

{
  "handoff": {
    "from": "triage",
    "to": "billing_agent",
    "intent": "refund",
    "order_id": "A-1042",
    "confidence": 0.91
  }
}

Müssen mehrere Agenten einander finden, legt A2A Extensions Fähigkeiten auf die Agent Card und verhandelt per Extension-Header. Das ersetzt die Pipeline nicht, es verteilt nur zwischen Agenten.

Was wählst du 2026?

Eine App, geschlossener interner Loop, unter zehn Tools: Function Calling reicht. Schema und strict: true zuerst ins CI.
IDE / Plattform / steckbare Dritt-Tools: MCP liefert, die API-Schicht nutzt Function Calling für diesen Hop.
Heterogene Agenten müssen sich finden und Extensions verhandeln: A2A dazunehmen, kein privates Kuvert erfinden.
Auf jedem Pfad: Tool-Parameter, Ergebnisse und Handoffs zuerst als JSON Schema, dann Adapter exportieren.

Warte nicht auf eine Keynote, die „das Protokoll vereinheitlicht“. Stabil 2026 sind Schichten, kein Sieger-Wette.

Typische Fehler

Den Agenten für ein gesprächiges ChatGPT halten. Ein Dialog demonstriert; Produktion braucht eine wiederherstellbare Zustandsmaschine.
Tool Calling und Function Calling als Rivalen sehen. Eins ist Idee, eins API-Rahmen. MCP ist eine dritte Liefer-Schicht.
arguments nicht prüfen. Stringifiziertes JSON, Zahlen als Strings, Extrafelder im Billing – alles auf diesem Hop.
Freitext als Tool-Ergebnis. Der nächste Hop nimmt „sieht erfolgreich aus“ als Bestellstatus.
50 Tools in einem Request. Große Schemas sind teuer und falsch gewählt. Ab zehn Tools Routing oder Retrieval.

FAQ

Muss ein Agent Function Calling nutzen?

Nein. Function Calling ist der häufigste API-Rahmen, aber MCP Tool Use und Vendor Tool Use sind ebenfalls Tool Calling. Entscheidend sind Host-Ausführung plus Schema-Prüfung – nicht ob das Feld tools oder inputSchema heißt.

Ist Tool Calling nur der neue Name für Function Calling?

Manche Docs mischen beides. Sauberer: Tool Calling ist der Schirm, Function Calling die OpenAI-kompatible Form tools / tool_calls. Als getrennte Kästen gezeichnet, verschwinden die meisten Streits.

Reicht JSON mode ohne Schema?

JSON mode garantiert nur „sieht aus wie JSON“, nicht legale Felder, Typen oder Enums. Structured Outputs 2026 fixieren den Durchmesser mit json_schema + strict. In einem Mehrschritt-Agenten fällt JSON mode durch das Eval-Set.

Auf DevDay 2026 warten?

Nein. Der 29. September kann Structured Outputs und Aufrufpläne vertiefen. „Schema zuerst schreiben“ ändert sich nicht. Tools und Handoffs jetzt ins Git; nach der Keynote nur Adapter tauschen.

Wie debugge ich Tool- und Handoff-JSON?

Im Browser formatieren, fehlendes required prüfen, gegen die Vorversion diffen. JSONSort läuft lokal und lädt nichts hoch. Keine geheimen Tool-Antworten auf öffentliche Sites kleben.

Fazit

Ein AI Agent ist eine Runtime mit Tools und Zustand, kein Modell, das besser redet. Tool Calling lässt ihn greifen, Function Calling ist die häufigste API-Form dieser Hand, JSON das Objekt, das an jedem Hop passen muss.

Fang heute mit schemas/tools/lookup_order.json an, nicht mit einem längeren Prompt. Modelle wechseln, Protokolle wachsen. Zuerst den Durchmesser stabilisieren.

Weiterlesen

Warum AI Agents jetzt JSON Schema brauchen Von Tool Calling zu strukturierten Workflows
MCP Tool Schema vs Function Calling Protokollgrenze für Tool-JSON
A2A Extensions und das JSON-Protokoll Die dritte Schicht der Multi-Agent-Interop
OpenAI DevDay 2026: zentrale Prognosen Wie drei Schichten eine JSON-Röhre werden
JSONSort lokaler Werkzeugkasten Formatieren, prüfen, Diff
Alle Beiträge Weitere Notizen zu JSON und AI-Entwicklung

Änderungsprotokoll: 2026-09-05 Erstveröffentlichung