← 返回首页
multi-agent2026-02-18

用 OpenClaw 搭建 5 角色 AI 协作操作系统 — 完整技术拆解

作者: @gkxspace查看原文 ↗
AD SLOT — TOP

用 OpenClaw 搭建 5 角色 AI 协作操作系统 — 完整技术拆解

作者: @gkxspace | 来源: X/Twitter | 日期: 2026-02-18

我花了很长时间，把 OpenClaw 从一个单助手，改造成了一套多角色协作操作系统。并非那种"多开几个 bot 各聊各的"。

5 个 AI 角色，共享一个网关，跑在 Discord 和 Telegram 双通道上，有明确的分工、路由、记忆隔离、协作规则，能像一个团队一样接力工作。

这篇文章，我把整个搭建过程、每一层的设计决策、具体配置、以及踩过的坑，全部拆开讲。

如果你也在玩 OpenClaw，或者对"怎么让多个 AI 真正协作"这件事感兴趣，这篇应该能帮你少走不少弯路。

先说结论：这不是"多机器人"，是单 Gateway 下的多 Agent 操作系统

很多人一听"5 个 AI 角色"，第一反应是：你跑了 5 个独立的 bot 吧？

是，但也不是。

我的架构是这样的：

  • 1 个 Gateway 进程，统一接入渠道与路由
  • 5 个独立 Agent：总指挥、军师、工程师、创作官、智库
  • 每个 Agent 有自己独立的 workspace（人格、规则、记忆、会话全部隔离）
  • 同时跑 Discord + Telegram 双通道，靠 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 -> zongzhihui
  • discord + engineer -> engineer
  • telegram + 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 最适合做多角色公开协作编排。

原因很具体：

  1. Discord 我配了 5 账号并行 + 明确的 @协作机制
  2. 角色身份可见、对话链可见、接力过程可见——观感上就像一个团队在讨论
  3. 总指挥全局监听 + 其他角色 mention gate 的策略，在群聊场景里更直观
  4. 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 给了一个很好的底座，但从"能跑"到"跑得好"，中间的工程量比大多数人想象的要大得多。

如果你也在做类似的事情，希望这篇能给你一些参考。当然这篇内容只是开始，后续会再出几篇内容，去分享更加"具体和精细"的问题。🦞

AD SLOT — BOTTOM