UnicomAI/wanwu: Eine Go-Plattform für Agenten, Workflows und RAG im Unternehmen

Welches Problem wanwu löst und für wen es gedacht ist

Der README beschreibt Wanwu als Plattform für Forward Deployed Engineers (FDEs), also für Personen, die beim Kunden vor Ort ein KI-Projekt von der Idee bis zum laufenden Betrieb bringen. Der Ausgangspunkt ist die Beobachtung, dass Unternehmen nicht an einzelnen Modellaufrufen scheitern, sondern an der Verteilung der Bausteine: Dokumente liegen in einem System, strukturierte Geschäftsdaten in einem anderen, Freigabeprozesse in einem dritten, und Altbestände ohne API in einem vierten. Wanwu versucht, diese vier Fälle in einer Oberfläche zusammenzuführen. Die fünf genannten Kernbausteine sind RAG, Ontologie-Agent, Workflow-Agent, GUI-Agent und ein General Agent mit Skill-Entwicklung. Dass die Plattform mehrinstanzfähig ist und auf Unternehmen abzielt, steht in der Projektbeschreibung. Für wen das konkret passt: Integratoren, die mehr als einen Kunden mit derselben Basis bedienen wollen, und interne Plattformteams, die Fachbereiche mit Vorlagen versorgen. Wer nur eine Bibliothek sucht, um einen einzelnen Agenten in eine bestehende Anwendung einzubetten, bekommt hier sehr viel mehr mitgeliefert als benötigt.

Fünf Bausteine, ein gemeinsames Datenmodell

Die Architektur lässt sich aus dem README nur in Umrissen ablesen. Erkennbar sind fünf Bausteine, die auf gemeinsame Unternehmensressourcen zugreifen. Der RAG-Baustein verarbeitet laut README zwölf Dateiformate und URL-Crawling, unterstützt OCR und private MinerU-Deployments, multimodale Suche, kaskadiertes und adaptives Chunking, Ranking und Quellenangaben. Darüber liegt UniAI-GraphRAG mit Ontologiemodellierung für domänenspezifische Zusammenhänge, das laut README die Vollständigkeit bei dokumentübergreifenden Zusammenfassungen und Mehrfachschritt-Schlussfolgerungen verbessern soll. Der Ontologie-Agent baut aus Unternehmensdaten und Dokumenten ein Wissensnetz, um strukturierte Daten in die Schlussfolgerung einzubeziehen. Der Workflow-Agent bietet eine Low-Code-Canvas mit Verzweigungen, API-Aufrufen, LLM-Knoten, Wissensdatenbanken, Code und MCP. Der GUI-Agent arbeitet auf der Oberfläche von Anwendungen statt über deren API und führt Aktionen laut README in isolierten Docker-Containern pro Bot aus. Der General Agent schließlich soll Skills per natürlichem Sprachbefehl erzeugen und Plattform-Apps per Klick in Skills umwandeln. Das gemeinsame Muster: Alle Bausteine greifen auf dieselben Unternehmensressourcen zu, statt jeweils eigene Datenhaltung aufzubauen. Ob das in der Implementierung tatsächlich so sauber getrennt ist, lässt sich aus dem Material nicht belegen.

Einbindung fremder Wissensdatenbanken als pragmatischer Kompromiss

Eine der konkreteren Angaben im README betrifft die Kompatibilität: Wissensdatenbanken, die in Dify angelegt wurden, sollen sich per API importieren und in Agenten, Chat und Workflows zur Suche nutzen lassen. Das ist bemerkenswert, weil es einen Migrationspfad anbietet, statt einen Neuanfang zu erzwingen. Wer bereits Dify betreibt, muss seine Dokumentenbestände nicht neu indexieren, sondern kann sie über die API anbinden. Der Preis dafür steht nicht im README: Ein solcher Import bedeutet in der Regel, dass ein Teil der Retrieval-Kette außerhalb der Plattform bleibt und die Qualität der Ergebnisse von zwei Systemen abhängt. Wer GraphRAG-Funktionen nutzen will, wird um eine eigene Indexierung in wanwu ohnehin nicht herumkommen, da die Graph-Anreicherung an die interne Verarbeitung gebunden ist. Die Dify-Anbindung ist damit eher ein Übergang als ein dauerhafter Betriebszustand.

Drei Auslieferungswege und ihre unterschiedlichen Anforderungen

Der README nennt drei Wege, die Plattform zum Kunden zu bringen. Erstens die fertige Plattform über die visuelle Oberfläche, ohne Programmierung für Agenten, Workflows und Frage-Antwort-Anwendungen. Zweitens die Einbettung über eine RESTful-API, die der README als BaaS bezeichnet, gedacht für OA-, CRM- und ERP-Systeme, mit feingranularer Rechteverwaltung. Drittens Skills in Kombination mit dem UniClaw-Client für Szenarien mit hohen Rechten, etwa lokale PC-Steuerung oder DingTalk-Nachrichten. Der dritte Weg ist der aufwendigste und der am wenigsten dokumentierte: Der Client wird über einen Baidu-Pan-Link verteilt, nicht über ein Paket-Repository. Für regulierte Umgebungen ist das ein Prüfpunkt, denn ein Download über einen Filehoster lässt sich schlechter in einen Software-Lieferprozess mit Prüfsummen und Herkunftsnachweis einbinden als ein signiertes Release-Artefakt. Der zweite Weg ist der technisch klarste, weil eine REST-Schnittstelle ohne Client-Installation auskommt. Der erste Weg eignet sich für schnelle Validierung vor Ort, verlagert aber die Betriebsverantwortung vollständig auf das Team, das die Plattform aufsetzt.

Betrieb, Versionen und was der README nicht sagt

Die Sprachversion ist Go, das README nennt in den Badges Go 1.24.0 oder neuer als Voraussetzung. Die letzten Releases sind v0.6.4 vom September 2026, davor v0.6.2 und v0.6.1 im Juli 2026. Die Versionsnummern im 0.6-Bereich und die Abstände zwischen den Veröffentlichungen deuten auf ein Projekt in aktiver Entwicklung, dessen Schnittstellen sich noch ändern können. Wer wanwu einführt, sollte damit rechnen, dass ein Upgrade nicht nur ein neues Binary bedeutet, sondern möglicherweise Anpassungen an Workflow-Definitionen oder Agenten-Konfigurationen. Konkrete Angaben zu Datenbank-Backends, Migrationsskripten, Backup-Verfahren, Konfigurationsdateien oder Umgebungsvariablen enthält das vorliegende Material nicht. Auch zu den Ressourcenanforderungen für den Betrieb mit OCR, MinerU und GraphRAG findet sich nichts. Das ist eine erhebliche Lücke für eine Plattform, die sich an Unternehmen richtet, denn die Kosten für OCR- und Graph-Verarbeitung fallen laufend an und lassen sich ohne Angaben nicht abschätzen. Wer eine Kapazitätsplanung braucht, muss sie aus einem eigenen Testaufbau gewinnen.

Grenzen des GUI-Agenten und Fälle, in denen wanwu das falsche Werkzeug ist

Der GUI-Agent ist der interessanteste und zugleich der riskanteste Baustein. Er arbeitet auf der Benutzeroberfläche von Anwendungen, die keine API anbieten, und führt seine Aktionen laut README in isolierten Docker-Containern pro Bot aus. Die Isolation ist sinnvoll, weil ein fehlgeleiteter Klick in einer Produktivoberfläche Schaden anrichten kann. Sie hilft aber nicht gegen das eigentliche Problem: Oberflächen ändern sich. Ein Update der Zielanwendung kann Koordinaten, Beschriftungen oder Dialogreihenfolgen verschieben und damit einen funktionierenden Ablauf unbrauchbar machen. Solche Agenten brauchen deshalb mehr Pflege als API-basierte Integrationen, nicht weniger. Für Prozesse, bei denen ein Fehler finanzielle oder rechtliche Folgen hat, ist ein auf Bilderkennung und Klicks basierender Agent ohne zusätzliche Absicherung schwer zu verantworten. Wanwu ist außerdem das falsche Werkzeug, wenn ein Team lediglich eine Prompt-Bibliothek oder einen einzelnen Chatbot mit einer Wissensdatenbank sucht. Der Betriebsaufwand für die Plattform steht in keinem Verhältnis zum Nutzen in solchen Fällen. Und wer ausschließlich mit einem einzigen LLM-Anbieter arbeitet und keine Mandantentrennung braucht, findet in schlankeren Bibliotheken einen kürzeren Weg.

Abgrenzung zu Dify und zu Agenten-Frameworks

Der naheliegendste Vergleich ist Dify, schon weil wanwu dessen Wissensdatenbanken importieren kann. Der Unterschied liegt im Schwerpunkt. Dify ist als LLMOps-Plattform um Anwendungen, Prompts und Wissensdatenbanken herum gebaut. Wanwu setzt zusätzlich auf den Ontologie-Agenten für strukturierte Geschäftsdaten und auf den GUI-Agenten für Systeme ohne API. Wer nur RAG und Chat braucht, fährt mit Dify einfacher, weil weniger Komponenten zu betreiben sind. Wer dagegen einen Freigabeprozess mit Verzweigungen, einen Altbestand ohne Schnittstelle und eine Wissensdatenbank in einem System abbilden muss, stößt bei reinen LLMOps-Werkzeugen an Grenzen. Eine zweite Abgrenzung betrifft Go-Frameworks für Agenten: Diese liefern Bausteine im Code, die ein Entwicklungsteam selbst verdrahtet. Wanwu liefert stattdessen eine laufende Plattform mit Oberfläche, Rechteverwaltung und Mandantenfähigkeit. Das ist der entscheidende Unterschied im Aufwand: Bei einem Framework schreibt man die Anwendung, bei wanwu betreibt man ein System. Wer die Kontrolle über jede Schicht behalten will, wird mit einem Framework glücklicher, auch wenn er mehr selbst bauen muss.

Lizenz, Wartungskosten und der erste Prüfschritt

Die Lizenz ist Apache-2.0, was die kommerzielle Nutzung, Veränderung und Weitergabe erlaubt, sofern die Lizenzbedingungen und Urheberrechtshinweise erhalten bleiben. Für Unternehmen ist das eine der unkomplizierteren Ausgangslagen, weil keine Copyleft-Pflichten auf eigene Änderungen durchschlagen. Das README spricht von einer entwicklerfreundlichen Lizenz und lädt ausdrücklich zum Aufbau auf der Plattform ein. Was die Lizenz nicht regelt, sind die Abhängigkeiten: OCR, MinerU, GraphRAG-Komponenten und der UniClaw-Client können eigene Bedingungen mitbringen, die im vorliegenden Material nicht aufgeführt sind. Eine Prüfung der Abhängigkeitsliste vor dem produktiven Einsatz ist daher sinnvoll, ersetzt aber keine Rechtsberatung. Bei den Wartungskosten ist der Rhythmus der Releases der wichtigste Anhaltspunkt: drei Veröffentlichungen zwischen Juli und September 2026 bedeuten, dass ein Team regelmäßig Zeit für Upgrades einplanen muss. Dazu kommt der Aufwand für die Pflege von GUI-Agenten, deren Abläufe bei Oberflächenänderungen nachgezogen werden müssen. Der erste konkrete Prüfschritt vor einer Entscheidung ist ein Testaufbau mit einer echten Dokumentensammlung des Zielkunden, um zu sehen, ob die zwölf angegebenen Dateiformate und das Chunking für die vorhandenen Unterlagen tragen, und ob die Antworten die Quellenangaben liefern, die der README zusagt.

Redaktionelles Fazit

Wer eine mehrinstanzfähige Agentenplattform mit RAG, Workflow-Canvas und GUI-Automatisierung sucht und bereit ist, die Betriebsdetails selbst zu prüfen, findet in wanwu einen Apache-2.0-lizenzierten Ausgangspunkt. Wer eine schlanke Bibliothek für einen einzelnen Agenten ohne Plattformbetrieb braucht, ist hier falsch. Vor dem Einsatz zu klären: ob die Go-Version 1.24.0 oder neuer in der Zielumgebung verfügbar ist, wie sich die Mandantentrennung in der gewählten Deployment-Variante konfigurieren lässt und ob der GUI-Agent-Client aus dem verlinkten Baidu-Pan-Paket bezogen werden kann.

Offizielle Quellen

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. UnicomAI/wanwu on GitHub