Wie ClawAI aufgebaut ist

Achtzehn unabhängig bereitstellbare Dienste, jeder mit einer eigenen Datenbank, koordiniert über ein ereignisgesteuertes Rückgrat. Antworten werden während der Erzeugung gestreamt, und jede Schicht ist eigenständig abgesichert.

Zuletzt geprüft 2026-07-25

Wie ClawAI aufgebaut ist

ClawAI besteht aus achtzehn unabhängig bereitstellbaren Diensten hinter einem einzigen Reverse-Proxy. Authentifizierung, Chat, Routing, Connectoren, Gedächtnis, Dateien, Recherche, Workspace, Bilderzeugung, Dokumentenexport, Abrechnung, Audit und Protokollierung laufen jeweils als eigener Prozess mit eigener Datenbank. Die Web-App erreicht sie alle über eine einzige API-Oberfläche.

Der Grund ist Eindämmung. Ein langsamer Anbieter, eine hängende Dateikonvertierung oder ein fehlgeschlagener Export kann den Chat nicht mit sich reißen, weil sie sich keinen Prozess, keinen Connection-Pool und keine Datenbank teilen. Jeder Dienst wird eigenständig bereitgestellt, skaliert und zurückgerollt.

18: Unabhängig bereitstellbare Dienste
Eine pro Dienst: Niemals eine gemeinsame Datenbank
HTTP + Events: Synchrone Aufrufe plus ein asynchroner Event-Bus
Ein Einstiegspunkt: Ein einziger Reverse-Proxy vor allem

Die Dienste

Nicht jeder Dienst ist von außen interessant. Das sind diejenigen, die eine einzelne Anfrage typischerweise berührt, ungefähr in der Reihenfolge, in der sie sie berührt.

AuthentifizierungPostgreSQL: Konten, Sitzungen, Token-Ausstellung und Refresh-Rotation, Rollen und Berechtigungssätze.
ChatPostgreSQL: Unterhaltungen und Nachrichten, Kontextzusammenstellung, Streaming-Ausführung und Mehrmodell-Orchestrierung.
RoutingPostgreSQL: Klassifiziert jede Nachricht, wendet den aktiven Modus und etwaige Richtlinien an und protokolliert die Entscheidung samt Fallback-Kette.
ConnectorenPostgreSQL: Anbieter-Zugangsdaten, Modellkataloge, Fähigkeits-Flags und kontinuierliche Health-Checks.
Gedächtnis und KontextPostgreSQL + pgvector: Gedächtniseinträge, die Vorschlags-Warteschlange, Kontextpakete samt ihrer Versionen sowie semantischer Abruf.
DateienPostgreSQL: Uploads, Sicherheitsscans, Textextraktion, OCR, Aufteilung in Abschnitte und Aufbewahrung.
RecherchePostgreSQL: Websuche, Abruf von Seiten und Zusammenstellung von Belegen für Antworten mit Quellen.
WorkspacePostgreSQL: OAuth-Verbindungen zu zwölf Drittanbieter-Tools, Webhooks, geplante Synchronisierung und werkzeugübergreifende Suche.
BilderzeugungPostgreSQL: Bildanfragen, Anbieter-Adapter und Fortschritt pro Schritt, während ein Bild gerendert wird.
DokumentenerzeugungPostgreSQL: Rendern von Antworten in PDF, DOCX, CSV, HTML, Markdown, TXT und JSON.
AbrechnungPostgreSQL: Tarife, Abonnements, versionierte Preise, Rechnungen und Durchsetzung von Kontingenten.
AuditMongoDB: Das unveränderliche Protokoll darüber, wer was getan hat, sowie das Nutzungs-Ledger, aus dem jede Kontingentzahl abgeleitet wird.
ProtokollierungMongoDB: Strukturierte Protokolle von jedem Dienst und vom Browser, aufbewahrt in einem rollierenden Zeitfenster.

Jeder Dienst benennt die Datenbank, die er besitzt. Nichts anderes verbindet sich damit – ein Dienst, der die Daten eines anderen braucht, fragt sie über HTTP an oder reagiert auf ein Event.

Eine Datenbank pro Dienst

Jeder Dienst besitzt genau eine Datenbank und ist das Einzige, was sich mit ihr verbindet. Es gibt kein gemeinsames Schema, keinen dienstübergreifenden Join und keine Reporting-Datenbank, die im Stillen die Tabellen aller anderen liest.

Der Preis dafür ist, dass manche Fragen zwei Aufrufe statt eines Joins brauchen. Der Nutzen ist, dass eine Schemaänderung in der Abrechnung den Chat nicht beschädigen kann und eine außer Kontrolle geratene Abfrage in der Protokollierung nicht den Connection-Pool erschöpfen kann, von dem Ihre Unterhaltung abhängt.

Keine dienstübergreifenden Datenbankabfragen: Ein Dienst liest seine eigenen Tabellen und die niemandes sonst. Daten von anderswo kommen über einen API-Aufruf oder ein Event an.
Schemas sind privat: Ein Dienst kann seine eigenen Tabellen ändern, ohne sich mit irgendjemandem abzustimmen, weil kein externer Konsument von ihrer Form abhängt.
Migrationen laufen pro Dienst: Jeder Dienst migriert seine eigene Datenbank beim Start. Es gibt keine globale Migration, auf die alle warten müssen.
Ausfälle bleiben lokal: Eine Datenbank, die langsam oder nicht verfügbar ist, beeinträchtigt eine Fähigkeit, nicht das ganze Produkt.

Das Leben einer Anfrage

Was zwischen dem Drücken von Senden und dem Lesen der Antwort passiert.

Die Anfrage wird authentifiziert
der Reverse-Proxy leitet sie an den Chat weiter, der Ihr Zugriffstoken und die mit Ihrer Rolle verknüpften Berechtigungen prüft.
Das Kontingent wird geprüft
die Abrechnung bestätigt, dass Ihr Tarif das angeforderte Modell erlaubt und Ihr tägliches sowie monatliches Kontingent noch Spielraum hat.
Die Nachricht wird gespeichert und angekündigt
der Chat schreibt die Nachricht in seine eigene Datenbank und veröffentlicht ein Event. Das Routing hört darauf.
Das Routing wählt ein Modell
die Nachricht wird klassifiziert, der aktive Modus und die Richtlinien werden angewendet, die Connector-Verfügbarkeit wird konsultiert, und eine Entscheidung samt Fallback-Kette wird protokolliert.
Der Kontext wird zusammengestellt
der Chat fragt das Gedächtnis nach relevanten Einträgen und Paketelementen sowie die Dateien nach relevanten Abschnitten und fügt sie dann innerhalb eines Token-Budgets in den Prompt ein.
Das Modell wird aufgerufen und gestreamt
der Chat ruft den Anbieter auf und leitet Phasen, Text, Denkprozess und Metriken über Server-Sent Events an Ihren Browser weiter, sobald sie eintreffen.
Das Ergebnis wird gespeichert
die Antwort, ihre Routing-Entscheidung, ihre Token-Anzahl und ihr Kontextbeleg werden gemeinsam festgehalten.
Nutzung und Audit werden protokolliert
die Abrechnung verrechnet die Kosten gegen Ihr Kontingent, und das Audit protokolliert das Ereignis. Auch die Gedächtnisextraktion läuft hier.

Die Schritte 1 bis 7 sind synchron – Sie warten auf sie. Schritt 8 und die Gedächtnisextraktion geschehen, nachdem die Antwort bereits auf Ihrem Bildschirm steht, sodass sie keine Latenz zu dem hinzufügen, was Sie erleben.

Der Event-Bus

Arbeit, die nicht abgeschlossen sein muss, bevor Sie eine Antwort sehen, wird als Event auf einem RabbitMQ-Topic-Exchange veröffentlicht und von den Diensten verarbeitet, die sich dafür interessieren. Nutzungsmessung, Audit-Einträge und Gedächtnisextraktion laufen alle auf diese Weise.

Events sind der Grund, warum der Chat nicht wissen muss, dass Audit existiert. Der Chat stellt fest, was passiert ist; alles, was reagieren muss, abonniert es. Einen Consumer hinzuzufügen erfordert keine Änderung am Publisher.

Topic-Exchange: Publisher benennen, was passiert ist, nicht, wer es hören soll. Consumer binden sich an die Muster, die sie interessieren.
Wiederholungen mit Backoff: Ein fehlgeschlagener Handler wird dreimal mit steigender Verzögerung wiederholt, was die vorübergehenden Fehler abfängt, aus denen die meisten von ihnen bestehen.
Dead-Letter-Queue: Eine Nachricht, die nach ihren Wiederholungen immer noch fehlschlägt, landet in einer Dead-Letter-Queue, statt verworfen zu werden oder alles dahinter zu blockieren.
Idempotente Handler: Handler tolerieren, dass dasselbe Event zweimal eintrifft, weil Zustellung mit mindestens einmaliger Garantie irgendwann genau das sicherstellt.
Alles ist auditierbar: Audit abonniert jedes Domänen-Event, sodass das Protokoll dessen, was passiert ist, nicht davon abhängt, dass sich jeder Dienst daran erinnert, eines zu schreiben.

Streaming

Antworten treffen über Server-Sent Events ein, nicht per Polling. Die Verbindung öffnet sich, wenn Sie eine Nachricht senden, und trägt alles, bis die Antwort fertig ist oder abgebrochen wird.

Pufferung ist von Anfang bis Ende deaktiviert – am Proxy und in jedem Dienst auf dem Weg –, weil ein gepufferter Stream nur eine langsame Antwort mit Umwegen ist.

Derselbe Kanal transportiert Textgenerierung, Fortschritt bei der Bilderzeugung und lang laufende Recherchen, sodass die Oberfläche einen einzigen Weg hat, laufende Arbeit zu zeigen, statt drei.

Phasenwechsel: Eingereiht, Routing, Kontext wird zusammengestellt, Modell wird aufgerufen, wird abgeschlossen – sodass eine Pause immer einen sichtbaren Grund hat.
Inhalts-Deltas: Der Antworttext, während das Modell ihn erzeugt, Token für Token.
Denkprozess-Deltas: Bei Modellen, die ihr Denken offenlegen, wird der Denkprozess-Stream getrennt von der Antwort geliefert und auch getrennt dargestellt.
Metrik-Takte: Token bisher, Token pro Sekunde, Zeit bis zum ersten Token, und wohin die Zeit tatsächlich ging – Modell-Laden, Prompt-Auswertung oder Generierung.
Abschluss-Events: Eine abschließende Nutzungszusammenfassung oder ein expliziter Fehler oder Abbruch. Der Stream hört nie einfach auf.

Was was speichert

Vier Arten von Speicher, jeder eingesetzt für das, worin er gut ist.

PostgreSQL: Das führende System für Konten, Unterhaltungen, Routing-Entscheidungen, Gedächtnis, Dateien, Verbindungen und Abrechnung – eine Datenbank pro Dienst.
pgvector: Vektor-Ähnlichkeitssuche innerhalb von PostgreSQL, verwendet, um relevante Erinnerungen und Kontextpaket-Elemente abzurufen, ohne eine separate Vektordatenbank zu betreiben.
MongoDB: Audit-Events, das Nutzungs-Ledger und strukturierte Protokolle: umfangreiche, nur anhängende Daten mit einem rollierenden Aufbewahrungsfenster.
Redis: Caching, Zähler für Ratenbegrenzung und kurzlebiger Koordinationszustand. Nichts Wichtiges wird nur hier gespeichert.

Sicherheitsmechanismen

Konkrete Kontrollen, die im Produkt existieren. Keine Zertifizierungsansprüche – siehe den Hinweis am Ende.

Zugriffs- und Refresh-Token: Kurzlebige Zugriffstoken mit Refresh-Rotation. Die Wiederverwendung eines rotierten Tokens macht die Sitzung ungültig.
Passwort-Hashing: Argon2 mit Salts pro Benutzer. Passwörter werden niemals in wiederherstellbarer Form gespeichert oder protokolliert.
Rollenbasierte Zugriffskontrolle: Rollen tragen explizite Berechtigungssätze, durchgesetzt durch Guards an jedem Endpunkt jedes Dienstes – nicht nur in der Oberfläche.
Verschlüsselte Zugangsdaten: Anbieter- und Connector-Geheimnisse werden ruhend mit AES-256-GCM verschlüsselt und nie von einer API zurückgegeben.
Schemavalidierung: Jeder Anfragekörper wird gegen ein Zod-Schema mit expliziten Längen- und Größengrenzen validiert, bevor er irgendeine Logik erreicht.
Ratenbegrenzung: Drosselung pro Konto auf jedem Dienst, damit ein Client nicht die Kapazität für alle anderen erschöpfen kann.
Sicherheits-Header: Eine strikte Content Security Policy mit Nonces pro Anfrage, HSTS und den üblichen Härtungs-Headern bei jeder Antwort.
TLS überall: TLS vom Browser bis zum Edge und erneut bei jedem internen Sprung, mit Zertifikatsprüfung zwischen den Diensten.
Protokoll-Schwärzung: Token, Passwörter, API-Schlüssel und Autorisierungs-Header werden entfernt, bevor irgendetwas in ein Protokoll geschrieben wird.

ClawAI besitzt heute keine Sicherheitszertifizierungen von Dritten – weder SOC 2 noch ISO 27001 noch HIPAA. Wir beschreiben die obigen Mechanismen, statt Zusicherungen zu suggerieren, die wir nicht erlangt haben. Unternehmen mit formalen Anforderungen sollten diese bei uns ansprechen, damit sie im Rahmen eines Projekts abgestimmt werden können.

Observability

Jeder Dienst sendet dieselben Signale in derselben Form, und sie landen alle an einem abfragbaren Ort. Ein Betreiber, der die Frage beantwortet, „was mit dieser Anfrage passiert ist", sollte nicht achtzehn Protokolldateien öffnen müssen.

Strukturierte Protokolle: JSON-Protokolle von jedem Dienst und vom Browser, versendet über den Event-Bus und aufbewahrt in einem rollierenden Zeitfenster.
Anfrage-Korrelation: Eine Anfrage-ID wird im Browser erzeugt und durch jeden Dienst-Sprung mitgeführt, sodass ein einziger Bezeichner den gesamten Pfad rekonstruiert.
Audit-Events: Ein separates, unveränderliches Protokoll sicherheits- und geschäftsrelevanter Aktionen, getrennt von den operativen Protokollen gehalten.
Nutzungs-Ledger: Jeder gemessene Aufruf wird als Ledger-Eintrag geschrieben. Kontingentzahlen werden aus dem Ledger abgeleitet, nicht aus einem Zähler, der abdriften könnte.
Health-Aggregation: Ein eigener Dienst fragt jeden anderen Dienst ab und meldet eine konsolidierte Ansicht davon, was verfügbar ist.

Wenn etwas ausfällt

Modellanbieter haben Ausfälle, Ratenlimits und langsame Tage. Die Plattform ist darauf ausgelegt, diese abzufedern, statt sie Ihnen als nie endenden Ladeindikator weiterzureichen.

Fallback-Ketten: Jede Routing-Entscheidung trägt eine geordnete Liste von Alternativen. Schlägt das gewählte Modell fehl, wird automatisch das nächste versucht, und die Ersetzung wird protokolliert.
Gesundheitsbasierte Vermeidung: Connectoren werden kontinuierlich auf ihre Verfügbarkeit geprüft, und ein Anbieter mit Problemen wird vom Router übersprungen, bis er sich erholt.
Sichere Wiederholungen: Event-Handler tolerieren doppelte Zustellung, sodass eine Wiederholung einen Fehler korrigiert, statt Ihr Kontingent doppelt zu belasten.
Fehler sind sichtbar: Wenn jede Option fehlschlägt, wird ein expliziter Fehler in die Unterhaltung geschrieben und den Stream hinuntergeschickt. Es gibt kein stilles Versagen, das die Oberfläche warten lässt.
Auswirkungsradius: Getrennte Prozesse und getrennte Datenbanken bedeuten, dass ein Ausfall eine Fähigkeit beeinträchtigt. Ein Ausfall der Bilderzeugung hindert Sie nicht am Chatten.

Dieselbe Architektur, innerhalb Ihres Netzwerks

Alles auf dieser Seite beschreibt den gehosteten Dienst, aber die Architektur ist nicht daran gebunden. Dieselben achtzehn Dienste, derselbe Event-Bus und dasselbe Datenmodell können innerhalb des eigenen Netzwerks eines Unternehmens bereitgestellt werden.

In dieser Konfiguration werden die externen Modellanbieter durch offene Modelle ersetzt, die auf Ihrer eigenen GPU-Hardware laufen, sodass kein Prompt, Dokument oder Gespräch Ihre Infrastruktur verlässt. Das ist ein individuell abgestimmtes Projekt und kein Tarif, den Sie kaufen können – wir dimensionieren es gemeinsam mit Ihrem Team.

Sprechen Sie mit uns über eine private Bereitstellung

Sehen Sie es in Aktion

Der schnellste Weg, eine Architektur zu beurteilen, ist, das zu nutzen, was sie hervorbringt. Der kostenlose Tarif ist in einer Minute eingerichtet.

Konto erstellen Sprechen Sie mit uns über eine private Bereitstellung