danghuangshang: ein Multi-Agent-System nach dem Vorbild der Ming-Kanzlei

Welche Lücke die Beamtenhierarchie schließt

Ein einzelner Chat-Assistent verliert bei längeren Aufgaben den Faden, sobald mehrere Fachgebiete betroffen sind. danghuangshang beantwortet das nicht mit einem größeren Modell, sondern mit Arbeitsteilung: Jede Aufgabe bekommt eine zuständige Stelle, und die Zuständigkeit ist im Rollenmodell festgeschrieben. Das README beschreibt die Zielgruppe als Nutzer, die auf Discord oder Feishu einen Agenten per Mention ansprechen und sofort eine Ausführung erwarten. Die sechs Ministerien decken dabei Softwareentwicklung (兵部), Finanzen (户部), Marketing (礼部), Betrieb (工部), Projektkoordination (吏部) und Justiz ab, dazu kommen 司礼监 als Eingangsstelle, 内阁 als Prompt-Optimierer und 都察院 als Prüfinstanz. Wer schon einmal versucht hat, einem einzelnen Agenten beizubringen, gleichzeitig Code zu schreiben und Budgets zu prüfen, erkennt das Muster: Der Kontext wird nicht geteilt, sondern über Zuständigkeit verteilt. Das ist der eigentliche Kern des Projekts, nicht die historische Staffage.

Der Weg einer Anweisung durch 司礼监, 内阁 und die sechs Ministerien

Das README zeigt zwei Betriebsarten. Im Standardpfad richtet der Nutzer eine Anweisung an 司礼监. Diese Stelle nimmt sie entgegen und leitet sie an 内阁 weiter, wo das Sprachmodell den Prompt anreichert: Absicht klären, Rückfragen erzeugen, einen Ausführungsplan bauen. Der optimierte Prompt samt Plan geht zurück an 司礼监, die ihn an die im Plan genannten Ministerien verteilt. Parallel existiert ein zweiter Pfad, in dem der Nutzer ein Ministerium direkt per Mention anspricht und 司礼监 vollständig überspringt. Das README empfiehlt den ersten Weg für komplexe Aufgaben und den zweiten für einfache. Bemerkenswert ist, dass die Prüfinstanz 都察院 nicht im regulären Fluss sitzt, sondern an ein Ereignis gekoppelt ist: einen Push nach GitHub. Erst dann läuft die Codeprüfung an, mit den Ergebnissen bestanden oder zurückgewiesen. Diese Ereignisbindung ist eine Designentscheidung mit Folgen. Wer nicht über GitHub arbeitet, bekommt die automatische Prüfung nicht, unabhängig davon, wie sorgfältig die übrigen Rollen besetzt sind.

Installation über full-install.sh, install-lite.sh und install-hermes.sh

Das README nennt vier Installationswege. Der lokale Weg klont das Repository und ruft bash scripts/full-install.sh auf. Der entfernte Weg zieht dasselbe Skript über curl, unter Windows über install.ps1 in PowerShell. Für Umgebungen mit vorhandenem OpenClaw existiert install-lite.sh, das nur Konfigurationsvorlagen setzt. Ein vierter Weg, install-hermes.sh, richtet dieselbe Rollenkonfiguration auf der Python-Laufzeitumgebung Hermes Agent von Nous Research ein; laut README können beide Laufzeiten parallel betrieben werden. Während der Installation wählt man eines von drei Regimen: ming-neige mit 18 Agenten, tang-sansheng oder modern-ceo mit jeweils 14. Der Wechsel erfolgt später über bash scripts/switch-regime.sh gefolgt vom Regimenamen. Konfiguriert werden ein LLM-API-Schlüssel und ein Discord-Bot-Token. Ein Detail, das man leicht überliest: Das README warnt, dass das ältere install.sh nicht zur entfernten Ausführung taugt und mit einem Fehler zum Pfad /dev/fd abbricht. Wer eine ältere Anleitung kopiert, läuft in genau diese Falle. Für Aktualisierungen nennt das Projekt scripts/safe-update.sh mit automatischer Sicherung, alternativ den manuellen Weg über git stash, git pull und git stash pop im Verzeichnis ~/clawd. Die Konfigurationsdatei ~/.openclaw/openclaw.json wird laut README automatisch gesichert, Arbeitsbereichsdateien wie MEMORY.md dagegen nicht.

allowBots: mentions ist keine Empfehlung, sondern eine Betriebsgrenze

Der sicherheitsrelevanteste Abschnitt des README betrifft nicht die Modellwahl, sondern die Bot-zu-Bot-Kommunikation. In der Discord-Konfiguration existiert der Schlüssel allowBots. Der Wert mentions bedeutet, dass ein Bot auf andere Bots nur reagiert, wenn er ausdrücklich erwähnt wird. Der Wert true hebt diese Einschränkung auf, und das README formuliert die Folge ungewöhnlich deutlich: Bots lösen sich gegenseitig aus und erzeugen einen Nachrichtenlawine. Neue Installationsskripte setzen mentions bereits als Vorgabe, ältere Konfigurationen möglicherweise nicht. Wer ein bestehendes System aktualisiert, sollte den Wert in ~/.openclaw/openclaw.json deshalb aktiv nachsehen. Ein zweiter Sicherheitshinweis datiert auf den 22. März 2026 und betrifft die Signaturprüfung eingehender Webhook-Aufrufe, mit Verweis auf docs/webhook-security.md. Beide Punkte zusammengenommen zeigen, wo die realen Risiken dieses Aufbaus liegen: nicht im Modellverhalten, sondern in der Verkettung mehrerer autonomer Bots, die auf denselben Nachrichtenkanal schreiben.

Drei Regime, drei Organisationslehren

Die Auswahl zwischen ming-neige, tang-sansheng und modern-ceo ist keine Kosmetik. Das Ming-Modell arbeitet mit einer Eingangsstelle und einem Optimierer, die den Verkehr bündeln; das README ordnet es Einzelprojekten zu. Das Tang-Modell verteilt den Ablauf auf drei Stationen mit gegenseitiger Prüfung, von der Ausarbeitung über die Kontrolle bis zur Ausführung, und richtet sich an Vorhaben mit strengeren Verfahrenswünschen. Das moderne Modell ersetzt die historischen Rollen durch CEO, Board und CxO und kommuniziert auf Englisch, was für international besetzte Teams naheliegt. Die Agentenzahl unterscheidet sich: 18 im Ming-Modell, 14 in den beiden anderen. Wer zwischen den Modellen wechselt, wechselt also nicht nur Bezeichnungen, sondern die Zahl der laufenden Bots und damit den Ressourcenbedarf. Das README behandelt diese Wahl als Einstiegsentscheidung, nicht als nachträgliche Anpassung. Sachlich ist das richtig, denn die Rollen sind über Skill-Dateien und Persona-Injektion an die Regime gebunden, und ein Wechsel per Skript setzt voraus, dass die Zielkonfiguration vollständig vorliegt.

Wo das Modell an seine Grenzen stößt

Die Prüfinstanz 都察院 hängt am GitHub-Push. Für Teams, die auf GitLab, Gitea oder einem internen Repository arbeiten, entfällt damit der einzige automatisierte Qualitätsfilter des Systems. Übrig bleibt eine Rollenhierarchie, die Aufgaben verteilt, aber Ergebnisse nicht eigenständig kontrolliert. Ein zweiter Punkt betrifft den Betriebsaufwand: Das README empfiehlt ausdrücklich einen Cloud-Server und rät von der Installation auf dem privaten Rechner ab. Das ist ein ehrlicher Hinweis darauf, dass hier nicht eine Bibliothek eingebunden, sondern eine dauerhaft laufende Bot-Flotte betrieben wird. Drittens ist der Kontext zwischen den Agenten nicht automatisch geteilt. Das README erwähnt eine Gedächtnisfunktion, beschreibt aber nicht, wie MEMORY.md zwischen den Ministerien abgeglichen wird, und verweist für Details auf die vollständige Dokumentation. Wer erwartet, dass 兵部 und 户部 denselben Projektstand kennen, sollte das vor dem Einsatz prüfen statt anzunehmen. Und schließlich: Das Projekt ist auf Chinesisch dokumentiert, mit englischer und japanischer Übersetzung der README. Die Betriebsdokumentation, auf die im Text verwiesen wird, liegt nach der Verzeichnisstruktur zu urteilen im Ordner docs und ist nicht in allen Teilen übersetzt.

CrewAI als Gegenentwurf: Prozess statt Plattform

Der naheliegende Vergleich ist CrewAI. Dort definiert man Agenten, Aufgaben und einen Prozess im Code der eigenen Anwendung; die Ausführung läuft im selben Prozess, die Ergebnisse kommen als Rückgabewerte an. danghuangshang geht den umgekehrten Weg: Die Agenten existieren als eigenständige Bots in Discord oder Feishu, und die Interaktion ist ein Chat, kein Funktionsaufruf. Der Unterschied zeigt sich im Betrieb. Bei CrewAI skaliert man die Anwendung, bei danghuangshang skaliert man die Zahl der Bot-Sitzungen, jede mit eigenem Token und eigener Konfiguration. Dafür bekommt man bei danghuangshang eine Bedienoberfläche, die kein eigenes Frontend benötigt, sowie Rollen, die ohne Programmieraufwand umbenannt oder ergänzt werden können. Das README selbst vergleicht das Projekt an einer Stelle mit ChatGPT, AutoGPT und CrewAI, ohne die Unterschiede im Einzelnen auszuführen. Wer die Agenten in eine bestehende Anwendung einbetten will, ist bei CrewAI richtig. Wer eine sichtbare, nebenläufig arbeitende Belegschaft in einem Chatwerkzeug möchte, bei danghuangshang.

Lizenz, Wartung und der Streit um die Urheberschaft

Das Projekt steht unter MIT-Lizenz. Das README bittet ausdrücklich darum, bei Fork und Weiterverwendung die Herkunft zu nennen und den Lizenztext zu behalten, und verweist auf eine Urheberschaftserklärung mit Zeitlinie: erster Beitrag auf einer chinesischen Plattform am 20. Februar 2025, vollständige Veröffentlichung auf GitHub zwei Tage später. In diesem Zusammenhang nennt das README namentlich ein Projekt namens Edict, dem eine hohe strukturelle Ähnlichkeit ohne Quellenangabe vorgeworfen wird. Für die Adoptionsentscheidung ist dieser Streit insofern relevant, als er die Herkunft der Architektur betrifft, nicht den Lizenztext. Die MIT-Lizenz erlaubt kommerzielle Nutzung und Veränderung; die Bitte um Namensnennung ist eine soziale Erwartung, keine Lizenzbedingung. Wer das Projekt in einem kommerziellen Umfeld einsetzt, sollte dennoch die genannten Dateien docs/originality.md und die Lizenzdatei selbst lesen, statt sich auf die Zusammenfassung im README zu verlassen. Zur Wartung: Der letzte Push datiert auf den 22. Mai 2026, die jüngste Veröffentlichung v3.0 auf den 12. März 2026 und trägt die Bezeichnung Dokumentationsumbau, Docker-Image und Abdeckung aller Plattformen. Ob und in welchem Umfang nach v3.0 weitere Änderungen an den Installationsskripten erfolgt sind, lässt sich aus dem vorliegenden Material nicht ableiten. Wer auf einem älteren Stand sitzt, sollte vor dem Update die Sicherung von MEMORY.md und der Arbeitsbereichsdateien selbst vornehmen, da scripts/safe-update.sh laut README nur ~/.openclaw/openclaw.json automatisch sichert.

Redaktionelles Fazit

Sinnvoll ist danghuangshang für Teams, die mehrere Discord- oder Feishu-Bots dauerhaft betreiben wollen und bereit sind, die Flottenkonfiguration selbst zu pflegen. Wer nur einen einzelnen Assistenten braucht oder keine Serverinstanz betreiben möchte, ist mit einem Framework wie CrewAI besser bedient, weil dort die Agenten im Prozess der Anwendung laufen statt als eigenständige Bots. Vor dem Einsatz sollte man prüfen, welche der drei Regime über switch-regime.sh tatsächlich zum eigenen Ablauf passen, ob die Datei ~/.openclaw/openclaw.json nach dem Installationslauf den Wert mentions für allowBots enthält und ob die eigene Umgebung die im README genannte Empfehlung erfüllt, die Installation auf einem Cloud-Server statt auf einem Arbeitsplatzrechner vorzunehmen.

Offizielle Quellen

1. License: MIT
2. Project website
3. README
4. Releases
5. wanikua/danghuangshang on GitHub