Wie KI-Agenten funktionieren: Vom LLM zur Feedback-Schleife

Eine Frage in ChatGPT einzugeben und eine Antwort zu erhalten, ist eine Sache. Einem System den Auftrag zu geben „Recherchiere die Konkurrenten meines Unternehmens, erstelle eine Vergleichstabelle und sende sie mir per E-Mail“ und mitzuerleben, wie dies automatisch in mehreren Schritten geschieht, ist eine völlig andere. Letzteres wird heute als KI-Agent bezeichnet, und um zu verstehen, wie er im Inneren funktioniert, muss man sechs Komponenten unterscheiden, die zusammen ein Modell, das nur Text vorhersagt, in etwas verwandeln, das entscheidet, handelt und seinen eigenen Kurs korrigiert.

Was ist ein KI-Agent?

Ein KI-Agent ist ein System, das um ein LLM (Sprachmodell) herum aufgebaut ist und mehrstufige Aufgaben autonom ausführen kann, indem es selbstständig entscheidet, welche Aktion es basierend auf dem aktuellen Aufgabenstatus als Nächstes ausführt. Der Hauptunterschied zu einem gewöhnlichen Chatbot liegt nicht im zugrunde liegenden Modell – meist ist es dasselbe –, sondern in der Architektur darum herum: Gedächtnis zwischen den Schritten, ein Planungszyklus, Zugriff auf Werkzeuge und ein Wiederholungsmechanismus, bis die Aufgabe erledigt ist.

Dies verändert die Art der Arbeit, die das System leisten kann, grundlegend. Ein Chatbot beantwortet eine Frage und stoppt. Ein Agent kann recherchieren, das Ergebnis lesen, feststellen, dass Informationen fehlen, mit einem anderen Begriff erneut suchen, alles organisieren und erst dann die endgültige Antwort liefern, ohne dass der Benutzer jeden Schritt vermitteln muss.

Der Begriff ist zu einem Sammelbegriff für sehr unterschiedliche Produkte geworden: Code-Agenten, die ganze Repositories bearbeiten, Browser-Agenten, die Formulare ausfüllen und auf Schaltflächen klicken, Kundendienst-Agenten, die interne Systeme abfragen, bevor sie einen Kunden antworten. Was sie alle trotz ihres so unterschiedlichen Erscheinungsbildes gemeinsam haben, ist genau diese sechsteilige Struktur, die dieser Artikel detailliert beschreibt. Jedes Teil einzeln zu verstehen, ermöglicht es, verschiedene Produkte fair zu vergleichen, anstatt alles nur nach dem Endergebnis auf dem Bildschirm zu beurteilen.

Es lohnt sich auch abzugrenzen, was ein Agent nicht ist. Er ist kein System mit „freiem Willen“ und trifft keine Entscheidungen außerhalb des vom Entwickler festgelegten Rahmens – die verfügbaren Werkzeuge, die Iterationsgrenzen und die Erfolgskriterien werden alle im Voraus konfiguriert. Die Autonomie eines Agenten ist innerhalb dieser Grenzen real, aber die Grenzen selbst werden weiterhin von Menschen definiert.

LLM: Die Denkmotor

Das LLM ist die Komponente, die entscheidet, was als Nächstes zu tun ist, aber ein häufiges Missverständnis sollte ausgeräumt werden: Das Modell „erinnert“ sich nicht zwischen zwei Aufrufen. Jedes Mal, wenn der Agent eine Entscheidung benötigt, erstellt er einen vollständigen neuen Prompt (mit Verlauf, Werkzeugergebnissen, Anweisungen) und sendet ihn an das Modell, das zustandslos antwortet, ohne eigenes eingebautes Gedächtnis.

Was das LLM so erscheinen lässt, als würde es über mehrere Schritte hinweg „denken“, ist eine Technik namens Chain-of-Thought: Anstatt direkt zu einer Antwort zu springen, wird das Modell dazu angeregt, Zwischenschritte des Denkens offenzulegen, bevor es die endgültige Aktion beschließt. Dies verbessert die Qualität komplexer Entscheidungen erheblich, da der Prozess des „schreibend Denkens“ dem Modell hilft, wichtige logische Schritte nicht zu überspringen.

In der Praxis erfüllt das LLM innerhalb eines Agenten eine ganz bestimmte Rolle: Es betrachtet den aktuellen Zustand (was bereits getan wurde, was das Werkzeug zurückgegeben hat, was das ursprüngliche Ziel ist) und entscheidet über die nächste Aktion, sei es ein Werkzeug aufzurufen, den Benutzer um weitere Informationen zu bitten oder festzustellen, dass die Aufgabe abgeschlossen ist.

Ein Punkt, der Anfänger oft überrascht: Dasselbe Modell mit demselben Prompt kann bei verschiedenen Ausführungen leicht unterschiedliche Entscheidungen treffen. Dies liegt daran, dass die Texterzeugung in einem LLM probabilistisch und nicht deterministisch ist, gesteuert durch einen Parameter namens Temperatur. Bei Agenten, die sensible Entscheidungen treffen (z. B. Geldbewegungen oder Datenlöschungen), wird häufig eine niedrige Temperatur eingestellt, um diese Variation zu reduzieren und das Verhalten vorhersagbarer zu machen, auch wenn es nie vollständig deterministisch ist.

Es ist auch erwähnenswert, dass „das LLM“ eines Agenten selten ein einzelner Modellaufruf ist. Anspruchsvollere Systeme verwenden verschiedene Modelle für verschiedene Schritte: ein günstigeres und schnelleres Modell für einfache Routing-Entscheidungen und ein größeres, teureres Modell nur für die Schritte, die tatsächlich tiefes Denken erfordern. Diese Arbeitsteilung hilft, die Kosten zu kontrollieren, ohne die Qualität dort zu opfern, wo sie wichtig ist.

Gedächtnis

Da das Modell nichts von sich aus speichert, ist das gesamte „Gedächtnis“ eines Agenten in Wirklichkeit Kontexttechnik: die Entscheidung, was bei jedem Aufruf wieder in den Prompt aufgenommen wird. Es gibt praktisch zwei Arten:

• Kurzzeitgedächtnis: der Verlauf des aktuellen Gesprächs oder der aktuellen Ausführung, der in das Kontextfenster des Modells passt. Es wächst mit jedem Schritt des Agenten und muss bei langen Aufgaben möglicherweise zusammengefasst werden, um das Token-Limit nicht zu überschreiten.
• Langzeitgedächtnis: Informationen, die über eine einzelne Ausführung hinaus bestehen bleiben müssen, werden außerhalb des Modells in einer Datenbank, einer Datei oder einem Vektorindex gespeichert und bei Bedarf abgerufen. Die häufigste Technik dafür ist RAG (Retrieval-Augmented Generation): Bevor das System antwortet, sucht es die relevantesten Abschnitte aus diesem externen Gedächtnis und fügt sie in den Prompt ein.

Ein praktisches Beispiel verdeutlicht den Unterschied: Ein Programmieragent, der den Code eines Projekts liest, speichert die aktuell geöffnete Datei als Kurzzeitgedächtnis, aber Teamkonventionen (wie „verwende immer striktes TypeScript“ oder „verwende niemals Bibliothek X“) werden normalerweise als Langzeitgedächtnis in einer Konfigurationsdatei gespeichert, die bei jeder neuen Sitzung neu geladen wird.

Das Kontextfenster eines Modells hat, so groß es auch sein mag, ein physisches Token-Limit, und jedes Token kostet Geld und Rechenzeit. Dies zwingt den Entwickler des Agenten zu ständigen Entscheidungen darüber, was es wert ist, im Kurzzeitgedächtnis behalten zu werden, und was zusammengefasst oder verworfen werden kann. Eine gängige Technik ist die progressive Komprimierung: Nach einer bestimmten Anzahl von Schritten erstellt der Agent selbst eine Zusammenfassung dessen, was bisher passiert ist, ersetzt den rohen Verlauf durch diese Zusammenfassung und setzt die Ausführung mit einem viel schlankeren Kontext fort.

Für das auf RAG basierende Langzeitgedächtnis beinhaltet der zugrunde liegende Mechanismus in der Regel eine Vektordatenbank: Jeder Informationsabschnitt wird in einen numerischen Vektor (Embedding) umgewandelt, der seine Bedeutung repräsentiert, und die Suche sucht nicht nach exakten Wörtern, sondern nach den Vektoren, die der aktuellen Frage semantisch am ähnlichsten sind. Deshalb kann ein gut konfigurierter RAG-Agent ein relevantes Dokument finden, selbst wenn es völlig andere Wörter verwendet als die, die der Benutzer eingegeben hat.

Planung

Bei einer komplexen Aufgabe löst ein Agent selten alles in einem einzigen Modellaufruf. Das heute am häufigsten verwendete Muster ist ReAct (Reasoning and Acting), veröffentlicht im Jahr 2022: Das Modell wechselt zwischen „Denken“ (Nachdenken, was zu tun ist) und „Handeln“ (Aufrufen eines Werkzeugs), wobei es das Ergebnis jeder Aktion beobachtet, bevor es die nächste entscheidet, anstatt zu versuchen, den gesamten Plan auf einmal vorherzusagen.

Es gibt auch das Muster „Plan-and-Execute“, bei dem das Modell zuerst einen vollständigen Plan mit mehreren Schritten schreibt und erst dann beginnt, diese einen nach dem anderen auszuführen. Es ist tendenziell vorhersagbarer, aber weniger flexibel: Wenn ein Schritt auf halbem Weg fehlschlägt oder neue Informationen offenbart, muss der Agent neu planen, was in diesem Design nicht immer automatisch behandelt wird.

In der Praxis mischen die meisten Produktionsagenten beide Ansätze: einen anfänglichen ungefähren Plan, der alle paar Schritte basierend auf dem, was tatsächlich passiert ist, überarbeitet wird, anstatt blind von Anfang bis Ende befolgt zu werden.

Ein konkretes Beispiel für das ReAct-Muster in Aktion: Fragen Sie einen Agenten: „Wie sind die Öffnungszeiten des nächsten Geschäfts, das Produkt X auf Lager hat?“ Ein starrer, auf einmal erstellter Plan würde wahrscheinlich scheitern, da der Agent noch nicht weiß, welche Geschäfte es gibt und welche das Produkt führen. Mit ReAct denkt das Modell zuerst („Ich muss nahegelegene Geschäfte finden“), handelt (ruft ein Ortssuchwerkzeug auf), beobachtet das Ergebnis, denkt erneut („Jetzt muss ich den Bestand jedes Geschäfts prüfen“), handelt erneut und formuliert erst dann mit ausreichenden Informationen die endgültige Antwort. Jede Entscheidung hängt vom Ergebnis der vorherigen ab, was in einem einzigen, festen Plan unmöglich vorherzusagen wäre.

Es gibt auch die Frage der Planungstiefe: Einfache Aufgaben können die explizite Planungsphase überspringen und direkt zur Werkzeugauswahl übergehen, während komplexe Aufgaben mit vielen Abhängigkeiten zwischen Teilaufgaben von einem explizit geschriebenen Plan profitieren, der manchmal sogar dem Benutzer vor Ausführungsbeginn angezeigt wird, damit er den Kurs genehmigen oder anpassen kann, bevor tatsächliche Maßnahmen ergriffen werden.

Werkzeuge

Werkzeuge geben dem Agenten die Fähigkeit, in der realen Welt zu handeln, über die reine Texterzeugung hinaus: Im Internet suchen, Code ausführen, eine Datenbank abfragen, eine E-Mail senden. Der technische Mechanismus dahinter ist das Function Calling (oder Tool Calling): Der Entwickler beschreibt jedes verfügbare Werkzeug mit Namen, Beschreibung und einem Schema der Parameter, die es akzeptiert, und das Modell gibt eine strukturierte Antwort zurück, die angibt, welches Werkzeug mit welchen Argumenten aufgerufen werden soll.

Das Modell selbst führt das Werkzeug nie aus. Es entscheidet und formatiert nur den Aufruf; wer tatsächlich den Code ausführt, die HTTP-Anfrage stellt oder die Datenbank abfragt, ist die Software um das Modell herum. Diese Trennung ist wichtig: Sie bedeutet, dass dasselbe „Gehirn“ mit völlig unterschiedlichen Werkzeugen verbunden werden kann, ohne neu trainiert werden zu müssen, indem nur die im Prompt verfügbaren Funktionen neu konfiguriert werden.

Das Model Context Protocol (ausführlich im vorherigen Artikel über MCP) löst genau den Teil der Standardisierung, wie diese Werkzeuge beschrieben und entdeckt werden, sodass ein Agent keine spezifische Integration für jeden externen Dienst benötigt, den er verwendet.

In der Praxis gruppieren sich die Werkzeuge eines Agenten in einige wiederkehrende Kategorien: Suche und Lesen von Informationen (Web, Dokumente, Datenbanken), Aktionen auf externen Systemen (E-Mail senden, Ticket erstellen, Tabelle aktualisieren), Codeausführung (Skript ausführen, SQL-Abfrage, Terminalbefehl) und Kommunikation mit dem Benutzer selbst (Bestätigung anfordern, Verständnisfrage stellen). Ein gut entworfener Agent erhält normalerweise nicht gleichzeitig Zugriff auf alle im System verfügbaren Werkzeuge, sondern nur auf die für die jeweilige Aufgabe erforderliche Teilmenge, nach dem gleichen Prinzip der geringsten Rechte, das in der Sicherheit traditioneller Systeme verwendet wird.

Die Qualität der Beschreibung jedes Werkzeugs ist wichtiger, als es scheint. Ein vager Name wie process_data mit einer einzeiligen Beschreibung führt tendenziell zu falschen oder schlecht formatierten Aufrufen, da das Modell nicht genügend Kontext hat, um zu entscheiden, wann es verwendet werden soll. Spezifische Beschreibungen mit Anwendungsbeispielen und klaren Grenzen (was das Werkzeug nicht tut) reduzieren die Fehlerrate in dieser Phase erheblich.

Ausführung

Die Ausführung ist die Softwareschicht, die oft als Laufzeit oder Orchestrator des Agenten bezeichnet wird, die die Entscheidung des LLM empfängt und tatsächlich umsetzt: die richtige API aufruft, den Befehl ausführt, auf die Antwort wartet, Fehler behandelt, falls der Aufruf fehlschlägt. Hier kommen auch die Sicherheitsschichten ins Spiel: Sandboxing für vom Modell generierten Code, Zeitlimits (Timeout) für jeden Aufruf und Validierung der Parameter vor der Ausführung von etwas Irreversiblem.

Ein Detail, das für Verwirrung sorgt: Nicht jede Ausführung ist sequentiell. Anspruchsvollere Agenten können mehrere Werkzeuge parallel auslösen, wenn sie unabhängig voneinander sind, wie z. B. gleichzeitiges Suchen in drei verschiedenen Quellen, was die Gesamtzeit der Aufgabe im Vergleich zum sequentiellen Aufrufen eines Werkzeugs nach dem anderen und Warten auf jede Antwort erheblich verkürzt.

Die Fehlerbehandlung in dieser Schicht ist das, was einen fragilen von einem zuverlässigen Agenten unterscheidet. Ein Werkzeugaufruf kann aus Dutzenden von Gründen fehlschlagen: Die externe API ist ausgefallen, die Parameter sind schlecht formatiert, die Berechtigung wurde verweigert, das Zeitlimit wurde überschritten. Ein gut konstruierter Orchestrator fängt jede Fehlerart separat ab und entscheidet, was damit zu tun ist: automatisch erneut versuchen (mit einer Begrenzung der Versuche, um einen permanenten Fehler nicht endlos zu wiederholen), den Fehler als Teil der Beobachtung an das LLM zurückgeben, damit es einen anderen Ansatz versucht, oder das Problem an einen menschlichen Eingriff eskalieren, wenn keine der automatischen Optionen das Problem löst.

Sandboxing verdient besondere Aufmerksamkeit, wenn das Werkzeug die Ausführung von vom Modell selbst generiertem Code beinhaltet. Das Ausführen dieses Codes direkt in derselben Umgebung, in der der Agent lebt, ist ein echtes Risiko, daher isolieren seriöse Implementierungen diese Ausführung in einem Container oder einer wegwerfbaren virtuellen Maschine, standardmäßig ohne Netzwerkzugriff oder Zugriff auf sensible Dateien, und geben nur das frei, was die spezifische Aufgabe tatsächlich benötigt.

Feedback-Schleife

Nachdem ein Werkzeug ausgeführt wurde, verschwindet sein Ergebnis nicht: Es kehrt in den Kontext zurück, als neue Information, die das LLM bei der nächsten Entscheidung berücksichtigen muss. Dieser Zyklus (Zustand wahrnehmen, planen, handeln, Ergebnis beobachten, Kontext aktualisieren) wiederholt sich so oft wie nötig, bis eines von zwei Dingen eintritt: Das Modell entscheidet, dass die Aufgabe abgeschlossen ist, oder der Agent erreicht eine Sicherheitsgrenze, wie eine maximale Anzahl von Iterationen oder eine Gesamtausführungszeit.

Diese Iterationsgrenze ist kein nebensächliches Detail. Ohne sie könnte ein schlecht konfigurierter Agent in eine Schleife geraten, in der er dieselbe Aktion wiederholt, ohne die Aufgabe jemals als abgeschlossen zu betrachten, und dabei unbegrenzt Tokens (und Geld) verbrauchen. Aus diesem Grund enthält praktisch jedes seriöse Agenten-Framework eine Art Sicherung: einen maximalen Schrittzähler, eine explizite Prüfung der Erfolgskriterien oder die Anforderung einer menschlichen Bestätigung nach einer bestimmten Anzahl von Versuchen ohne Fortschritt.

Es ist wichtig, zwei Arten des Anhaltens zu unterscheiden. Das „glückliche“ Anhalten erfolgt, wenn das LLM den aktuellen Zustand mit dem ursprünglichen Ziel vergleicht und explizit zu dem Schluss kommt, dass alle Kriterien erfüllt sind. Das Anhalten aufgrund einer Grenze erfolgt, wenn der Agent die Anzahl der Iterationen oder das erlaubte Zeit-/Kostenbudget erschöpft hat, ohne das Ziel zu erreichen. In diesem Fall besteht das erwartete Verhalten nicht darin, einfach zu blockieren, sondern dem Benutzer zu berichten, was bis zu diesem Punkt getan wurde und warum die Aufgabe nicht allein abgeschlossen werden konnte.

Ein immer häufigeres Muster in Produktionssystemen ist der Human-in-the-Loop: Für risikoreiche Aktionen (Geld bewegen, Daten löschen, eine öffentliche Kommunikation senden) enthält die Feedback-Schleife eine obligatorische Pause, die auf die menschliche Genehmigung wartet, bevor zur nächsten Iteration übergegangen wird, selbst wenn der Agent bereits allein entschieden hat, dass dies die richtige Aktion ist.

Der vollständige Kreislauf im Diagramm

Wenn man die sechs Teile zusammensetzt, ergibt sich der Kreislauf eines KI-Agenten wie folgt:

Der zentrale Punkt dieser Darstellung ist, dass der Rückwärtspfeil kein ästhetisches Detail ist: Er unterscheidet einen Agenten von einem einfachen automatisierten Ablauf mit festen Schritten. Der Agent entscheidet bei jeder Runde des Kreislaufs, ob er fortfahren muss oder ob er das Ziel bereits erreicht hat.

Chatbot vs. Agent

Ein direkter Vergleich lohnt sich, da die Grenze zwischen beiden für den Endbenutzer nicht immer offensichtlich ist:

Aspekt	Traditioneller Chatbot	KI-Agent
Struktur der Antwort	Eine Frage, eine Antwort	Mehrere verkettete Schritte bis zur Zielerreichung
Zugriff auf Werkzeuge	Selten oder gar nicht	Zentral, via Function Calling oder MCP
Gedächtnis zwischen Schritten	Nur der Verlauf des aktuellen Gesprächs	Kurz- und Langzeit, oft mit externer Suche (RAG)
Entscheidungsautonomie	Gering, der Benutzer führt jeden Austausch	Hoch, das System entscheidet selbst über die nächsten Schritte
Abbruchkriterium	Ende der generierten Nachricht	Erfolgskriterium der Aufgabe oder Iterationsgrenze

In der Praxis ist die Grenze ein Spektrum, keine scharfe Linie: Viele Produkte sind heute Chatbots mit einigen einfachen eingebundenen Werkzeugen, ohne einen vollständigen Planungszyklus zu haben. Der Begriff „Agent“ wird tendenziell für Systeme reserviert, die ihre eigenen nächsten Schritte tatsächlich entscheiden, nicht nur eine Funktion ausführen, wenn der Benutzer explizit darum bittet.

Ein praktischer Test, um die beiden bei der Bewertung eines Produkts zu unterscheiden: Bitten Sie um eine Aufgabe, die mindestens drei voneinander abhängige Schritte erfordert, ohne den genauen Ablauf zu erläutern, nur das gewünschte Ergebnis. Ein Chatbot neigt dazu, weitere Anweisungen zu verlangen oder zu versuchen, alles in einer einzigen, oberflächlichen Antwort zu erledigen. Ein echter Agent zerlegt die Anfrage in Teilaufgaben, verwendet Werkzeuge, um jede zu lösen, und liefert das Endergebnis erst nach Abschluss des gesamten Kreislaufs von selbst aus.

Vollständiges Beispiel

Um dies konkret zu machen, lohnt es sich, einen hypothetischen Marktforschungsagenten zu begleiten, der den Auftrag erhält: „Recherchiere die 3 wichtigsten Konkurrenten meines Unternehmens in Brasilien und sende mir eine Zusammenfassung per E-Mail.“

Schritt 1, Planung: Das LLM zerlegt den Auftrag in Teilaufgaben: Konkurrenten suchen, Daten zu jedem sammeln, zu einer Zusammenfassung synthetisieren, per E-Mail senden. Dieser anfängliche Plan wird im Kurzzeitgedächtnis der Ausführung gespeichert.

Schritt 2, erstes Werkzeug: Der Agent ruft ein Websuchwerkzeug mit der Abfrage „wichtigste Konkurrenten [Unternehmen] Brasilien“ auf. Das Ergebnis (eine Liste von Namen und Links) kehrt als Beobachtung zurück.

Schritt 3, Feedback und Neuplanung: Das LLM stellt fest, dass die Suche 5 Namen zurückgegeben hat, aber nur 3 benötigt werden. Es filtert die relevantesten heraus und entscheidet, für jeden ein neues Werkzeug aufzurufen, das grundlegende öffentliche Daten extrahiert (Größe, Hauptprodukte, Marktpräsenz).

Schritt 4, parallele Ausführung: Da die drei Konkurrenten unabhängig voneinander sind, löst der Orchestrator die drei Extraktionsaufrufe gleichzeitig aus, anstatt nacheinander, was Zeit spart.

Schritt 5, Synthese: Mit den drei Datensätzen im Kurzzeitgedächtnis generiert das LLM den Text der vergleichenden Zusammenfassung, bereits formatiert.

Schritt 6, letztes Werkzeug: Der Agent ruft das E-Mail-Sendewerkzeug auf und übergibt die generierte Zusammenfassung als Nachrichtentext.

Schritt 7, Abschluss: Das LLM beobachtet die Sendebestätigung, überprüft, ob alle Punkte des ursprünglichen Plans erfüllt sind, und beendet den Kreislauf, indem es dem Benutzer mitteilt, dass die Aufgabe abgeschlossen ist.

Beachten Sie, dass der Benutzer zu keinem Zeitpunkt zwischen den Schritten eingreifen musste. Dies ist nur möglich, weil jedes der sechs Teile (LLM, Gedächtnis, Planung, Werkzeuge, Ausführung, Feedback-Schleife) genau die in den vorherigen Abschnitten beschriebene Rolle gespielt hat.

FAQ

Benötigt ein KI-Agent immer ein Langzeitgedächtnis?

Nein. Einfache Aufgaben, die in einer einzigen Sitzung gelöst werden, können nur mit Kurzzeitgedächtnis (dem Verlauf der aktuellen Ausführung) funktionieren. Langzeitgedächtnis ist wichtig, wenn der Agent sich an etwas zwischen verschiedenen Ausführungen erinnern muss.

Wie viele Iterationen führt ein Agent normalerweise durch, bevor er anhält?

Das variiert stark mit der Komplexität der Aufgabe und der Konfiguration des verwendeten Frameworks, aber die meisten Produktionssysteme legen eine explizite Grenze fest, in der Regel zwischen 5 und 25 Iterationen, um Endlosschleifen zu vermeiden.

Ist ein Chatbot mit Plugins bereits ein Agent?

Das hängt davon ab, wie viel Autonomie er hat. Wenn der Benutzer jede Aktion explizit anfordern muss, ist es eher ein Chatbot mit Werkzeugen. Wenn das System selbstständig die Reihenfolge der zur Erfüllung eines Ziels erforderlichen Aktionen bestimmt, ist dies bereits Agentenverhalten.

Was passiert, wenn ein Werkzeug mitten in der Ausführung fehlschlägt?

Das hängt vom Orchestrator ab. Robuste Implementierungen geben den Fehler als Teil der Beobachtung zurück, und das LLM entscheidet, ob es erneut versucht, einen anderen Ansatz versucht oder den Fehler dem Benutzer meldet, anstatt den gesamten Kreislauf zu blockieren.

Kann ein Agent mehr als ein LLM gleichzeitig verwenden?

Ja, und das wird immer üblicher. Ein kleineres, günstigeres Modell kann einfache Routing-Entscheidungen übernehmen, während ein größeres Modell nur bei Schritten zum Einsatz kommt, die tieferes Denken erfordern. Dies hilft, die Gesamtkosten der Ausführung zu kontrollieren, ohne die Qualität in den wichtigsten Teilen zu beeinträchtigen.

Vom Jargon befreit, ist ein KI-Agent keine isolierte neue Technologie, sondern eine spezifische Art, bereits bekannte Teile (ein Sprachmodell, eine Art Gedächtnis, Zugriff auf Werkzeuge) in einem Kreislauf zu organisieren, der sich wiederholt, bis ein Ziel erreicht ist. Diese sechs Teile einzeln zu verstehen, ermöglicht es zu diagnostizieren, warum ein bestimmter Agent versagt, in einer Schleife stecken bleibt oder ein unvollständiges Ergebnis liefert, anstatt das gesamte System als Blackbox zu behandeln.