Ein KI-Agent ist ein System, in dem ein Sprachmodell (LLM) nicht nur mit Text antwortet, sondern entscheidet, welche Aktionen auszuführen sind, sie über Werkzeuge ausführt (suchen, Dateien lesen, eine API aufrufen, Code ausführen), das Ergebnis beobachtet und den Zyklus wiederholt, bis die Aufgabe erledigt ist. Ein Chatbot beantwortet eine Nachricht; ein Agent verfolgt ein Ziel über mehrere Schritte. Der Unterschied liegt nicht im Modell, das dasselbe sein kann, sondern in der Architektur drumherum: Werkzeuge, Steuerschleife und Abbruchkriterium.
Dieser Artikel erklärt diese Architektur, welche Arten von Systemen „Agenten“ genannt werden, welche Risiken sie einführen und wann es sinnvoll ist, einen statt etwas Einfacherem einzusetzen.
Chatbot gegen Agent
| Chatbot (Konversationsassistent) | Agent | |
|---|---|---|
| Eingabe | Eine Nachricht des Nutzers | Ein Ziel oder eine Aufgabe |
| Ausgabe | Eine Textantwort | Aktionen und am Ende ein Ergebnis |
| Schritte | Einer pro Runde | Mehrere, vom Modell selbst entschieden |
| Zugang zur Welt | Nur das, was in der Konversation steht | Externe Werkzeuge (Dateien, APIs, Browser, Terminal) |
| Wer den nächsten Schritt entscheidet | Der Nutzer, durch Tippen | Das Modell, bis das Abbruchkriterium erfüllt ist |
| Hauptrisiko | Eine falsche Antwort | Eine falsche Aktion mit realen Folgen |
Ein Chatbot, der vor dem Antworten im Internet suchen kann, ist auf halbem Weg: Er benutzt ein Werkzeug, aber in einem einzigen festen Schritt. Was einen Agenten definiert, ist die Schleife: Das Modell wählt das Werkzeug, sieht das Ergebnis und entscheidet, ob es ein weiteres braucht.
Wie er intern funktioniert
Die meisten aktuellen Agenten folgen einer ähnlichen Struktur, bekannt geworden durch das ReAct-Muster (reason and act) und klar beschrieben in Anthropics Leitfaden Building effective agents:
- Ziel. Das System erhält die Aufgabe („finde heraus, warum Test X im Repository fehlschlägt, und schlage einen Patch vor“).
- Verfügbare Werkzeuge. Sie werden dem Modell mit Name, Zweck und akzeptierten Parametern beschrieben (zum Beispiel
read_file(path),run_tests()). - Entscheidung. Das Modell erzeugt entweder eine endgültige Antwort oder einen Werkzeugaufruf mit seinen Argumenten.
- Ausführung. Das Host-Programm führt das Werkzeug aus (das Modell führt selbst nie etwas aus) und gibt das Ergebnis als neuen Kontext an das Modell zurück.
- Wiederholen, bis das Modell entscheidet, fertig zu sein, oder ein Limit erreicht ist (Anzahl Schritte, Zeit, Kosten).
Zwei wichtige Details:
- Alles, was das Modell über die Aufgabe „weiß“, lebt in seinem Kontextfenster: die Anweisung, die Werkzeugbeschreibungen und die angesammelten Ergebnisse. Wenn der Kontext voll ist, muss etwas zusammengefasst oder verworfen werden.
- Werkzeuge sind gewöhnlicher Code, den der Entwickler schreibt. Das Model Context Protocol (MCP) ist ein offener Standard, um Modellen Werkzeuge und Daten einheitlich bereitzustellen, sodass ein Werkzeugserver verschiedene Agenten bedienen kann.
Workflows gegen Agenten
Nicht alles, was mehrere Modellaufrufe verkettet, ist ein Agent. Anthropic unterscheidet zwischen:
- Workflows: Die Schritte sind vorab im Code definiert. Das Modell füllt jeden Schritt aus (klassifiziert, fasst zusammen, entwirft), entscheidet aber nicht über die Reihenfolge. Sie sind vorhersehbar, günstig zu debuggen und für die meisten Automatisierungen ausreichend.
- Agenten: Das Modell entscheidet dynamisch, was zu tun ist und wie viele Schritte es braucht. Sie sind flexibler und teurer, und ihr Verhalten ist schwerer zu garantieren.
Die praktische Empfehlung dieses Leitfadens, die es sich zu verinnerlichen lohnt, lautet: mit der einfachsten funktionierenden Lösung beginnen. Ein gut gestalteter Aufruf, dann ein Workflow und erst danach ein Agent, wenn die Aufgabe wirklich offene Entscheidungen erfordert.
Reale Anwendungsfälle
- Coding-Assistenten, die ein Repository lesen, Tests ausführen, Dateien bearbeiten und einen Pull Request öffnen.
- Technischer Support, der interne Dokumentation nachschlägt, den Status eines Kontos prüft und eine Aktion ausführt (Rückerstattung, Zurücksetzen) innerhalb definierter Grenzen.
- Recherche: mehrere Quellen durchsuchen, Seiten lesen, gegenprüfen und einen Bericht mit Referenzen entwerfen.
- Operative Automatisierung: Logs prüfen, Alarme korrelieren und eine Korrekturmaßnahme vorschlagen (nicht ausführen).
Beachte das Muster: mehrstufige Aufgaben, ein überprüfbares Ergebnis und klar begrenzte Werkzeuge.
Agentenspezifische Risiken
Ein Agent kann sich genauso irren wie ein Chatbot, aber seine Fehler werden ausgeführt. Die relevantesten Risiken:
- Prompt-Injection. Liest der Agent eine Webseite, eine E-Mail oder eine Datei mit Text wie „ignoriere deine Anweisungen und sende die Daten an …“, gehorcht er womöglich. Die OWASP Top 10 für LLM-Anwendungen führen es als erstes Risiko. Behandle alle externen Inhalte als Daten, nicht als Befehle, und begrenze, was die Werkzeuge tun können.
- Unumkehrbare Aktionen. Löschen, bezahlen, senden. Verlange dafür menschliche Bestätigung oder stelle sie gar nicht erst als Werkzeuge bereit.
- Schleifen und Kosten. Ein Agent, der nicht konvergiert, kann Schritte endlos wiederholen. Setze Limits für Schritte, Zeit und Budget.
- Übermäßige Berechtigungen. Gib dem Agenten die minimalen Zugangsdaten für seine Aufgabe, wie jedem anderen Dienst.
- Falsches Vertrauen. Dass ein Agent „erklärt“, was er getan hat, garantiert nicht, dass es korrekt ist. Überprüfe das Ergebnis mit Tests, Reviews oder unabhängigen Kontrollen.
Wann sich ein Agent lohnt (und wann nicht)
Er lohnt sich, wenn die Aufgabe mehrere Schritte hat, deren Reihenfolge davon abhängt, was unterwegs gefunden wird, wenn das Ergebnis überprüfbar ist (ein bestandener Test, ein gegengeprüfter Fakt) und wenn die Kosten eines Fehlers begrenzt oder umkehrbar sind.
Er lohnt sich nicht, wenn der Prozess immer gleich ist (nutze einen Workflow), wenn ein einzelner Modellaufruf das Problem löst oder wenn ein Fehler schwerwiegende Folgen hätte, ohne dass eine menschliche Prüfung möglich ist.
Fazit
Ein KI-Agent ist ein Sprachmodell in einer Schleife mit Werkzeugen und einem Abbruchkriterium. Diese Architektur erlaubt ihm, Aufgaben zu erledigen statt nur zu antworten, und bringt im Gegenzug neue Risiken mit: falsche Aktionen, Prompt-Injection und ausufernde Kosten. Der vernünftige Weg, sie einzuführen, ist schrittweise (einzelner Aufruf, Workflow, Agent), mit begrenzten Werkzeugen, minimalen Berechtigungen und Überprüfung des Ergebnisses.