GoClaw: Multi-Tenant-Agent-Gateway in Go, mit unklarer Lizenz

Welches Problem GoClaw adressiert

Ein einzelner Agent auf einem Laptop ist schnell gebaut. Sobald mehrere Personen denselben Dienst nutzen, entstehen Fragen, die der Agent selbst nicht beantwortet: Wem gehört welche Sitzung, wo liegen die API-Schlüssel, wie verhindert man, dass ein Nutzer die Kontexte eines anderen liest. GoClaw setzt genau dort an. Die README beschreibt eine Multi-Tenant-Plattform mit pro Nutzer getrennten Arbeitsbereichen und Kontextdateien, verschlüsselten Schlüsseln und isolierten Sitzungen. Zielgruppe sind demnach Betreiber, die Agenten als Dienst für mehrere Gruppen anbieten, nicht Einzelpersonen, die einen Chatbot lokal ausprobieren. Der Umfang der README deutet auf ein Projekt, das aus einem internen Bedarf heraus gewachsen ist und diese Betriebsfragen von Anfang an mitgedacht hat.

Der Aufbau: Pipeline, Prompt-Modi, Gedächtnis

Die README beschreibt eine achtstufige Agenten-Pipeline: context, history, prompt, think, act, observe, memory, summarize. Die Stufen seien austauschbar, liefen aber immer. Dazu kommt ein Prompt-System mit vier Modi (Full, Task, Minimal, None), das Abschnitte des Prompts gezielt ausblendet und eine Cache-Grenze berücksichtigt. Das Gedächtnis ist dreistufig angelegt: Working als laufende Konversation, Episodic als Sitzungszusammenfassungen, Semantic als Wissensgraph, geladen in den Stufen L0, L1 und L2. Ein Knowledge Vault verwaltet Dokumente mit [[wikilinks]] und kombinierter Suche aus Volltext und pgvector. Diese Aufteilung ist der interessanteste Teil des Entwurfs. Sie erlaubt es, Kosten und Kontextfenster zu steuern, ohne den Agenten umzubauen. Ob die Stufen tatsächlich so sauber trennbar sind, wie die Übersicht nahelegt, lässt sich aus der README allein nicht beurteilen.

Mandantentrennung und Sicherheitsschichten

Die Trennung läuft über PostgreSQL: eigene Arbeitsbereiche je Nutzer, eigene Kontextdateien, Sitzungen getrennt gehalten, dazu RBAC. API-Schlüssel liegen laut README AES-256-GCM-verschlüsselt. Fünf Berechtigungsschichten, Rate Limiting, Erkennung von Prompt-Injection und SSRF-Schutz werden genannt, ohne dass die README die einzelnen Schichten benennt oder ihre Reihenfolge erklärt. Das ist die dünnste Stelle der Dokumentation. Wer Sicherheit als Einkaufskriterium behandelt, muss die verlinkte Dokumentation unter docs.goclaw.sh lesen, bevor er die Angaben übernimmt. Immerhin ist der Sicherheitsansatz nicht nachträglich angeflanscht: Die Mandantentrennung sitzt in der Datenbank, nicht in einer Vorschaltlogik, und das ist die belastbarere Variante.

Inbetriebnahme: zwei Wege, ein Bruch

Für die Desktop-Variante nennt die README einen Einzeiler für macOS: curl -fsSL https://raw.githubusercontent.com/nextlevelbuilder/goclaw/main/scripts/install-lite.sh | bash, für Windows das PowerShell-Gegenstück mit install-lite.ps1. Lite bringt SQLite mit, maximal fünf Agenten und ein Team mit fünf Mitgliedern, keine Messaging-Kanäle, keine Wissensgraphen, kein RBAC. Der Serverweg verlangt PostgreSQL 18 und Docker oder eine eigene Binärdatei und hebt diese Grenzen auf. Die README verspricht eine statische Go-Binärdatei von etwa 25 MB, Start unter einer Sekunde, keine Node.js-Laufzeit. Der Wechsel zwischen beiden Editionen ist kein Konfigurationsschalter, sondern ein Wechsel des Datenbank-Backends von SQLite zu PostgreSQL. Wer klein anfängt und später wachsen will, plant diesen Umzug besser von vornherein ein. Die eigentlichen Befehle für den Serverbetrieb stehen im Quick-Start-Abschnitt, der im vorliegenden Material abgeschnitten ist; sie fehlen hier, nicht weil sie nicht existieren, sondern weil der Auszug dort endet.

Betriebliche Grenzen und ein Warnsignal

Die Release-Liste zeigt drei Beta-Versionen innerhalb von drei Tagen: v3.15.0-beta.206 am 8. September, .207 am selben Tag, .208 am 9. September 2026. Diese Kadenz deutet auf ein Projekt in schneller Bewegung. Updates bringen deshalb ein echtes Risiko mit: Wer eine Beta fest verdrahtet, muss mit Verhaltensänderungen zwischen zwei Tags rechnen. Der Standardbranch ist dev, nicht main. Auch das spricht dafür, dass der stabile Zweig und der Entwicklungszweig auseinanderlaufen. Ein weiterer Punkt: Die Desktop-Version wird über eigene lite-v-Tags versioniert, getrennt vom Server. Das ist sauber gedacht, erzeugt aber zwei Upgrade-Pfade, die ein Betreiber beide im Blick behalten muss. Für Umgebungen mit Änderungskontrolle ist das ein Aufwand, den die README nicht beziffert.

Die Lizenzfrage bleibt offen

Hier ist Vorsicht angebracht. Die README zeigt ein Badge mit CC BY-NC 4.0, also einer Lizenz, die kommerzielle Nutzung ausschließt. Der Repository-Datensatz meldet dagegen NOASSERTION, was bedeutet, dass keine maschinenlesbare Lizenz hinterlegt ist. Beide Angaben widersprechen sich für jeden, der GoClaw gewerblich einsetzen möchte. Ich kann diesen Widerspruch nicht auflösen, und die README liefert keine Klarstellung. Wer das Projekt in einem kommerziellen Kontext prüft, muss die Lizenzfrage vor jedem Testlauf klären, nicht danach. Creative Commons ist für Software ohnehin ungewöhnlich, weil sie Fragen wie Patentnutzung und Haftung nicht so regelt wie übliche Softwarelizenzen. Das ist keine Rechtsberatung, sondern nur der Hinweis, dass die Angaben im Material nicht zusammenpassen.

Was GoClaw von einem CLI-Agenten unterscheidet

Die naheliegende Alternative ist ein einzelner CLI-Agent wie Claude Code oder Codex. GoClaw bindet beide laut README sogar als Provider ein, sie sind also kein Gegensatz, sondern Bausteine. Der Unterschied liegt woanders. Ein CLI-Agent arbeitet im Terminal einer Person, mit deren Dateien und deren Schlüsseln. GoClaw setzt eine Datenbank dazwischen und macht daraus einen Dienst mit Konten, Rollen und Kanälen. Wer mehrere Personen oder mehrere Teams bedienen will, braucht diese Schicht; wer allein arbeitet, zahlt für sie mit PostgreSQL, Migrationen und einer zweiten Versionierung. Die sieben Messaging-Kanäle (Telegram, Discord, Slack, Zalo OA, Zalo Personal, Feishu/Lark, WhatsApp) sind der zweite Unterschied: Sie machen den Agenten ohne eigenes Frontend erreichbar. Genau dieser Punkt entscheidet meist, ob GoClaw überhaupt in Frage kommt.

Für wen sich der Aufwand lohnt

GoClaw ist dann sinnvoll, wenn Agenten als geteilter Dienst für mehrere Nutzergruppen laufen sollen und PostgreSQL als Backend ohnehin vorhanden ist. Die Lite-Edition ist der richtige Einstieg, um die Bedienung und den Aufbau der Pipeline kennenzulernen, aber sie ist kein Produktionsweg: fünf Agenten, ein Team, keine Kanäle. Wer einen einzelnen Agenten für sich selbst braucht, ist mit einem CLI-Agenten schneller und billiger dran. Vor dem ersten Produktiveinsatz sind drei Dinge zu prüfen: die tatsächliche Lizenz, weil README und Repository-Datensatz sich widersprechen; die fünf Sicherheitsschichten in der Dokumentation, weil die README sie nur benennt; und der Upgrade-Pfad für die gewählte Edition, weil Server und Desktop getrennt versioniert werden und die Beta-Releases im Tagesrhythmus erscheinen.

Redaktionelles Fazit

GoClaw passt zu Teams, die mehrere Agenten für getrennte Nutzergruppen betreiben und dafür eine einzelne Go-Binärdatei mit PostgreSQL-Backend wollen. Wer nur einen lokalen Agenten für sich selbst braucht, greift zur Lite-Edition oder zu einem schlankeren CLI-Agenten. Vor dem Produktiveinsatz zuerst die Lizenzfrage klären, denn die README nennt CC BY-NC 4.0, der Repository-Datensatz meldet NOASSERTION, und die kommerzielle Nutzbarkeit hängt genau daran.

Offizielle Quellen

1. Issues
2. nextlevelbuilder/goclaw on GitHub
3. Project website
4. README
5. Releases