KI-Agenten bauen: Tool Calling, Speicher und Loop-Muster

Die meisten Entwickler behandeln KI-Agenten wie Chatbots mit zusätzlichen Schritten. Eine Frage stellen, eine Antwort erhalten, weitermachen. Sobald Sie möchten, dass ein Agent tatsächlich etwas tut – Daten abruft, eine Datenbank aktualisiert, eine Entscheidung über mehrere Schritte hinweg trifft –, bricht dieses Modell zusammen. Hier ist Architektur wichtig und hier scheitern die meisten Implementierungen innerhalb der ersten zwei Wochen nach der Produktion.

Ein KI-Agent ist eine Schleife, kein Modell. Das Modell ist die Entscheidungsmaschine. Die Schleife ist das Betriebssystem, das entscheidet, was als Nächstes passiert.

Die Kern-Agenten-Schleife

Jeder funktionale Agent folgt diesem Muster:

1. Benutzer gibt Eingabe/Kontext an
2. LLM entscheidet, was zu tun ist (einschließlich: nichts tun)
3. Wenn das LLM eine Aktion gewählt hat:
   - Führe das Tool aus
   - Erfasse das Ergebnis
   - Gib das Ergebnis an das LLM zurück
4. Wiederhole, bis das LLM sagt: „Ich bin fertig“
5. Gib die endgültige Antwort an den Benutzer zurück

Die Schleife ist der Vertrag. Das Modell ist der Entscheidungsträger darin. Verwechseln Sie diese, und Sie werden wochenlang damit verschwenden, Prompts zu debuggen, wenn das eigentliche Problem Ihre Schleifenlogik ist.

Das habe ich bei AlgoVesta auf die harte Tour gelernt. Wir haben einen Agenten gebaut, um Marktdaten zu analysieren und Trades auszuführen. Der Prompt wurde mit 40 % Genauigkeit festgelegt – bis wir feststellten, dass die Schleife dasselbe Tool zweimal aufrief, ihm veraltete Ergebnisse aus dem ersten Aufruf zuführte und sich dann wunderte, warum der Agent schlechte Entscheidungen traf. Das Modell war in Ordnung. Die Verkabelung war kaputt.

Tool Calling: Der Vertrag zwischen LLM und Code

Tool Calling ist die Art und Weise, wie das LLM Ihrem Code mitteilt, was ausgeführt werden soll. Es ist keine Prompt-Technik. Es ist ein API-Vertrag.

Die meisten Modelle unterstützen dies jetzt nativ – Claude (über tool_use-Block), GPT-4o (über function_calling), Mistral (über tool_call). Die Namen unterscheiden sich. Das Konzept ist identisch: Das Modell gibt strukturierte Daten zurück, die besagen: „Führe dieses Tool mit diesen Parametern aus.“

So sieht eine grundlegende Tool-Definition aus:

{
  "name": "fetch_user_data",
  "description": "Ruft Benutzerkontoinformationen ab, einschließlich Guthaben und Transaktionshistorie",
  "input_schema": {
    "type": "object",
    "properties": {
      "user_id": {
        "type": "string",
        "description": "Die eindeutige Benutzerkennung"
      },
      "include_history": {
        "type": "boolean",
        "description": "Transaktionshistorie einschließen (Standard: falsch)"
      }
    },
    "required": ["user_id"]
  }
}

Die Beschreibung ist wichtig. Eine vage Beschreibung wie „Daten abrufen“ führt dazu, dass das Modell das Tool falsch verwendet. Eine spezifische Beschreibung wie „Ruft Benutzerkontoinformationen ab, einschließlich Guthaben und Transaktionshistorie“ gibt dem Modell den Kontext, um zu entscheiden, ob es dieses Tool überhaupt benötigt.

Hier ist ein reales Szenario: Wir hatten einen Agenten, der die Benutzerberechtigung prüfen sollte, bevor Entscheidungen getroffen wurden. Er rief ständig das falsche Tool auf, weil die Beschreibung generisch war. Durch die Änderung zu „Kundenberechtigung basierend auf Kontenalter, Guthaben und Transaktionsmustern validieren“ sank die Fehlerrate von 18 % auf 3 %.

Die Tool-Definition ist die Hälfte des Prompt-Engineerings. Schreiben Sie sie klar.

Speicher: Konversation oder Zustand

Hier weichen die meisten Hobbyprojekte von Produktionssystemen ab.

Konversationsspeicher (der Chatverlauf, den Sie dem Modell zurückgeben) funktioniert, bis er es nicht mehr tut. Token-Limits existieren. Claude Sonnet 4 hat 200.000 Token, aber das Einspeisen eines 6-monatigen Gesprächsverlaufs in jeden API-Aufruf verschwendet Token und verlangsamt die Inferenz. Nachdem AlgoVesta etwa 3.000 Agenteninteraktionen pro Monat erreichte, erkannten wir, dass wir Budget für Kontext verbrannten, den das Modell nicht benötigte.

Produktionsagenten benötigen zwei Speicherebenen:

Kurzzeitgedächtnis: Die aktuelle Konversation oder Aufgabe. Halten Sie sie knapp – nur die letzten 5–10 Nachrichten oder die letzten 5 Minuten der Interaktion, je nachdem, was kürzer ist.

Langzeitgedächtnis: Fakten, an die sich der Agent erinnern muss, die er aber nicht in jedem Prompt benötigt. Speichern Sie dies separat – eine Datenbank, einen Vektorspeicher oder eine strukturierte Wissensbasis – und rufen Sie es nur ab, wenn es relevant ist.

Hier ist das Muster:

1. Benutzer sendet Nachricht
2. Frage den Langzeitspeicher nach relevanten Fakten
3. Füge diese Fakten zum System-Prompt hinzu
4. Füge den aktuellen Gesprächsverlauf hinzu (letzte N Nachrichten)
5. An LLM senden
6. Wenn der Agent etwas Wichtiges gelernt hat, speichere es
7. Fahre mit dem Tool Calling fort

Für einen Handelsagenten speichern wir frühere Entscheidungen und deren Ergebnisse. Wenn der Agent entscheidet, ob er einen Handel ausführen soll, rufen wir die letzten 5 ähnlichen Trades und ihre Ergebnisse ab – nicht den gesamten Gesprächsverlauf, nur das Signal.

Dies ist eine 10-Zeilen-Änderung von „naiven Speicher“ zu „skalierbarem Speicher“. Die meisten Entwickler machen diesen Schritt nie.

Fehlerbehandlung und Wiederholungslogik

Ein Tool-Aufruf schlägt fehl. Die Datenbank war langsam. Die API gab ein Timeout zurück. Was macht der Agent?

Wenn Ihre Schleife einfach abstürzt, haben Sie ein Spielzeug gebaut. Produktionsagenten benötigen Fallback-Logik.

Minimales praktikables Muster:

for attempt in range(max_retries):

    try:

        result = execute_tool(tool_name, params)

        if result.success:

            return result

    except ToolExecutionError as e:

        if attempt == max_retries - 1:

            # Letzter Versuch fehlgeschlagen. Informiere das LLM.

            agent_message = f


📚 Related Articles

Building AI Agents: Tool Calling, Memory, and Loop Patterns