Kapitel 4 — KI-Agenten und Tool-Calling

Veröffentlicht am: 2026-04-17 Zuletzt aktualisiert am: 2026-07-05 Version: 1
Kapitel 4 — KI-Agenten und Tool-Calling

Kapitel 4 — KI-Agenten und Tool-Calling

Vierter Beitrag der kapitelweisen Tour durch LLM Primer V: Building Real-World LLM Applications. Das Kapitel behandelt einen Agenten als Sprachmodell, das gegen Werkzeuge geschleift wird, deren Schemata, Gedächtnisschichten und Multi-Agenten-Verdrahtung eingebaut sein müssen, bevor der Schleife mit irgendetwas Ernsthaftem vertraut werden kann.


Warum dieses Kapitel existiert

Ein zustandsloses Modell, das nur Text entgegennimmt und Text ausgibt, ist ein Taschenrechner. Produktive Arbeit verlangt, es in einen Akteur zu verwandeln, der Ziele über mehrere Schritte verfolgt — ruf dieses Werkzeug, dann jenes, entscheide dann, welches Ergebnis der Nutzerin zusammengefasst wird, und stopp, wenn die Aufgabe erledigt ist. Der Zug sieht im Diagramm einfach aus und ist in der Realität nicht einfach. Agenten wandern, kreiseln, rufen das falsche Werkzeug, erfinden Argumente, die das Werkzeug nicht akzeptieren kann, vergessen, was sie schon geholt haben, und handeln außerhalb ihrer Autorität. Kapitel 4 handelt vom Engineering, das die Schleife lesbar und begrenzt hält — die Schemata, die Gedächtnisdisziplin und die Multi-Agenten-Struktur, die aus einem plausibel aussehenden Demo einen Produktivakteur machen.

In einem Satz: Die Agentenschleife ist generisch; die Werkzeuge sind die Persönlichkeit — Tool-Schemata, Fehlerverträge und Schreibdisziplin für Gedächtnis sind die höchsten Ingenieurhebel im gesamten System.

4.1 Agenten-Architekturen als Komposition, nicht als Auswahl

Die Basisschleife ist ReAct: über die Situation nachdenken, handeln, indem ein Werkzeug aufgerufen wird, das Ergebnis beobachten und wiederholen, bis das Ziel erreicht ist oder das Schrittbudget erschöpft. Produktionssysteme komponieren dann drei Augmentierungen auf der Basis, statt zwischen ihnen zu wählen. Native Function-Calling — der Provider zwängt Tool-Argumente zur Decodierzeit gegen ein JSON-Schema — härtet den I/O-Vertrag, sodass die Schleife nicht mehr aus fehlerhaften Aufrufen genesen muss. Explizites Planen im Plan-and-Execute-Stil zieht für Aufgaben mit langem Horizont einen Plan nach vorn und lässt den Planer nur dann neu laufen, wenn sich die Welt verändert. Workflow-Orchestrierung kodiert die bekannten Übergänge der Aufgabe als Graph und überlässt dem Modell nur die Innerhalb-Phase-Entscheidungen, was die Form ist, in der die meisten Enterprise-Bereitstellungen konvergieren, weil sie das Wissbare vom Urteilsbedürftigen trennt. Reflection-Schleifen, Multi-Modell-Routing über eine kostengestaffelte Flotte und Spezialisten-Sub-Agenten stehen daneben als weitere Augmentierungen.

4.2 Tool-Calling-Mechanik — das Schema ist der Vertrag

Jedes Werkzeug hat ein Schema, und das Schema ist der Vertrag, den die Schleife dem Modell auferlegt. Eigenschaftsbeschreibungen sind Dokumentation für das Modell, nicht für den menschlichen Leser; Enums schließen den Argumentraum, wo die Domäne es zulässt; Idempotenzschlüssel lassen die Schleife einen Tool-Aufruf wiederholen, ohne seine Wirkung zu verdoppeln; strukturierte retriable Fehler lassen das Modell sauber wiederherstellen, statt zu raten. Werkzeuge sollten minimal sein — ein klarer Job pro Werkzeug —, weil ein aufgeblasenes Werkzeug mit zehn optionalen Flags ein Werkzeug ist, das das Modell falsch bedienen wird. Ein ask_user-Werkzeug gehört explizit in den Katalog, damit der Agent einen legitimen Weg hat, Mehrdeutigkeit zu eskalieren, statt Argumente zu erfinden. Nebenläufigkeit ist nur sicher, wenn Werkzeuge Unabhängigkeit deklarieren; die Schleife behandelt deklariert-unabhängige Werkzeuge als parallelisierbar und alles andere als strikt sequentiell. Jeder reale Produktionsvorfall, der zu „der Agent hat das Falsche getan“ zurückverfolgt wurde, löst sich in ein Werkzeug auf, dessen Schema nicht sagte, was seine Argumente bedeuteten.

4.3 Drei Speicherschichten: Kurzzeit, Langzeit, semantisch

Agenten brauchen Gedächtnis, weil eine Aufgabe selten in einen Turn passt. Kurzzeitspeicher ist ein gleitendes Fenster über die jüngste Konversation mit gepinnten Nachrichten, die den Gleitzug überleben — der System-Prompt, das aktuelle Ziel, der laufende Plan —, und regelmäßige Zusammenfassung der Läufe, die aus dem Fenster fallen. Langzeitspeicher ist ein Vektorspeicher kuratierter Fakten, geschrieben bei Bestätigung, nicht bei jeder Beobachtung, und an mehreren Stellen der Schleife abgerufen, nicht nur am Anfang. Semantisches Gedächtnis ist ein Wissensgraph aus Tripeln für Anfragen, die strukturierte Komposition statt Ähnlichkeit brauchen — „wer berichtet an wen“, „welche Produkte gehören zu welcher Kategorie“, Beziehungen, die der Vektorspeicher flach macht. Die drei werden unterschiedlich gespeichert, weil sie unterschiedlich genutzt werden, und die Disziplin lautet, Schreib- und Leseoperationen an die richtige Schicht zu routen, statt alles in einen Embedding-Index zusammenzuklappen.

Wert, das festzuhalten: Die Intelligenz eines Agenten lebt in den Entscheidungen des Modells; die Zuverlässigkeit des Agenten lebt in dem Engineering, das sie umgibt. Begrenze die Schleife, begrenze die Werkzeuge, begrenze die Schreiboperationen ins Gedächtnis.

Was Kapitel 4 vorbereitet

Agenten und RAG produzieren beide stochastische Traces. Der Nutzer beschwert sich, das Log zeigt hundert Spans über drei Werkzeuge und acht Modellaufrufe, und das Team muss entscheiden, ob der Fehler eine Retrieval-Regression ist, ein Prompt-Drift, ein Tool-Schema-Problem oder der Agent, der korrekt gegen ein kaputtes nachgelagertes System entschieden hat. Diese Frage lässt sich nicht beantworten ohne eine Disziplin, Traces in messbare Pass/Fail-Signale zu verwandeln. Kapitel 5 ist diese Disziplin — LLM-as-Judge, die RAG-Triade, Trajectory-Tests für Agenten und die kontinuierliche Schleife, in der Produktions-Traces die Eval-Menge speisen, die das nächste Release durchlässt.


Als Nächstes — Kapitel 5: LLM-Anwendungen evaluieren. Die Evaluationsdisziplin, die stochastische Traces in Pass/Fail-Signale verwandelt, gegen die ein Team ausliefern kann.

Möchtest du das ganze Bild? Das Buchkapitel schreitet eine vollständige ReAct-Implementierung ab, eine explizite Planner-Executor-Trennung, die Tool-Schema-Muster mit konkreten refund_order- und ask_user-Beispielen und den Drei-Schicht-Gedächtnisspeicher mit Retrieval- und Write-Back-Logik. Band IV deckte MCP-spezifische Tiefe ab; Band V fokussiert auf die Schleife selbst. LLM Primer V auf Amazon →

SHO
SHO