Wie ein konversationeller KI-Agent von innen funktioniert

Wie ein konversationeller KI-Agent von innen funktioniert (OpenClaw-Architektur)

Wie funktioniert ein konversationeller KI-Agent in der Praxis, Runde für Runde? Dieser Beitrag öffnet die Black Box von OpenClaw: vom Moment, in dem die Nachricht des Kunden auf WhatsApp eintrifft, bis zum Text, den der Agent zurückschreibt. Es wird technisch. Es lohnt sich, wenn Sie Produktarchitektur entscheiden, wenn Sie eine Lösung kaufen und die Tiefe bewerten möchten, oder wenn Sie wissen möchten, was hinter der Konversation passiert.

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

---

Warum die Architektur wichtig ist

Konversationelle Agenten, die in einer Demo zu funktionieren scheinen, aber in der Produktion zusammenbrechen, haben in der Regel eines dieser 4 Probleme:

1. Hohe Latenz — Kunde wartet 8 Sekunden auf Antwort, Konversation stirbt.
2. Unkontrollierte Halluzination — Agent erfindet Preis, Öffnungszeiten, Richtlinien.
3. Verlorener Kontext — Kunde kehrt nach 2 Tagen zurück und Agent "vergisst" alles.
4. Unkontrollierte Kosten — Jede lange Konversation füllt den Prompt und Sie zahlen ein Vermögen für Token.

Alle 4 sind Architekturentscheidungen, keine Modellbeschränkungen. OpenClaw wurde gebaut, um alle 4 zu vermeiden — und der Weg zum Verständnis ist, den Zyklus einer Runde zu betrachten.

---

Der Zyklus einer Runde (6 Phasen)

Stellen Sie sich vor, der Kunde hat gerade die Nachricht "ich möchte für Samstagmorgen buchen" gesendet. Was passiert zwischen "received" und der Antwort des Agenten?

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

Die WhatsApp-Nachricht trifft per Webhook von Meta direkt bei einem Cloudflare Worker am geografisch nächstgelegenen Point of Presence (PoP) ein. In Brasilien bedeutet dies São Paulo oder Rio, Netzwerklatenz < 20ms.

Der Worker macht drei Dinge:

1. Validiert die Signatur des Webhooks (HMAC gegen WABA-Geheimnis).
2. Identifiziert den Tenant anhand der Telefonnummer des Empfängers (Multi-Tenant nach to_number).
3. Normalisiert die Payload — Audio wird zu Transkription, Bild wird zu 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} bereit für den nächsten Schritt.

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

Der Agent benötigt 3 Kontextteile, bevor er entscheidet:

• Kürzlicher Verlauf des Gesprächs (letzte N relevante Durchgänge).
• Langzeitgedächtnis des Kunden (Präferenzen, Kaufhistorie, Notizen).
• Agentenstatus (Persona, aktivierte Skills, Regeln).

Alle kommen 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 das gesamte Gespräch in den Prompt. Der Memory Manager v2 von OpenClaw (beschrieben in unserer internen Dokumentation) wählt nur die für den aktuellen Durchgang relevanten Durchgänge aus (letzte N + N mit hoher semantischer Relevanz). Dies hält die Token-Kosten vorhersehbar, selbst bei Gesprächen mit 100+ Durchgängen.

Phase 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 Gesprächsphase erlaubt sind (nicht jeder Skill ist jederzeit verfügbar).
• Skills, die dieser Tenant aktiviert hat (Kalender erscheint nur, wenn der Tenant integriert hat).

Am Ende haben Sie eine kleine Teilmenge von Skills, die an das Modell übergeben werden — nicht die 50 möglichen, sondern nur die 4, die hier Sinn ergeben. Dies reduziert drastisch die Wahrscheinlichkeit, dass das Modell den falschen Skill aufruft.

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

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

• System Prompt = Persona des Agenten + Regeln + verfügbare Skills.
• History = in Phase 2 ausgewählte Durchgänge.
• User Message = Nachricht des aktuellen Durchgangs.

Das Modell antwortet mit einer von zwei Möglichkeiten:

• Endgültige Antwort (direkter Text für 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" }
}

Phase 5 — Ausführung mit Leitplanken (variabel, ~100-500ms)

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

1. Validiert Parameter (hat date_range das richtige Format? liegt es innerhalb der Tenant-Regeln?).
2. Prüft Berechtigung (hat dieser Agent das Recht, diesen Kalender abzufragen?).
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 zum nächsten Aufruf weitergegeben wird. Wenn die Skill fehlschlägt, weiss das Modell, dass sie fehlgeschlagen ist. Null Risiko, dass der Agent "erfindet", es gäbe einen Termin um 9h, wenn es keinen gibt.

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

Phase 6 — Antwort und Persistierung (~50ms)

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

"Ich habe Samstag um 10h und 11h. Welchen bevorzugen Sie?"

Parallel dazu führt der Worker folgendes 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 produziert hat (z.B.: "Kunde bevorzugt Samstag").
4. Gibt Observability-Event aus (Latenzmetrik, Token-Kosten, Eskalationsrate).

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

---

Wo liegt die Verteidigung gegen Halluzination

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

1. Erzwungene Source-of-truth. Faktische Daten (Preis, Zeit, Name) kommen immer von der Skill, niemals vom Modell allein.
2. Doppelte Überprüfung bei sensiblen Daten. Terminvereinbarung wird mit dem Kunden bestätigt, bevor sie persistiert wird. Zahlung wird bestätigt, bevor Zugang freigegeben wird.
3. Explizite negative Regeln. Die Persona jedes Agenten enthält "erfinde niemals X, Y, Z" — das Modell gehorcht.
4. Fallback auf Mensch. Wenn keine Skill die Frage abdeckt, sagt der Agent "lass mich das mit dem Team prüfen" und eröffnet ein Ticket — er rät nicht.

In Audits, die wir in den letzten 6 Monaten durchgeführt haben (echte Gespräche manuell überprüft), lag die Rate faktischer Halluzinationen unter 0,3% der Turns — und fast alle Fälle waren auf Konfiguration zurückzuführen (Tenant vergass, relevante Skill zu aktivieren), nicht auf Modellfehler.

---

Die Kosten pro Gespräch

Gute Architektur ist unsichtbar, bis Sie die Rechnung sehen. Da jede Runde 1-2 LLM-Aufrufe + Lookups in D1 macht, liegen die typischen Kosten pro vollständigem Gespräch (10-15 Runden) bei: