Ich habe ein KI-Betriebssystem mit 5 Rollen und OpenClaw entwickelt: Eine vollständige technische Analyse

Ich habe viel Zeit damit verbracht, OpenClaw von einem einzelnen Assistenten in ein kollaboratives Multi-Rollen-Betriebssystem zu verwandeln. Es geht nicht nur darum, "ein paar Bots zum separaten Chatten zu öffnen."

5 KI-Rollen, die sich einen Gateway teilen, auf Discord- und Telegram-Dual-Kanälen laufen, mit klarer Arbeitsteilung, Routing, Speicherisolation und Kollaborationsregeln, die wie ein Team im Staffellauf zusammenarbeiten können.

In diesem Artikel zerlege ich den gesamten Konstruktionsprozess, die Designentscheidungen auf jeder Ebene, die spezifischen Konfigurationen und die Fallstricke, auf die ich gestoßen bin.

Wenn du auch OpenClaw verwendest oder dich dafür interessierst, "wie man mehrere KIs wirklich zusammenarbeiten lässt", sollte dir dieser Beitrag helfen, viele Umwege zu vermeiden.

Fazit vorab: Das ist kein "Multi-Bot", sondern ein Multi-Agenten-Betriebssystem unter einem einzigen Gateway

Wenn viele Leute "5 KI-Rollen" hören, ist ihre erste Reaktion: Du betreibst 5 unabhängige Bots, oder?

Ja, aber auch nein.

Meine Architektur sieht so aus:

• 1 Gateway-Prozess, der Kanalzugriff und Routing vereinheitlicht
• 5 unabhängige Agents: Commander, Stratege, Ingenieur, Kreator, Denker
• Jeder Agent hat seinen eigenen unabhängigen Arbeitsbereich (Persönlichkeit, Regeln, Speicher und Sitzungen sind alle isoliert)
• Gleichzeitiger Betrieb von Discord- + Telegram-Dual-Kanälen (kann viele Plattformen ausführen, aber ich verwende nur Discord), mit Bindings für präzise Nachrichtenverteilung
• Privat- und Gruppenchats verwenden völlig unterschiedliche Mechanismen

Eine Analogie: Das ist nicht, 5 Leute einzustellen und sie in einen Raum zu werfen, um sich frei zu verhalten. Das ist, ein Unternehmen zu gründen – mit einer Organisationsstruktur, Stellenbeschreibungen, Kommunikationsprotokollen, unabhängigen Büros und Besprechungsregeln.

OpenClaw selbst ist ein Open-Source-Framework für persönliche KI-Assistenten, das mehrere Plattformen (Discord, Telegram, WhatsApp usw.) und mehrere Modelle (Claude, GPT, Gemini usw.) mit vollständig lokalisierten Daten unterstützt.

Seine Multi-Agenten-Fähigkeit ist der Kerngrund, warum ich mich dafür entschieden habe – native Unterstützung für unabhängige Arbeitsbereiche mehrerer Agents + Bindings-Routing, was es mir ermöglichte, ein echtes kollaboratives System darauf aufzubauen.

1. Gesamtarchitektur: Single Gateway + Multi-Agent + Multi-Workspace + Multi-Channel

Lass uns zuerst über die grundlegenden Architekturentscheidungen sprechen.

1) Einheitliches Hosting über einen einzigen Gateway

Ich habe derzeit einen OpenClaw-Gateway-Prozess, der alle Fähigkeiten trägt – Nachrichtenzugriff, Routing, Sitzungsverwaltung, Tool-Aufrufe, Speicherindizierung und Zustandsverwaltung, alles in einem Gateway.

Warum nicht für jede Rolle einen eigenen Satz von Diensten betreiben? Drei Gründe:

• Zentrale Wartung: Nur ein Gateway zu warten, kein Bedarf, unabhängige Dienste für jede Rolle zu betreiben.
• Einheitliche Konfiguration: Eine Master-Konfiguration verwaltet globale Strategien, und Überwachung/Fehlerbehebung sind ebenfalls zentralisiert.
• Kollaborationsgrundlage: Damit Rollen zusammenarbeiten können, müssen sie sich zur effizienten Kommunikation in derselben Laufzeitumgebung befinden.

2) 5 parallele Agents, nicht 5 lose Bots

Meine 5 festen Rollen:

• Commander (zongzhihui): Globales Situationsbewusstsein, Aufgabenzerlegung, -zuweisung, -korrektur und -abschluss.
• Stratege (junshi): Strategische Analyse, Vorschlagsbewertung und Risikovorhersage.
• Ingenieur (engineer): Technische Ausführung, Code-Implementierung und Systemwartung.
• Kreator (creator): Inhaltserstellung, Ausdrucksoptimierung und externe Ausgabe.
• Denker (zhiku): Wissensprüfung, Qualitätskontrolle und Compliance-Checks.

Jeder Agent hat seinen eigenen Arbeitsbereich, wie workspace-engineer, workspace-junshi usw. Persönlichkeitsdateien, Regeldateien, Speicherdateien und Skript-Assets sind alle unabhängig und kontaminieren sich nicht gegenseitig.

3) Multi-Channel-Dual-Stack-Zugriff: Discord + Telegram

Derselbe Gateway ist sowohl mit Discord als auch mit Telegram verbunden. Jede Rolle hat accountId-level Bindings auf beiden Kanälen. Natürlich kannst du mit derselben Konfigurationsdatei auch weitere Plattformen wie Lark, WeChat usw. integrieren.

Das ist keine "doppelte Bereitstellung über Plattformen hinweg", sondern "derselbe Gehirncluster, verschiedene Zugriffsebenen". Ich habe Discord als das Hauptkollaborationsschlachtfeld konfiguriert.

Wenn du möchtest, dass mehrere Agents innerhalb einer Gruppe kooperieren und zusammenarbeiten, wähle einfach Discord; eine Plattform reicht aus. Andere sind nicht perfekt, ich habe sie ausprobiert!!!

2. Routing-Ebene: Bindings, die "Konten" auf "Rollen" abbilden

Das ist die Eingangslogik des gesamten Systems.

Ich habe eine explizite Binding-Strategie für Dual-Kanäle konfiguriert: channel + accountId -> agentId.

Konkret:

• discord + zongzhihui -> zongzhihui
• discord + engineer -> engineer
• telegram + creator -> creator
• ... insgesamt 10 Zuordnungen (5 Rollen × 2 Kanäle)

Warum das tun?

Weil das System auf der Eingangsebene entscheidet, "wer diese Nachricht behandeln soll", anstatt alle Agents hören zu lassen und dann um die Antwort zu konkurrieren. Wenn dieser Schritt nicht gut gemacht ist, wird jede nachfolgende Zusammenarbeit chaotisch.

Du kannst dir Bindings als die "Empfangstriage" dieses Systems vorstellen. Wenn eine Nachricht hereinkommt, wird zuerst geprüft, welcher Kanal und welches Konto sie erhalten hat, und dann wird sie direkt an die entsprechende Rolle weitergeleitet – sauber und effizient.

3. Sitzungsisolation: Warum sich private Chats nicht überschneiden und Gruppenchats nicht chaotisch sind

Dies ist einer der kritischsten Engineering-Punkte in meinem System.

Kernkonfiguration: session.dmScope = per-account-channel-peer

Dieser Parameter bedeutet: Der Privatchat-Kontext wird durch drei Dimensionen isoliert: "Konto + Kanal + Peer-Benutzer."

Warum diese Wahl?

• Wenn dieselbe Person dieselbe Rolle über Discord und Telegram kontaktiert, überschneiden sich die Kontexte nicht.
• Wenn verschiedene Benutzer dieselbe Rolle kontaktieren, sind die Kontexte vollständig isoliert.
• In Multi-Agent- + Multi-Account-Szenarien wird das Risiko von "Übersprechen" minimiert.

Mit anderen Worten, ich habe nicht nur "Multi-Rollen" erstellt; ich habe auch "Kontextisolationsstrategie-Engineering" betrieben.

Viele Leute bauen Multi-Agent-Systeme, in denen die Rollen klar geteilt sind, aber die Kontextverwaltung ein Chaos ist – der Inhalt von Privatchat von Benutzer A landet in der Antwort von Benutzer B, oder die Discord-Konversationserinnerung kontaminiert den Telegram-Kontext.

per-account-channel-peer ist die von OpenClaw für Multi-Account-Szenarien empfohlene Isolationsstrategie, und meine Tests zeigen, dass es tatsächlich die stabilste Wahl ist.

4. Gruppenchat-Orchestrierung: Regelgesteuerte Zusammenarbeit, kein freies Chatten

Dieser Teil ist der interessanteste und hat die meisten Fallstricke.

Kernstrategie: Commander Globales Zuhören + Andere Rollen @ Ausgelöst

Meine Gruppenchat-Strategie auf der Discord-Seite sieht wie folgt aus:

Commander: requireMention = false (Globales Zuhören)

• Kann standardmäßig alle Nachrichten in der Gruppe sehen.
• Verantwortlich für das Erfassen der globalen Situation, das Beurteilen, ob Zusammenarbeit erforderlich ist, das Durchführen von Aufgabenzerlegung und das Zuweisen von Arbeit.

Andere 4 Rollen: `requireMention = true` (@ Ausgelöst)

• Handeln nur, wenn sie explizit @erwähnt werden.
• Reduziert Rauschen und vermeidet, dass sie sich gegenseitig überschreien.

Jede Rolle ist mit `mentionPatterns` konfiguriert

• Zum Beispiel kann der Ingenieur durch @Engineer oder [@engineer](https://x.com/@engineer) ausgelöst werden.
• Macht das Herbeirufen in der Gruppe stabiler und vorhersehbarer.

Was ist das Wesen dieser Kombination?

• Der Commander "sieht das große Ganze", wie ein PM in einem Team.
• Spezialisierte Rollen werden "bei Bedarf ausgelöst", wie Experten in verschiedenen Positionen.
• Die Gruppenkommunikation ändert sich von "frei" zu "kontrolliertem Staffellauf".

Praktischer Effekt: Du stellst eine Frage in der Gruppe, der Commander beurteilt zuerst, um welche Art von Aufgabe es sich handelt, @erwähnt dann die entsprechende Rolle, um sie zu bearbeiten. Sobald die Rolle fertig ist, schließt der Commander den Kreis. Der gesamte Prozess ist wie ein echtes Team, das ein Meeting abhält.

5. Discord vs. Telegram: Warum Discord das Hauptschlachtfeld ist

Streng genommen liegt es nicht daran, dass "nur Discord zusammenarbeiten kann". Es ist nur so, dass Discord unter meiner aktuellen Konfiguration am besten für die Multi-Rollen-öffentliche Kollaborationsorchestrierung geeignet ist.

Konkrete Gründe:

1. Ich habe 5 parallele Konten auf Discord konfiguriert + einen klaren @Kollaborationsmechanismus.
2. Rollenidentitäten, Gesprächsketten und der Staffellaufprozess sind alle sichtbar – es sieht aus wie eine Teamdiskussion.
3. Die Strategie des globalen Zuhörens des Commanders + der Erwähnungs-Gate der anderen Rollen ist in Gruppenchatszenarien intuitiver.
4. Ich habe derzeit die Discord groupPolicy auf open gesetzt, was eine höhere Flexibilität bietet.

Auf der Telegram-Seite tendiert meine Strategie zu allowlist + mention gate, was eingeschränkter und sicherer ist, geeignet für "kontrollierte Produktionskanäle".

Die Zusammenfassung ist also: Discord ist die Kollaborationsbühne.

6. Konfigurationsebene + Prompt-Ebene: Dual-Track-Governance

Dies ist der größte Unterschied zwischen diesem System und "nur herumspielen".

Ich verlasse mich weder ausschließlich auf die Konfiguration noch ausschließlich auf Prompts. Ich verwende zwei sich überschneidende Tracks.

A. Konfigurations-Track (Plattformebenen-Kontrolle)

Dies sind harte Konfigurationen auf der OpenClaw-Plattformebene:

• Kanalrichtlinie: groupPolicy, dmPolicy, steuert grundlegende Strategien für Gruppen- und Privatchats.
• requireMention: Wer muss standardmäßig @erwähnt werden, um zu antworten.
• bindings: Nachrichten-Routing-Zuordnung.
• dmScope: Sitzungsisolationsgranularität.
• agentToAgent Ping-Pong-Limit: Ich habe dies auf 0 gesetzt, um sinnloses Hin und Her zwischen Agents direkt zu unterdrücken.

Der letzte Punkt ist entscheidend – wenn du das Ping-Pong zwischen Agents nicht begrenzt, siehst du zwei KIs in einer Gruppe, die höflich sind, sich gegenseitig bestätigen und sich endlos im Kreis drehen. Es auf 0 zu setzen, sagt dem System: Agents sollten sich nicht automatisch anpingen.

B. Regel-Track (Verhaltensebenen-Kontrolle)

Dies sind die Regeldateien, die ich in jedem Arbeitsbereich geschrieben habe:

• SOUL.md: Die Seelendatei der Rolle – Persönlichkeit, Ton, Verantwortlichkeiten und Qualitätsniveau der Ausgabe.
• AGENTS.md: Betriebshandbuch – Kollaborationscheckprozesse, Speicher-Lese-/Schreibnormen und Lazy-Loading-Strategien.
• ROLE-COLLAB-RULES.md: Rollenspezifische Kollaborationsgrenzen und rote Linien.
• TEAM-RULEBOOK.md: Einheitliche harte Regeln für das Team (von allen Rollen geteilt).
• TEAM-DIRECTORY.md: Zuordnungstabelle von Rollen zu echten IDs, um zu verhindern, dass die falsche Person @erwähnt wird.

Der Effekt der Überlappung dieser beiden Tracks ist: die Plattformebene begrenzt den Fluss + die Verhaltensebene fügt Einschränkungen hinzu.

Es geht nicht darum, alles auf das "Selbstbewusstsein" des Modells zu setzen. Modelle machen Fehler, driften ab und vergessen Regeln. Daher müssen zuerst harte Einschränkungen auf der Konfigurationsebene gesetzt werden, gefolgt von sanfter Führung auf der Prompt-Ebene. Doppelte Absicherung.

7. Workspace-Dateisystem: Das "Unabhängige Büro" jeder Rolle

Das Dateigerüst für jeden Arbeitsbereich ist im Grunde konsistent, was wichtig ist – es zeigt, dass ich standardisiere, nicht nur Dateien wahllos für jede Rolle anhäufe.

Standard-Dateistruktur

8. Speichersystem: Lazy Loading + Schichtung + Archivierung

Speicherverwaltung ist der am meisten übersehene, aber problematischste Teil eines Multi-Agent-Systems.

Meine Strategie ist nicht "so viel wie möglich merken", sondern eine klare Schichtung:

1) Kurzzeitprotokolle (tägliches Gedächtnis)

• Zeichnet die Aufgabenprozesse des Tages, Kontextfragmente und Vor-Ort-Entscheidungen auf.
• Dateien sind nach Datum benannt, wodurch natürlich eine Zeitleiste entsteht.

2) Langzeitspeicher (MEMORY.md)

• Destilliert stabile Vorlieben, langfristige Entscheidungen, wiederverwendbare Erfahrungen und harte Regeln.
• Nicht alles kommt hinein; nur verifizierte, stabile Informationen werden geschrieben.

3) Gruppen-Langzeitspeicher (GROUP_MEMORY.md)

• Behält nur wiederverwendbare und sichere Informationen aus der Gruppe.
• Mischt keine Privatchat-Inhalte bei; dies ist eine rote Linie für den Datenschutz.

4) Kaltarchivierung (archive)

• Alte Daten werden regelmäßig archiviert, um zu verhindern, dass der aktive Kontext außer Kontrolle gerät.
• Es wird nicht gelöscht, sondern in einen Low-Priority-Speicher verschoben.

5) Abrufmechanismus (memory_search + memory_get)

• Zuerst semantischer Abruf, dann präzises Lesen.
• Vermeidet vollständiges Laden – das Kontextfenster ist eine begrenzte Ressource und darf nicht verschwendet werden.

Der Kernwert dieser Schichtung:

• Die Privatchat-Qualität wird nicht durch Gruppenchat-Verlauf kontaminiert.
• Die Gruppenkollaboration wird nicht durch persönlichen privaten Kontext gestört.
• Das Kontextfenster wird "bei Bedarf geladen", nicht "vollständig eingefüllt".

Ich behandle das Kontextbudget als ein Ressourcenmanagementproblem. Tokens sind endlich; jede eingespeicherte Erinnerung belegt Inferenzplatz. Daher muss jedes Bit sorgfältig berechnet werden.

9. Privater Modus vs. Gruppenmodus: Zwei Strategien für dieselbe Rolle

Das ist etwas, woran viele nicht denken: Dieselbe Rolle sollte sich in privaten und Gruppenchats unterschiedlich verhalten.

Ich unterscheide explizit zwischen den beiden Modi in der SOUL.md jeder Rolle:

Privater Modus:

• Jede Rolle agiert als Solo-Experte und behandelt Benutzerprobleme Ende-zu-Ende.
• Kein Kollaborationsprozess erforderlich; gib direkt vollständige Antworten.
• Der Qualitätsstandard ist "eine Person kann es bewältigen."

Gruppenmodus:

• Führt inkrementelle Staffelläufe gemäß den Team-Kollaborationsprotokollen durch.
• Jede Rolle ist nur für das verantwortlich, was sie gut kann.
• Der Commander ist für die Verknüpfung und den Abschluss verantwortlich.

Spezifisch für jede Rolle:

• Commander: Im Standard schweigt und beobachtet er in Gruppen; greift nur bei Bedarf stark ein, um zu vermeiden, dass andere überschrien werden.
• Ingenieur: Ergebnisse müssen ausführbar, verifizierbar und rückgängig machbar sein – nicht nur eine Idee liefern.
• Stratege: Schlussfolgerungen müssen mit Annahmen und Verifikationspfaden kommen – nicht nur aus dem Stegreif.
• Denker: Audits müssen Problembewertung + Reparaturpläne liefern – nicht nur sagen "es gibt ein Problem."
• Kreator: Ausdruck darf Authentizität und Ausführbarkeit nicht opfern – nicht nur Ästhetik verfolgen.

Dies ist die Quelle dafür, dass "dieselbe Rolle in verschiedenen Szenarien unterschiedlich abschneidet". Es verlässt sich nicht auf das eigene Urteilsvermögen des Modells, sondern wird explizit über Regeldateien mitgeteilt.

Abschließende Worte

Multi-Agent bedeutet nicht nur, ein paar mehr Bots zu öffnen. Es ist ein ganzes Engineering-System – von Architekturdesign, Routing-Strategien, Sitzungsisolation, Kollaborationsorchestrierung, Speicherverwaltung und Regel-Governance bis hin zu automatisierten Checks; jede Ebene muss sorgfältig entworfen werden.

OpenClaw bietet eine großartige Grundlage, aber der Engineering-Aufwand von "ausführbar" bis "gut laufend" ist viel größer, als die meisten Leute sich vorstellen.

Wenn du etwas Ähnliches machst, hoffe ich, dass dir dieser Beitrag eine gewisse Referenz gibt. Natürlich ist dieser Inhalt nur der Anfang; ich werde später noch mehrere Beiträge veröffentlichen, um mehr "spezifische und verfeinerte" Probleme zu teilen.