导语

你想要的不是五个互相抢话的 bot，而是一套像公司一样有分工、有规章、有协作流程的 AI 团队吗？我用 OpenClaw 把单助手改造成了单 Gateway 下的多 Agent 操作系统。能在 Discord 和 Telegram 同时跑，能做精细路由、会话隔离和分层记忆。下面把完整的设计、关键配置、实战示例和踩过的坑都给你拆开了。

概览：把它想成一家公司，不是五个聊天机器人

核心思路很直白：一个 Gateway 进程承载接入、路由、会话和工具调用；五个并行 Agent 各司其职；每个 Agent 有独立 workspace（人格、规则、记忆、会话隔离）。

我用的五个固定角色：

总指挥（zongzhihui）：态势感知、任务拆解、派工、收口。
军师（junshi）：策略、风险评估、方案优劣判定。
工程师（engineer）：技术实现、代码、部署。
创作官（creator）：文案、输出、表达优化。
智库（zhiku）：审核、合规、质量把关。

渠道层我并行接入 Discord 和 Telegram。Discord 做协作主战场，Telegram 做受控生产通道。

架构要点（简明）

Single Gateway：只跑一个 Gateway 进程。运维和监控都集中。角色间协作更高效。
Multi-Agent：每个 Agent 在独立 workspace 下运行，互不污染。
Multi-Channel：channel+accountId -> agentId 的 binding 路由，入口就决定处理者。
会话隔离：按 account + channel + peer 做 DM 级别隔离，私聊不会串到群聊，也不会跨渠道污染记忆。

路由层示例：bindings（实操样例）

在 OpenClaw 的 bindings 配置里，我把“渠道 + 账号”映射到具体 agent：

{
  "bindings": [
    {"channel":"discord","accountId":"zongzhihui_id","agentId":"zongzhihui"},
    {"channel":"discord","accountId":"engineer_id","agentId":"engineer"},
    {"channel":"telegram","accountId":"creator_id","agentId":"creator"}
    // ... 共 5 角色 × 2 渠道 映射
  ]
}

原则是：入口决定去向。不要把所有消息广播给每个 agent 去抢答。

会话隔离：关键配置与原因

配置要点：

session.dmScope = per-account-channel-peer

解释一下：私聊上下文按（账号 + 渠道 + 对端用户）做隔离。后果是：

同一用户在 Discord 和 Telegram 找同一个角色，不会串。
不同用户找同一个角色，各自上下文独立。

实战意义：减少记忆污染。多 agent 系统失败常因为上下文混乱，而不是模型能力不够。

群聊编排：总指挥 + @触发的玩法（推荐）

别让所有 agent 都“开麦”。我的群聊策略：

总指挥 requireMention = false（全局监听）
其他 4 个角色 requireMention = true（只有被 @ 才回应）

每个角色写清楚 mentionPatterns，比如：

工程师可被 @工程师、@engineer 触发
创作官可被 @创作官、@creator 触发

实战场景：你在群里问“帮我写个爬虫”，总指挥先判断任务类型，然后 @engineer 去实现，最后 @creator 做输出包装，总指挥收口发布成果。这个流程像真实团队开小会，清晰又可控。

为什么把 Discord 当主战场

要点很具体：

Discord 支持多账号并行、@机制和可见对话链。
总指挥能在群里监控全局态势，其他角色按需介入，过程对人可见。
Telegram 更适合作为受控的“生产”通道，用 allowlist + mention gate 收敛行为。

结论：如果你想做公开协作、多人可见的接力式工作流，优先用 Discord。

双轨治理：配置层 + 规则层（别把一切交给 prompt）

我做了两条治理轨道：

A. 平台配置（硬约束）

channelPolicy：groupPolicy、dmPolicy
requireMention：谁必须被 @
bindings：路由分配
dmScope：会话隔离粒度
agentToAgent ping-pong 限制：设为 0，禁止 agent 间自动来回聊天

B. workspace 规则（软引导）

每个 workspace 都有一组文件：SOUL.md、AGENTS.md、ROLE-COLLAB-RULES.md、TEAM-RULEBOOK.md 等，用来定义人格、协作边界和记忆写入规范。

双轨叠加后，平台先限流，规则再引导。模型会犯错，靠这两层把问题压到最低。

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：当日流水

把这些文件模板化，能把“人设漂移”问题降到最低。

记忆体系：懒加载 + 分层 + 归档（节省 token）

策略：

短期流水：当日事件按日期文件存储
长期记忆：只写稳定、验证过的信息到 MEMORY.md
群聊记忆：GROUP_MEMORY.md，只保留群可复用信息
冷归档：定期把旧数据移到低优先级存储
检索机制：先 semantic search，再精确读取

别把所有东西都丢进长期记忆。把上下文预算当成稀缺资源来管理。

私聊模式 vs 群聊模式：同一角色两套 SOP

我在 SOUL.md 明确分两个模式：

私聊：作为单兵专家，端到端解决问题，输出要完整可执行。
群聊：按团队流程分工，提供增量贡献，由总指挥收口。

举例：工程师在私聊里直接给出可运行脚本；在群聊里只给实现步骤+风险点，等总指挥决定是否执行。

快速上手步骤（一页式）

启动一个 OpenClaw Gateway。把所有 platform token 放在同一个配置文件里。
建立 5 个 workspace，每个 workspace 放 SOUL.md、AGENTS.md、ROLE-COLLAB-RULES.md 等。
在 bindings 里按 channel+accountId 映射到 agentId。
设置 session.dmScope = per-account-channel-peer。
在平台配置里把 agentToAgent ping-pong 限制设为 0。
在 Discord 设置总指挥开放监听，其他角色 requireMention = true。
先跑一周 observe，收集错误案例，改 AGENTS.md 的检查清单。

实战示例：用户在 Discord 问“帮我写个爬虫”

消息进入 Gateway，根据 bindings 定位到总指挥（zongzhihui）。
总指挥判断任务：技术实现 -> 派工给 engineer；需要输出文档 -> 同时 @creator 准备说明文档。
engineer 生成代码、测试用例，写入 daily memory。
creator 把说明打磨成对外文档。
总指挥收口，汇报结果并写入 GROUP_MEMORY.md（仅保留可复用要点）。

避坑清单（实操总结）

不要把所有消息广播给所有 agent。会产生抢答和循环。
别把私聊和群聊记忆混在一起。隐私和上下文会互相污染。
不限制 agent 间 ping-pong，会看到无意义的互相确认。
别把所有信息都写进长期记忆。长期记忆必须经过验证。
不做文件化规则就放任模型自觉执行，结果会漂移。

结束语

多 Agent 不是把几个 bot 丢进同一频道就完事。它是一整套工程系统：架构、路由、隔离、编排、记忆治理、规则治理，每一层都要落地。OpenClaw 给了坚实的底座，但工程细节决定体验。照着这个流程搭一套，你会省很多试错时间。

如果你想，我可以把我的 workspace 模板发给你参考，或者把几段关键配置抽成可复制的 json/yaml。想要哪部分先发过来？🙂

用 OpenClaw 架出 5 角色 AI 协作系统：完整技术拆解与实操配置

导语