OpenClaw 单群多 Bot，不回复、易中断？我这样解决了

最近很多人都在研究一件事：拉一个微信群，放多个机器人，分配一个任务，让群里机器人自动回复，就像老板分配活，机器人呼哧呼哧干活一样——爽！

举个例子：你想写一篇关于 OpenClaw 最新版本的公众号文章，内部机器人自动分工——文案收集机器人先收集素材，然后交给文案编写机器人成文，最后质检机器人检查合格后直接发给用户。理想很丰满，但一上手，大多数人都会遇到两个坑：

1. 无论如何，群就是没反应，机器人跟没睡醒一样。
2. 好不容易动起来了，又动不动就中断，像个半路掉链子的实习生。

今天不堆原理，直接上流程图和实操步骤。1000多字的原理稿写好了又删了，直接一张图说清楚核心逻辑。

下面三个步骤，搭配好 Boss 节点和子 Agent 的配置文件，就能稳定跑起来。

解决办法

这套配置里有两个角色：

• Boss
  ：负责分配任务给子 Agent，并接收子 Agent 的结果，相当于项目经理。

• 子 Agent
  ：负责具体干活，干完活之后要同时把结果发给 Boss 和群里。

下面三步搞定：

第一步：配置多个机器人的基本信息

这一步看似简单，但手动配置 openclaw.json 时，80% 的人都会栽坑。推荐用下面这个提示词来生成配置文件：

只需要告诉大模型你的飞书 APPID、APPSecert，以及是否是 Boss 节点，它就能自动给你配好。省时省心，还不容易出错。

第二步：配置 Boss 的 Agents.md

Boss 的配置文件里，两点必须卡死：

01 明确 Boss 的角色，把所有子 Agent 的信息列出来

比如：

## 成员分工
- yu-redian：资料收集、外部信息、热点判断、事实整理、风险提醒
- yu-writer：改稿、成文、公众号内容、标题优化、正式输出
- yu-qa：答疑、解释概念、补充说明、裁判型总结

02 明确 Boss 的红线任务

Boss 的首要职责是分配任务，不是自己干活。所以必须给足约束，比如：

只要你在群里说出“收到”“开始分配”“我来安排”“请稍等”等表述，
你必须在同一轮立即调用至少一个子 Agent，
如果没有立即调用，则本轮任务视为失败。
如果是多人协作任务，把上一个 Agent 的正式输出结果作为素材转给下一个 Agent。

只有当至少一个子 Agent 的调度已成功返回时，你才能对外说“已经开始分配”“已经安排”“正在推进”。
如果 `sessions_send` 超时、失败、或没有确认回传，你不得假装已经成功分发，必须明确说明：卡在第几步、当前状态是什么、接下来准备如何重试或补救。

第三步：配置子 Agent 的 Agents.md

子 Agent 的作用是干活，干完后把结果传递给 Boss，同时还要发到群里。写清楚执行顺序和群 ID 获取规则，是稳定运行的关键。

比如：

### 群 ID 获取规则（按优先级）
1. Boss 消息正文中明确写了群 ID（如"群 ID：-5225805751"或"发到群 -5225805751"）→ 用这个
2. 消息正文没有群 ID，但 sourceSession 元数据中包含群信息（如 `sourceSession=agent:yu-wiki:telegram:group:-5225805751`）→ 从中提取
3. 两处都没有群 ID → 不发群，只回传 Boss

### 执行顺序
1. **先发群**：用 message tool 发到对应群
   {
     "action": "send",
     "channel": "telegram",
     "target": "<动态获取的群ID>",
     "message": "? 瑜见热点：nn资料清单..."
   }
2. **再回传 Boss**：
   已发群：是
   群：<群ID>
   核心结果：...
   状态：可进入下一步
   [已完成，请boss进行下一步工作安排。]
3. **announce step**：回复 ANNOUNCE_SKIP

另外，子 Agent 也要遵守强制规则：

## 群任务强制规则
- 凡是明确标记为“群任务”的指令，必须直接发到群里
- 发群是必做动作，不是可选动作
- 必须先发群，再回 Boss
- 发群完成后，再通过 sessions_send 把结果同步给 Boss
- 同步给 Boss 时，必须明确写出：`已发群：是 / 群：... / 核心结果：... / 状态：可进入下一步`
- 并明确告知：`[已完成，请boss进行下一步工作安排。]`
- 不要只回复“收到”“我来写”“我整理一下”“稍等”
- 不要先解释写作思路，再决定是否执行
- 群任务中，你输出的必须是正式内容，不是流程说明

写在后面的话

这套配置是经过几天调优后的成果。现在不管怎么问，都能稳定运行。唯一的代价是 token 消耗比较大，毕竟多轮对话加多 Agent 协同，算力成本确实不低。但比起手动调度和反复试错，这点成本是值得的。