KI-Agent-Architekturdiagramm: Modell, Tools, Speicher und Guardrails

Die meisten Diagramme von KI-Agenten zeigen ein Roboter-Icon neben einem LLM-Logo und einen Pfeil mit der Aufschrift „Tools“. Dieses Bild verbirgt die Fragen, die darüber entscheiden, ob ein Agent sicher läuft: Wer wählt den nächsten Schritt, was darf der Agent anfassen, wo kommt nicht vertrauenswürdiger Text herein, und was stoppt einen Lauf, der nirgendwohin führt?

Dieser Artikel zerlegt einen Agenten in seine Teile, geht die Schleife durch, die ihn antreibt, behandelt Tools und das Model Context Protocol, Speicher, Guardrails, Limits und Tracing und zeichnet einen Kundensupport-Agenten, der Bestellungen nachschlagen und Erstattungen auslösen kann.

Workflow oder Agent?

Der Leitfaden von Anthropic zum Bau effektiver Agenten zieht eine nützliche Grenze. In einem Workflow werden LLMs und Tools über Codepfade orchestriert, die du vorab geschrieben hast. In einem Agenten steuert das Modell seinen eigenen Prozess und entscheidet Schritt für Schritt, welche Tools es nutzt, bis die Aufgabe erledigt ist.

Derselbe Leitfaden empfiehlt die einfachste Lösung, die funktioniert. Folgt eine Aufgabe immer denselben drei Schritten, schreib diese Schritte in Code und ruf das Modell darin auf. Greif zu einem Agenten, wenn der Weg davon abhängt, was der Agent unterwegs findet: ein Supportfall, bei dem die nächste Abfrage von der letzten Antwort abhängt, oder eine Programmieraufgabe, die mehrere Runden aus Ändern und Testen braucht.

Die Teile eines Agenten

Das Modell ist nur ein Kasten. Der Großteil der Engineering-Arbeit und der Risikokontrolle steckt im Code drumherum.

Die Schleife

Auf das Wesentliche reduziert ist die Runtime eine Schleife:

def run(task, user):
    messages = [system_prompt(user), task]
    for step in range(MAX_STEPS):
        reply = llm.generate(messages, tools=allowed_tools(user))
        if not reply.tool_calls:
            return check_output(reply.text)
        for call in reply.tool_calls:
            result = execute(call, user)   # permission check, approval, timeout
            messages.append(tool_result(call, result))
    return stop("step limit reached", messages)

Das Modell führt nie selbst etwas aus. Es liefert entweder eine Antwort oder die Anfrage, ein Tool mit bestimmten Argumenten aufzurufen, und die Runtime entscheidet, ob und wie das passiert. Genau dort liegt die Kontrolle: Berechtigungsprüfungen, Freigaben, Timeouts und Limits sitzen alle in execute und in der Schleife, nicht im Prompt.

Tools, und wo MCP hineinpasst

Ein Tool ist eine Funktion, die das Modell anfordern kann: ein Name, eine Beschreibung und ein JSON-Schema für die Argumente. Die Beschreibungen zählen genauso viel wie der Code, denn sie sind alles, was das Modell darüber weiß, wann es ein Tool nutzen soll.

Das Model Context Protocol ist ein offener Standard, um KI-Anwendungen mit externen Systemen zu verbinden. Ein MCP-Server stellt Tools, Daten und Prompts bereit; die Agent-Runtime agiert als Client. Statt jede Integration in den Code des Agenten zu verdrahten, liefert jedes System einen Server aus, und jede MCP-fähige Runtime kann ihn nutzen.

Gute Tools haben ein paar Gemeinsamkeiten:

• Wenige und spezifische. refund_order(order_id, amount, reason) schlägt ein generisches call_api(url, body).
• Lesen und Schreiben getrennt, sodass eine Rolle Lese-Tools ohne Schreib-Tools bekommen kann.
• Klare Fehler, auf die das Modell reagieren kann, etwa „Betrag übersteigt Bestellsumme“.
• Idempotenzschlüssel bei Schreibvorgängen, damit ein wiederholter Schritt nicht doppelt erstattet.

Speicher

Agenten haben zwei Arten von Gedächtnis, und Diagramme vermischen sie oft:

• Das Arbeitsgedächtnis ist der Kontext, der in jedem Schritt an das Modell geht: Anweisungen, die Unterhaltung und die bisherigen Tool-Ergebnisse. Es ist durch das Kontextfenster des Modells und die Kosten begrenzt, also fassen lange Läufe ältere Schritte zusammen oder verwerfen rohe Tool-Ausgaben, sobald sie genutzt wurden.
• Langzeitwissen liegt außerhalb des Modells: Dokumente, Richtlinien, alte Tickets. Der Agent ruft die relevanten Teile ab, oft aus einem Vektorindex, und fügt sie dem Arbeitsgedächtnis hinzu. Das RAG-Architekturdiagramm behandelt die Retrieval-Pipeline im Detail.

Aufgabenzustand, der einen Absturz überleben muss, etwa welche Schritte schon gelaufen sind und welche Freigabe aussteht, gehört in eine normale Datenbank, nicht in den Kontext des Modells.

Guardrails und Berechtigungen

Die OWASP Top 10 für LLM-Anwendungen führen Prompt Injection an erster Stelle. Ein anderer Eintrag, Excessive Agency, beschreibt schädliche Aktionen, die ein LLM-System ausführen kann, weil es mehr Funktionen, Berechtigungen oder Autonomie hat als nötig. Agenten sind beidem ausgesetzt: Sie lesen nicht vertrauenswürdigen Text (Nutzereingaben, Webseiten, abgerufene Dokumente, Tool-Ergebnisse) und sie können handeln.

Regeln, die sich in der Praxis bewähren:

• Behandle jedes Tool-Ergebnis und jedes abgerufene Dokument als Daten. Text auf einer Webseite kann keine Berechtigungen erteilen oder die Aufgabe ändern.
• Handle mit den Berechtigungen des Nutzers, nicht mit einem Service-Account, der jeden Kunden sehen kann.
• Schreibvorgänge absichern. Lesevorgänge laufen frei; Schreibvorgänge über einer Schwelle oder irreversible Aktionen warten auf einen Menschen.
• Code-Ausführung in einer Sandbox: standardmäßig ohne Zugangsdaten und ohne Netzwerk.
• Ausgaben prüfen, bevor sie Nutzer oder andere Systeme erreichen, auf geleakte interne Daten oder unsichere Inhalte.

Das Datenflussdiagramm für Threat Modeling ist ein guter Weg, um zu finden, wo nicht vertrauenswürdiger Text in eine Komponente gelangt, die handeln kann.

Limits und Kosten

Ein Agent, der ohne Fortschritt kreist, verbrennt Geld und Geduld. Setz Limits in der Runtime, nicht im Prompt:

• Schritte: eine maximale Zahl von Modellaufrufen pro Aufgabe.
• Zeit: ein Wall-Clock-Limit pro Aufgabe und ein Timeout pro Tool-Aufruf.
• Geld: ein Token- oder Dollar-Budget pro Aufgabe sowie pro Nutzer und Tag.
• Rate: Anfragelimits pro Nutzer an der API, wie im Design eines Rate Limiters.

Wird ein Limit erreicht, stopp sauber: Gib zurück, was bisher gefunden wurde, sag, welches Limit den Lauf gestoppt hat, und behalte den Trace zur Prüfung.

Tracing und Evals

Zeichne jeden Schritt auf: den gesendeten Kontext, das Modell und seine Einstellungen, jeden Tool-Aufruf mit Argumenten und Ergebnissen, Tokens, Latenz und Kosten. OpenTelemetry hat semantische Konventionen für generative KI, sodass diese Traces in dieselben Backends fließen können wie der Rest deines Systems; das Architekturdiagramm für Observability zeigt diese Pipeline.

Traces beantworten „Was ist in diesem Lauf passiert?“. Evals beantworten „Wird der Agent besser oder schlechter?“: ein fester Satz realistischer Aufgaben, automatisch bewertet, ausgeführt bei jeder Änderung an Prompts, Tools oder Modellen.

Das Architekturdiagramm

So liest du es:

• Links: Der Nutzer schickt eine Aufgabe über die Chat-App, die Anmeldung und Sessions übernimmt und die Aufgabe mit der Identität des Nutzers an die Guardrails weitergibt.
• Mitte: Der Agent-Loop schickt Kontext und Tool-Liste an das LLM (durchgezogen) und bekommt eine Antwort oder einen Tool-Aufruf zurück (gestrichelt). Er liest und schreibt das Arbeitsgedächtnis; der Markdown-Block listet die Limits.
• Rechts: Tool-Aufrufe gehen an Websuche, eine Code-Sandbox und die Bestell-API. Eine Erstattung wartet auf die Freigabe (gestrichelt).
• Unten: Der Wissensindex liefert abgerufene Dokumente ins Arbeitsgedächtnis, und jeder Schritt wird in Traces und Evals aufgezeichnet (gepunktet).

Ein durchgespieltes Beispiel: eine Erstattung

Ein Kunde schreibt: „Bestellung 4411 kam kaputt an, ich will mein Geld zurück.“

1. Die Guardrails prüfen die Nachricht und hängen die Identität des Kunden an.
2. Das Modell fordert get_order(4411) an. Die Runtime prüft, dass die Bestellung diesem Kunden gehört, und liefert: vor drei Tagen zugestellt, 180 Dollar.
3. Die Runtime ruft die Erstattungsrichtlinie aus dem Wissensindex ab und fügt sie dem Arbeitsgedächtnis hinzu: Beschädigte Artikel sind innerhalb von 30 Tagen erstattungsfähig.
4. Das Modell fordert refund_order(4411, 180, "damaged") an. Der Betrag liegt über der Schwelle von 100 Dollar, also pausiert die Runtime den Lauf und schickt eine Freigabeanfrage an eine Support-Leitung.
5. Die Leitung gibt frei. Die Runtime führt die Erstattung mit einem Idempotenzschlüssel aus und liefert die Bestätigung zurück.
6. Das Modell schreibt die Antwort, die Ausgabeprüfungen sind bestanden, und der Kunde bekommt eine Antwort.

Drei Modellaufrufe, zwei Tool-Aufrufe, ein Retrieval, eine Freigabe und ein Trace, der jeden Schritt zeigt.

Was in ein Agent-Diagramm gehört

• Wer den nächsten Schritt entscheidet: das Modell oder Code, den du geschrieben hast.
• Jedes Tool, mit Lese- oder Schreibzugriff und wessen Berechtigungen es nutzt.
• Freigabepunkte für riskante Aktionen.
• Limits: Schritte, Zeit und Budget.
• Wo nicht vertrauenswürdiger Text hereinkommt: Nutzereingaben, Webseiten, Dokumente, Tool-Ergebnisse.
• Tracing, damit Reviewer wissen, dass Läufe überprüft werden können.

In Archboard nachbauen

1. Melde dich mit Google oder GitHub an und leg ein Diagramm an.
2. Füge aus dem C4-Modell-Pack zwei Person-Nodes für Nutzer und Freigebende hinzu und einen Container für die Chat-App.
3. Füge aus dem Basis-Pack einen Rahmen für die Agent-Runtime hinzu, mit einem Container für den Agent-Loop und zwei Komponente-Nodes für Guardrails und Arbeitsgedächtnis.
4. Füge aus dem ML-Pack ein Modell und einen Vektorindex hinzu, einen zweiten Rahmen mit drei Dienstkarte-Nodes aus dem Stack-Pack für die Tools und Ablaufverfolgung aus dem DevOps-Pack.
5. Zeichne die Antworten des Modells gestrichelt und die Tracing-Kante gepunktet, und füge einen Markdown-Block aus dem Basis-Pack mit den Limits hinzu. Wenn ein Agent es für dich zeichnen soll, siehe Diagramme mit KI-Agenten über MCP erstellen.

Das Beispiel nutzt 15 Diagramm-Nodes und bleibt damit im Free-Plan.

FAQ

Was ist der Unterschied zwischen einem KI-Agenten und einem Workflow? In einem Workflow entscheidet dein Code die Abfolge der Schritte und ruft das Modell darin auf. In einem Agenten entscheidet das Modell den nächsten Schritt und welche Tools es nutzt, innerhalb einer Schleife, die dein Code kontrolliert.

Was ist MCP in einer Agent-Architektur? Das Model Context Protocol ist ein offener Standard, um KI-Anwendungen mit Tools und Daten zu verbinden. Systeme stellen MCP-Server bereit, und die Agent-Runtime verbindet sich als Client mit ihnen.

Wie verhindere ich, dass ein Agent schädliche Aktionen ausführt? Gib ihm nur die Tools, die er braucht, führe sie mit den Berechtigungen des Nutzers aus, verlange eine menschliche Freigabe für Schreibvorgänge über einer Schwelle und behandle alle Tool-Ergebnisse und Dokumente als nicht vertrauenswürdige Daten.

Wie merken sich Agenten Dinge? Innerhalb eines Laufs über den Kontext, der in jedem Schritt an das Modell geht. Über Läufe hinweg über gespeichertes Wissen, das bei Bedarf abgerufen wird, und über Aufgabenzustand in einer Datenbank.

Wie halte ich die Kosten von Agenten im Griff? Setz in der Runtime Limits für Schritte, Zeit und Tokens pro Aufgabe, füge Budgets pro Nutzer hinzu und trace jeden Lauf, damit teure Muster in Reviews auffallen.

Kostenlos starten — ein Seat, keine Kreditkarte.