Ho creato un sistema operativo collaborativo AI a 5 ruoli con OpenClaw: un'analisi tecnica completa

Ho speso molto tempo a trasformare OpenClaw da un singolo assistente in un sistema operativo collaborativo multi-ruolo. Non si tratta solo di "aprire qualche bot per chattare separatamente."

5 ruoli AI, che condividono un unico gateway, in esecuzione su canali duali Discord e Telegram, con una chiara divisione dei compiti, routing, isolamento della memoria e regole di collaborazione, in grado di lavorare a staffetta come un team.

In questo articolo, analizzo l'intero processo di costruzione, le decisioni di progettazione a ogni livello, le configurazioni specifiche e le insidie che ho incontrato.

Se anche tu stai usando OpenClaw o sei interessato a "come far collaborare davvero più AI", questo articolo dovrebbe aiutarti a evitare molti giri viziosi.

Conclusione prima di tutto: Non è un "multi-bot", ma un sistema operativo multi-agente sotto un unico Gateway

Quando molti sentono "5 ruoli AI", la prima reazione è: stai eseguendo 5 bot indipendenti, giusto?

Sì, ma anche no.

La mia architettura è così:

• 1 processo Gateway, che unifica l'accesso ai canali e il routing
• 5 Agenti indipendenti: Comandante, Stratega, Ingegnere, Creatore, Pensatore
• Ogni Agente ha il proprio spazio di lavoro indipendente (personalità, regole, memoria e sessioni sono tutte isolate)
• Esecuzione simultanea su canali duali Discord + Telegram (può supportare molte piattaforme, ma io uso solo Discord), utilizzando bindings per una distribuzione precisa dei messaggi
• Le chat private e di gruppo utilizzano meccanismi completamente diversi

Un'analogia: Non si tratta di assumere 5 persone e gettarle in una stanza a fare ciò che vogliono. Si tratta di costruire un'azienda, con una struttura organizzativa, descrizioni delle mansioni, protocolli di comunicazione, uffici indipendenti e regole per le riunioni.

OpenClaw stesso è un framework open-source per assistenti AI personali che supporta più piattaforme (Discord, Telegram, WhatsApp, ecc.) e più modelli (Claude, GPT, Gemini, ecc.), con dati completamente localizzati.

La sua capacità multi-agente è il motivo principale per cui l'ho scelto: supporto nativo per spazi di lavoro indipendenti multi-agente + routing tramite bindings, che mi ha permesso di costruire un vero sistema collaborativo su di esso.

1. Architettura Generale: Gateway Singolo + Multi-Agente + Multi-Workspace + Multi-Canale

Per prima cosa, parliamo delle decisioni architetturali di base.

1) Hosting Unificato tramite Gateway Singolo

Attualmente ho un unico processo Gateway di OpenClaw che gestisce tutte le capacità: accesso ai messaggi, routing, gestione delle sessioni, chiamate agli strumenti, indicizzazione della memoria e gestione dello stato, tutto in un unico gateway.

Perché non eseguire una serie di servizi per ogni ruolo? Tre motivi:

• Manutenzione centralizzata: Un solo Gateway da mantenere, nessuna necessità di eseguire servizi indipendenti per ogni ruolo.
• Configurazione unificata: Un'unica configurazione master gestisce le strategie globali, e anche il monitoraggio e la risoluzione dei problemi sono centralizzati.
• Base per la collaborazione: Affinché i ruoli collaborino, devono essere nello stesso runtime per una comunicazione efficiente.

2) 5 Agenti in Parallelo, Non 5 Bot Isolati

I miei 5 ruoli fissi:

• Comandante (zongzhihui): Consapevolezza globale della situazione, scomposizione dei compiti, assegnazione, correzione e chiusura.
• Stratega (junshi): Analisi strategica, valutazione delle proposte e previsione dei rischi.
• Ingegnere (engineer): Esecuzione tecnica, implementazione del codice e manutenzione del sistema.
• Creatore (creator): Creazione di contenuti, ottimizzazione dell'espressione e output esterno.
• Pensatore (zhiku): Audit della conoscenza, controllo qualità e verifiche di conformità.

Ogni agente ha il proprio spazio di lavoro, come workspace-engineer, workspace-junshi, ecc. I file di personalità, i file delle regole, i file di memoria e le risorse degli script sono tutti indipendenti e non si contaminano a vicenda.

3) Accesso Dual-Stack Multi-Canale: Discord + Telegram

Lo stesso Gateway è connesso sia a Discord che a Telegram. Ogni ruolo ha binding a livello di accountId su entrambi i canali. Ovviamente, puoi usare questo stesso file di configurazione per integrare più piattaforme come Lark, WeChat, ecc.

Non si tratta di "distribuzione duplicata su più piattaforme", ma di "lo stesso cluster di cervelli, diversi livelli di accesso". Ho configurato Discord come campo di battaglia principale per la collaborazione.

Se vuoi che più agenti cooperino e collaborino all'interno di un gruppo, scegli semplicemente Discord; una piattaforma è sufficiente. Le altre non sono perfette, le ho provate!!!

2. Livello di Routing: I Bindings Mappano "Account" a "Ruoli"

Questa è la logica di ingresso dell'intero sistema.

Ho configurato una strategia di binding esplicita per i canali duali: canale + accountId -> agentId.

Nello specifico:

• discord + zongzhihui -> zongzhihui
• discord + engineer -> engineer
• telegram + creator -> creator
• ... un totale di 10 mappature (5 ruoli × 2 canali)

Perché farlo?

Perché il sistema decide "chi deve gestire questo messaggio" al livello di ingresso, invece di lasciare che tutti gli agenti lo sentano e poi si affrettino a rispondere. Se questo passaggio non è fatto bene, tutta la collaborazione successiva sarà caotica.

Puoi pensare ai binding come al "triage della reception" di questo sistema. Quando arriva un messaggio, controlla prima quale canale e account lo hanno ricevuto, poi lo instrada direttamente al ruolo corrispondente: pulito ed efficiente.

3. Isolamento delle Sessioni: Perché le Chat Private Non si Incrociano e le Chat di Gruppo Non Sono Caotiche

Questo è uno dei punti ingegneristici più critici del mio sistema.

Configurazione principale: session.dmScope = per-account-channel-peer

Questo parametro significa: Il contesto della chat privata è isolato in base a tre dimensioni: "account + canale + utente peer."

Perché scegliere questo?

• Se la stessa persona contatta lo stesso ruolo tramite Discord e Telegram, i contesti non si incroceranno.
• Se utenti diversi contattano lo stesso ruolo, i contesti sono completamente isolati.
• Negli scenari multi-agente + multi-account, il rischio di "dialoghi incrociati" è ridotto al minimo.

In altre parole, non ho solo creato "multi-ruoli"; ho anche fatto "ingegneria della strategia di isolamento del contesto."

Molte persone costruiscono sistemi multi-agente in cui i ruoli sono chiaramente divisi, ma la gestione del contesto è un disastro: il contenuto della chat privata dell'Utente A finisce nella risposta dell'Utente B, o la memoria della conversazione di Discord contamina il contesto di Telegram.

per-account-channel-peer è la strategia di isolamento raccomandata da OpenClaw per scenari multi-account, e i miei test mostrano che è effettivamente la scelta più stabile.

4. Orchestrazione delle Chat di Gruppo: Collaborazione Guidata dalle Regole, Non Chat Libera

Questa parte è la più interessante e ha anche più insidie.

Strategia Principale: Ascolto Globale del Comandante + Altri Ruoli Attivati tramite @

La mia strategia per le chat di gruppo sul lato Discord è la seguente:

Comandante: requireMention = false (Ascolto globale)

• Può vedere tutti i messaggi nel gruppo per impostazione predefinita.
• Responsabile di cogliere la situazione globale, giudicare se è necessaria una collaborazione, eseguire la scomposizione dei compiti e assegnare il lavoro.

Altri 4 Ruoli: `requireMention = true` (Attivati tramite @)

• Agiscono solo quando vengono menzionati esplicitamente tramite @.
• Riduce il rumore ed evita che si parlino addosso.

Ogni ruolo è configurato con `mentionPatterns`

• Ad esempio, l'ingegnere può essere attivato da @Engineer o [@engineer](https://x.com/@engineer).
• Rende la convocazione nel gruppo più stabile e prevedibile.

Qual è l'essenza di questa combinazione?

• Il Comandante "vede il quadro generale", come un PM in un team.
• I ruoli specializzati sono "attivati su richiesta", come esperti in varie posizioni.
• Il discorso di gruppo passa da "forma libera" a "staffetta controllata."

Effetto reale: Fai una domanda nel gruppo, il Comandante giudica prima di che tipo di compito si tratta, poi menziona tramite @ il ruolo corrispondente per gestirlo. Una volta che il ruolo ha finito, il Comandante chiude il cerchio. L'intero processo è come un vero team che tiene una riunione.

5. Discord vs Telegram: Perché Discord è il Campo di Battaglia Principale

A rigor di termini, non è che "solo Discord può collaborare." È solo che, nella mia configurazione attuale, Discord è più adatto per l'orchestrazione della collaborazione pubblica multi-ruolo.

Motivi specifici:

1. Ho configurato 5 account paralleli su Discord + un chiaro meccanismo di collaborazione tramite @.
2. Le identità dei ruoli, le catene di conversazione e il processo di staffetta sono tutti visibili: sembra una discussione di squadra.
3. La strategia dell'ascolto globale del Comandante + il gate di menzione per gli altri ruoli è più intuitiva negli scenari di chat di gruppo.
4. Attualmente ho impostato il groupPolicy di Discord su open, che offre una maggiore flessibilità.

Sul lato Telegram, la mia strategia tende a allowlist + gate di menzione, che è più vincolata e sicura, adatta per "canali di produzione controllati."

Quindi il riassunto è: Discord è il palcoscenico della collaborazione.

6. Livello di Configurazione + Livello di Prompt: Governance a Doppio Binario

Questa è la più grande differenza tra questo sistema e "giocare per divertimento."

Non mi affido esclusivamente alla configurazione, né esclusivamente ai Prompt. Uso due binari sovrapposti.

A. Binario di Configurazione (Controllo a Livello di Piattaforma)

Queste sono configurazioni rigide a livello di piattaforma OpenClaw:

• politica del canale: groupPolicy, dmPolicy, che controllano le strategie di base per chat di gruppo e private.
• requireMention: Chi deve essere menzionato tramite @ per impostazione predefinita per rispondere.
• bindings: Mappatura del routing dei messaggi.
• dmScope: Granularità dell'isolamento delle sessioni.
• limite di ping-pong agentToAgent: L'ho impostato a 0, sopprimendo direttamente gli scambi insignificanti tra agenti.

L'ultimo è cruciale: se non limiti il ping-pong agente-agente, vedrai due AI in un gruppo fare complimenti, confermare a vicenda e andare in loop all'infinito. Impostarlo a 0 dice al sistema: gli agenti non dovrebbero pingarsi automaticamente a vicenda.

B. Binario delle Regole (Controllo a Livello Comportamentale)

Questi sono i file delle regole che ho scritto in ogni spazio di lavoro:

• SOUL.md: Il file dell'anima del ruolo: personalità, tono, responsabilità e livello di qualità dell'output.
• AGENTS.md: Manuale operativo: processi di verifica della collaborazione, norme di lettura/scrittura della memoria e strategie di caricamento lazy.
• ROLE-COLLAB-RULES.md: Confini e linee rosse della collaborazione specifici del ruolo.
• TEAM-RULEBOOK.md: Regole rigide unificate per il team (condivise da tutti i ruoli).
• TEAM-DIRECTORY.md: Tabella di mappatura dei ruoli agli ID reali per evitare di menzionare la persona sbagliata tramite @.

L'effetto della sovrapposizione di questi due binari è: il livello della piattaforma limita il flusso + il livello comportamentale aggiunge vincoli.

Non si tratta di mettere tutto sulla "autocoscienza" del modello. I modelli commettono errori, vanno alla deriva e dimenticano le regole. Pertanto, i vincoli rigidi devono essere impostati prima al livello di configurazione, seguiti da una guida morbida al livello di prompt. Doppia sicurezza.

7. File System dello Spazio di Lavoro: "Ufficio Indipendente" di Ogni Ruolo

La struttura dei file per ogni spazio di lavoro è sostanzialmente coerente, il che è importante: mostra che sto standardizzando, non solo accumulando file a caso per ogni ruolo.

Struttura File Standard

8. Sistema di Memoria: Caricamento Lazy + Stratificazione + Archiviazione

La gestione della memoria è la parte più facilmente trascurata ma più problematica in un sistema multi-agente.

La mia strategia non è "ricordare il più possibile", ma una chiara stratificazione:

1) Registri a Breve Termine (memoria giornaliera)

• Registra i processi delle attività della giornata, i frammenti di contesto e le decisioni sul campo.
• I file vengono nominati per data, creando naturalmente una sequenza temporale.

2) Memoria a Lungo Termine (MEMORY.md)

• Distilla preferenze stabili, decisioni a lungo termine, esperienza riutilizzabile e regole rigide.
• Non tutto viene inserito; vengono scritte solo informazioni verificate e stabili.

3) Memoria a Lungo Termine di Gruppo (GROUP_MEMORY.md)

• Conserva solo informazioni riutilizzabili e sicure provenienti dal gruppo.
• Non mescola contenuti di chat private; questa è una linea rossa per la privacy.

4) Archiviazione a Freddo (archive)

• I dati vecchi vengono archiviati periodicamente per evitare che il contesto attivo si espanda in modo incontrollato.
• Non vengono eliminati, ma spostati in uno storage a bassa priorità.

5) Meccanismo di Recupero (memory_search + memory_get)

• Prima richiamo semantico, poi lettura precisa.
• Evita il caricamento completo: la finestra di contesto è una risorsa limitata e non può essere sprecata.

Il valore principale di questa stratificazione:

• La qualità della chat privata non è contaminata dalla cronologia delle chat di gruppo.
• La collaborazione di gruppo non viene interferita dal contesto privato personale.
• La finestra di contesto viene "caricata su richiesta", non "riversata completamente."

Tratto il budget del contesto come un problema di gestione delle risorse. I token sono finiti; ogni ricordo infilato occupa spazio di inferenza. Quindi, ogni bit deve essere calcolato attentamente.

9. Modalità Privata vs Modalità Gruppo: Due Strategie per lo Stesso Ruolo

Questa è una cosa a cui molti non pensano: lo stesso ruolo dovrebbe comportarsi in modo diverso nelle chat private e di gruppo.

Distinguo esplicitamente tra le due modalità nel file SOUL.md di ogni ruolo:

Modalità Privata:

• Ogni ruolo agisce come un esperto solista, gestendo i problemi dell'utente dall'inizio alla fine.
• Nessun processo di collaborazione necessario; fornisce risposte complete direttamente.
• Lo standard di qualità è "una persona può gestirlo."

Modalità Gruppo:

• Esegue una staffetta incrementale secondo i protocolli di collaborazione del team.
• Ogni ruolo è responsabile solo di ciò in cui è bravo.
• Il Comandante è responsabile del collegamento e della chiusura.

Specifico per ogni ruolo:

• Comandante: Rimane in silenzio e osserva per impostazione predefinita nei gruppi, intervenendo con forza solo quando necessario per evitare di sovrapporsi agli altri.
• Ingegnere: I risultati devono essere eseguibili, verificabili e ripristinabili, non solo fornire un'idea.
• Stratega: Le conclusioni devono essere accompagnate da presupposti e percorsi di verifica, non solo buttate lì.
• Pensatore: Gli audit devono fornire una classificazione dei problemi + piani di riparazione, non solo dire "c'è un problema."
• Creatore: L'espressione non può sacrificare autenticità ed eseguibilità, non solo perseguire l'estetica.

Questa è la fonte del "ruolo che si comporta in modo diverso in scenari diversi." Non si basa sul giudizio del modello, ma viene detto esplicitamente tramite file di regole.

Parole Finali

Multi-Agente non significa solo aprire qualche bot in più. È un intero sistema ingegneristico: dalla progettazione architetturale, alle strategie di routing, all'isolamento delle sessioni, all'orchestrazione della collaborazione, alla gestione della memoria, alla governance delle regole e ai controlli automatizzati; ogni livello necessita di una progettazione attenta.

OpenClaw fornisce un'ottima base, ma la quantità di ingegneria che va da "funzionante" a "funzionante bene" è molto più grande di quanto la maggior parte delle persone immagini.

Se stai facendo qualcosa di simile, spero che questo articolo ti dia qualche spunto. Ovviamente, questo contenuto è solo l'inizio; pubblicherò altri articoli in seguito per condividere questioni più "specifiche e raffinate."