Wie funktionieren KI-Agenten? Planung, Tools und Gedächtnis

Bitten Sie einen Chatbot, „den Preis dieses Produkts in den drei größten Onlineshops zu vergleichen", liefert er entweder alte Informationen aus seinen Trainingsdaten oder sagt, dass er das nicht kann. Geben Sie dieselbe Anfrage einem KI-Agenten, zerlegt er die Aufgabe in Schritte: Er sucht die Shops, öffnet jede Produktseite, extrahiert den Preis, probiert einen anderen Weg, wo er keinen findet, und baut am Ende eine Tabelle. Hinter beiden Systemen kann dieselbe Art Sprachmodell stehen; der Unterschied entsteht durch die Schleife, die Tools und das Gedächtnis rund um das Modell.

In diesem Artikel erklären wir, was ein KI-Agent ist und wie er sich von einem Chatbot unterscheidet, die Schleife aus Wahrnehmen, Planen, Handeln und Bewerten, die ein Agent bei jedem Schritt wiederholt, und wie Planung, Tool-Nutzung (Function Calling) und Gedächtnis funktionieren. Danach behandeln wir, wie Agenten ins Web gelangen, warum sie Fehler machen und wie Sie entscheiden, ob eine Aufgabe einen Agenten oder einen vorab festgelegten Workflow braucht.

Was ist ein KI-Agent und wie unterscheidet er sich von einem Chatbot?#

Ein Chatbot erzeugt pro Nachricht eine Antwort. Er kann sich an den Gesprächsverlauf erinnern, startet aber keine Aktion von sich aus und prüft nicht das Ergebnis einer Aufgabe, um einen neuen Schritt zu gehen. Sie fragen, er antwortet.

Ein KI-Agent arbeitet auf ein Ziel hin und entscheidet selbst, welche Schritte er dafür geht. Der Artikel Building effective agents von Anthropic zieht die Grenze so: Systeme, die ein Sprachmodell und Tools über vorab im Code festgelegte Pfade verbinden, sind Workflows; Systeme, in denen das Modell seinen eigenen Ablauf und seine Tool-Nutzung dynamisch steuert, sind Agenten.

Wie funktioniert die Agentenschleife?#

Das treffendste Modell für die Arbeitsweise eines Agenten ist die Wiederholung einer einzigen Schleife. Die Schleife läuft, bis das Ziel erreicht oder eine Abbruchbedingung erfüllt ist.

1. Wahrnehmen. Der Agent sammelt die aktuelle Lage: das Ziel des Nutzers, den Gesprächsverlauf, die Ergebnisse früherer Schritte und aus dem Gedächtnis abgerufene Informationen. All das kommt in das Kontextfenster des Modells.
2. Planen. Anhand dieses Kontexts wählt das Modell die nächste Aktion. Mal ein einzelner Schritt wie „Ich sollte zuerst suchen", mal ein Plan aus mehreren Schritten.
3. Handeln. Das Modell erzeugt einen Tool-Aufruf: Es schreibt in einem strukturierten Format, welches Tool es mit welchen Parametern ausführen will. Die Anwendung führt den Aufruf tatsächlich aus.
4. Bewerten. Das Ergebnis des Tools geht zurück an das Modell. Das Modell prüft, ob das Ergebnis es dem Ziel näherbringt: Sind die erwarteten Daten gekommen, ist ein Fehler aufgetreten, sollte sich der Plan ändern?
5. Wiederholen oder abschließen. Ist das Ziel erreicht, erzeugt das Modell die endgültige Antwort. Wenn nicht, geht die Schleife zurück zu Schritt eins. Abbruchbedingungen wie eine maximale Schrittzahl, ein Budgetlimit oder eine Nutzerfreigabe verhindern, dass die Schleife endlos läuft.

Eine der meistzitierten Beschreibungen dieser Schleife ist das 2022 veröffentlichte ReAct-Paper. Es zeigt, dass ein Modell, das zwischen „Reasoning" (Begründungstext) und „Acting" (Tool-Aufrufen) abwechselt, bessere Ergebnisse liefert als Ansätze, die nur auf Begründen oder nur auf Handeln setzen. Die meisten heutigen Agenten-Frameworks nutzen eine Variante dieser Idee.

Das folgende Gerüst zeigt die Schleife anbieterunabhängig. Die Funktion call_model wird durch die API des genutzten Modells ersetzt:

MAX_STEPS = 10

def run_agent(goal, tools, call_model):
    messages = [{"role": "user", "content": goal}]
    for step in range(MAX_STEPS):
        reply = call_model(messages, tools)          # planen
        messages.append(reply.as_message())
        if not reply.tool_calls:                      # kein Tool angefordert: Aufgabe erledigt
            return reply.text
        for call in reply.tool_calls:                 # handeln
            try:
                result = tools[call.name](**call.arguments)
            except Exception as exc:                  # Fehler an das Modell zurückgeben
                result = f"Tool-Fehler: {exc}"
            messages.append({"role": "tool", "tool_call_id": call.id, "content": str(result)})
        # die Bewertung erfolgt beim nächsten call_model-Aufruf
    return "Schrittlimit erreicht, die Aufgabe konnte nicht abgeschlossen werden."

Zwei kritische Details der Schleife lassen sich am Code ablesen: Tool-Fehler bringen das Programm nicht zum Absturz, sondern gehen an das Modell zurück, damit es einen anderen Weg versuchen kann; und es gibt immer eine Abbruchbedingung wie MAX_STEPS.

Wie funktioniert die Planung?#

Planung bedeutet, dass der Agent ein großes Ziel in ausführbare Schritte zerlegt. Verbreitete Ansätze:

• Schritt für Schritt (ReAct-Stil): Das Modell wählt in jeder Schleife nur die nächste Aktion. Das ist flexibel, weil das Ergebnis jedes Schritts den nächsten beeinflusst. Bei langen Aufgaben droht es, den Faden zu verlieren.
• Erst planen, dann ausführen: Das Modell erstellt zu Beginn einen vollständigen Plan und arbeitet die Schritte dann der Reihe nach ab. Das ist effizient, wenn die Aufgabe vorhersehbar ist; bei einem unerwarteten Ergebnis muss der Plan neu erstellt werden.
• Aufgabenzerlegung: Ein Hauptagent teilt die Aufgabe in Teilaufgaben und übergibt jede an einen eigenen Unteragenten oder einen eigenen Modellaufruf. Das wird für parallele Recherchearbeit genutzt.
• Selbstbewertung (Reflection): Das Modell kritisiert das erzeugte Ergebnis in einem eigenen Schritt und korrigiert es bei Bedarf. Die Qualität steigt, doch jede Bewertung bedeutet zusätzliche Kosten und Latenz.

Welcher Ansatz passt, hängt von der Struktur der Aufgabe ab. Für eine Aufgabe, deren Schritte weitgehend vorab bekannt sind, eignet sich Planung zu Beginn; für eine Recherche, bei der das Ergebnis jedes Schritts den nächsten bestimmt, der schrittweise Ansatz.

Wie funktioniert die Tool-Nutzung (Function Calling)?#

Ein Sprachmodell kann von sich aus keine Webseite öffnen, keine Datenbank abfragen und keine Datei schreiben. Damit es das kann, gibt die Anwendung dem Modell Tool-Definitionen. Will das Modell ein Tool nutzen, erzeugt es statt Klartext einen strukturierten Aufruf, der dem Schema des Tools folgt. Die Function-Calling-Dokumentation von OpenAI und die entsprechenden Dokumentationen anderer Anbieter beschreiben diesen Ablauf nach derselben Logik.

Eine Tool-Definition hat drei Teile: einen Namen, eine Beschreibung, die dem Modell den Zweck des Tools erklärt, und eine Definition der Parameter in JSON Schema. Ein Tool, das den Preis von einer Produktseite holt, könnte etwa so definiert sein:

{
  "name": "get_product_price",
  "description": "Öffnet die angegebene Produktseiten-URL und liefert den dort angezeigten Preis und die Währung. Nur für URLs erlaubter Domains nutzen.",
  "input_schema": {
    "type": "object",
    "properties": {
      "url": {
        "type": "string",
        "description": "Die vollständige Adresse der Produktseite, beginnend mit https://"
      },
      "country": {
        "type": "string",
        "enum": ["TR", "DE", "US"],
        "description": "Aus welchem Land der Preis gesehen werden soll"
      }
    },
    "required": ["url"]
  }
}

Der Feldname für das Parameterschema variiert je Anbieter; manche APIs nutzen input_schema, andere parameters. Die Logik ist dieselbe.

Der Ablauf eines Tool-Aufrufs:

1. Die Anwendung sendet die Anfrage des Nutzers und die Tool-Definitionen an das Modell.
2. Hält das Modell das Tool für nötig, liefert es einen Aufruf mit dem Namen get_product_price und Argumenten wie {"url": "https://...", "country": "TR"}.
3. Die Anwendung empfängt den Aufruf, prüft die Argumente und führt das Tool in ihrem eigenen Code aus.
4. Das Ergebnis des Tools ({"price": "...", "currency": "TRY"} oder eine Fehlermeldung) geht zurück an das Modell.
5. Das Modell nutzt das Ergebnis, um entweder ein neues Tool aufzurufen oder dem Nutzer zu antworten.

Der wichtigste Punkt ist Schritt drei: Das Tool führt immer die Anwendung aus. Das Modell fordert die Ausführung nur an. Deshalb liegen Autorisierung, Validierung und Sicherheitsprüfungen in der Verantwortung des Codes, der das Tool ausführt, nicht des Modells. Deshalb müssen Tool-Beschreibungen auch klar sein: Das Modell nutzt ein Tool nur so korrekt, wie es dieses aus der Beschreibung versteht.

MCP, das Protokoll, mit dem Tools standardisiert zwischen verschiedenen Anwendungen geteilt werden, erklären wir in Was ist MCP (Model Context Protocol)?.

Gedächtnis: kurzfristig und langfristig#

Sprachmodelle erinnern sich von sich aus an nichts von einem Aufruf zum nächsten. Das „Gedächtnis" eines Agenten ist schlicht das, was die Anwendung dem Modell bei jedem Aufruf mitgibt.

Das Kurzzeitgedächtnis ist das Kontextfenster: das Ziel des Nutzers, der Gesprächsverlauf, Tool-Aufrufe und ihre Ergebnisse. Je länger die Schleife läuft, desto voller wird dieses Fenster. Nähert sich das Limit des Kontextfensters, wählt die Anwendung meist einen dieser Wege:

• Ältere Schritte zusammenfassen und Details verwerfen.
• Große Tool-Ausgaben (etwa eine ganze HTML-Seite) kürzen oder nur den benötigten Teil behalten.
• Nur das Ergebnis abgeschlossener Teilaufgaben behalten.

Das Langzeitgedächtnis liegt außerhalb des Kontextfensters, in einer Datenbank, einer Datei oder einem Vektorspeicher. Der Agent ruft Informationen bei Bedarf mit einem Tool aus diesem Speicher ab. Nutzerpräferenzen, aus früheren Aufgaben gelernte Informationen und große Dokumentsammlungen werden so gespeichert.

Wie gelangt ein Agent ins Web?#

Die meisten Agenten, die aktuelle Informationen brauchen, erreichen das Web auf einem von drei Wegen:

• Such-API. Der Agent sendet eine Suchanfrage und erhält eine Liste von Titeln, Adressen und kurzen Auszügen. Das ist schnell und günstig, zeigt aber nur Auszüge.
• HTTP-Client. Der Agent ruft eine bestimmte Adresse ab und erhält HTML oder Text der Seite. Das funktioniert gut bei statischen Seiten und liefert bei Seiten, deren Inhalt per JavaScript lädt, leere Ergebnisse.
• Browser. Der Agent steuert einen echten Browser: öffnet Seiten, klickt, füllt Formulare aus, erstellt Screenshots. Das ist der leistungsfähigste Weg, aber auch der langsamste und teuerste.

Hinter diesen Tools stehen netzwerkseitig gewöhnliche HTTP-Anfragen, und jede Regel des Web Scrapings gilt auch hier: Rate-Limits, robots.txt, Bedingungen der Website, Sitzungsverwaltung. Weil ein Agent in Sekunden Dutzende Seiten öffnen kann, zählen diese Regeln bei Agenten sogar noch mehr.

Ein Proxy sitzt in diesem Aufbau auf der Netzwerkebene und dient drei Zwecken:

• Standort: Den Agenten den Preis eines Produkts in Türkiye und in Deutschland getrennt sehen lassen.
• Ausgangskontrolle: An einer Stelle begrenzen und protokollieren, welche Domains der Agent wie schnell erreicht.
• Isolierung: Den Agentenverkehr von den Haupt-IP-Adressen des Unternehmens getrennt halten.

Wie Sie diese Ebene gestalten, samt Maßnahmen gegen Prompt Injection, erklärt Sicherer Webzugriff für LLMs: Rate-Limits und Berechtigungen. Wie Websites mit Agentenverkehr umgehen und warum Agenten gesperrt werden, behandelt Warum werden KI-Shopping-Agenten auf Websites blockiert?. Ein Beispiel, wie ein Sprachmodell strukturierte Daten aus Webseiten extrahieren kann, finden Sie in Web Scraping mit GPT-6 Astra.

Warum machen Agenten Fehler?#

Die Fehler von Agentensystemen unterscheiden sich von den Fehlern eines einzelnen Modellaufrufs, weil sich Fehler über Schritte hinweg anhäufen.

• Fehlerakkumulation. Selbst wenn jeder Schritt nur eine kleine Fehlerwahrscheinlichkeit hat, multiplizieren sich diese Wahrscheinlichkeiten über eine Aufgabe mit zehn Schritten. Wird früh die falsche Seite geöffnet, beruht jeder spätere Schritt auf falschen Daten.
• Falsche Tool-Argumente. Das Modell kann einen nicht existierenden Parameter, eine fehlerhafte Adresse oder eine erfundene ID erzeugen. Ohne Validierung auf Tool-Seite wandert der Fehler stillschweigend weiter.
• In Schleifen hängen bleiben. Dasselbe fehlschlagende Tool immer wieder mit denselben Argumenten aufrufen. Ohne Schrittlimit und Wiederholungserkennung wachsen die Kosten unkontrolliert.
• Ein volles Kontextfenster. Große Tool-Ausgaben füllen das Kontextfenster, und das Modell übersieht zunehmend die Anweisungen vom Anfang der Aufgabe.
• Ein unklares Ziel. Ein Ziel mit undefinierten Kriterien wie „Finde das passendste Produkt" lässt den Agenten nicht entscheiden, wann er aufhören soll.
• Nicht vertrauenswürdige Inhalte. Webseiten, Dokumente und E-Mails können Text enthalten, der wie Anweisungen an das Modell aussieht. Verwechselt der Agent diesen Text mit der Anfrage des Nutzers, kann er unerwartete Aktionen ausführen. Dieses Risiko heißt indirekte Prompt Injection.
• Verlorene Fehlermeldungen. Wird ein Tool-Fehler nicht klar an das Modell zurückgegeben, nimmt das Modell womöglich an, die Aufgabe sei erfolgreich abgeschlossen.

Die meisten dieser Fehler entstehen durch das Systemdesign, nicht durch das Modell, und lassen sich durch Design verringern: Tool-Argumente validieren, Schritt- und Budgetlimits setzen, Tool-Ausgaben kürzen, vor kritischen Aktionen eine menschliche Freigabe verlangen und Webinhalte als Daten statt als Anweisungen behandeln.

Workflow oder Agent?#

Agenten sind beeindruckend, aber nicht für jede Aufgabe das richtige Werkzeug. Der Artikel von Anthropic empfiehlt, mit der einfachsten Struktur zu beginnen, die die Aufgabe löst, und Komplexität nur hinzuzufügen, wenn sie einen messbaren Nutzen bringt. In der Praxis heißt das:

• Für eine Aufgabe, deren Schritte vorab bekannt sind und jedes Mal in derselben Reihenfolge ablaufen (täglich Preise von denselben 50 Seiten holen und in eine Tabelle schreiben), ist ein im Code festgelegter Workflow günstiger, schneller und vorhersagbarer. Ein Sprachmodell kann in diesem Workflow nur an einem bestimmten Schritt eingesetzt werden, etwa zum Extrahieren von Daten aus unregelmäßigem Text.
• Für eine Aufgabe, deren Schritte sich mit der Lage ändern und bei der vorab nicht klar ist, welche Quellen zu prüfen sind (Informationen über einen neuen Markt aus verstreuten Quellen zusammentragen), ist ein Agent sinnvoll.

Auch der Kosten- und Zuverlässigkeitsunterschied zwischen einer klassischen Scraping-Pipeline und einem agentenbasierten Ansatz sollte in diesem Rahmen beurteilt werden. Extraktion mit Selektoren liefert auf jeder Seite dasselbe Ergebnis; ein Agent kann sich anpassen, wenn sich die Seitenstruktur ändert, verursacht aber für jede Seite die Kosten eines Modellaufrufs.

Anwendungsfälle#

• Markt- und Wettbewerbsrecherche: Der Agent trägt Produkt-, Preis- und Kampagneninformationen aus verschiedenen Quellen zusammen und markiert Widersprüche. Den Rechercheaufbau beschreibt unsere Seite zur Marktforschung.
• Ausnahmebehandlung in einer Datenerfassungs-Pipeline: Eine klassische Scraping-Pipeline bewältigt die meisten Seiten; Seiten, auf denen Selektoren scheitern, gehen an einen Agenten. Den allgemeinen Aufbau zeigt unsere Seite zur Datenerfassung.
• Interner Wissensassistent: Der Agent durchsucht interne Dokumente, ruft die relevanten Abschnitte ab und antwortet mit Quellen.
• Softwareentwicklung: Der Agent durchsucht die Codebasis, liest Dateien, schlägt Änderungen vor und führt Tests aus.
• Vorsortierung im Kundensupport: Der Agent klassifiziert die Anfrage, fragt den Bestellstatus ab und übergibt nur bei Bedarf an einen Menschen.

Häufige Fehler#

• Einen Agenten für eine Aufgabe bauen, die ein einfacher Workflow erledigen könnte. Kosten, Latenz und Unvorhersehbarkeit steigen ohne Grund.
• Keine Abbruchbedingung setzen. Ein Agent ohne Schrittlimit, Budgetlimit oder Timeout kann unkontrollierte Kosten erzeugen.
• Kurze, vage Tool-Beschreibungen schreiben. Das Modell ruft das Tool in der falschen Situation oder mit falschen Argumenten auf.
• Tool-Argumente nicht validieren. Jeder vom Modell erzeugte Wert sollte als nicht vertrauenswürdige Eingabe gelten.
• Webinhalte als Anweisungen behandeln. Text auf einer Seite darf nicht dieselbe Autorität haben wie die Anfrage des Nutzers.
• Kritische Aktionen ohne Freigabe lassen. Unumkehrbare Aktionen wie Zahlungen, das Senden von E-Mails oder das Löschen von Daten sollten eine menschliche Freigabe verlangen.
• Regeln der Website für den Agenten aussetzen. Jede Seite, die ein Agent öffnet, unterliegt denselben Rate-Limits und Bedingungen wie eine Seite, die ein Scraper öffnet. Den rechtlichen Rahmen finden Sie in Ist Web Scraping legal?.

Entscheidungshilfe#

Häufig gestellte Fragen#

Was ist der wesentliche Unterschied zwischen einem KI-Agenten und einem Chatbot?#

Ein Chatbot erzeugt pro Nachricht eine Antwort und startet keine Aktionen von sich aus. Ein KI-Agent plant mehrere Schritte zu einem Ziel, ruft Tools auf, bewertet Ergebnisse und hält die Schleife in Gang, bis das Ziel erreicht ist.

Führt der Agent die Tools selbst aus?#

Nein. Das Modell schreibt nur in einem strukturierten Format, welches Tool es mit welchen Argumenten ausführen will. Die Anwendung, die den Agenten betreibt, führt das Tool immer aus, gibt das Ergebnis an das Modell zurück und übernimmt die Sicherheitsprüfungen.

Wo liegt das Gedächtnis eines Agenten?#

Informationen zur aktuellen Aufgabe liegen im Kontextfenster des Modells, also im Nachrichtenverlauf, der bei jedem Aufruf an das Modell geht. Informationen, die über Aufgaben hinweg bestehen sollen, speichert die Anwendung in einer Datenbank oder Datei und ruft sie bei Bedarf mit einem Tool ab.

Welche Regeln sollte ein Agent beim Erfassen von Daten auf Websites befolgen?#

Dieselben Regeln wie ein Scraper: robots.txt, Bedingungen der Website, Rate-Limits und Datenschutzgesetze. Ein KI-System zu sein, ändert diese Regeln nicht; weil es schnell arbeiten kann, ist es umso wichtiger, Limits auf Systemebene durchzusetzen.

Warum liefern Agenten für dieselbe Aufgabe unterschiedliche Ergebnisse?#

Sprachmodelle erzeugen nicht bei jedem Aufruf exakt dieselbe Ausgabe, und der Weg, den der Agent bei jedem Schritt wählt, beeinflusst den nächsten. Weil sich externe Quellen wie das Web ändern, kann dieselbe Anfrage zudem andere Daten erreichen. Für Arbeit, bei der Wiederholbarkeit zählt, passt der Workflow-Ansatz besser.

Woran erkenne ich, ob eine Aufgabe zu einem Agenten passt?#

Können Sie die Schritte der Aufgabe vorab als Ablaufdiagramm zeichnen, genügt wahrscheinlich ein Workflow. Lassen sich die Schritte erst entscheiden, wenn Zwischenergebnisse eintreffen, und ist der Nutzen dieser Flexibilität die Mehrkosten wert, ist ein Agent sinnvoll.

Fazit#

Ein KI-Agent ist ein System, in dem ein Sprachmodell eine Schleife aus Wahrnehmen, Planen, Handeln und Bewerten durchläuft, bis es ein Ziel erreicht. Planung zerlegt die Aufgabe in Schritte, Tool-Nutzung lässt das Modell in der Außenwelt handeln, und das Gedächtnis wird über das Kontextfenster und externe Speicher verwaltet. Die Tools führt immer die Anwendung aus, daher sind Berechtigungen, Validierung, Rate-Limits und menschliche Freigabe Teil des Systemdesigns. Wählen Sie einen Workflow für Aufgaben mit vorab bekannten Schritten und einen Agenten für offene Aufgaben. Um den Webzugriff Ihrer Agenten mit Standort- und Ausgangskontrolle zu steuern, sehen Sie sich unsere Proxy-Dienste an.