夜雨聆风
前面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的反馈的。
三种模式完整对比
| 协调者 | |||
| 触发者 | |||
| 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的管理方式升级。
目前我用过的聊天软件还没有能实现这种规则的，只好退而求其次：
所有的都不需要@就可以回复。 只有管理员一个人可以回复信息，其它人禁止回复。
这是最简单的方式，也可以用spawn_sender，来减少上下文的传递（不影响token), 或通过写共享文件来实现信息的分享。
有问题评论区见！