Edict: Multi-Agent-Orchestrierung nach dem Drei-Behörden-Modell

Edicts Pipeline von taizi bis shangshu in vier Stufen

Edict organisiert Multi-Agent-Arbeit als feste Kette: Eine eingehende Nachricht erreicht zuerst taizi, der zwischen Smalltalk und echtem Auftrag unterscheidet, nur Aufträge werden zu Aufgaben. Danach plant zhongshu, zerlegt Anfragen in Teilaufträge und entwirft einen Lösungsansatz. menxia prüft diesen Plan, shangshu verteilt die freigegebenen Teilaufträge an die Fachabteilungen, die parallel arbeiten, und sammelt die Ergebnisse. Laut README besteht die Vollbesetzung aus zwölf Agenten, elf Fachrollen plus einer Kompatibilitätsrolle, mit einem strengen Rechte-Matrix-Modell, das festlegt, welcher Agent wen anschreiben darf. Jeder Agent erhält einen eigenen Workspace, eigene Skills und ein eigenes Modell. Die Metapher aus dem alten Beamtenwesen ist im README bewusst gewählt, der eigentliche Nutzen liegt in der Trennung von Planung, Prüfung und Ausführung, die drei getrennte Agenten erzwingt.

menxia-Review als erzwungene Qualitätsstufe vor der Ausführung

Der Hauptunterschied zu anderen Rahmenwerken liegt laut Projektvergleich in der Review-Stufe. Während CrewAI und AutoGen-Konstellationen typischerweise Ergebnisse direkt abliefern, prüft menxia jeden Plan, bevor er ausgeführt wird: Ist die Zerlegung vollständig, sind die Teilaufträge sinnvoll geschnitten. Unzureichende Pläne werden nicht mit einer Warnung versehen, sondern zurückgewiesen, es folgt eine erneute Planungsrunde, bis der Plan die Prüfung passiert. Die README betont, dass dieses Verfahren kein optionales Plugin ist, sondern Teil der Architektur, jeder Auftrag muss durch diese Stufe, ohne Ausnahme. Ob dieses Modell in der Praxis Zeit spart oder nur Durchläufe verbraucht, hängt vom Aufgabentyp ab; für einfache Anfragen ist die Pipeline erkennbar Überhang, für mehrstufige Aufträge mit Risiko die eigentliche Zielgruppe.

Kanban-Dashboard mit kanban_update.py und Audit-Spur

Das Dashboard mit dem Namen 军机处 besteht aus zehn Bedienfeldern. Das Kanban-Board zeigt Aufgaben nach Statusspalten, mit Filterung nach Behörde, Volltextsuche und Statusabzeichen, die Aktivität, Stagnation oder Alarm markieren, gestützt auf Herzschlag- und Aktivitätsprüfung der Agenten. Eine zentrale Komponente ist kanban_update.py, das Übergänge zwischen Status prüft und illegale Sprünge verweigert, die Aufgabenliste kann also nicht durch willkürliche Updates korrumpiert werden. Abgeschlossene Aufträge werden als Memorials archiviert, mit einer fünfstufigen Zeitleiste vom Eingang über Planung und Prüfung bis zur Rückmeldung, und lassen sich als Markdown kopieren. Dazu kommen ein Monitor mit Balkendiagrammen zur Verteilung, eine Token-Rangliste aller Agenten sowie Sitzungsansichten für OC-Konversationen mit Quellkanal und Nachrichtenverlauf.

Aufsetzen über install.sh, openclaw.json und SOUL.md

Voraussetzung für den echten Betrieb ist eine bestehende OpenClaw-Installation, dazu Python 3.10 oder neuer und macOS oder Linux. Der Weg im README: git clone https://github.com/cft0808/edict.git, dann cd edict und chmod +x install.sh && ./install.sh. Das Skript erzeugt alle Agent-Workspaces, schreibt in jedes eine SOUL.md mit Rollenprofil, Arbeitsablaufregeln und Datensäuberungsregeln, registriert die Agenten samt Rechte-Matrix in openclaw.json und verknüpft die data- und scripts-Verzeichnisse per Symlink mit dem Projektordner. Außerdem setzt es sessions.visibility all, damit Nachrichten zwischen Agenten überhaupt ankommen, und synchronisiert API-Schlüssel von einem konfigurierten Agenten auf alle übrigen. Beim ersten Lauf gilt ein Reihenfolgehinueis aus der README: zuerst mit openclaw agents add taizi einen Schlüssel eintragen, danach install.sh erneut ausführen. Der Frontend-Bau benötigt Node.js 18 oder neuer und wird übersprungen, falls Node fehlt.

Docker-Demo auf Port 7891 mit --platform linux/amd64

Ohne OpenClaw lässt sich das System ansehen: docker run -p 7891:7891 cft0808/sansheng-demo startet einen Container mit vorgespielten Daten, das Dashboard liegt dann unter http://localhost:7891. Auf x86- oder amd64-Maschinen wie Ubuntu oder WSL2 meldet das Image laut README einen exec format error; der Ausweg ist docker run --platform linux/amd64 -p 7891:7891 cft0808/sansheng-demo oder docker compose up, dessen Compose-Datei die Plattformangabe bereits enthält. Für die Produktion liegt eine systemd-Einheit bei: edict.service nach /etc/systemd/system/ kopieren, daemon-reload, dann enable und start; alternativ steuert bash edict.sh mit start, status, restart und stop den Dienst. Der schnelle Start ohne Docker läuft über ./start.sh oder getrennt über bash scripts/run_loop.sh für den Datenaktualisierungszyklus und python3 dashboard/server.py für den Dashboardserver, danach öffnet man http://127.0.0.1:7891.

Modellwechsel im Dashboard und Feishu-Nachrichtenpush

Das Bedienfeld für Modelle erlaubt es, jedem Agenten ein anderes LLM zuzuordnen und den Wechsel direkt aus dem Dashboard vorzunehmen; nach dem Anwenden startet der Gateway neu und die Änderung greift laut README in etwa fünf Sekunden. Das ist praktisch, weil Planungs- und Prüfaufgaben oft von einem anderen Modell profitieren als Ausführungsaufgaben, die Kostenkontrolle bleibt wegen der Token-Rangliste sichtbar. Das Skills-Panel listet installierte Fähigkeiten je Behörde und erlaubt das Hinzufügen neuer. Ein eigenes Panel sammelt tägliche Technologie- und Finanznachrichten und kann als Sammlung über Feishu pushen, eine Zusatzfunktion, die mit der Orchestrierung selbst wenig zu tun hat. Die Befehlskette startet der Nutzer über die Vorlagenbibliothek mit neun vorbereiteten Auftragsvorlagen, deren Formulare eine Zeit- und Kostenschätzung anzeigen, bevor der Auftrag abgeschickt wird.

Vergleichstabelle zu CrewAI, MetaGPT und AutoGen samt Grenzen

Die README vergleicht sich direkt mit CrewAI, MetaGPT und AutoGen und beansprucht Unterschiede bei Review-Pflicht, Live-Dashboard, Eingriffsmöglichkeiten wie Anhalten, Abbrechen und Fortsetzen, Audit-Ablage, Agent-Überwachung, heißem Modellwechsel und einfachem Einsatz. Diese Tabelle ist Selbstauskunft, ein eigener Test fehlt ihr gegenüber. Für die Bewertung zählt aber, was das Projekt real bietet: eine installierbare Pipeline mit sichtbarem Ablauf und Zwangs-Review, die an OpenClaw gebunden bleibt. Die Metadaten zeigen Python als Sprache, MIT als Lizenz, 16.713 Sterne, 1.749 Forks und 25 offene Issues auf dem main-Zweig, die Releases-Liste ist leer, Versionen sind also über den Repository-Stand zu verfolgen. Die Dokumentation liegt in docs/getting-started.md und docs/task-dispatch-architecture.md, README-Varianten in Englisch und Japanisch stehen daneben, das Archiv-Dokument auf Englisch nennt sich selbst OpenClaw Multi-Agent Orchestration System.

Redaktionelles Fazit

Edict passt für Entwickler, die ohnehin OpenClaw betreiben und eine Multi-Agent-Kette mit sichtbarem Ablauf, eingreifbarer Kanban-Oberfläche und dokumentierter Audit-Spur wollen, etwa für Aufgaben mit Planungs- und Review-Bedarf. Unpassend ist es ohne OpenClaw-Grundlage, auf Windows ohne Docker und für alle, die einen fertigen Produkt-Dienst suchen, denn die Releases-Liste ist leer und der Betrieb läuft über eigene Skripte. Vor dem echten Einsatz sollte der vorbereitete Demo-Container cft0808/sansheng-demo auf Port 7891 geprüft werden, um zu sehen, ob Kanban und Zustandsmodell zur eigenen Arbeitsweise passen.

Offizielle Quellen

1. Official documentation
2. Official README
3. Project repository