OpenClaw 多角色 AI 協作系統完整設計指南
日期: Wed Feb 18 12:07:13 +0000 2026
標籤:
AI Agent 協作系統架構Prompt 工程
來源: [@gkxspace (余溫)](來源 URL) 日期: 2026-03-06 標籤:
ai-toolsopenclawmulti-agentdiscordtelegram
我用 OpenClaw 搭了一套 5 角色 AI 協作操作系統，來個完整的技術拆解！
我花了很長時間，把 OpenClaw 從一個單助手，改造成了一套多角色協作操作系統。並非那種「多開幾個 bot 各聊各的」。
5 個 AI 角色，共享一個網關，跑在 Discord 和 Telegram 雙通道上，有明確的分工、路由、記憶隔離、協作規則，能像一個團隊一樣接力工作。
這篇文章，我把整個搭建過程、每一層的設計決策、具體配置、以及踩過的坑，全部拆開講。
如果你也在玩 OpenClaw，或者對「怎麼讓多個 AI 真正協作」這件事感興趣，這篇應該能幫你少走不少彎路。
先說結論：這不是「多機器人」，是單 Gateway 下的多 Agent 操作系統
很多人一聽「5 個 AI 角色」，第一反應是：你跑了 5 個獨立的 bot 吧？
是，但也不是。
我的架構是這樣的：
- 1 個 Gateway 進程，統一接入渠道與路由
- 5 個獨立 Agent：總指揮、軍師、工程師、創作官、智庫
- 每個 Agent 有自己獨立的 workspace（人格、規則、記憶、會話全部隔離）
- 同時跑 Discord + Telegram 雙通道（能跑超多個平台，但沒必要，我就用 Discord），靠 bindings 精準分發消息
- 私聊和群聊走完全不同的機制
一個類比：這不是招了 5 個人扔進一個房間讓他們自由發揮。這是搭了一家公司——有組織架構、有崗位說明、有溝通協議、有獨立辦公室、有會議規則。
OpenClaw 本身就是一個開源的個人 AI 助手框架，支援多平台（Discord、Telegram、WhatsApp 等）、多模型（Claude、GPT、Gemini 等），資料完全本地化。
它的多智能體能力是我選擇它的核心原因——原生支援多 agent 獨立工作區 + bindings 路由，這個底子讓我能在上面搭出真正的協作系統。
一、總體架構：Single Gateway + Multi-Agent + Multi-Workspace + Multi-Channel
先講最底層的架構決策。
1）單 Gateway 統一承載
我當前是一個 OpenClaw Gateway 進程承載全部能力——消息接入、路由、會話管理、工具調用、記憶索引、狀態管理，全在一個網關裡。
為什麼不是每個角色跑一套服務？三個原因：
- 運維集中：只維護一個 Gateway，不用每個角色跑一套獨立服務
- 配置統一：一個總配置管全局策略，監控和排障也集中在一處
- 協作基礎：角色之間要協作，必須在同一個運行時裡才能高效通信
2）5 個 Agent 並行，不是 5 個散裝 bot
我的 5 個固定角色：
- 總指揮（zongzhihui）：全局態勢感知、任務拆解、派工、糾偏、收口
- 軍師（junshi）：策略分析、方案評估、風險預判
- 工程師（engineer）：技術執行、代碼實現、系統維護
- 創作官（creator）：內容創作、表達優化、對外輸出
- 智庫（zhiku）：知識審核、質量把關、合規檢查
每個 agent 有自己的 workspace，比如 workspace-engineer、workspace-junshi 這種。人格文件、規則文件、記憶文件、腳本資產全部獨立，互不污染。
3）多渠道雙棧接入：Discord + Telegram
同一套 Gateway 上同時接了 Discord 和 Telegram，每個角色在兩個渠道都有 accountId 級別的綁定，當然，你可以用這一份配置文件接入更多的平台，比如飛書、微信等等。
這不是「多平台重複部署」，而是「同一個大腦集群，不同接入層」。Discord 我配成了協作主戰場。
如果你想讓多個🦞配合起來，群內協作起來，那麼你就直接選 Discord，一個平台就夠了，其它都不完美，我試過！
二、路由層：bindings 把「帳號」映射到「角色」
這是整個系統的入口邏輯。
我配了雙通道的顯式綁定策略：channel + accountId -> agentId。
具體就是：
discord + zongzhihui -> zongzhihuidiscord + engineer -> engineertelegram + creator -> creator- ……共 10 條映射（5 角色 × 2 渠道）
為什麼要這樣做？
因為系統在入口層就決定了「誰該處理這條消息」，而不是讓所有 agent 都聽到後再搶答。這一步做不好，後面所有的協作都是亂的。
你可以理解為：bindings 就是這個系統的「前台分診」。消息進來，先看是哪個渠道、哪個帳號收到的，直接路由到對應角色，乾淨俐落。
三、會話隔離：為什麼我能做到「私聊不串、群聊不亂」
這是我這套系統裡最關鍵的工程點之一。
核心配置：session.dmScope = per-account-channel-peer
這個參數的意思是：私聊上下文按「帳號 + 渠道 + 對端用戶」三個維度隔離。
為什麼選這個？
- 同一個人通過 Discord 和 Telegram 找同一個角色，上下文不會串
- 不同用戶找同一個角色，上下文完全隔離
- 多 agent + 多帳號場景下，「錯串」風險降到最低
換句話說，我不是只做了「多角色」，我還做了「上下文隔離策略工程」。
很多人搭多 agent 系統，角色分得很清楚，但上下文管理一塌糊塗——A 用戶的私聊內容跑到 B 用戶的回覆裡，或者 Discord 的對話記憶污染了 Telegram 的上下文。
per-account-channel-peer 是 OpenClaw 官方在多帳號場景下推薦的隔離策略，我實測下來確實是最穩的選擇。
四、群聊編排：不是讓 AI 自由聊天，而是「規則驅動協作」
這部分是整個系統最有意思的地方，也是坑最多的地方。
核心策略：總指揮全局監聽 + 其他角色 @ 觸發
我在 Discord 側的群聊策略是這樣的：
總指揮：requireMention = false（全局監聽）
- 默認能看到群內所有消息
- 負責抓全局態勢、判斷是否需要協作、做任務拆解和派工
其他 4 個角色：requireMention = true（@ 觸發）
- 只在被明確 @ 時才行動
- 減少噪音，避免搶話
每個角色都配了 mentionPatterns
- 比如工程師可以被
@工程師、@engineer觸發 - 讓群裡的召喚更穩定、更可預測
這套組合的本質是什麼？
- 總指揮「看全局」，像團隊裡的 PM
- 專職角色「按需觸發」，像各個崗位的專家
- 群裡的發言從「自由發散」變成「可控接力」
實際跑起來的效果：你在群裡提一個問題，總指揮先判斷這是什麼類型的任務，然後 @ 對應角色來處理。角色處理完，總指揮做收口。整個過程像一個真實團隊在開會。
五、Discord vs Telegram：為什麼我把 Discord 當主戰場
嚴格來說，不是「只有 Discord 才能協作」。而是在我當前的配置下，Discord 最適合做多角色公開協作編排。
原因很具體：
- Discord 我配了 5 帳號並行 + 明確的 @ 協作機制
- 角色身份可見、對話鏈可見、接力過程可見——觀感上就像一個團隊在討論
- 總指揮全局監聽 + 其他角色 mention gate 的策略，在群聊場景裡更直觀
- Discord 的 groupPolicy 我目前設的是 open，靈活性更高
而 Telegram 那邊，我的策略偏 allowlist + mention gate，更收斂、更安全，適合做「受控生產通道」。
所以總結就是：Discord 是協作舞台。
六、配置層 + 提示詞層：雙軌治理
這是我這套系統和「隨便玩玩」最大的區別。
我不是只靠配置，也不是只靠 Prompt。我做的是兩條軌道疊加。
A. 配置軌（平台級控制）
這些是 OpenClaw 平台層面的硬配置：
- channel policy：groupPolicy、dmPolicy，控制群聊和私聊的基本策略
- requireMention：誰默認必須被 @ 才響應
- bindings：消息路由映射
- dmScope：會話隔離粒度
- agentToAgent ping-pong 限制：我設為 0，直接壓制 agent 之間的無意義來回對話
最後這個很關鍵——如果不限制 agent 之間的 ping-pong，你會看到兩個 AI 在群裡互相客套、互相確認、無限循環。設為 0 就是告訴系統：agent 之間不要自動互 ping。
B. 規則軌（行為級控制）
這些是我在每個 workspace 裡寫的規則文件：
- SOUL.md：角色的靈魂文件——人格、語氣、職責、輸出質量底線
- AGENTS.md：運行手冊——協作檢查流程、記憶讀寫規範、懶加載策略
- ROLE-COLLAB-RULES.md：角色專屬的協作邊界和紅線
- TEAM-RULEBOOK.md：團隊統一的協作硬規則（所有角色共享）
- TEAM-DIRECTORY.md：角色與真實 ID 的映射表，防止 @ 錯人
兩條軌道疊加後實現的效果是：平台層先限流 + 行為層再約束。
不是把一切壓在模型的「自覺」上。模型會犯錯、會漂移、會忘記規則。所以必須在配置層先做硬約束，再在提示詞層做軟引導。雙保險。
七、Workspace 文件體系：每個角色的「獨立辦公室」
每個 workspace 的文件骨架基本一致，這很重要——說明我在做標準化，不是每個角色隨便堆文件。
標準文件結構
| 文件 | 作用 |
|---|---|
| SOUL.md | 角色靈魂：人格定義、行為模式、質量底線 |
| AGENTS.md | 運行手冊：協作流程、記憶規範、檢查清單 |
| ROLE-COLLAB-RULES.md | 協作邊界：這個角色能做什麼、不能做什麼 |
| IDENTITY.md | 身份定義：名字、定位、能力範圍、對外口徑 |
| USER.md | 用戶畫像：偏好、目標、禁忌、常用術語 |
| TOOLS.md | 工具清單：允許調用哪些工具、權限邊界 |
| MEMORY.md | 長期記憶：穩定偏好、長期決策、可復用經驗 |
| GROUP_MEMORY.md | 群聊記憶：只保留群可復用且安全的信息 |
| HEARTBEAT.md | 心跳規範：周期性自檢、失敗恢復、狀態維護 |
| memory/YYYY-MM-DD*.md | 每日流水：當天任務過程、上下文碎片、現場決策 |
八、記憶系統：懶加載 + 分層 + 歸檔
記憶管理是多 agent 系統裡最容易被忽視、但最容易出問題的部分。
我的策略不是「能記多少記多少」，而是做了明確的分層：
1）短期流水（daily memory）
- 記錄當天的任務過程、上下文碎片、現場決策
- 文件名按日期命名，天然有時間線
2）長期記憶（MEMORY.md）
- 沉澱穩定的偏好、長期決策、可復用經驗、硬規則
- 不是什麼都往裡塞，只有經過驗證的、穩定的信息才寫入
3）群聊長期記憶（GROUP_MEMORY.md）
- 只保留群裡可復用且安全的信息
- 不混入私聊內容，這是隱私紅線
4）冷歸檔（archive）
- 老數據定期歸檔，防止活躍上下文膨脹失控
- 不是刪除，是移到低優先級存儲
5）檢索機制（memory_search + memory_get）
- 先語義召回，再精確讀取
- 避免全量加載——上下文窗口是有限資源，不能浪費
這套分層的核心價值：
- 私聊質量不被群聊歷史污染
- 群聊協作不被個人私密上下文干擾
- 上下文窗口「按需加載」，不是「全量灌入」
我把上下文預算當成資源管理問題來處理。token 是有限的，每一個塞進去的記憶都在佔用推理空間。所以必須精打細算。
九、私聊模式 vs 群聊模式：同一個角色，兩套運行策略
這是很多人沒想到的一點：同一個角色在私聊和群聊裡，應該表現不同。
我在每個角色的 SOUL.md 裡都明確區分了兩種模式：
私聊模式：
- 各角色作為單兵專家，端到端處理用戶問題
- 不需要協作流程，直接給出完整答案
- 質量標準是「一個人能搞定」
群聊模式：
- 按團隊協作協議做增量接力
- 每個角色只負責自己擅長的部分
- 總指揮負責串聯和收口
具體到每個角色：
- 總指揮：群裡默認沉默觀察，必要時才強介入，避免搶話
- 工程師：交付必須可執行、可驗證、可回滾——不是給個思路就完了
- 軍師：結論必須帶假設和驗證路徑——不是拍腦袋
- 智庫：審核必須給問題分級 + 修復方案——不是只說「有問題」
- 創作官：表達不能犧牲真實性和可執行性——不是只追求好看
這就是「同一個角色在不同場景表現差異化」的來源。不是靠模型自己判斷，是靠規則文件明確告訴它。
寫在最後
多 Agent 不是多開幾個 bot。它是一整套工程系統——從架構設計、路由策略、會話隔離、協作編排、記憶管理、規則治理、到自動化檢查，每一層都需要認真設計。
OpenClaw 給了一個很好的底座，但從「能跑」到「跑得好」，中間的工程量比大多數人想像的要大得多。
如果你也在做類似的事情，希望這篇能給你一些參考。當然這篇內容只是開始，後續會再出幾篇內容，去分享更加「具體和精細」的問題。🦞