Welche Arten von KI-Agenten gibt es?

Welche Arten von KI-Agenten gibt es

Die Arten von KI-Agenten stammen aus einer Taxonomie: einfache reflexbasierte Agenten, modellbasierte reflexbasierte Agenten, zielbasierte Agenten, nutzenbasierte Agenten und lernende Agenten. Jeder Name beschreibt einen Aspekt: wie viele Informationen der Agent speichert und wie weit er plant, bevor er handelt. Zwei weitere Begriffe, Multi-Agenten-Systeme und hierarchische Systeme, beschreiben, wie mehrere Agenten miteinander verbunden sind, und nicht, wie ein einzelner Agent Entscheidungen trifft.

Diese Liste ist älter als jedes Modell, das Sie verwendet haben. Sie stammt aus dem Standardlehrbuch für KI und hat das Aufkommen großer Sprachmodelle überstanden, weil sie die Frage stellt, die Ihre Architektur weiterhin bestimmt: Was muss dieses System wissen, bevor es handelt? Wenn Sie noch klären, wo ein Agent endet und ein Chat-Assistent beginnt, lesen Sie zuerst den Unterschied zwischen einem KI-Agenten und dem LLM, auf dem er ausgeführt wird. Diese Seite setzt danach an.

Einfache Reflexagenten: eine Bedingung, eine Aktion

Ein einfacher Reflexagent ordnet die aktuelle Eingabe einer Aktion zu und speichert keine Informationen aus der Vergangenheit. Wenn die Temperatur über 25 liegt, schalten Sie den Lüfter ein. Das ist der gesamte Mechanismus.

Sie haben mit hoher Wahrscheinlichkeit bereits einen solchen Agenten ausgeführt. Ein Webhook, der einen n8n-Workflow auslöst, eine Formulareingabe liest und eine Zeile in eine Datenbank schreibt, ist ein einfacher Reflexagent. Das gilt auch dann, wenn ein Sprachmodell dazwischengeschaltet ist und eine Kategorie für diese Zeile auswählt. Fragen Sie ihn, was er vor einer Stunde getan hat. Er kann es Ihnen nicht sagen, weil niemand die Antwort gespeichert hat.

Dieser Typ funktioniert häufiger zuverlässig, als viele erwarten. Der Betrieb ist kostengünstig, und Fehler sind nachvollziehbar: Die Bedingung war erfüllt oder nicht. Wenn die eigentliche Aufgabe lautet: „Wenn X eintrifft, führe Y aus“, schafft ein Speicher zusätzliche Fehlerquellen, ohne einen Nutzen zu bringen. Ein durch einen Webhook ausgelöster n8n-Agent ist dieser Eintrag der Taxonomie mit einer Benutzeroberfläche darüber.

Er versagt, sobald die richtige Aktion von der bisherigen Historie abhängt. Ein Antwort-Bot ohne Thread-Status widerspricht sich bei der dritten Nachricht, weil die ersten beiden Nachrichten nie Teil seiner Eingabe waren.

Modellbasierte Reflexagenten: Zustand zwischen Ereignissen beibehalten

Ein modellbasierter Reflexagent hält ein internes Bild seiner Umgebung vor und aktualisiert dieses Bild, sobald neue Eingaben eintreffen. Mit „Modell“ ist hier ein Modell der Welt gemeint, kein neuronales Netzwerk. Der Begriff entstand etwa vierzig Jahre vor seiner heutigen Bedeutung und sorgt beim ersten Lesen fast immer für Verwirrung.

Eine Regel in der Hausautomation, die das Licht nach zwanzig Minuten ohne Bewegung ausschaltet, ist modellbasiert. Das muss sie sein. „Jetzt keine Bewegung“ und „seit 21:40 keine Bewegung“ sind für einen einfachen Reflexagenten dieselbe Eingabe. Nur ein gespeicherter Zustand kann sie unterscheiden.

Die LLM-Variante ist jeder Agent mit einem dahinterliegenden Speicher: eine fortlaufend aktualisierte Zusammenfassung der Unterhaltung oder eine einfache Markdown-Datei, die der Agent zu Beginn jedes Durchlaufs liest. Ein lokaler Speicherdienst für einen Agenten verpackt diese Idee als Dienst. Der Mechanismus ändert sich nicht. Das interne Bild des Agenten von der Welt bleibt über das Ereignis hinaus bestehen, durch das es erzeugt wurde.

Zustand hat seinen Preis. Eine veraltete Information ist schlechter als keine Information, weil der Agent mit voller Sicherheit und ohne Warnung danach handelt. Alles, was Sie speichern, benötigt eine Möglichkeit zum Ablaufen oder zur erneuten Prüfung. Andernfalls schlussfolgert der Agent weiterhin über einen Server, den Sie im März außer Betrieb genommen haben.

Zielbasierte Agenten: Planung bis zu einem überprüfbaren Zustand

Ein zielbasierter Agent erhält einen Zielzustand und sucht nach einer Abfolge von Aktionen, die diesen Zustand erreicht. Er arbeitet rückwärts von dem Zustand, den er am Ende erreichen muss. Der Weg dorthin ist daher nicht vorab festgelegt.

Ein Coding-Agent ist das anschaulichste Beispiel, das Sie selbst ausführen können. „Den fehlschlagenden Test erfolgreich ausführen“ nennt weder Dateien noch Schritte. Der Agent liest den Test, erstellt einen Plan, ändert etwas, führt den Test aus, liest den Fehler und versucht es erneut. Die Schleife endet mit einer Prüfung, die er tatsächlich ausführen kann. Deshalb funktioniert diese Anweisung, während „diesen Code verbessern“ nicht funktioniert. Ein Ziel, das der Agent bewerten kann, ist ein Ziel, das der Agent erreichen kann. Ein Ziel, das er nicht bewerten kann, führt zu einer Endlosschleife mit anfallenden Kosten. Einen Coding-Agent auf dem eigenen VPS ausführen verlagert diese Schleife an einen Ort, an dem sie arbeiten kann, ohne Ihren Laptop zu belegen.

Die Kosten entstehen in dieser Zeile. Jeder Planungsschritt ist ein weiterer Modellaufruf, der den bisherigen Verlauf mitführt. Eine Aufgabe mit zehn Schritten kostet daher nicht zehnmal so viel wie ein einzelner Schritt, sondern mehr. Entscheidend ist die Gestaltung der Schleife und die Bedingung, die sie beendet. Darum geht es in Schleifen-Engineering.

Agenten auf Basis einer Nutzenfunktion: Auswahl zwischen mehreren guten Antworten

Ein Ziel ist binär. Der Nutzen ist ein Punktwert. Ein Agent auf Basis einer Nutzenfunktion steht vor mehreren akzeptablen Ergebnissen und wählt dasjenige aus, das gemäß einer von Ihnen definierten Funktion den höchsten Wert erzielt.

Ein Backup-Auftrag, der vor Beginn des Arbeitstags abgeschlossen sein muss, ohne die Uplink-Bandbreite auszulasten, ist ein Nutzenproblem. Es gibt keine einzige richtige Antwort, sondern nur einen Zielkonflikt. Ein Router, der entscheidet, welches Modell welche Anfrage verarbeitet, und dabei den Preis gegen die Antwortqualität abwägt, hat dieselbe Struktur.

Der Algorithmus ist nicht der schwierige Teil. Schwierig ist es, eine realistische Nutzenfunktion zu formulieren. Bewerten Sie nur die Kosten, erhalten Sie bei jeder Anfrage das günstigste Modell, auch bei der einen Anfrage, für die das teure Modell erforderlich war. Das System optimiert genau das, was Sie gemessen haben. Das ist problematisch, wenn Sie diese Messgröße gewählt haben, weil sie leicht zu erfassen war.

Lernende Agenten: der Typ, den die meisten bereits zu haben glauben

Ein lernender Agent ändert sein eigenes Verhalten anhand von Rückmeldungen zu früheren Ergebnissen. Er benötigt eine Komponente, die das Ergebnis bewertet, und eine weitere, die daraufhin die Policy ändert.

Sehr wenige Self-Hosted-Systeme erfüllen diese Kriterien. Ein Agent, der von ihm in der vergangenen Woche geschriebene Notizen liest, ist ein modellbasierter Agent mit einer Speicherdatei. Seine Gewichte sind identisch. Seine Policy ist identisch. Retrieval ist kein Lernen. Diese Unterscheidung ist praktisch relevant: Ein speicherbasiertes System wiederholt einen Fehler dauerhaft, sofern niemand den Speicher bearbeitet. Ein lernendes System sollte dagegen aufhören, diesen Fehler zu machen.

Wenn Sie den Lernanteil umsetzen möchten, entwickeln Sie zuerst die Bewertung. Ein bewerteter Testsatz, ein Durchlauf Ihrer Änderung damit und die Entscheidung, die Änderung zu übernehmen oder zu verwerfen, bilden eine geschlossene Schleife, in der Sie die lernende Komponente sind. Das ist langsamer, als es klingt, und derzeit die einzige Variante, die mit Self-Hosted-Komponenten funktioniert. Ein Eval-Harness selbst hosten ist der Ausgangspunkt dafür.

Multi-Agent- und hierarchische Systeme: Anordnungen, keine Typen

Dies sind kein sechster und siebter Typ. Sie beschreiben, wie Agents angeordnet sind.

Ein Multi-Agent-System führt mehrere Agents gleichzeitig in einer gemeinsamen Umgebung aus, beispielsweise in einer Warteschlange oder einem git-Repository. Weil die Umgebung gemeinsam genutzt wird, entstehen dort Konflikte. Zwei Agents, die dieselbe Datei bearbeiten, sind der typische Fehlerfall. Die Lösung ist eine Sperre oder eine Arbeitswarteschlange. Kein Prompt kann dieses Problem lösen.

Ein hierarchisches System stellt den Workern einen Supervisor übergeordnet voran. Der Supervisor teilt eine Aufgabe auf, verteilt die Teilaufgaben und führt die Ergebnisse wieder zusammen. Dieser Ansatz ist verbreitet, weil er der menschlichen Arbeitsteilung entspricht. Er ist jedoch ressourcenintensiv, weil der Kontext des Supervisors mit jedem gelesenen Bericht wächst. Ein Multi-Agent-Harness zeigt, wie diese Verdrahtung in der Praxis aussieht.

Ein Agent, der zuverlässig arbeitet, ist besser als vier, die meistens funktionieren.

Jede Übergabe ist eine Stelle, an der Informationen verloren gehen können. Beginnen Sie mit einer Schleife. Teilen Sie sie erst auf, wenn Sie den Schritt benennen können, der den Engpass bildet.

Warum fast jedes reale System hybrid ist

Betrachten Sie einen Deployment-Agenten, den Sie selbst betreiben könnten. Ein Webhook startet ihn; das ist reflexbasiert. Er liest den aktuellen Release-Status; das ist modellbasiert. Er plant die Schritte von der laufenden Version zur Zielversion; das ist zielbasiert. Er wählt anhand der aktuellen Auslastung ein Rollout-Fenster; das ist nutzenbasiert. Er ändert seine eigene Richtlinie nicht und lernt daher nicht.

Ein System deckt gleichzeitig vier Zeilen der Taxonomie ab. Die Taxonomie ist als Checkliste für den Entwurf nützlich, nicht als Bezeichnung für das fertige Produkt. Wenn sich das System fehlerhaft verhält, ist die entscheidende Frage, welche Schicht fehlerhaft ist. Ein Trigger, der auf das falsche Ereignis reagiert hat, ein veralteter Status, eine Zielprüfung, die niemals erfolgreich sein kann, und eine Bewertung, die das falsche Ergebnis belohnt, sind vier unterschiedliche Fehler mit vier unterschiedlichen Lösungen.

Welcher Typ für welche Aufgabe geeignet ist

• Fester Auslöser, feste Reaktion, keine Historie erforderlich: einfacher Reflex.
• Die richtige Reaktion hängt davon ab, was zuvor geschehen ist: modellbasierter Reflex.
• Der Endzustand ist überprüfbar, aber der Weg dorthin ist im Voraus unbekannt: zielbasiert.
• Mehrere akzeptable Ergebnisse mit einem echten Zielkonflikt zwischen ihnen: nutzenbasiert.
• Sie benötigen Ergebnisse, die sich im Laufe der Zeit verbessern: Bauen Sie eine Evaluierungsschleife auf, und akzeptieren Sie, dass Sie die lernende Komponente sind.

Können Sie diese Agents selbst hosten, und was kostet das?

Ja. Die Kosten teilen sich in zwei Bereiche. Die Orchestrierung ist günstig. Eine n8n-Instanz oder eine Agentenschleife in Python wartet die meiste Zeit auf Netzwerkaufrufe. Dafür reichen 2 vCPU und 4 GB RAM aus. Die Kosten entstehen beim Modell.

Ruft der Agent eine gehostete API auf, benötigt der Server kaum Ressourcen. Die Rechnung steigt mit der Anzahl der Tokens. Bei einem zielbasierten Agenten hängt sie davon ab, wie viele Planungsschritte Sie zulassen. Begrenzen Sie daher die Schleife.

Wenn Sie das Modell auf eigener Hardware ausführen, bestimmt der RAM, welche Modelle Sie überhaupt betreiben können. Die folgenden Werte sind typische veröffentlichte Dateigrößen für quantisierte Gewichte mit 4 Bit (Stand August 2026). Daneben steht ein Richtwert für den gesamten RAM-Bedarf. Kontextfenster und Laufzeitumgebung benötigen zusätzlich zu den Gewichten weiteren Speicher.

[
  {
    "label": "3B model",
    "weights_gb": 2,
    "ram_needed_gb": 6
  },
  {
    "label": "8B model",
    "weights_gb": 4.9,
    "ram_needed_gb": 10
  },
  {
    "label": "14B model",
    "weights_gb": 9,
    "ram_needed_gb": 16
  },
  {
    "label": "32B model",
    "weights_gb": 20,
    "ram_needed_gb": 32
  },
  {
    "label": "70B model",
    "weights_gb": 43,
    "ram_needed_gb": 64
  }
]

Ein 8B-Modell mit 4 Bit benötigt etwa 4.9 GB für die Gewichte. Ein System mit 10 GB RAM kann es ohne Auslagerung ausführen. Ein 70B-Modell mit derselben Quantisierung benötigt 43 GB für die Gewichte und etwa 64 GB RAM. Beachten Sie, was diese Zahlen nicht angeben: die Geschwindigkeit. Auf einem VPS ohne GPU erzeugt ein 8B-Modell mit 4 Bit nur einstellige Tokenraten pro Sekunde. Das reicht für einen Agenten, der über Nacht eine Warteschlange abarbeitet. Für Aufgaben, auf deren Ergebnis eine Person wartet, ist es langsam. Verwenden Sie lokale Inferenz für Batch-Aufgaben. Für interaktive Aufgaben verwenden Sie eine GPU oder eine API. Die Übersicht selbst hostbarer KI-Agents zeigt, welche Projekte den Speicherplatz wert sind. Ein Lernpfad für Agents im Jahr 2026 zeigt, was Sie in welcher Reihenfolge lernen sollten.

Wo die Taxonomie nicht mehr weiterhilft

Sie sagt nichts über Tools oder Berechtigungen aus. In der Lehrbuchdefinition nehmen Agenten ihre Umgebung wahr und handeln. Niemand, der dieses Kapitel geschrieben hat, musste sich Gedanken darüber machen, dass ein Agent ein Produktions-API-Token besitzt. Ein zielbasierter Agent mit Shell-Zugriff und ein zielbasierter Agent mit nur einer schreibgeschützten Datenbankverbindung stehen in derselben Tabellenzeile, haben aber ein völlig unterschiedliches Risiko. Legen Sie fest, worauf ein Agent zugreifen darf, bevor Sie entscheiden, wie intelligent er sein soll, und lesen Sie wie Sie Geheimnisse von einem KI-Agenten fernhalten, bevor Sie ihm eine Zugangsdaten geben.

Außerdem sagt sie nichts darüber aus, was passiert, wenn ein Schritt fehlschlägt. Echte Agenten verbringen den Großteil ihrer Laufzeit mit der Fehlerbehandlung: mit einer Rate-Limit-Antwort oder mit einem Tool, das etwas zurückgegeben hat, was das Modell nicht erwartet hat. Dieser Code entscheidet darüber, ob Ihr System nutzbar ist. Keine Zeile der Taxonomie beschreibt ihn.

FAQ

Welche fünf Typen von KI-Agenten gibt es?

Einfache reaktive Agenten, modellbasierte reaktive Agenten, zielbasierte Agenten, nutzenbasierte Agenten und lernende Agenten. Sie sind danach geordnet, wie viel der Agent vor seiner Aktion weiß. Ein einfacher reaktiver Agent sieht nur die aktuelle Eingabe. Ein modellbasierter Agent speichert Zustandsinformationen über seine Umgebung. Ein zielbasierter Agent plant den Weg zu einem Zielzustand. Ein nutzenbasierter Agent bewertet mehrere akzeptable Ergebnisse und wählt das mit dem höchsten Wert. Ein lernender Agent ändert seine eigene Richtlinie anhand von Feedback. Das wird in praktisch keiner Self-Hosting-Umgebung tatsächlich umgesetzt.

Welchen Typ von KI-Agenten sollte ich für eine einfache Automatisierung verwenden?

Einen einfachen reaktiven Agenten. In der Praxis bedeutet das einen Webhook oder einen Zeitplan, der eine feste Abfolge auslöst. Wenn die richtige Reaktion nur von der gerade eingegangenen Eingabe abhängt, führt zusätzlicher Speicher zu weiteren Fehlerquellen, ohne neue Fähigkeiten zu bieten. Wechseln Sie zu einem modellbasierten Entwurf, sobald Sie eine Entscheidung benennen können, für die bekannt sein muss, was zuvor passiert ist.

Kann ich eigene KI-Agenten auf einem VPS betreiben?

Ja. Die Orchestrierungsschicht benötigt nur wenige Ressourcen. 2 vCPU und 4 GB RAM reichen für eine Workflow-Engine oder eine Agentenschleife problemlos aus. Die eigentliche Entscheidung betrifft den Ort, an dem das Modell ausgeführt wird. Eine gehostete API hält den Server klein und verlagert die Kosten auf Tokens. Ein lokales Modell benötigt RAM proportional zu seiner Parameteranzahl. Ohne GPU erzeugt es nur einstellige Tokenzahlen pro Sekunde. Das eignet sich eher für eingereiht verarbeitete Batch-Aufgaben als für ein Chatfenster.

Ist ein Large Language Model allein ein KI-Agent?

Nein. Ein Modell ordnet Eingabetext Ausgabetext zu und beendet seine Ausführung anschließend. Es wird zu einem Agenten, wenn etwas das Modell in eine Schleife einbindet, die Aktionen in der Außenwelt ausführen und das Ergebnis wieder zurückführen kann. Dafür benötigt die Schleife aufrufbare Tools und eine Bedingung, die ihr Ende festlegt. Der Wrapper ist der Agent. Das Modell ist eine Komponente innerhalb des Agents.

Benötige ich ein Multi-Agent-System?

Meistens nicht. Eine einzelne Schleife mit mehreren Tools erledigt die meisten Aufgaben und lässt sich wesentlich einfacher debuggen. Mehrere Agenten sind sinnvoll, wenn Teile einer Aufgabe tatsächlich unabhängig voneinander sind und gleichzeitig ausgeführt werden können oder wenn ein Teil ein anderes Modell benötigt. Der Preis dafür ist zusätzlicher Koordinationsaufwand: gemeinsamer Zustand und ein Supervisor, dessen Kontext mit jedem eingelesenen Bericht eines Workers wächst. Fügen Sie den zweiten Agenten hinzu, sobald Sie den langsamen Arbeitsschritt konkret benennen können.