WeKnora: RAG, ReAct-Agent und Auto-Wiki in einer selbst hostbaren Go-Plattform

Welches Problem WeKnora adressiert und für wen es gedacht ist

Die Ausgangslage ist bekannt: Dokumente liegen über Feishu, GitLab, Notion, Yuque, Tencent IMA und RSS verteilt, und niemand findet sie wieder. WeKnora setzt genau dort an. Das README beschreibt die Plattform als LLM-gestütztes Wissensframework für Dokumentenverständnis, semantische Suche und autonomes Schlussfolgern. Die Zielgruppe ist damit nicht der einzelne Entwickler mit einer PDF-Sammlung, sondern das Unternehmen mit mehreren Arbeitsbereichen, Rollen und Datenquellen. Auf diese Zielgruppe sind die Mechanismen zugeschnitten: eine vierstufige Rollenmatrix, Eigentümerschaft pro Ressource und ein Audit-Log pro Arbeitsbereich. Wer nur eine Frage-Antwort-Schnittstelle über ein paar Handbüchern braucht, zahlt für diese Struktur mit Konfigurationsaufwand, ohne sie zu nutzen. Interessant ist die Plattform für Teams, die ohnehin mehrere Quellsysteme synchron halten müssen und die Datenhoheit behalten wollen. Das README nennt lokale und private Cloud-Deployments ausdrücklich als Betriebsmodell. Ein weiterer Adressat sind Integratoren, die den Agenten über eine API anbinden wollen. Dafür existieren laut README API-Schlüssel mit einem Principal-Modell und eingeschränktem Geltungsbereich, dazu ein MCP-Server als PyPI-Paket tencent-weknora-mcp. Der Preis für diesen Zuschnitt: Die Plattform bringt einen eigenen Betriebs- und Updatezyklus mit, den ein Skript über einem Vektorindex nicht hat.

Ingestion, Chunking und Retrieval: der Datenfluss im Detail

Der Weg durch das System beginnt bei der Aufnahme. Das README nennt über zehn Dokumentformate, darunter PDF, Word, Excel, Bilder und XMind. Office-Dateien werden laut v0.8.0-Notizen mit einem prozessinternen Parser namens anydoc gelesen, also ohne externen Konvertierungsdienst. Anschließend entstehen Retrieval-Chunks, die seit v0.7.2 direkt in der Oberfläche bearbeitet werden können. Das ist der architektonisch ungewöhnliche Teil: Chunks haben eine Versionshistorie mit Diff und Rollback, und eine Änderung löst laut Release Notes eine automatische Neuindizierung aus. Wer schon einmal einen Vektorindex neu aufbauen musste, weil ein fehlerhaftes Chunk die Trefferliste dominierte, erkennt den Nutzen. Die Suche selbst kombiniert Vektorsuche, Reranking und Embeddings, die über austauschbare Anbieter angebunden sind. Welche Vektordatenbanken im Detail unterstützt werden, steht nicht im vorliegenden README-Ausschnitt; das ist eine der Stellen, an denen die Beschreibung dünn bleibt und die verlinkte Produktdokumentation die eigentliche Quelle wäre. Ein weiterer Mechanismus verdient Aufmerksamkeit: die Ordnerstruktur. Upload-Pfade werden als erstklassige Daten gespeichert, sodass sich Dokumente wie in einem Dateimanager verschieben und umbenennen lassen. In vielen RAG-Aufbauten geht die Ablagestruktur beim Import verloren. WeKnora behandelt sie als Teil des Modells. Für die Ausgabe existieren zwei Betriebsarten: die direkte Frage-Antwort über RAG und der Agentenpfad, der Retrieval, MCP-Werkzeuge und Websuche selbst orchestriert.

Der ReAct-Agent und warum die Sandbox-Backends die eigentliche Designentscheidung sind

Der Agent ist als ReAct-Schleife beschrieben: Er plant, ruft Werkzeuge auf, beobachtet Ergebnisse und entscheidet weiter. Die Werkzeuge umfassen Retrieval, MCP-Aufrufe, einen mandantenspezifischen Skill-Katalog und Websuche. Die entscheidende Änderung kam in v0.8.0. Der lokale Host-Prozess als Ausführungsbackend wurde entfernt, geblieben sind Docker, E2B und Cube, wobei Docker ausdrücklich Opt-in ist. Das ist eine Sicherheitsentscheidung mit spürbaren Folgen. Ein Agent, der fremden Code aus einem Skill-Katalog ausführt, kann im Host-Kontext weitreichenden Schaden anrichten; die Verlagerung in Container oder entfernte Sandboxen kostet Latenz und verlangt eine Netzwerkrichtlinie pro Mandant, die das README ebenfalls nennt. Wer WeKnora auf einer Maschine ohne Container-Runtime startet, bekommt den Agenten mit Skill-Ausführung nicht in der früheren Form. Der Skill-Katalog selbst lässt sich aus ClawHub, SkillHub, Git oder einem Zip-Archiv befüllen, mit Snapshots pro Sandbox und getrennten Umgebungsvariablen für Person und Arbeitsbereich. Ein weiterer Baustein ist das sitzungsübergreifende Langzeitgedächtnis, das laut Release Notes Profile, Präferenzen, Fakten, Aufgaben und Interessen unterscheidet, automatisch extrahiert und über search_memory abrufbar ist. Die automatische Extraktion ist der wunde Punkt: Was als Fakt gespeichert wird, entscheidet ein Modell, und das README beschreibt ein Bestätigungsschritt, aber keine Regeln, wie falsche Einträge wieder verschwinden.

Wiki-Modus: destillierte Dokumente mit Versionskontrolle

Der dritte Modus unterscheidet WeKnora von reinen Frage-Antwort-Systemen. Im Wiki-Modus verdichten Agenten die Rohdokumente zu einem verlinkten Markdown-Wissensbestand mit einem interaktiven Wissensgraphen. Seiten lassen sich manuell bearbeiten, es gibt eine Revisionshistorie mit zeilenweisem Diff und einen Ein-Klick-Rollback. Die Idee ist, dass die Wissensbasis sich selbst pflegt, statt bei jeder Änderung der Quelldateien zu verrotten. Ob dieser Anspruch trägt, lässt sich aus dem README nicht belegen; dort steht die Funktionsbeschreibung, nicht das Verhalten im Dauerbetrieb. Zwei Punkte sind dennoch konkret. Erstens: Die Versionierung von Wiki-Seiten und die Versionierung von Retrieval-Chunks sind getrennte Mechanismen mit ähnlicher Semantik. Wer beide Pfade parallel nutzt, muss verstehen, dass eine zurückgerollte Wiki-Seite nicht automatisch die Chunks zurücksetzt, aus denen sie entstanden ist. Zweitens: Der Wiki-Modus erzeugt Markdown und keinen proprietären Speicher, was die Mitnahme der Inhalte erleichtert, falls die Plattform später ersetzt wird. Für Teams, die aus verstreuten Notizen eine prüfbare Wissenssammlung aufbauen wollen, ist das der interessanteste Teil des Projekts. Für Teams, deren Dokumente sich wöchentlich ändern, ist die Frage offen, wie viel manuelle Nacharbeit die automatische Destillation tatsächlich spart. Das README gibt dazu keine Zahlen.

Inbetriebnahme: Docker Compose, Makefile und die Umgebungsvariablen

Der Start erfolgt nach der Anleitung, die das README verlinkt, über Docker Compose und ein Makefile. Üblich sind in solchen Repositories die Ziele make up, make down und make logs, und das README verweist für Details auf den Abschnitt Getting Started sowie auf eine ausgelagerte Dokumentationsseite mit rund 150 Umgebungsvariablen. Aus dem Release-Text sind konkrete Schlüssel belegt: RESOURCE_URL_MODE steuert, ob Datei-URLs direkt ladbar sind, mit dem Wert public für die öffentliche Variante. Für die Sandbox-Ausführung ist Docker ausdrücklich Opt-in, das heißt, ohne entsprechende Konfiguration bleibt der Skill-Pfad inaktiv. Ein MCP-Server steht als PyPI-Paket tencent-weknora-mcp bereit, und für DeepSeek existiert ein Plugin unter dem npm-Namen @wxg-prc-cpg/dsh-weknora. Wer den Agenten über eine externe Anwendung ansprechen will, braucht einen API-Schlüssel mit eingeschränktem Geltungsbereich. Ich habe nichts davon ausgeführt; alle Angaben stammen aus dem README und den Release Notes. Wer die tatsächlichen Compose-Dateien, Ports und Pflichtvariablen braucht, muss sie im Repository prüfen, weil der vorliegende Ausschnitt sie nicht auflistet. Das ist keine Kleinigkeit: Bei einem Stack dieser Breite entscheidet die Compose-Datei darüber, welche Dienste überhaupt zusammen starten, und das README allein reicht dafür nicht.

Grenzen, Betriebsrisiken und der Lizenzstatus

Die auffälligste Unklarheit steht in den Metadaten selbst. Das Badge im README nennt MIT, die Lizenzangabe des Repositories lautet NOASSERTION. Das bedeutet, dass die Lizenz nicht automatisch erkannt wurde; es bedeutet nicht zwingend, dass keine gilt. Wer WeKnora kommerziell einsetzen will, muss die LICENSE-Datei im Repository selbst lesen, bevor er plant. Das ist keine Formalie, sondern der erste Prüfpunkt. Ein zweites Risiko liegt im Umfang. Mehrere Datenquellen, IM-Kanäle wie WeCom, Feishu, Slack und Telegram, über zwanzig LLM-Anbieter, austauschbare Vektor- und Speicher-Backends: Jede dieser Achsen ist eine eigene Fehlerquelle und ein eigener Upgrade-Pfad. Die Versionshistorie zeigt den Takt. Zwischen v0.7.1 im Juli und v0.8.0 im September liegen drei Releases mit Änderungen, die Betriebsverhalten verschieben, etwa die Entfernung des lokalen Sandbox-Backends. Solche Schnitte verlangen, dass jemand die Release Notes vor jedem Update liest. Ein dritter Punkt: Multi-Tenancy mit Rollenmatrix und Audit-Log ist eine Zusage, die das README macht, aber nicht belegt. Wer mandantengetrennte Datenhaltung braucht, sollte die Zuordnung von Arbeitsbereich zu Speicher-Backend im eigenen Aufbau verifizieren, statt sie anzunehmen. Und schließlich: Der Agent führt Fremdcode aus. Ohne Container-Runtime und Netzwerkrichtlinie ist der sicherheitsrelevante Teil des Systems nicht in Betrieb.

Abgrenzung zu Dify und RAGFlow

Dify verfolgt einen anderen Ansatz: eine visuelle Workflow-Oberfläche, in der Prompts, Verzweigungen und Werkzeugaufrufe als Graph zusammengesteckt werden. Der Unterschied liegt nicht im Funktionsumfang, sondern in der Form der Kontrolle. Bei Dify ist der Ablauf explizit gezeichnet und damit für Nicht-Programmierer lesbar; bei WeKnora entscheidet der ReAct-Agent zur Laufzeit, welche Werkzeuge er in welcher Reihenfolge aufruft. Das macht WeKnora flexibler bei Aufgaben, deren Schritte sich vorher nicht aufzählen lassen, und schwerer nachvollziehbar, wenn ein Ergebnis falsch ist. RAGFlow setzt einen anderen Schwerpunkt: tiefes Dokumentenparsing mit Layout-Erkennung, um Tabellen und Spaltenstrukturen korrekt in Chunks zu überführen. WeKnora nennt zwar über zehn Formate und den anydoc-Parser, stellt aber die Wissenspflege über Wiki-Seiten und Chunk-Versionierung in den Vordergrund. Für einen Bestand aus komplexen Geschäftsberichten mit vielen Tabellen ist RAGFlow näher an der Problemstellung; für einen Bestand aus verstreuten Notizen und Wiki-Seiten, die aktuell gehalten werden sollen, liegt WeKnora näher. Beide Alternativen sind wie WeKnora selbst hostbar, was den Vergleich auf die Frage verengt, welcher Mechanismus zur eigenen Dokumentenform passt.

Redaktionelles Fazit

WeKnora passt zu Teams, die eine selbst gehostete Wissensbasis mit mehreren Mandanten, austauschbaren LLM- und Vektor-Backends und einem Agenten mit echter Sandbox-Isolation brauchen, und die bereit sind, den Go-Stack selbst zu betreiben. Wer eine reine Dokumenten-Q&A ohne Agenten, Sandbox und Wiki-Pflege sucht, trägt hier mehr Betriebsfläche als Nutzen. Vor der Einführung zuerst das Verzeichnis docs/ im Repository lesen, weil das README auf eine ausgelagerte Dokumentationsseite verweist und die Lizenzangabe NOASSERTION lautet, obwohl das Badge MIT nennt.

Offizielle Quellen

1. Issues
2. Project website
3. README
4. Releases
5. Tencent/WeKnora on GitHub