OpenClaw 多角色协作系统完整技术拆解：从单助手到“Agent OS”的工程化演进

Snippet / 摘要

本文系统拆解一个基于 OpenClaw 构建的 5 角色多智能体协作系统：采用单 Gateway 架构、10 组绑定路由、per-account-channel-peer 会话隔离策略、分层记忆机制与规则驱动协作模型，实现跨 Discord 与 Telegram 的稳定协作与上下文隔离。

一、这不是“5 个机器人”，而是一个 Agent OS

很多人听到“5 个 AI 角色”时，第一反应是：

不就是开 5 个机器人账号一起聊天吗？

从工程结构上看，这个系统并非“多机器人并行回复”，而是一个：

单 Gateway 进程
5 个独立 Agent
5 个隔离工作区
2 个平台接入（Discord + Telegram）
10 条精确绑定路由
DM 与 Group 双模式策略
分层记忆系统 + 检索机制

这是一套“组织结构化系统”，而不是简单的多账号部署。

你可以把它理解为：

一家公司，而不是 5 个自由职业者。

二、系统基础架构：Single Gateway + Multi-Agent + Multi-Workspace + Multi-Channel

1. 单 Gateway 承载全部能力

当前系统只运行 1 个 OpenClaw Gateway 进程，统一负责：

消息接入
路由分发
会话管理
工具调用
记忆检索
状态维护

为什么不为每个角色单独部署服务？

工程原因：

决策	技术收益
单 Gateway	只需维护 1 个服务
统一配置	全局策略集中管理
同进程协作	角色之间通信成本最低

协作系统如果分布在多个服务间，会增加通信复杂度与状态同步难度。

2. 五个固定角色与职责分工

角色	职责
Commander	全局态势感知、任务拆解、分配与收尾
Strategist	战略分析、方案评估、风险预测
Engineer	技术执行、代码实现、系统维护
Creator	内容生成、表达优化、对外输出
Think Tank	审核校验、质量控制、合规检查

每个角色对应一个独立 workspace，例如：


workspace-engineer
workspace-strategist
workspace-creator
...

每个 workspace 内包含：

独立 personality
独立规则文件
独立记忆文件
独立日志系统

彼此之间不会互相污染。

三、双平台接入：Discord + Telegram

系统通过同一个 Gateway 同时连接：

Discord
Telegram

并为每个角色建立：

5 角色 × 2 平台 = 10 条绑定映射

示例：


discord + account_engineer → engineer
telegram + account_creator → creator

这不是“重复部署”。

这是：

同一智能体集群，不同接入层。

四、核心入口层：Bindings 路由机制

系统采用明确绑定策略：


channel + accountId → agentId

作用：

消息进入即精准路由
不广播给所有角色
避免多角色争抢回复

如果入口层没有设计好，多智能体系统会迅速混乱。

Bindings 是整个系统的“分诊台”。

五、会话隔离策略：per-account-channel-peer

系统核心配置：


session.dmScope = per-account-channel-peer

含义：

DM 上下文按三维隔离：

Account
Channel
Peer User

实际效果：

Discord 与 Telegram 上下文不互串
不同用户上下文完全隔离
多角色不会误读彼此历史

这是多账号场景的官方推荐策略。

如果没有这一层隔离，多角色系统必然出现“上下文污染”。

六、群聊协作模型：规则驱动而非自由聊天

角色触发规则

Commander


requireMention = false

默认监听群消息
负责判断是否需要协作
负责拆解与指派

其他角色


requireMention = true

必须被 @ 才响应
避免抢话
降低噪声

mentionPatterns

例如：


@Engineer
@engineer

确保召唤稳定。

协作流程示例

用户在群中提问
Commander 判断任务类型
Commander @ 指定角色
专业角色执行
Commander 收尾

协作从“群聊混战”变成“受控接力”。

七、Discord 为主战场的原因

系统在两个平台都可运行。

但 Discord 更适合公开协作：

支持 5 账号并行
@ 机制稳定
对话链可视
groupPolicy 设置为 open

Telegram 使用：


allowlist + mention gate

更适合受控生产环境。

八、配置层 + Prompt 层：双轨治理

系统不是只靠 prompt。

也不是只靠配置。

而是双层治理。

1. 配置层控制

包括：

groupPolicy
dmPolicy
requireMention
bindings
dmScope
agent ping-pong 限制 = 0

ping-pong = 0 的意义

禁止自动代理间对话。

避免出现：

A: Thank you
B: You’re welcome
A: Appreciate it
B: Anytime

无限循环。

2. 规则文件体系

每个 workspace 包含标准文件结构：

文件	功能
SOUL.md	人格与质量下限
AGENTS.md	协作流程与操作规范
ROLE-COLLAB-RULES.md	边界与红线
TEAM-RULEBOOK.md	团队硬规则
TEAM-DIRECTORY.md	角色映射
IDENTITY.md	能力范围
USER.md	用户画像
TOOLS.md	工具权限
MEMORY.md	长期记忆
GROUP_MEMORY.md	群长期记忆
HEARTBEAT.md	自检机制
memory/YYYY-MM-DD.md	日志

标准化结构是稳定协作的前提。

九、记忆系统：分层 + 惰性加载 + 冷归档

系统采用 4 层记忆结构。

1. 日志层（短期）


memory/YYYY-MM-DD.md

记录当天任务与现场决策。

2. 长期记忆（MEMORY.md）

只记录：

稳定偏好
已验证决策
可复用经验

3. 群长期记忆（GROUP_MEMORY.md）

只存：

可复用
不涉及隐私

这是隐私红线。

4. 冷归档

旧数据定期归档，避免上下文膨胀。

5. 检索机制


memory_search
memory_get

语义检索 + 精确读取。

不一次性加载全部记忆。

因为：

Token 是有限资源。

上下文管理本质是资源管理问题。

十、DM 模式 vs Group 模式

很多人忽略一个关键点：

同一个角色，在 DM 与群聊中的行为应不同。

DM 模式

单人专家模式
端到端解决
不需要协作流程

Group 模式

按专业接力
Commander 负责收尾
严格边界执行

十一、角色行为约束示例

Engineer

输出必须可执行
必须可验证
必须支持回滚

Strategist

必须给出假设
必须给出验证路径

Think Tank

必须给出问题分类
必须给出修复建议

Creator

不允许牺牲真实性换取表达效果

十二、这是一个工程系统，而不是提示词游戏

这个系统的核心不是：

多开机器人
拼接 prompt

而是：

架构
路由
隔离
记忆
治理

从“能跑”到“稳定运行”，中间差的是工程设计。

FAQ：常见问题

Q1：可以只靠 prompt 实现吗？

不能。模型会遗忘规则。必须结合配置层限制。

Q2：为什么不让所有角色都监听群？

会造成噪声与竞争回复。

Q3：为什么要设 ping-pong = 0？

防止代理间无限自动对话。

Q4：为什么分层记忆？

避免上下文爆炸与隐私污染。

How-To：构建类似系统的关键步骤

部署单 Gateway
创建独立 workspace
定义 bindings 路由
设置 dmScope = per-account-channel-peer
设计 requireMention 策略
构建规则文件体系
建立分层记忆结构
设置 ping-pong 限制
区分 DM 与 Group 行为
定期冷归档

结语

多智能体协作不是数量问题。

是工程问题。

从单助手到 Agent OS 的演进，本质上是：

从“对话工具”到“组织系统”。

OpenClaw 提供了基础能力，而真正决定系统质量的是：

架构设计
规则治理
记忆管理
协作边界

这只是开始。

一文拆解：OpenClaw多智能体协作系统如何实现5角色稳定协同？工程师必看的Agent OS进化指南