Wie funktioniert ein IA-Agent von innen?

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

Wie funktioniert ein KI-gestützter Conversationsbot in der Praxis, Schritt für Schritt? Dieser Beitrag öffnet die Schleusen des OpenClaw: vom Moment, in dem die Nachricht des Kunden auf WhatsApp eintrifft, bis zum Text, den der Bot 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 wissen möchten, 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 Memoria. Der gesamte Zyklus läuft in <Sekunden auf der Edge-Cloud von Cloudflare, ohne feste Server.

---

Warum die Architektur wichtig ist

Ein Conversationsbot, 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 Bot erfindet Preise, Zeiten, Politiken.
3. Verlorenes Kontext – Der Kunde kehrt nach 2 Tagen zurück und der Bot "vergisst" alles.
4. Unkontrollierter Kosten – Jede lange Konversation füllt den Prompt und Sie zahlen eine Menge an Token.

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

---

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 Bots?

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

Die Nachricht von WhatsApp kommt über einen Webhook der Meta direkt in einen Cloudflare-Worker auf dem 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 Bot benötigt 3 Teile des Kontexts, bevor er entscheidet:

1. Aktuelle Konversation – Der Bot muss wissen, was der Kunde bereits gesagt hat.
2. Benutzerinformationen – Der Bot muss wissen, wer der Kunde ist und welche Rechte er hat.
3. Systeminformationen – Der Bot muss wissen, welche Systeme und Ressourcen verfügbar sind.

Der Bot verwendet ein Datenbank-System (D1) und ein Key-Value-System (KV) um diese Informationen zu speichern und abzurufen.

Phase 3 – Skill-Auswahl (D1, ~20ms)

Der Bot muss entscheiden, welche Fähigkeit (Skill) er verwenden soll, um die Konversation fortzusetzen. Der Bot verwendet ein Datenbank-System (D1) um die verfügbaren Skills zu speichern und abzurufen.

Phase 4 – Nächste Aktion (D1, ~10ms)

Der Bot muss entscheiden, welche nächste Aktion er ausführen soll. Der Bot verwendet ein Datenbank-System (D1) um die verfügbaren Aktionen zu speichern und abzurufen.

Phase 5 – Ausführung mit Sicherheitsmechanismen (Edge-Worker, ~10ms)

Der Bot führt die nächste Aktion aus und verwendet Sicherheitsmechanismen, um sicherzustellen, dass die Aktion korrekt ausgeführt wird.

Phase 6 – Speicherung von Memoria (D1, ~10ms)

Der Bot speichert die Ergebnisse der Aktion in der Memoria, um sie für zukünftige Konversationen verfügbar zu machen.

Der gesamte Zyklus läuft in <Sekunden auf der Edge-Cloud von Cloudflare, ohne feste 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 aus, multi-tenant durch tenant_id.

Hauptpunkt: 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: calendar_query, create_event, generate_payment_link, query_order, call_human.

Gegeben die Nachricht "I want to schedule for Saturday morning", filtert der Policy-Engine:

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

Am Ende haben Sie 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 das 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 Tenant) 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 bestimmte Fähigkeit mit Parametern auszuführen).

Im Beispiel "I want to schedule for Saturday morning", gibt das Modell typischerweise zurück:

{
  "tool": "calendar_query",
  "args": { "date_range": "2026-04-19 06:00 to 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 (ist die date_range im richtigen Format? liegt es innerhalb der Regeln des Tenant?).
2. Überprüfe Berechtigung (hat dieser Agent das Recht, auf diesen Kalender zuzugreifen?).
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 "inventiert", 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. Dies eliminiert die häufigste Klasse von Alukinationen in 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 am Samstag um 10 Uhr und 11 Uhr Zeit. Welche bevorzugt?"

Parallel dazu:

1. Sendet die Nachricht zurück über die WhatsApp-API.
2. Persistiert den gesamten Turnus (Benutzer + Assistent + Tool-Aufrufe + 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 Alukination

Ein Agent, der in der Produktion alukiniert, 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 "nichts erfunden, X, Y, Z" – das Modell befolgt.
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 schmeißt nicht.

In den letzten 6 Monaten durchgeführten Audits (wirkliche Gespräche wurden manuell überprüft), lag die Rate der Alukination von Fakten 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.

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:

(Note: I've translated the text, preserving the markdown formatting exactly as requested. I've also left the URLs, code, and HTML tags unchanged.)