Wie ein konversationeller KI-Agent von innen funktioniert

Wie ein KI-Konversationsagent von innen funktioniert (OpenClaw-Architektur)

Wie funktioniert ein KI-Konversationsagent in der Praxis, Schritt für Schritt? Dieser Beitrag öffnet die Blackbox von OpenClaw: vom Moment, in dem die Kundennachricht auf WhatsApp eintrifft, bis zum Text, den der Agent zurückschreibt. Es wird technisch. Es lohnt sich, wenn Sie über Produktarchitektur entscheiden, wenn Sie eine Lösung kaufen und das Fundament bewerten wollen, oder wenn Sie einfach gerne wissen, was hinter dem Gespräch passiert.

TL;DR: Jeder Turn durchläuft 6 Phasen — Ingest, Kontext auflösen, Skills auswählen, nächste Aktion entscheiden, mit Guard-Rails ausführen, Gedächtnis persistieren. Der gesamte Zyklus läuft in <2 Sekunden am Cloudflare-Edge, ohne festen Server.

---

Warum die Architektur wichtig ist

Ein Konversationsagent, der in einer Demo zu funktionieren scheint, aber in der Produktion versagt, hat in der Regel eines dieser 4 Probleme:

1. Hohe Latenz — der Kunde wartet 8 Sekunden auf eine Antwort, das Gespräch stirbt.
2. Unkontrollierte Halluzination — der Agent erfindet Preise, Uhrzeiten, Richtlinien.
3. Verlorener Kontext — der Kunde kommt nach 2 Tagen zurück und der Agent „vergisst" alles.
4. Unkontrollierte Kosten — jedes lange Gespräch füllt den Prompt und Sie zahlen ein Vermögen an Token.

Alle 4 sind Architekturentscheidungen, keine Einschränkungen des Modells. OpenClaw wurde gebaut, um alle 4 zu vermeiden — und der Weg zum Verständnis führt über den Zyklus eines Turns.

---

Der Zyklus eines Turns (6 Phasen)

Stellen Sie sich vor, der Kunde hat gerade die Nachricht "quero marcar pra sábado de manhã" gesendet. Was passiert zwischen dem „received" und der Antwort des Agenten?

Phase 1 — Ingest (Edge Worker, <50ms)

Die WhatsApp-Nachricht kommt über den Meta-Webhook direkt bei einem Cloudflare Worker am geografisch nächstgelegenen Point of Presence (PoP) an. In Brasilien bedeutet das São Paulo oder Rio, Netzwerklatenz < 20ms.

Der Worker erledigt drei Dinge:

1. Validiert die Signatur des Webhooks (HMAC gegen das WABA-Secret).
2. Identifiziert den Tenant anhand der Telefonnummer des Empfängers (Multi-Tenant über to_number).
3. Normalisiert den Payload — Audio wird zur Transkription, Bild wird zur Beschreibung, Standort wird zu {lat,lng}, Text bleibt wie er ist.

Am Ende von Phase 1 haben Sie ein Objekt {tenant_id, conversation_id, user_message}, das für den nächsten Schritt bereit ist.

Phase 2 — Kontext auflösen (D1 + KV, ~80ms)

Der Agent braucht 3 Kontextbausteine, bevor er entscheiden kann:

• Aktueller Verlauf der Konversation (letzte N relevante Turns).
• Langzeitgedächtnis des Kunden (Präferenzen, Kaufhistorie, Notizen).
• Agentenstatus (Persona, aktivierte Skills, Regeln).

Alles kommt aus D1 (Cloudflares verteiltes SQLite). D1 ersetzt traditionelles Postgres/Mongo — kein Datenbankserver zu warten, Zugriff in wenigen ms vom Worker aus, Multi-Tenant über tenant_id.

Kernpunkt: Wir laden nicht die gesamte Konversation in den Prompt. Der Memory Manager v2 von OpenClaw (beschrieben in unserer internen Dokumentation) wählt nur die für den aktuellen Turn relevanten Turns aus (letzte N + N mit hoher semantischer Relevanz). Das hält die Token-Kosten vorhersehbar, selbst bei Konversationen mit über 100 Turns.

Stufe 3 — Skill-Auswahl (Policy Engine, ~20ms)

Jeder Agent hat eine Reihe verfügbarer Skills — Funktionen, die er aufrufen kann. Beispiele: consultar_calendario, criar_evento, gerar_link_pagamento, consultar_pedido, chamar_humano.

Bei der Nachricht "quero marcar pra sábado de manhã" filtert die Policy Engine:

• Skills, die mit der erkannten Absicht kompatibel sind (Terminplanung).
• Skills, die für diese Konversationsphase erlaubt sind (nicht jeder Skill ist jederzeit verfügbar).
• Skills, die dieser Tenant aktiviert hat (Kalender erscheint nur, wenn der Tenant ihn integriert hat).

Am Ende hat man eine kleine Teilmenge von Skills, die dem Modell übergeben wird — nicht die 50 möglichen, sondern nur die 4, die hier Sinn ergeben. Das reduziert drastisch die Wahrscheinlichkeit, dass das Modell einen falschen Skill aufruft.

Stufe 4 — Entscheidung (LLM-Aufruf, 400–1200ms)

Jetzt kommt das Modell ins Spiel. OpenClaw macht einen einzelnen Aufruf an ein Frontier-LLM (Anthropic Claude, OpenAI GPT, Google Gemini — pro Tenant konfigurierbar) mit:

• System-Prompt = Persona des Agenten + Regeln + verfügbare Skills.
• History = in Stufe 2 ausgewählte Turns.
• User Message = Nachricht des aktuellen Turns.

Das Modell antwortet mit einer von zwei Möglichkeiten:

• Endgültige Antwort (Text direkt an den Kunden).
• Tool Call (Anfrage zur Ausführung eines bestimmten Skills mit Parametern).

Im Beispiel "quero marcar pra sábado de manhã" gibt das Modell typischerweise zurück:

{
  "tool": "consultar_calendario",
  "args": { "date_range": "2026-04-19 06:00 to 12:00" }
}

Stufe 5 — Ausführung mit Guard-Rails (variabel, ~100–500ms)

Der Skill läuft nicht im Modell. Er läuft in unserem eigenen Code, der:

1. Validiert Parameter (hat date_range das richtige Format? Liegt es innerhalb der Regeln des Tenants?).
2. Prüft Berechtigung (darf dieser Agent diesen Kalender abfragen?).
3. Führt den Aufruf aus (Google Calendar API in diesem Fall).
4. Gibt strukturiertes Ergebnis an das Modell zurück.

Warum ist das wichtig? Weil das Modell niemals das Ergebnis erfindet. Wenn der Kalender [10h, 11h] zurückgibt, ist es genau das, was in den nächsten Aufruf geht. Wenn der Skill fehlschlägt, weiß das Modell, dass er fehlgeschlagen ist. Null Risiko, dass der Agent „erfindet", dass um 9 Uhr ein Termin frei ist, wenn das nicht der Fall ist.

Für Fälle, die sensible Informationen betreffen (Preis, Frist, Kundenname), erzwingt die Pipeline einen tool call — sie lässt das Modell nicht aus eigenem „Wissen" antworten. Das eliminiert die häufigste Klasse von Halluzinationen bei kommerziellen Agenten.

Stufe 6 — Antwort und Persistierung (~50ms)

Mit dem Ergebnis des Skills in der Hand macht das Modell den zweiten Aufruf — diesmal um die endgültige Antwort für den Kunden zu formulieren. Z.B.:

"Ich habe Samstag um 10 Uhr und 11 Uhr. Was bevorzugen Sie?"

Parallel dazu führt der Worker folgende Schritte aus:

1. Sendet die Nachricht über die WhatsApp-API zurück.
2. Persistiert den vollständigen Turn (user + assistant + tool calls + Dauer) in D1.
3. Aktualisiert das Langzeitgedächtnis, wenn der Turn eine neue Tatsache hervorgebracht hat (z.B.: „Kunde bevorzugt Samstag").
4. Emittiert ein Observability-Event (Latenz-Metrik, Token-Kosten, Eskalationsrate).

All das läuft parallel. Die Persistierung blockiert nicht das Senden der Nachricht — der Kunde wartet nicht auf D1.

---

Wo die Verteidigung gegen Halluzination steckt

Ein Agent, der in Produktion halluziniert, verliert schnell das Vertrauen. OpenClaw hat 4 Verteidigungslinien:

1. Erzwungene Source-of-Truth. Faktische Daten (Preis, Uhrzeit, Name) kommen immer vom Skill, nie vom Modell allein.
2. Doppelte Überprüfung bei sensiblen Daten. Terminbuchungen werden mit dem Kunden bestätigt, bevor sie persistiert werden. Zahlungen werden bestätigt, bevor der Zugang freigegeben wird.
3. Explizite Negativregeln. Die Persona jedes Agenten enthält „erfinde niemals X, Y, Z" — das Modell gehorcht.
4. Fallback auf einen Menschen. Wenn kein Skill die Frage abdeckt, sagt der Agent "Lassen Sie mich das mit dem Team abklären" und eröffnet ein Ticket — er rät nicht.

Bei Audits, die wir in den letzten 6 Monaten durchgeführt haben (echte Konversationen, manuell überprüft), lag die Rate faktischer Halluzinationen unter 0,3 % der Turns — und fast alle Fälle waren konfigurationsbedingt (Tenant hat vergessen, den relevanten Skill zu aktivieren), kein Modellfehler.

---

Die Kosten pro Konversation

Gute Architektur ist unsichtbar, bis man die Rechnung ansieht. Da jeder Turn 1–2 LLM-Aufrufe + Lookups in D1 macht, liegen die typischen Kosten pro vollständiger Konversation (10–15 Turns) bei: