Lösungen für
Bitte auswählen
Web-App testen
ki-konzepte

KI-Agenten bauen — vom Tool Use zum Multi-Agent-System

Redaktion ·

Wann ist es überhaupt ein Agent — und nicht bloß eine Schleife mit LLM

„Agent” ist 2026 das Modewort, mit dem alles Mögliche etikettiert wird: ein Chatbot mit zwei Tools, eine Pipeline aus drei LLM-Aufrufen, ein Cursor-ähnliches IDE-Plugin, ein autonomes Recherche-System. Brauchbare Definition: Ein Agent entscheidet zur Laufzeit selbst, welche Tools er wann aufruft, wie oft er die Schleife durchläuft und wann er fertig ist. Eine Workflow dagegen läuft auf vorab festgelegten Pfaden — der Code ruft das LLM in einer geplanten Reihenfolge, das Modell trifft keine Steuerungsentscheidungen.

Diese Trennung ist nicht akademisch. Anthropic zieht sie in „Building Effective Agents” sehr bewusst, weil die meisten produktiven Systeme keine Agenten brauchen — eine deterministische Workflow ist billiger, schneller und debugbarer. Erst wenn die Aufgabe so unvorhersehbar ist, dass sich die Schritte nicht im Voraus auflisten lassen, lohnt der Agent-Loop. Dieser Artikel geht den Weg vom einzelnen Tool-Call bis zum Multi-Agent-Setup und zeigt unterwegs, an welchen Stellen die Komplexität sich noch lohnt — und wo nicht mehr.

Der Agent-Loop — was im Inneren passiert

Reduziere einen Agent auf das Minimum, bleibt eine Schleife mit vier Phasen: beobachten → planen → handeln → bewerten. Das Modell bekommt einen Zustand (System-Prompt, bisheriger Verlauf, Tool-Ergebnisse), wählt eine Aktion (meist: ein Tool-Call mit Argumenten), das Tool führt aus, das Ergebnis wandert zurück in den Kontext, und das Modell entscheidet, ob die Aufgabe erledigt ist oder die Schleife noch eine Runde dreht.

Daraus folgen drei Bausteine, ohne die kein Agent funktioniert: ein Mechanismus, mit dem das Modell Tools aufruft (Function Calling), ein Mechanismus, der Tool-Antworten in maschinenlesbarer Form zurückgibt (Strukturierter Output), und eine Stop-Bedingung, die die Schleife verlässt, wenn ein vereinbartes Signal kommt (typisch: das Modell ruft kein Tool mehr auf, sondern produziert eine reine Textantwort).

Tool Use als Vertrag zwischen Modell und Code

Function Calling ist seit 2023 Standardausstattung jeder relevanten LLM-API. Du beschreibst Tools als JSON-Schema (Name, Beschreibung, Parameter mit Typen), das Modell antwortet — wenn es ein Tool nutzen will — mit einem tool_call-Block, der Tool-Name und Argumente enthält. Dein Code führt das Tool aus, schreibt das Ergebnis als tool_result zurück in die Nachrichtenliste, und schickt die ergänzte Liste erneut ans Modell. Das Modell hat damit denselben Mechanismus wie ein Mensch, der eine API-Doku liest: Es weiß, was ein Tool tut, weil die Beschreibung es ihm sagt — nicht, weil es trainiert wurde, dieses spezifische Tool zu kennen.

In der Praxis hängt die Qualität eines Agenten wesentlich an den Tool-Beschreibungen. Anthropic empfiehlt, Tool-Definitionen wie sorgfältig dokumentierte Funktionen zu behandeln: konkrete Beispiele, klare Bedingungen, wann ein Tool nicht verwendet werden soll, präzise Fehlertexte. Wenn Tools schlecht beschrieben sind, halluziniert das Modell Argumente oder ruft das falsche Tool auf — das ist kein Modell-Bug, sondern ein Schnittstellen-Bug.

Strukturierter Output und das Antwort-Schema

Sobald ein Tool nicht nur „macht etwas” können soll, sondern „gibt mir Daten in Form X zurück”, brauchst du strukturierten Output. Drei Wege sind verbreitet: das Modell selbst zu JSON zwingen (über das Tool-Calling-Schema oder einen JSON-Mode), eine Pydantic-/Zod-Validierung am Ausgang, oder Constrained Decoding wie in vLLM oder llama.cpp, das auf Token-Ebene erzwingt, dass nur valide JSON-Tokens generiert werden. Letzteres ist robust, aber an die jeweilige Inferenz-Engine gebunden.

Stop-Bedingungen — der häufigste Fehler

Endlose Loops sind die typische Pannenquelle. Drei Schutzmechanismen sind unverzichtbar: ein hartes Iterations-Limit (z. B. „max. 25 Tool-Calls pro Anfrage”), eine Token-Budget-Grenze pro Anfrage und ein Stop-Signal, das das Modell explizit sendet (eine Antwort ohne Tool-Call, oder ein dediziertes finish-Tool). Ohne diese drei kann ein Agent in eine Reparatur-Schleife laufen, in der er denselben fehlerhaften Tool-Call zwanzig Mal hintereinander leicht variiert — und mit jeder Iteration wachsen die Token-Kosten.

MCP — vom Tool-Call zur Tool-Plattform

Function Calling ist anbieterspezifisch: Das JSON-Schema liest sich bei OpenAI, Anthropic und Google fast gleich, aber die Tools selbst musst du pro Anbieter neu integrieren. Das Model Context Protocol (MCP) ändert diese Dynamik. Es definiert ein Standard-Protokoll, mit dem ein MCP-Server (eine Anwendung, die Tools, Ressourcen oder Prompts bereitstellt) sich an einem MCP-Client (einem KI-Assistenten oder Agenten) andockt. Anthropic hat MCP Ende 2024 vorgestellt, im Lauf von 2025 haben OpenAI, Microsoft, Google und AWS Unterstützung in ihre eigenen Stacks aufgenommen, und im Dezember 2025 hat Anthropic MCP an die Agentic AI Foundation übergeben — als neutrale Infrastruktur. Die aktuelle Spezifikation ist auf den 25. November 2025 datiert.

Praktisch heißt das: Ein einmal geschriebener MCP-Server für deine internen APIs lässt sich an Claude, ChatGPT, Cursor, Microsoft 365 Copilot und LangGraph andocken, ohne den Server pro Klient anzupassen. Das war 2024 noch Einzelfall-Integration, ist 2026 Stand der Technik. Laut MCP-Adoption-Tracking erreicht das Protokoll im Frühjahr 2026 rund 97 Mio. SDK-Downloads pro Monat, mit über 5.800 publizierten Servern.

Code Execution mit MCP — der Token-Hebel

Eine interessante 2026er Entwicklung: Statt jeden Tool-Aufruf einzeln durchs Modell zu schicken, kann der Agent stattdessen Code schreiben, der mehrere Tool-Aufrufe orchestriert und nur das Endergebnis ans Modell zurückgibt. Anthropic beschreibt das in einem Engineering-Beitrag mit einem konkreten Beispiel: Eine zwei Stunden lange Meeting-Transkription aus Google Drive nach Salesforce zu spiegeln, kostet bei direkter Tool-Orchestrierung rund 150.000 Tokens, weil das Transkript mehrfach durch den Kontext fließt. Mit Code Execution sinkt der Verbrauch auf ca. 2.000 Tokens — eine Reduktion um 98,7 Prozent. Das Pattern lohnt sich nicht für jede Aufgabe, aber für datenintensive Workflows mit vielen Zwischenschritten ist es der Hebel des Jahres.

Fünf Workflow-Patterns vor dem ersten echten Agenten

Bevor du einen autonomen Agent-Loop baust, prüfe, ob eine der fünf Workflow-Patterns aus Anthropics Playbook reicht. Diese Patterns haben deterministische Steuerung — du kontrollierst den Pfad, nicht das Modell — und sind dadurch billiger, schneller und einfacher zu debuggen.

Prompt Chaining

Eine Aufgabe wird in feste Teilschritte zerlegt, jeder Schritt ist ein eigener LLM-Call, dessen Ausgabe in den nächsten fließt. Klassisch: Entwurf → Lektorat → Veröffentlichung. Einsatz, wenn die Schritte feststehen und Genauigkeit über Latenz geht.

Routing

Ein erster LLM-Call klassifiziert die Eingabe (Support-Anfrage: Rechnung / Technik / Sales?), und routet sie zum spezialisierten Folge-Prompt. Vorteil: Du kannst pro Kategorie ein passgenaues Prompt schreiben, statt einen Mega-Prompt für alles.

Parallelization

Mehrere LLM-Calls laufen parallel — entweder als „Sectioning” (ein Auftrag, in unabhängige Teile zerlegt: Übersetze drei Absätze gleichzeitig) oder als „Voting” (drei parallele Calls beantworten dieselbe Frage, ein vierter konsolidiert). Spart Latenz oder erhöht Robustheit.

Orchestrator-Workers

Ein zentraler Orchestrator-LLM zerlegt eine unklare Aufgabe spontan in Teilaufgaben und delegiert sie an Worker-LLMs. Beispiel: „Recherchiere alle Wettbewerber im DACH-Markt mit ARR > 10 Mio. €” — der Orchestrator entscheidet, welche Suchanfragen sinnvoll sind, ein Worker macht jede Recherche, der Orchestrator konsolidiert. Wird ein Agent, sobald die Anzahl der Worker-Aufrufe nicht im Voraus feststeht.

Evaluator-Optimizer

Ein erstes Modell produziert eine Antwort, ein zweites bewertet anhand klarer Kriterien, das erste verbessert. Loop bis das zweite Modell „okay” sagt oder ein Iterations-Limit zuschlägt. Funktioniert, wenn das Bewertungs-Kriterium klar formulierbar ist (Code kompiliert, Tests grün, Format korrekt).

Frameworks — wann ein Framework, wann nicht

Du kannst einen Agent mit der nackten Anthropic- oder OpenAI-API in 200 Zeilen Python bauen. Das ist oft die richtige Antwort. Frameworks lohnen erst, wenn der State komplex wird — Persistenz zwischen Runs, Human-in-the-Loop, Time-Travel-Debugging.

LangGraph ist 2026 das verbreitetste Framework für stateful Agents. Es modelliert den Agent als gerichteten Graph: Knoten sind Funktionen oder LLM-Calls, Kanten definieren Übergänge, ein typisierter State-Objekt fließt durch den Graph. Der Vorteil gegenüber Eigenbau ist nicht der Graph an sich — den hättest du auch in einer Match-Case-Anweisung — sondern das eingebaute Checkpointing: Jeder State-Übergang wird persistiert. Das ermöglicht Time-Travel-Debugging, Human-in-the-Loop (Graph pausieren, auf menschliche Freigabe warten, weitermachen), und Failure Recovery mitten im Lauf. LangGraph 1.x ist seit Anfang 2026 stabil, der Repo zählt im Frühjahr 2026 rund 30.000 GitHub-Stars.

Daneben relevant: CrewAI für rollenbasierte Multi-Agent-Setups, AutoGen (Microsoft) für Forschung und konversationelle Agenten, OpenAI Agents SDK für die OpenAI-Plattform-Integration. Faustregel: Wenn dein Agent weniger als fünf Schritte hat und keinen persistenten State braucht, ist Eigenbau schneller. Sobald du Checkpointing oder Multi-Agent-Koordination willst, fängt der Framework-Nutzen an.

Multi-Agent-Setups — wann es sich lohnt

Multi-Agent klingt verlockend („mehrere spezialisierte Agenten arbeiten zusammen”), bringt aber harten Mehraufwand: Token-Verbrauch steigt überproportional, weil jeder Agent seinen eigenen Kontext mitschleppt; Koordinations-Bugs werden zur dominanten Fehlerklasse; Latenz summiert sich. Faustregel: Steig erst auf Multi-Agent um, wenn ein Single-Agent klar an Aufgabentrennung scheitert — also wenn der eine Prompt zu lang wird, Tool-Listen über 30–40 Stück anwachsen, oder verschiedene Subaufgaben so unterschiedliche Prompt-Stile brauchen, dass ein gemeinsamer Prompt nur noch Kompromiss ist.

Wenn du dann doch zu Multi-Agent greifst, ist das Orchestrator-Worker-Pattern aus Anthropics Playbook der pragmatische Einstieg: Ein steuernder Agent kennt die Aufgabe und delegiert; mehrere Worker sind jeweils auf einen Aufgaben-Typ spezialisiert. Das ist überschaubar, weil die Hierarchie klar ist. Voll-emergente Multi-Agent-Schwärme („Agent-Swarms”) sind 2026 in Forschung und Demo verbreitet, in produktiven Systemen aber selten — die Debugbarkeit ist es nicht wert.

Stolperfallen — vier Klassiker

Endloser Loop ohne Stop-Bedingung. Schon erwähnt, aber so häufig, dass es noch mal extra steht. Maximale Iterationen, maximales Token-Budget, klares Stop-Signal — alle drei.

Token-Akkumulation pro Tool-Call. Jedes Tool-Ergebnis bleibt im Kontext und wird beim nächsten Modell-Call mitgeschickt. Bei einer Schleife mit 20 Iterationen und Tool-Antworten von je 5k Tokens wachst du auf 100k+ Input-Tokens, bevor du fertig bist. Gegenmittel: Tool-Antworten zusammenfassen oder verwerfen, sobald sie nicht mehr gebraucht werden. Code Execution mit MCP (siehe oben) ist die radikalere Lösung.

Tool-Halluzination. Das Modell ruft ein Tool auf, das es im Schema gar nicht gibt, oder erfindet Argumente, die nicht im Schema stehen. Eskaliert besonders bei langen Tool-Listen. Defense: striktes Tool-Whitelisting auf der Server-Seite — nicht das Modell um „Bitte halluziniere nicht” bitten, sondern den Aufruf außerhalb des Schemas einfach ablehnen und die Fehlermeldung zurückgeben („Tool ‘X’ existiert nicht. Verfügbar sind: …”). Das Modell korrigiert sich aus dem Fehler-Kontext schneller als jeder Prompt-Kniff.

Implizite Stop-Bedingung in Multi-Agent-Setups. Bei Orchestrator-Worker-Setups vergessen Bauer:innen oft, dass der Orchestrator selbst ein Iterations-Limit braucht — sonst kann er Worker beliebig oft erneut beauftragen, weil ein Worker-Ergebnis nie „gut genug” wirkt. Symptom: Aufgabe scheint erledigt, aber das System fragt einen weiteren Worker. Heilmittel: pro Aufgabentyp eine harte Anzahl an Delegations-Versuchen festlegen.

Kurzes Rechenbeispiel — Single-Agent vs. Multi-Agent

Stell dir eine Recherche-Aufgabe vor, die fünf parallele Web-Searches und zwei interne API-Calls braucht. Mit dem Stand der Preise im Frühjahr 2026 und Claude Sonnet als Modell:

| Setup | Iterationen | Avg Input pro Call | Avg Output | Tool-Calls | Geschätzte Kosten | |---|---|---|---|---|---| | Single-Agent, naive | 9 | 8.000 | 800 | 7 | ~0,28 $ | | Single-Agent, mit Tool-Result-Trimming | 9 | 4.000 | 800 | 7 | ~0,15 $ | | Multi-Agent (Orchestrator + 5 Worker) | 18 (gesamt) | 6.000 | 600 | 7 | ~0,40 $ |

Werte sind illustrativ, der Punkt ist die Richtung: Multi-Agent ist nicht günstiger, sondern teurer — den Aufpreis zahlst du für Spezialisierung, nicht für Ersparnis. Wer Multi-Agent aus Kostengründen einführt, hat das falsche Argument. Wer es aus Aufgabentrennungs-Gründen einführt und die Mehrkosten einkalkuliert, hat das richtige.

Fazit

KI-Agenten 2026 sind kein magisches Konstrukt, sondern eine sehr disziplinierte Schleife mit drei Pflicht-Bausteinen (Function Calling, Strukturierter Output, Stop-Bedingung) und vier Stolperfallen, die jeder einmal trifft. Der wichtigste Schritt ist die Frage vor dem Agenten: Reicht eine Workflow? Wenn ja — bauen, fertig. Wenn nein, ist der Aufwand begründet, und dann lohnt es sich, von Anfang an Iterations-Limits, Token-Tracking und einen Eval-Pfad mitzudenken.

MCP hat die Tool-Landschaft 2026 zu einem echten Ökosystem gemacht — wer einen MCP-Server für seine Domäne schreibt, schließt damit gleich Claude, ChatGPT und ein halbes Dutzend andere Klienten an. Frameworks wie LangGraph nehmen dir den State-Management-Boilerplate ab, sobald deine Agenten Persistenz oder Human-in-the-Loop brauchen. Und Multi-Agent ist die letzte Eskalationsstufe, nicht der Default — solange ein Single-Agent die Aufgabe löst, lass ihn arbeiten.

Wenn du tiefer rein willst: Tool-Use- und Strukturierter-Output-Spezifika sind in den jeweiligen Glossar-Einträgen erklärt — und für die Pricing-Schicht darunter (was kostet eine Agent-Anfrage in Tokens) gibt es das Pricing-Lexikon.

Themenuebersicht

KI-KonzepteAgenten