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

Was ein AI Agent ist — Chat und Workflows

Die Minimaldefinition braucht drei Dinge: ein Ziel (was der Nutzer fertig haben will), Wahrnehmung (Kontext plus Werkzeugbelege), Aktion (welches Werkzeug, welche Argumente, oder die Endantwort). Das Modell wählt die Aktion je Schritt; die Runtime führt aus und schreibt Beobachtungen zurück. Keine Schleife, keine Werkzeuge, keine prüfbare Argumentform — das ist nur Chat.

Der Unterschied zum Chatbot ist die Stoppbedingung, nicht die Marke. Chat darf nach einer Runde enden. Ein Agent sollte die Aufgabe nicht für erledigt erklären, bevor Werkzeugergebnisse da sind — er sucht Rechnungen, fasst zusammen, fragt nach. Der Unterschied zum klassischen Workflow ist, wer die Kanten zeichnet: n8n-/Temporal-Hops verdrahten Menschen; den nächsten Hop wählt das Modell aus der aktuellen JSON-Beobachtung. Workflows sind vorhersagbar und replaybar; Agenten sind flexibel und machen „falsche Argumente“ zu einem Erstklassfehler.

Formen 2026: Coding-Agenten (Dateien, Tests, Patches), Support- und Ops-Agenten (Bestellungen, Tickets), Multi-Agent-Orchestrierung (ein Planer delegiert an Spezialisten). Der Vertrag ist derselbe: Grenzen in JSON Schema; arguments und results parsebar. Apple kann dieselbe Funktion an App Intents und Modellwerkzeuge geben — siehe Apple AI Agent und JSON.

Ablauf 2026: beobachten → entscheiden → aufrufen → beobachten

Das Demovideo abziehen: eine typische Schleife hat fünf Schritte.

1. Das Nutzerziel kommt in den Kontext (natürliche Sprache plus optionale Systemgrenzen).
2. Die Runtime injiziert die Werkzeugliste: name, description, JSON Schema (parameters / inputSchema).
3. Das Modell liefert tool_calls (Funktion + arguments) oder finalen Text / Structured Output.
4. Die Runtime parst arguments, führt lokale Funktion, HTTP oder MCP tools/call aus und schreibt result-JSON in die Nachrichten.
5. Das Modell liest das Ergebnis und wählt das nächste Werkzeug oder stoppt. maxSteps, Abbruch oder Schema-Fehler stoppen ebenfalls.

Die Schleifenform selbst kann Config sein, kein Frameworkzauber. Das JSON unten beschreibt nur Hops und Stopps — Fachfelder gehören auf das Schema jedes Werkzeugs.

{
  "loop": "agent",
  "maxSteps": 8,
  "stopWhen": ["final_answer", "max_steps", "user_cancel", "schema_fail"],
  "hops": [
    { "kind": "model", "emits": "tool_calls | text" },
    { "kind": "runtime", "emits": "tool_result JSON" },
    { "kind": "model", "emits": "next_tool | final JSON" }
  ]
}

Fehler häufen sich bei Schritt 3→4: arguments als String wie ein Objekt behandelt, Zahlen als Strings, required fehlt, Werkzeugname driftet vom Cache. Ein „klügeres“ Modell heilt Vertragsdrift nicht. Zustandsloses MCP hängt Protokollmetadaten an jede Anfrage; die Form hängt weiter am Schema, das Sie dem Modell gaben.

Tool Calling und Function Calling: zwei Namen, ein Mechanismus

Ingenieurtechnisch dasselbe: Das Modell fasst die Datenbank nicht an; es sendet eine strukturierte Bitte „rufe diese Funktion mit diesen Argumenten“, die Runtime führt aus. Produktnamen 2023–2026:

OpenAI faltete functions später in tools und ergänzte strict. Anthropic sagt tool_use / input_schema. Gemini function declarations. MCP JSON-RPC tools/call. Namen unterscheiden sich; arguments bleibt ein JSON-Objekt. „Function Calling ist tot“ ist selten ein guter Migrationsgrund — gealtert sind Feldnamen, nicht der Mechanismus.

Dieselbe Rechnungssuche als OpenAI-strict-Tool. Unter strict muss jede property in required stehen, sonst darf das Modell Felder weglassen, die Sie für default gehalten haben:

{
  "type": "function",
  "function": {
    "name": "searchInvoices",
    "description": "Search invoices by date range and status",
    "strict": true,
    "parameters": {
      "type": "object",
      "properties": {
        "startDate": { "type": "string", "format": "date" },
        "endDate": { "type": "string", "format": "date" },
        "status": {
          "type": "string",
          "enum": ["draft", "sent", "paid", "void"]
        }
      },
      "required": ["startDate", "endDate", "status"],
      "additionalProperties": false
    }
  }
}

Beim Aufruf sieht ein typisches tool_calls so aus. arguments ist weiter ein String: erst parsen, dann prüfen. Ein fehlgeschlagenes JSON.parse heißt nicht automatisch „Modell kaputt“ — Syntax und Schema trennen. Taxonomie: KI-JSON-Fehlerleitfaden.

{
  "id": "call_8f3a",
  "type": "function",
  "function": {
    "name": "searchInvoices",
    "arguments": "{\"startDate\":\"2026-01-01\",\"endDate\":\"2026-01-31\",\"status\":\"paid\"}"
  }
}

Warum JSON die Vertragssprache des Agenten ist

Eine Agent-Pipeline trägt mindestens drei JSON-Nutzlasten, die aus einem kanonischen Schema kommen sollten:

1. Werkzeugdefinition: name / description / parameters (oder MCP inputSchema).
2. Modell-arguments: gewählte Schlüssel, oft als String in tool_calls.
3. Werkzeugergebnis: ok / result oder Fehlerumschlag, damit das Modell den nächsten Hop wählt.

Ein Viertes ist optional: Structured Output der Endantwort. Diese Datei beschreibt die Antwort an Nutzer oder Downstream — nicht, was searchInvoices braucht. Gleiche Syntax, andere Semantik; Dateien und Versionen trennen. Siehe Structured-Output-Tutorial.

Nach erfolgreichem Lauf einen stabilen Umschlag zurückgeben, statt rohes Downstream-HTTP an das Modell zu kippen. Das result unten zeigt nur Fachfelder; das Rohe gehört in Logs. Stabile Form macht Retries und Zusammenfassungen vorhersagbar:

{
  "toolCallId": "call_8f3a",
  "name": "searchInvoices",
  "ok": true,
  "result": {
    "count": 2,
    "items": [
      { "id": "INV-1042", "total": 1280.5, "currency": "USD" },
      { "id": "INV-1048", "total": 640.0, "currency": "USD" }
    ]
  }
}

Stacks 2026: OpenAI, Anthropic, Gemini, MCP

Kein überall tragbares Schema, aber Tool-Calling-Strukturen konvergieren: arguments ist ein JSON-Objekt; der Vertrag ein JSON-Schema-Subset.

MCP ist Entdeckung und Transport, kein Typsystem. inputSchema deklariert die Form; der Server parst und validiert weiter. Feldmapping und ein Schema auf drei Flächen: MCP und JSON Schema. Multi-Agent-Übergaben laufen über A2A message/send; Skill-Listen hängen ebenfalls Schema — Agent zu Agent, nicht Modell zu Werkzeug. Vergleich A2A vs MCP.

Zustandsloses MCP skaliert besser, wenn Sessions das Protokoll verlassen; arguments heilt es nicht. Ein veralteter tools/list-Cache schreibt die falsche Form. Details: Stateless-MCP-Leitfaden.

Validierung vor Ort und JSONVue

Jeder Hop: parse → Schema → Fachregeln. Ein kluges Modell ersetzt diese drei Schritte nicht.

1. arguments-String: JSON.parse; bei Fehler raw + tool_call-id loggen und retrybaren Umschlag zurückgeben.
2. Gegen parameters / inputSchema prüfen (Draft 2020-12); path und keyword ausgeben.
3. Fachtor: Datumsbereich, Enum vs Rechte, Fremdschlüssel. Erst dann die Downstream-API.

Drei Blobs nebeneinander: Modell-arguments, Body an MCP oder HTTP, Objekt, das der Server wirklich nutzte. Abweichung ist fast immer der Adapter. Im Browser: JSON-Formatierer fürs Parsen; JSON-Schema-Validator für arguments vs Schema-Datei; JSON Diff für Modell-arguments vs Downstream-Body. valid / missing-field / wrong-enum in CI und manuellem Debug teilen.

Weiter: MCP und JSON Schema, Structured Output, KI-JSON-Fehler, A2A vs MCP.

FAQ

Fazit und nächste Schritte

Ein KI-Agent 2026: Das Modell wählt Aktionen in einer Schleife, die Runtime führt Werkzeuge aus, JSON Schema beschreibt jeden Hop. Tool Calling und Function Calling sind Produktnamen desselben Mechanismus. MCP, A2A und Structured Output regieren verschiedene Hops — eine Datei darf sie nicht alle zwingen.

Als Nächstes: die drei JSON in Ihrem System (Definition, arguments, result) auflisten und prüfen, ob sie ein Schema teilen; valid / fehlendes Feld / falsches Enum in JSONVue replayen. Protokoll im MCP-Artikel; Endform in Structured Output; Fehlerschichten im JSON-Fehlerleitfaden.