Agierende KI erklärt: Von Sprachmodellen zu autonomen Agenten
Eine strukturierte Erklärung, wie LLMs durch Werkzeuge, Speicherfunktionen, Planung, mehrere Agent-Architekturen sowie MCP-Integration zu agierenden Systemen werden.
Große Sprachmodelle haben die Art und Weise, wie wir mit Software arbeiten, verändert.
Anstatt dem Computer eine strenge Abfolge von Anweisungen zu geben, kann man nun einen Auftrag wie folgt formulieren:
"Prüfen Sie, warum die Rechnung dieses Kunden gestiegen ist, überprüfen Sie den Vertrag sowie die Nutzungsdetails und eröffnen Sie ein Ticket, falls die Gebühr fehlerhaft ist."
Eine herkömmliche Anwendung würde einen fest programmierten Arbeitsablauf benötigen, um jede dieser Schritte zu bewältigen.
Ein agierendes System hingegen kann selbst entscheiden, welche Daten es benötigt, welche Tools es aufrufen muss, welcher Schritt als Nächstes kommt und wann die Aufgabe abgeschlossen ist.
Das wirft eine natürliche Frage auf:
Wie sind wir von einem LLM, das lediglich Text erzeugt, zu einem System übergegangen, das echte Aufgaben erledigen kann?
Das Verständnis für agierende KI bedeutet, diesen Fortschritt Schritt für Schritt nachzuvollziehen.
Von LLM zu Agent
Diese Entwicklung vollzieht sich in mehreren unterschiedlichen Phasen.
LLM
User → Prompt → LLM → Response
In seinem Kern erzeugt das Modell Ausgaben hauptsächlich auf der Grundlage des ihm gegebenen Kontexts.
Betrachten wir folgende Anfrage:
"Erklären Sie, was ein Transformer ist."
Das LLM kann direkt antworten, da das notwendige Wissen bereits in seinen trainierten Parametern zusammen mit dem bereitgestellten Kontext enthalten ist.
Nun betrachten wir eine andere Anfrage:
"Wie ist das aktuelle Wetter in Bangalore?"
Hier benötigt das Modell aktuelle Informationen, die mit ziemlicher Sicherheit nicht zu seinen Trainingsdaten gehören. Diese Lücke weist auf die nächste Phase hin.
RAG
User → Retrieve Knowledge → LLM → Response
Retrieval-Augmented Generation ermöglicht es einem Modell, vor der Erstellung einer Antwort externe Informationen – Unternehmensdokumente, Richtlinienhandbücher, Datenbanken – abzurufen.
Zum Beispiel:
"Wie lautet die Rückerstattungspolitik unseres Unternehmens?"
Das System holt den entsprechenden Text der Richtlinie ab und gibt ihn als Teil der Anfrage an das LLM weiter.
RAG behebt die Wissenslücke.
Doch es bleibt noch eine Einschränkung:
Was passiert, wenn das System eine Aktion ausführen muss anstelle nur einer Frage zu beantworten?
LLM mit Tool-Nutzung
User → LLM → Tool → Result → LLM → Response
In dieser Phase erhält das Modell die Fähigkeit, mit externen Systemen zu interagieren.
Nehmen wir ChatGPT als Beispiel: Wenn man fragt
"Wie ist das aktuelle Wetter?"
Es kann ein Wettertool aufrufen, um Echtzeitdaten abzurufen, anstatt sich ausschließlich auf im Modell enthaltene Kenntnisse zu verlassen.
Tools öffnen im Grunde eine Tür vom LLM in die Außenwelt.
Trotzdem gibt es hier eine wichtige Nuance zu beachten.
Falls ein Entwickler den Ablauf explizit hardcodet, zum Beispiel:
Question → Weather API → Response
bleibt die Reihenfolge der Schritte im Voraus festgelegt.
Ein Agent geht auf diese Idee noch weiter ein.
Agent
Goal
↓
Reason
↓
Choose Action
↓
Use Tool
↓
Observe Result
↓
Decide Next Action
↓
Repeat
↓
Complete Goal
Der entscheidende Unterschied liegt in der dynamischen Entscheidungsfindung. Ein Workflow folgt einem von dem Entwickler im Voraus festgelegten Weg. Ein Agent hingegen kann seinen eigenen Weg basierend auf dem, was er unterwegs lernt, bestimmen.
Genau diese Fähigkeit, den nächsten Schritt dynamisch zu wählen, definiert im Kern das agente Verhalten.
Was ist eigentlich ein KI-Agent?
Hier ist eine funktionierende Definition:
Ein KI-Agent ist ein durch ein LLM angetriebenes System, das ein Ziel verfolgt, indem es dynamisch entscheidet, welche Aktionen ausgeführt werden sollen, dabei auf Werkzeuge und Kontext zurückgreift, die Ergebnisse dieser Aktionen beobachtet und diesen Zyklus wiederholt, bis das Ziel erreicht ist oder eine Stoppbedingung eintritt.
In der Regel umfasst ein Agent:
LLM + Instructions + Tools + State + Memory + Context + Orchestration + Guardrails
Das LLM übernimmt das Denken und Entscheiden.
Werkzeuge liefern konkrete Fähigkeiten.
Der Zustand verfolgt, was derzeit geschieht.
Das Gedächtnis sorgt für Kontinuität über die Zeit hinweg.
Schutzmechanismen legen Grenzen für das Verhalten fest.
Die Orchestrierung verbindet all diese Komponenten miteinander.
Der wesentliche Punkt ist folgender:
Ein Agent erzeugt nicht einfach nur eine Antwort. Er kann sich für einen Handlungsablauf entscheiden und diesen umsetzen.
Warum brauchen wir Agenten?
Nun, da Sie eine funktionierende Definition eines Agenten haben, stellt sich eine natürliche Frage:
Warum die ganze zusätzliche Komplexität?
Tatsächlich erfordert nicht jede Aufgabe einen Agenten.
Wenn ein Workflow einer festgelegten, vorhersehbaren Abfolge folgt:
Receive request
↓
Validate
↓
Call API
↓
Return result
ist ein einfacher, deterministischer Ablauf in der Regel einfacher und zuverlässiger.
Vergleichen Sie das nun mit einer Anfrage wie dieser:
">Ermitteln Sie, warum unsere Cloud-Kosten diesen Monat gestiegen sind."
Hier gibt es keinen einzigen im Voraus festgelegten Weg. Das System muss möglicherweise folgende Schritte durchlaufen:
Check billing
↓
Find Azure costs increased
↓
Check deployments
↓
Find new service
↓
Check service usage
↓
Find abnormal traffic
↓
Investigate logs
↓
Generate explanation
Beachten Sie, was passiert: Der Agent hat keine Möglichkeit, zu wissen, dass Schritt 5 erforderlich ist, bevor er bereits Schritt 2 durchlaufen hat. Das Ergebnis jeder Aktion bestimmt, was als Nächstes kommt.
Genau in solchen Situationen zeigt sich, warum ein agiler Ansatz aufgrund seiner Komplexität sinnvoll ist.
Eine einfache Regel
Bleiben Sie bei Workflows, wenn die Reihenfolge der Schritte im Voraus bekannt ist. Wenden Sie Agenten an, wenn der nächste Schritt stark davon abhängt, was im Laufe des Vorgangs enthüllt wird.
Der Agentenzyklus
Was passiert eigentlich, sobald man einem Agenten ein Ziel übergeben hat?
Zentral bei jedem Agenten steht der Agentenzyklus.
┌─────────────┐
│ Goal │
└──────┬──────┘
↓
┌─────────────┐
│ Reason │
└──────┬──────┘
↓
┌─────────────┐
│ Choose Tool │
└──────┬──────┘
↓
┌─────────────┐
│ Execute │
└──────┬──────┘
↓
┌─────────────┐
│ Observe │
└──────┬──────┘
↓
Goal done?
/ \
No Yes
↓ ↓
Reason Finish
Das grundlegende Muster lässt sich wie folgt zusammenfassen:
Überlegen → Handeln → Beobachten → Wiederholen
Zum Verständnis:
User:
"Investigate this invoice."
Agent:
"I need invoice details." ↓get_invoice() ↓Tool returns invoice information. ↓Agent:
"The amount looks unusual. I need the contract." ↓get_contract() ↓Contract returned. ↓Agent:
"Now I can compare the two."
Während dieses Austauschs passt der Agent seine Sicht der Situation ständig an, je nachdem neue Informationen aus seiner Umgebung einfließen.
Reale Produktionsysteme integrieren Logik zur Wiederholung von Vorgängen, Validierung, Speichermanagement, Autorisierungsprüfungen, Überwachungsfunktionen sowie Regeln dafür, wann man aufhören soll – doch dieser Schleifenmechanismus bildet das grundlegende Gerüst hinter all dem.
Werkzeuge: Den Agenten die Fähigkeit zum Handeln geben
Dieser Schleifenmechanismus wirft sofort eine weitere Frage auf:
Wie kann ein Agent tatsächlich in die reale Welt eingreifen?
Ein LLM allein hat keinen direkten Zugang zu den Systemen Ihres Unternehmens.
Werkzeuge sind es, die ihm diesen Zugang ermöglichen.
Zum Beispiel:
get_customer()
get_invoice()
search_policy()
query_database()
create_ticket()
send_email()
Mit den richtigen Werkzeugen sieht der Ablauf so aus:
Agent
↓
"I need the invoice"
↓
get_invoice()
↓
Invoice data
↓
Agent
↓
"I need the contract"
↓
get_contract()
↓
Contract data
Werkzeuge eröffnen es Agenten, sich mit einer Vielzahl externer Systeme zu verbinden, wie zum Beispiel:
- Web-APIs
- Relationale oder NoSQL-Datenbanken
- Suchmaschinen
- Lokaler oder cloudbasierter Dateispeicher
- Quellcode-Plattformen wie GitHub
Eine solche Reichweite verändert grundlegend das, was ein LLM tut. Es erzeugt nicht mehr nur Text.
Sondern es fungiert als Entscheidungsträger, der über eine Reihe von Fähigkeiten handelt.
Aber was sollte der Agent sich merken?
Sobald ein Agent mehrere Schritte miteinander verknüpft, taucht eine neue Herausforderung auf.
Stellen Sie sich einen Agenten vor, der bereits diese Abfolge durchlaufen hat:
Retrieved the invoice
Checked the contract
Queried usage
Found an anomaly
Er muss sich diese Ergebnisse merken, um den nächsten Schritt bestimmen zu können.
Und wenn derselbe Benutzer am nächsten Tag zurückkommt, benötigt der Agent möglicherweise auch den Kontext aus dem früheren Gespräch.
Dies ist genau der Punkt, an dem Zustand und Gedächtnis eine Rolle spielen.
Gedächtnis: Kontinuität für Agenten schaffen
Jeder Agent, der in mehreren Interaktionen arbeitet, benötigt ein gewisses Gedächtnissystem.
Es hilft, das Gedächtnis in zwei Kategorien einzuteilen:
Kurzfristiges Gedächtnis
Dies umfasst alle Informationen, die zur Erledigung der aktuellen Aufgabe benötigt werden.
User request + Conversation + Current plan + Tool results
Zum Beispiel könnte ein Agent bei der Untersuchung eines Rechnungsproblems Details wie folgende speichern:
Invoice = $14,000
Contract = $10,000
Usage = Normal
Diese Daten sind nur für den aktuellen Ablauf relevant.
Langfristiges Gedächtnis
Dies umfasst Informationen, die in späteren Interaktionen nützlich sein könnten.
Zum Beispiel:
User prefers concise reports.
Customer uses Enterprise contract.
Previous incident was resolved using procedure X.
In diesem Sinne verleiht das Gedächtnis dem Agenten Kontinuität zwischen verschiedenen Aufgaben, anstatt ihn jedes Mal dazu zwingen zu müssen, alles von vorne zu lernen.
Eine einfache Version dieser Architektur sieht so aus:
Agent
↓
Memory Manager
/ | \
↓ ↓ ↓
Working Episodic Semantic
Memory Memory Memory
Trotzdem sollte das Speichern von Daten nicht bedeuten, dass alles unbegrenzt aufbewahrt wird.
Eine für die Produktion geeignete Einrichtung benötigt in der Regel:
Store
↓
Index
↓
Retrieve
↓
Rank
↓
Inject relevant memory
Das Ziel ist es nicht, die Menge der gespeicherten Daten zu maximieren.
Das Ziel ist es, den Speicherinhalt relevant zu halten.
Planung: Entscheidung darüber, was als Nächstes getan werden soll
In dieser Phase kann der Agent Tools aufrufen und vergangenen Kontext abrufen. Doch Aufgaben mit vielen Variablen stellen weiterhin eine Herausforderung dar.
Darum kommt eine weitere Fähigkeit ins Spiel:
Planung.
Nehmen wir diesen Auftrag als Beispiel:
"Analysieren Sie, warum unsere Rechnungen gestiegen sind, und erstellen Sie einen Bericht."
Der Agent könnte ihn in folgende Schritte unterteilen:
1. Retrieve current billing
2. Retrieve historical billing
3. Compare services
4. Identify anomalies
5. Investigate causes
6. Verify against policy
7. Generate report
Die Planung kann in einer expliziten Form erfolgen:
{
"steps": [
"fetch_billing",
"compare_history",
"investigate_anomaly",
"generate_report"
]
}
Oder es kann implizit sein, wobei das Modell seinen nächsten Schritt unmittelbar nach dem Betrachten der Ausgabe jedes Tools wählt.
Zum Beispiel:
Get billing
↓
Observe increase
↓
Investigate service
↓
Observe anomaly
↓
Check logs
↓
Generate conclusion
Das ist wichtig, weil die Planung nicht unbedingt in einem speziellen Planungsagenten stattfinden muss.
Ein einziger Agent ist oft in der Lage, sowohl zu planen als auch die Arbeit selbst auszuführen.
Von einem Agenten zu verschiedenen Architekturen
Zu diesem Zeitpunkt sind die grundlegenden Bausteine bereits vorhanden:
LLM
+
Tools
+
State
+
Memory
+
Planning
Aber was passiert, wenn das Problem größer wird als das, was ein einziger Agent bewältigen kann?
Ein einzelner Agent ist nicht immer die richtige Lösung.
Deshalb werden verschiedene Architekturmuster verwendet, um agentenbasierte Systeme zu erstellen.
A. Einzelner Agent
Agent
/ | \
↓ ↓ ↓
DB API Search
Ein einziger Agent verwaltet mehrere Tools gleichzeitig.
Nehmen wir ein Szenario aus dem Kundenservice: Ein Agent kann gleichzeitig auf Kundendaten, Rechnungsdaten, Richtliniedokumente sowie ein Ticketsystem zugreifen.
Es macht in der Regel Sinn, hier anzufangen, da dadurch das Gesamtdesign einfach und leicht verständlich bleibt.
B. Sequenzieller Workflow
Research
↓
Analysis
↓
Generation
↓
Validation
Dieses Muster eignet sich für Situationen, in denen die Reihenfolge der Schritte im Voraus bekannt ist.
Ein Dokumentverarbeitungspipeline durchläuft beispielsweise immer die gleichen Phasen:
Extract
↓
Analyze
↓
Generate
↓
Validate
Streng genommen ähnelt dies eher einem festgelegten Workflow als einem vollständig autonomen Agenten, obwohl LLMs die Arbeit in jeder einzelnen Phase dennoch erledigen können.
C. Orchestrator-Worker
Orchestrator
/ | \
↓ ↓ ↓
Market Research Risk Investment
tool tool tool
Hier entscheidet ein Orchestrator im Echtzeit-Modus, welche Worker-Agenten tatsächlich benötigt werden.
Betrachten wir eine Anfrage wie folgt:
"Ich investiere meine 1000 Rs im Aktienmarkt ="
Der Orchesterleiter könnte Folgendes einsetzen:
Financial Research Worker
Market Research Worker
Risk Analysis Worker
Welche Arbeiter erstellt werden, hängt vollständig davon ab, was die Anfrage erfordert.
D. Bewertungs-Optimierer
Mannchmal ist die effektivste Methode, um die Qualität der Ausgabe eines Agenten zu verbessern, es einer separaten Bewertungsschritt zu überlassen.
Generator
↓
Output
↓
Evaluator
↓
Pass ─────→ Done
│
↓
Feedback
↓
Generator
Zum Beispiel:
Generate SQL
↓
Execute SQL
↓
Error
↓
Analyze error
↓
Correct SQL
↓
Execute again
In dieser Konfiguration kommt die Rückmeldung direkt aus der Umgebung, in der der Agent arbeitet.
Dieser Ansatz eignet sich besonders gut in Bereichen, in denen die Richtigkeit objektiv überprüft werden kann – wie bei generiertem Code, SQL-Abfragen, strukturierten Daten oder automatisierten Tests.
E. Mehr-Agenten-Systeme
Wenn ein Bereich komplex genug wird, kann es hilfreich sein, die Verantwortlichkeiten auf mehrere spezialisierte Agenten aufzuteilen.
Supervisor
/ | \
↓ ↓ ↓
Market Research Risk Investment
Agent Agent Agent
Jeder Agent kann in den folgenden Aspekten unterschiedlich sein:
- Anweisungen
- Werkzeuge
- Wissen
- Verantwortlichkeiten
- Bewertungskriterien
Doch die Hinzufügung weiterer Agenten bedeutet nicht automatisch eine Verbesserung.
Die Erhöhung der Anzahl der Agenten bringt außerdem mit sich:
- Erhöhte Latenzzeiten
- Höhere Kosten
- Mehr Kommunikation zwischen Agenten
- Schwereres Zustandsmanagement
- Mehr Stellen, an denen Fehler auftreten können
- Schwierigere Fehlersuche
Eine nützliche Richtlinie:
Fangen Sie mit einem einzigen Agenten an und teilen Sie ihn erst in mehrere Agenten auf, wenn die Spezialisierung klare Vorteile bringt.
Verbindung von Agenten zur Außenwelt: MCP
Sobald die Fähigkeiten eines Agenten zunehmen, kann seine Liste der benötigten Werkzeuge schnell anwachsen.
Stellen Sie sich einen Unternehmensagenten vor, der Zugang zu folgenden Ressourcen benötigt:
GitHub
Slack
Jira
PostgreSQL
Snowflake
Google Drive
AWS
Azure
Datadog
Falls jede KI-Anwendung ihre eigene Integration für jedes dieser Systeme manuell entwickeln muss, wird das gesamte Ökosystem zu einer Aufwandsbelastung für die Wartung.
Genau diese Lücke wird durch das Model Context Protocol (MCP) geschlossen.
Was ist MCP?
Model Context Protocol (MCP) ist ein offenes Protokoll, das entwickelt wurde, um zu standardisieren, wie KI-Anwendungen mit externen Tools, Ressourcen und Anfragen kommunizieren.
Einfach ausgedrückt:
MCP dient als standardisierte Schnittstelle zwischen KI-Anwendungen und externen Funktionen.
Ohne einen gemeinsamen Standard entsteht Folgendes:
Agent
├── Custom GitHub integration
├── Custom Slack integration
├── Custom Database integration
└── Custom Jira integration
Mit MCP sieht die Situation hingegen so aus:
AI Application
↓
MCP Client
↓
┌─────────┼─────────┐
↓ ↓ ↓
GitHub Jira DB
MCP Server MCP Server MCP Server
MCP definiert eine Host-Client-Server-Architektur zusammen mit standardisierten Bausteinen – nämlich Tools, Ressourcen und Anfragen.
MCP-Tools
Das sind Aktionen, die das Modell ausführen darf:
create_issue()
search_repository()
execute_query()
MCP-Ressourcen
Das sind Kontextdaten, die an das Modell übergeben werden können:
database schema
repository files
documents
configuration
MCP-Aufforderungen
Das sind wiederverwendbare Vorlagen für häufige Interaktionen:
review_code()
generate_report()
debug_error()
Hier ist der wichtigste Punkt, den man im Hinterkopf behalten sollte:
MCP erstellt keinen Agenten.
Was es Ihnen bietet, ist eine gängige Methode dafür, dass ein Agent oder jede KI-Anwendung auf externe Fähigkeiten zugreifen kann. MCP ist die Verbindungsstufe; der Agent selbst bleibt die Entscheidungsebene.
Nun kann der Agent handeln – aber kann er sich verbessern?
In dieser Phase ist der Agent in der Lage, Folgendes zu tun:
Understand
↓
Plan
↓
Use tools
↓
Retrieve knowledge
↓
Remember information
↓
Take actions
Doch ein Produktivsystem wirft eine weitere Frage auf:
Was passiert, wenn der Agent etwas falsch macht?
Nehmen wir an, er wählt ständig das falsche Werkzeug für eine Aufgabe.
User:
Investigate invoice.
Agent:
Calls get_customer_profile()User:
Wrong tool. You should check invoice_details().
Sollte man den Prompt sofort reparieren?
Wahrscheinlich nicht.
Die Rückmeldungen, die ein Benutzer gibt, können selbst falsch, bösartig, unvollständig oder nur für einen bestimmten Fall gültig sein. Das ist der Grund hinter Lernschleifen.
Lernschleifen
Ein häufiger Irrtum lautet folgendermaßen:
"Wenn ich einem Agenten Rückmeldungen gebe, lernt das zugrunde liegende LLM automatisch."
In der Praxis ist das in der Regel nicht der Fall.
Lernen findet auf verschiedenen Ebenen statt.
Ebene 1 – Rückmeldungen im Kontext
Agent:
I'll create a P2 ticket.
User:
No, this should be P1.Agent:
Understood. P1.
Hier passt der Agent sein Verhalten nur für das laufende Gespräch an.
Die Gewichte des zugrunde liegenden Modells bleiben unverändert.
Niveau 2 – Speicher
Die Einstellung kann stattdessen gespeichert werden:
User preference:
Incident priority should default to P1 for this category.
Spätere Sitzungen können diese gespeicherte Einstellung wieder herunterladen. Das Modell hat sich nicht geändert – der Agent verfügt lediglich über mehr Kontext, auf den er zurückgreifen kann.
Niveau 3 – Systemverbesserung
Betrachten Sie nun ein Muster wiederholter Fehler.
Production
↓
Trace
↓
Evaluation
↓
Failure detected
↓
Improve prompt/tool/model
↓
Deploy new version
Eine Lösung auf dieser Ebene könnte gleichzeitig mehrere Teile des Workflows beeinflussen:
- Die Formulierung der Anfragen
- Wie Tools beschrieben werden
- Die Routenlogik zur Auswahl eines Pfades
- Der Abrufschritt
- Die Beispiele, die dem Agenten gezeigt werden
- Das Feintunen eines Modells
- Der Austausch gegen ein ganz anderes Modell
Diese Ansammlung von Änderungen entspricht viel besser dem, was Menschen eigentlich mit einem Lernzyklus eines Agents meinen.
Die Schlussfolgerung lautet folgende:
Feedback sollte in der Regel zur Bewertung und Verbesserung des Systems beitragen, anstatt direkt in ein dauerhaftes Verhalten integriert zu werden.
Schutzmaßnahmen und Sicherheit
Sobald ein Agent mit der Ausführung von Aktionen beginnt, taucht eine neue Herausforderung auf:
Was verhindert, dass er schädliche Dinge tut?
Ein Agent kann mit Datenbanken, Produktivinfrastrukturen, Finanzsystemen oder Kundendaten verbunden sein.
Das bedeutet, die Architektur muss Grenzen dafür vorgeben, was der Agent tun darf.
User
↓
Input Guardrail
↓
Agent
↓
Authorization
↓
Tool
↓
External System
↓
Output Validation
Schutzmaßnahmen sind nützlich, um Dinge wie folgende aufzudecken:
- Prompt-Injektion
- Unsichere Anfragen
- Sensible Informationen
- Ungültige Tool-Argumente
- Verstöße gegen Richtlinien
Trotzdem reichen Schutzmaßnahmen allein nicht aus.
Stellen Sie sich vor, der Agent versucht, Folgendes auszuführen:
DELETE production_database
Man möchte nicht, dass das System auf das Modell zur Logikverarbeitung angewiesen ist:
"Das klingt gefährlich."
Anstelle dessen sollte die Autorisierungslogik dies jedes Mal deterministisch blockieren.
Das grundlegende Prinzip hier ist:
Das LLM sollte niemals die endgültige Sicherheitsbarriere sein.
Echte Authentifizierung, Autorisierung, Zugriffskontrolle, Eingabenvalidierung sowie standardmäßige Anwendungs-Sicherheitspraktiken müssen den Agenten umfassen.
Prompt-Injection in agilen Systemen
Prompt-Injection wird besonders kritisch, sobald ein Agent Inhalte von außerhalb des Systems abrufen kann.
Betrachten Sie dieses Szenario:
Agent
↓
Search document
↓
Document contains malicious instruction
↓
Agent interprets it as an instruction
↓
Tool call
↓
Potentially harmful action
Der wichtigste Unterschied, den man im Hinterkopf behalten sollte, ist:
Instructions
≠
Retrieved Data
Eine Webseite, E-Mail, Supportanfrage, GitHub-Issue oder jedes andere Dokument kann Text enthalten, der so formatiert ist, dass er wie eine Anweisung aussieht. Der Agent sollte nicht alles, was er abruft, automatisch als vertrauenswürdig oder autoritativ betrachten. Genau deshalb erfordern agentbasierte Systeme eine strengere Sicherheit als einfache Frage-und-Antwort-Tools.
Bewertung: Beurteilen Sie nicht nur die endgültige Antwort
Sobald ein Agent eingesetzt wird, gibt es eine zentrale Frage, auf die Sie ständig antworten müssen:
Führt der Agent seine Aufgabe tatsächlich gut aus?
Bei herkömmlicher Software lautet die übliche Frage:
"War die Ausgabe korrekt?"
Mit Agenten müssen Sie auch folgende Frage stellen:
"Hat der Agent einen sinnvollen Weg eingeschlagen, um dorthin zu gelangen?"
Zum Beispiel:
Request
↓
Wrong Tool
↓
Wrong Tool
↓
Correct Tool
↓
Correct Answer
Die endgültige Antwort kann richtig sein, selbst wenn der Agent viel Mühe darauf verwendet hat, sie zu finden.
Deshalb sollte man die gesamte Vorgehensweise bewerten und nicht nur das Ergebnis:
Input
↓
Plan
↓
Tool Selection
↓
Arguments
↓
Tool Result
↓
Next Decision
↓
Final Answer
Bei der Einstellung der Bewertung sollten Sie auf Anzeichen achten wie zum Beispiel ob die Aufgabe abgeschlossen wurde, ob das richtige Werkzeug gewählt wurde, ob die Argumente korrekt eingegeben wurden, wie gut der abgerufte Kontext war, wie direkt der Weg zur Antwort führte, wie lange es dauerte, was die Kosten waren, ob Sicherheitsregeln verletzt wurden und wie oft ein Mensch eingreifen musste.
Die Vorgehensweise zeigt Ihnen wie der Agent zum Ergebnis gelangt ist, was genauso wichtig ist wie das Ergebnis selbst.
Beobachtbarkeit
Die Bewertung zeigt an, ob alles funktioniert. Die Beobachtbarkeit zeigt Ihnen warum etwas schiefgelaufen ist.
Ein nützlicher Ablaufverlauf könnte wie folgt aussehen:
Trace: 12345
User Request
↓
LLM Call #1
↓
search_customer()
↓
Result
↓
LLM Call #2
↓
get_invoice()
↓
Result
↓
LLM Call #3
↓
Final Answer
Ihre Protokolle sollten jede Aufrufung eines Modells, jeden Aufruf einer Tool-Funktion samt deren Argumenten und Ergebnissen, die Dauer der Ausführung, den Tokenverbrauch, eventuelle Fehler oder Wiederholungsversuche, ausgelöste Schutzmechanismen sowie das endgültige Ergebnis erfassen.
Ohne dieses Maß an Detailgenauigkeit wird die Diagnose des Verhaltens eines Agents nahezu unmöglich.
Zum Beispiel, wenn ein Agent eine falsche Antwort liefert, sollte ein gutes Protokoll es ermöglichen, herauszufinden, ob die Ursache darin lag:
Wrong retrieval?
↓
Wrong tool?
↓
Wrong tool arguments?
↓
Incorrect reasoning?
↓
Bad final generation?
Deshalb ist Observabilität ein zentraler Bestandteil der Systementwicklung und nicht nur eine nachträglich hinzugefügte Lösung für das Monitoring.
Alles zusammenfassen: Produktionsarchitektur
Schritt für Schritt haben wir neue Funktionen auf die ursprüngliche LLM-Plattform aufgebaut:
LLM
↓
RAG
↓
Tools
↓
Agent Loop
↓
Memory
↓
Planning
↓
MCP
↓
Learning & Evaluation
↓
Security & Guardrails
Ein echtes Produktionsystem verbindet all diese Komponenten miteinander:
USER
│
↓
API / Application
│
↓
Authentication
│
↓
┌─────────────┐
│ Agent │
│ Runtime │
└──────┬──────┘
│
┌────────────┼────────────┐
↓ ↓ ↓
Context Memory Tools
Manager │ │
│ ↓ ↓
↓ Vector DB MCP / APIs
RAG │
│ ┌──────────┼──────────┐
↓ ↓ ↓ ↓
Knowledge GitHub DB SaaS
│
↓
Tool Results
│
↓
Agent
│
┌──────┴──────┐
↓ ↓
Response Action
│
↓
External
System
Und umfasst schließlich das Ganze:
Security
Guardrails
Observability
Evaluation
Human Approval
Cost Monitoring
Diese umgebende Schicht ist es, die ein vielversprechendes Prototyp in einen Agenten verwandelt, den man tatsächlich in der Produktion einsetzen kann.
Der größere Überblick
Rückblickend begann die Reise mit einem einfachen LLM:
User → Prompt → LLM → Response
Dann zeigten sich die ersten Mängel.
Das Modell hatte keinen Zugriff auf externe Kenntnisse.
Deshalb kam RAG ins Spiel.
Es benötigte eine Möglichkeit, mit externen Systemen zu interagieren.
Daher gaben wir ihm Tools.
Es musste entscheiden, welche Aktion in jedem Schritt sinnvoll war.
Deshalb wurde der Agent Loop eingeführt.
Es musste den früheren Kontext speichern.
Daher fügten wir Memory hinzu.
Härtere Aufgaben erforderten die Aufteilung der Arbeit in kleinere Schritte.
Deshalb kam anschließend das Planning.
Die Koordination mehrerer spezialisierter Fähigkeiten erforderte eine bessere Struktur.
Daher haben wir verschiedene Agent-Architekturen vorgestellt sowie, wo sinnvoll, vollständige Multi-Agent-Systeme.
Sobald die Anzahl der Integrationen zunahm, trat ein neues Problem auf.
Darum kommen standardisierte Protokolle wie MCP ins Spiel, die eine konsistente Verbindungsstufe bieten.
Sobald das System anfing, eigenständig bedeutungsvolle Entscheidungen zu treffen, benötigte es:
Sicherheit → Bewertung → Beobachtbarkeit → Rückmeldung → Kontinuierliche Verbesserung
Zu diesem Zeitpunkt handelt es sich nicht mehr nur um ein LLM, das in einen Prompt eingebettet ist.
Es ist zu einem vollständigen agentbasierten System geworden.
Das mentale Modell der agentbasierten KI
In seinem Kern lässt sich das Modell auf Folgendes reduzieren:
GOAL
↓
REASON
↓
PLAN
↓
ACT
↓
OBSERVE
↓
EVALUATE
↓
REMEMBER
│
└────────→ REASON
Um diesen Loop herum befindet sich:
Security
+
Guardrails
+
Authorization
+
Observability
+
Human Oversight
Das verfolgt die folgende Entwicklung:
LLM
↓
LLM + RAG
↓
LLM + Tools
↓
Agent
↓
Agent + Memory
↓
Agent + MCP
↓
Multi-Agent / Agentic Systems
↓
Continuous Evaluation & Improvement
Aber das Ziel ist es nicht, die Autonomie so weit wie möglich zu treiben.
Das Ziel sollte eine zuverlässige Autonomie sein.
Fazit
Agierende KI wird oft auf eine ansprechende Formel reduziert:
LLM + Tools
Doch das ist nur der Ausgangspunkt.
Ein für die Produktion geeigneter Agent vereint:
- Logikvermögen, angetrieben durch ein LLM
- Wissen, bereitgestellt über RAG
- Kontinuität, aufrechterhalten durch Speicherung
- Aktionen, ausgeführt über Tools
- Vernetzung, ermöglicht durch Protokolle wie MCP
- Planung, für mehrschrittige Probleme
- Rückmeldung, zur Verbesserung
Die grundlegende architektonische Regel lässt sich einfach formulieren:
Verlassen Sie sich auf deterministischen Code, wo Korrektheit unverzichtbar ist, und nutzen Sie lernbasierte Verarbeitungssysteme nur in Fällen, in denen Flexibilität und Urteilsvermögen tatsächlich einen Mehrwert schaffen.
Die stärksten agierenden Systeme werden nicht dadurch definiert, wie viele Funktionen sie bieten.
Sie heben sich dadurch ab, dass sie wissen, was zu tun ist, die richtigen Werkzeuge einsetzen, den richtigen Kontext berücksichtigen, ihre eigene Arbeit überprüfen, ihre Grenzen respektieren und erkennen, wann sie pausieren oder einen Menschen einbeziehen müssen.
Das ist der eigentliche Wandel, den agierende KI darstellt:
Vom Umgang mit Systemen, die nur Antworten liefern, hin zu Systemen, die Ziele erkennen, darauf handeln, aus den Ergebnissen lernen und mit Menschen zusammenarbeiten, um echte Aufgaben zu erledigen.
Zusätzliche Literatur
- ReAct erklärt: Wie KI-Agenten Denken mit Handlungen in der realen Welt verbinden — Erfahren Sie, wie das ReAct-Framework Denken und Werkzeugnutzung miteinander verbindet, um KI-Agenten zu unterstützen, und wie es sich von Chain-of-Thought-, RL- sowie Denkmodellen unterscheidet.