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 提供了基础能力，而真正决定系统质量的是：
-
架构设计 -
规则治理 -
记忆管理 -
协作边界
这只是开始。
