Wie funktioniert ein IA-Agent durchsichtig?

Wie Funktioniert ein KI-gestützter Konversationsagent von Innen (OpenClaw-Architektur)

Wie funktioniert ein KI-gestützter Konversationsagent in der Praxis, Schritt für Schritt? Dieser Beitrag öffnet die Schleusung des OpenClaw: vom Moment, in dem die Nachricht des Kunden auf WhatsApp eintrifft, bis zum Text, den der Agent zurück schreibt. Es wird technisch sein. Es lohnt sich, wenn Sie Produktarchitektur planen, eine Lösung kaufen und die Grundlagen verstehen wollen, oder wenn Sie gerne wissen, was hinter der Konversation passiert.

TL;DR: Jeder Schritt geht durch 6 Phasen – Eingabe, Kontextauflösung, Skill-Auswahl, nächste Aktion, Ausführung mit Sicherheitsmechanismen, Speicherung von Informationen. Der gesamte Zyklus läuft in <Sekunden auf der Edge-Cloud von Cloudflare, ohne festen Server.

---

Warum die Architektur wichtig ist

Ein Konversationsagent, der in einem Demo funktioniert, aber in der Produktion bricht, hat eines der folgenden 4 Probleme:

1. Hohe Latenz – Der Kunde wartet 8 Sekunden auf eine Antwort, die Konversation stirbt.
2. Unkontrollierte Alukination – Der Agent erfindet Preise, Zeiten oder Politiken.
3. Verlorenes Kontext – Der Kunde kehrt nach 2 Tagen zurück und der Agent "vergisst" alles.
4. Unkontrollierter Kosten – Jede lange Konversation füllt den Prompt und Sie zahlen eine hohe Menge an Token.

Die 4 sind Auswahlmöglichkeiten der Architektur, keine Einschränkungen des Modells. Der OpenClaw wurde entwickelt, um die 4 zu vermeiden – und der Weg, um es zu verstehen, ist, den Zyklus eines Schritts zu betrachten.

---

Der Zyklus eines Schritts (6 Phasen)

Stellen Sie sich vor, der Kunde hat gerade die Nachricht "Ich möchte am Samstag morgen buchen" gesendet. Was passiert zwischen dem "Empfang" und der Antwort des Agents?

Phase 1 – Eingabe (Edge-Worker, <ms)

Die Nachricht von WhatsApp trifft über einen Webhook der Meta direkt in einen Cloudflare-Worker am nächstgelegenen Standort (PoP). In Brasilien bedeutet das São Paulo oder Rio, Netzwerklatenz <0ms.

Der Worker macht drei Dinge:

1. Validiert die Signatur des Webhooks (HMAC gegen den geheimen WABA-Schlüssel).
2. Identifiziert den Tenant durch den Telefonnummer des Empfängers (multi-Tenant durch to_number).
3. Normalisiert den Payload – Audio wird in eine Transkription, Bild wird in eine Beschreibung, Standort wird in {lat,lng}, Text bleibt wie er ist.

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

Phase 2 – Kontextauflösung (D1 + KV, ~80ms)

Der Agent benötigt 3 Teile des Kontexts, bevor er entscheidet:

1. Tenant-Informationen – Informationen über den Kunden, wie z.B. sein Name, seine E-Mail-Adresse oder seine Telefonnummer.
2. Konversationshistorie – Informationen über die vorherigen Nachrichten im Gespräch, wie z.B. die letzte Nachricht, die der Kunde gesendet hat.
3. Aktuelle Situation – Informationen über die aktuelle Situation, wie z.B. derzeitige Uhrzeit, Datum oder Standort.

Der Agent verwendet diese Informationen, um den Kontext des Gesprächs zu verstehen und die nächste Aktion zu bestimmen.

Phase 3 – Skill-Auswahl (D1 + KV, ~80ms)

Der Agent wählt die geeignete Skill (Fähigkeit) aus, um die nächste Aktion auszuführen. Die Skill-Auswahl basiert auf den Informationen, die der Agent in der Phase 2 erhalten hat.

Phase 4 – Nächste Aktion (D1 + KV, ~80ms)

Der Agent bestimmt die nächste Aktion, die er ausführen soll. Die nächste Aktion basiert auf der Skill-Auswahl und den Informationen, die der Agent in den vorherigen Phasen erhalten hat.

Phase 5 – Ausführung mit Sicherheitsmechanismen (D1 + KV, ~80ms)

Der Agent führt die nächste Aktion aus, während er Sicherheitsmechanismen einsetzt, um sicherzustellen, dass die Aktion korrekt und sicher durchgeführt wird.

Phase 6 – Speicherung von Informationen (D1 + KV, ~80ms)

Der Agent speichert die Informationen, die während der Ausführung der Aktion gesammelt wurden, um sie für zukünftige Gespräche verfügbar zu machen.

Der gesamte Zyklus läuft in <Sekunden auf der Edge-Cloud von Cloudflare, ohne festen Server.

• Aktueller Verlauf der Konversation (letzte N relevante Schritte).
• Langfristige Speicherung des Kunden (Präferenzen, Kaufhistorie, Notizen).
• Status des Agents (Persona, aktivierte Fähigkeiten, Regeln).

Alle stammen aus D1 (Cloudflare-Verteiltes SQLite). D1 ersetzt traditionelles Postgres/Mongo – ohne Server zum Warten, Zugriff in wenigen Millisekunden vom Worker, multi-tenant durch tenant_id.

Hinweis: Wir laden die gesamte Konversation nicht in den Prompt. Der Memory Manager v2 von OpenClaw (beschrieben in unserer internen Dokumentation) wählt nur die relevanten Schritte für den aktuellen Schritt aus (letzte N + N relevante Schritte mit hoher semantischer Bedeutung). Dies hält den Tokenkostenpreis auch bei Konversationen mit über 100 Schritten vor.

Stufe 3 – Auswahl von Fähigkeiten (Policy-Engine, ~20ms)

Jeder Agent hat ein Set von Fähigkeiten zur Verfügung – Funktionen, die er aufrufen kann. Beispiele: kalender_abfragen, ereignis_erstellen, zahlung_link_generieren, bestellung_abfragen, mensch_rufen.

Gegeben die Nachricht "Ich möchte am Samstag morgen anrufen", filtert die Policy-Engine:

• Fähigkeiten, die mit der detektierten Absicht kompatibel sind (Termine planen).
• Fähigkeiten, die für diese Konversationsphase zugelassen sind (nicht jede Fähigkeit ist zu jeder Zeit verfügbar).
• Fähigkeiten, die dieser Mieter aktiviert hat (Kalender erscheint nur, wenn der Mieter integriert hat).

Am Ende hat man ein kleines Subset von Fähigkeiten, das an den Modell anliegt – nicht die 50 möglichen, sondern nur die 4, die hier Sinn ergeben. Dies reduziert drastisch die Wahrscheinlichkeit, dass der Modell eine falsche Fähigkeit aufruft.

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

Jetzt tritt das Modell ein. OpenClaw macht eine einzige Anfrage an einen LLM an der Grenze (Anthropic Claude, OpenAI GPT, Google Gemini – konfigurierbar durch Mieter) mit:

• System Prompt = Agent-Persona + Regeln + verfügbare Fähigkeiten.
• Geschichte = ausgewählte Schritte im Stufe 2.
• Benutzer-Nachricht = Nachricht des aktuellen Schritts.

Das Modell gibt eine von zwei Dingen zurück:

• Endgültige Antwort (direkt zum Kunden).
• Tool-Aufruf (Anfrage, eine Fähigkeit mit Parametern auszuführen).

Im Beispiel "Ich möchte am Samstag morgen anrufen", gibt das Modell typischerweise zurück:

{
  "tool": "kalender_abfragen",
  "args": { "datum": "2026-04-19 06:00 bis 12:00" }
}

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

Die Fähigkeit läuft nicht im Modell. Sie läuft in unserem Code, der:

...

1. Überprüfe Parameter (date_range hat die richtige Form? liegt es innerhalb der Regeln des Tenant?).
2. Überprüfe Berechtigung (dieser Agent hat das Recht, diesen Kalender abzufragen?).
3. Erstelle die Anfrage (Google Calendar API in diesem Fall).
4. Richte das Ergebnis ein für das Modell.

Warum ist das wichtig? Weil das Modell nie das Ergebnis selbst erstellt. Wenn der Kalender [10h, 11h] zurückgibt, ist das genau das, was an die nächste Anfrage weitergegeben wird. Wenn die Skill fehlschlägt, weiß das Modell, dass sie fehlschlagen ist. Es besteht kein Risiko, dass der Agent "erfindet", dass er um 9 Uhr Zeit hat, wenn er keine Zeit hat.

Bei Fällen, die sensible Informationen (Preis, Frist, Name des Kunden) beinhalten, zwingt der Pipeline tool call – er lässt das Modell nicht antworten, indem es "seine eigenen Kenntnisse" verwendet. Das eliminiert die häufigste Klasse von Halluzinationen bei Handelsagenten.

Stufe 6 – Antwort und Persistenz (~50ms)

Mit dem Ergebnis der Skill in der Hand, macht das Modell die zweite Anfrage – jetzt, um die endgültige Antwort für den Kunden zu bilden. Zum Beispiel:

"Ich habe Samstag um 10 Uhr und 11 Uhr. Welche bevorzugt?"

Parallel dazu:

1. Sendet die Nachricht zurück über die WhatsApp-API.
2. Persistiert den gesamten Turnus (Benutzer + Assistent + Tool-Anrufe + Dauer) im D1.
3. Aktualisiert die Langzeit-Memory , wenn der Turnus neue Fakten produziert (z.B. "Kunde bevorzugt Samstag").
4. Emittiert ein Ereignis der Beobachtbarkeit (Latenz-Metrik, Token-Kosten, Skalierungstakt).

Alles läuft parallel. Die Persistenz blockiert nicht die Nachrichtensendung – der Kunde wartet nicht auf den D1.

---

Wo ist die Verteidigung gegen Halluzinationen

Ein Agent, der in der Produktion halluziniert, verliert schnell die Vertrauenswürdigkeit. Der OpenClaw hat 4 Linien von Verteidigung:

1. Quelle der Wahrheit zwingend. Fakten (Preis, Zeit, Name) kommen immer von der Skill, nie vom Modell allein.
2. Doppelte Überprüfung bei sensiblen Daten. Terminierung wird mit dem Kunden bestätigt, bevor sie persistiert wird. Zahlung wird bestätigt, bevor der Zugriff freigegeben wird.
3. Explizite Negativregeln. Die Persona jedes Agents enthält "nicht erfunden X, Y, Z" – das Modell befolgt sie.
4. Fallback auf den Menschen. Wenn keine Skill die Frage abdeckt, sagt der Agent "Lassen Sie mich mit dem Team überprüfen" und öffnet ein Ticket – er nicht schüttet.

In den letzten 6 Monaten durchgeführten Audits (wirkliche Gespräche wurden manuell überprüft), lag die Rate der Halluzinationen bei unter 0,3% der Turnus – und fast alle Fälle waren durch Konfiguration (Tenant vergaß, die relevante Skill zu aktivieren), nicht durch Fehler des Modells.

---

Der Kosten pro Gespräch

(Keine Übersetzung erforderlich)

Eine gute Architektur ist unsichtbar, bis man die Rechnung sieht. Da jeder Turnus 1-2 Aufrufe an das LLM plus Lookups in D1 ausführt, liegt der durchschnittliche Kosten pro vollständiger Konversation (10-15 Turnus) bei:

(Einige Wörter wurden an die deutsche Sprache angepasst, um eine bessere Übersetzung zu erhalten.)