OpenClaw 多agent群聊的 3种模式实战

前面3篇都围绕单Agent应用，这篇我们看看如何组建一个3个不同的团队。

多个数字人好处多：

• 保密性好：工作数字人不知道我股票的信息，写文章数字人不知道我家里这种设备密码。
• 上下文信息关联度高：数字人的专业性，保障了输入输出的有效信息高，模型能更准确反馈信息。
• 并行度高：单个数字人是任务排队机制，队列中有任务先进先出，多agent可以将长任务单独执行，主任务不阻塞

缺点：

• 每次与专用数字人对话都要进行切换，挺麻烦。
• 数字人之间的信息共享需要携带在提示词中，否则就不知道。
• 目前openclaw的机制还是以单agent为主，多agent的支持还有待提升。

这种问题，我们通过拉群来解决，不同的群管理方法不同。

• 有些群乱哄哄，谁都能出来说两句，各有个的看法。
• 有些群里面只有老板安排活才有人主动说话，其它人都是应声虫，和自己没有关系的事从来不多嘴。
• 有些群就像联合国大会，有明确的目标，有主持人，有确定的流程，让谁说话才会说话，没有轮到他就不能说。
• 有些群就像创建公司，面对复杂的任务，大家分工明确，互相协作，通过反复的沟通调整，达成目的。

我们将有序的这三种模式分别叫做：群管理员路由模式、辩论主持人模式、工作流模式。

他们代表编程中的：switch、while、socket，你可以用他们组合成可通信的应用。

群管理员路由模式（switch)

群里消息 → 主数字人收到 → 匹配规则 → 分发任务 → 返回结果                           ↓                         不匹配 → main 自己处理

角色定位

• main:: 主数字人, 接收消息
• other agent: 子数字人,处理子任务消息

核心特点

• 1对1：一个消息 → 一个 sub-agent
• 无状态：每次独立，不记录上下文
• 直接转发：路由表匹配 → 转发 → 结束
• sub-agent 直接回复用户

就像我们ClawSpace这个群：当我行程查询时，assistant会将任务交给travel去处理，因为这些信息也只有travel可以正确处理。

辩论主持人模式(while)

辩论请求 → main 收到 → 识别主题                           ↓                      进入下一轮 →   正方A                          ↓                      进入下一轮 →   反方B                          ↓                      进入下一轮 →   正方A1                          ↓                      进入下一轮 →   反方B1                          ↓                      汇总所有观点 → 编排成文 → 发到群里                          ↓                     裁判评判  →  发起投票  →  收集投票信息                          ↓                    主观评价与打分总结 

角色定位：

• user : 需求发起，不参与讨论，参与投票环节
• main：主持人，管理讨论流程、控制讨论节奏，轮次管理、结束流程
• work：辩论正方，参与多轮辩论，可以有多名
• dev：辩论反方，参与多轮辩论，可以有多名
• home：裁判，独立判断正反方观点，收集公布所有人的投票信息

核心特点

 • 检测辩论关键词，初始化辩论主题、轮次、评判方法

 • 协调主持人、正方、反方参与辩论  

• 收集观点整理到群里   

• 流程控制（开场→发言→总结→搜集投票-评判）

就像我们DebateGroup这个群：

工作流模式(socket)

用户需求 → work (项目经理)               ↓          ┌────┴────┐          ↓         ↓        dev       tester          ↓         ↓    [交付/问题] ↔ [测试结果/问题]          ↓         ↓       work (汇总/再分配)

注意：理论上有死循环的风险。 实际上目前实践过程未遇到。

角色定位：

• 我 : 需求提出放，关键决策选择
• work：接收需求、拆解需求、方案设计、任务分发、进度管理、结果汇总
• dev：开发实现、交付成果、反馈需求问题、处理bug报告
• tester：测试验证、反馈bug、报告结果

核心特点

 • 所有任务是动态拆解，根据反馈回路进行调整。 • 同时协调多个参与方，并行进行开发、测试任务，跟踪子任务状态。  • 参与方dev与tester之间是有互动的，可以自我改进的  • 交付确认，经过任务委托方（work)验证，以开发总结、测试报告为基础的。

就像我们ProjectManage这个群： work拆解方案，接受子agent的反馈的。

三种模式完整对比

如果我们拉了一个数字人的群，什么都不处理，那这群里面要不没有人说话，要不乱哄哄,各抒己见。

如何实现多数字人协同

要实现这三种模式的关键有三个（可以让OpenClaw自己配置）：

• subagent的限制
• 路由规则或提示词限制
• 聊天软件的限制

subagent配置限制

默认情况下，agent不允许创建其它的agent session, 需要开启

//以work为例，可以调用dev和tester{  "id": "work",  "subagents": {    "allowAgents": [ //调用创建哪些subagent      "dev",      "tester"    ]  }}

prompt 注入

群管理路由SKILL：

# Router Skill - 消息路由## 功能根据消息内容自动路由到对应的专业 Agent。## 配置来源从 `/home/openclaw/workspace/config/router-routes.json` 读取路由配置。每条规则支持以下字段：- `name`: 规则名，便于排障- `pattern`: 命中关键词/正则片段- `exclude`: 排除词；命中则跳过该规则- `agentId`: 目标 agent- `desc`: 规则说明- `priority`: 优先级，越大越优先- `chatTypes`: 适用聊天类型，如 `group`

辩论SKILL：

# Debate Arena Skill - 完整辩论流程## 触发条件当用户消息包含以下关键词时激活：- 辩论相关：辩论、arena、对抗- 命令：init、add、start、next、stop、status## 核心流程### 1. 加载辩论引擎const { DebateArena } = require('~/workspace/scripts/debate-framework/debate-arena.js');...

产研项目管理群提示词：

//agent.md 对work的注入## 协作定位- `work` 是 `work -> dev -> tester` 链路的协调者- 用户需求进入 `work` 后，由 `work` 判断是否转给 `dev` 或 `tester`- `work` 负责任务分派与最终收口；## work → dev任务：<做什么>目标：<完成标准>范围：<改哪里>约束：<不要做什么>上下文：<原话/路径>## work → tester...

聊天软件支持

实现多agent协作其实到目前为止都与聊天软件没有关系。 与单一一个agent沟通，都可以实现多agent的协作。 但其体验会非常差，不理解这次讨论的过程，群里也没有氛围感。

默认不@让群里主bots回复

让所有人都不能@不回复，同时设定只有某一个人的消息可以回复即可。

"account": "openclaw_assistant","requireMention": false,"allowFrom": [  "ou_xxxxx" ]

让sub-agent 具备 message 工具权限

sub-agent可以自行回消息，不需要主agent汇集消息。

"tools": {  "message": true},

群聊期望（这是聊天软件决定的）：

• Wish 1：不@不允许回复，保证群里面不会进入无休无止的大乱斗。
• Wish 2：不需要@群管理员，他就会立刻响应我。
• Wish 3: 期望谁干活，谁说一话，而不是让领导做汇报。
• Wish 4: 期望多agent管理对session的管理方式，特别是群组session的管理方式升级。

目前我用过的聊天软件还没有能实现这种规则的，只好退而求其次：

1. 所有的都不需要@就可以回复。
2. 只有管理员一个人可以回复信息，其它人禁止回复。

这是最简单的方式，也可以用spawn_sender，来减少上下文的传递（不影响token), 或通过写共享文件来实现信息的分享。

有问题评论区见！