最近在产品工作中，我接触到越来越多团队在尝试用 OpenClaw 搭建多机器人协作系统。
一个典型的场景是：在飞书群里部署多个 Bot，通过"Boss Bot"分配任务给"子 Bot"，各自负责不同环节（如文案收集→编写→质检），形成流水线式的自动化工作流。
听起来很高效，但实际操作中，大多数人都会卡在两个问题：群里机器人根本不回复，或者任务执行到一半就中断了。
我花了几天时间调试和验证，找到了问题的根本原因和解决办法，先看流程图
今天把实操经验整理出来，希望能帮你少走一些弯路。
核心问题诊断
多 Bot 不回复或易中断的原因主要源于：
- 机制理解不足：Boss 和子 Agent 的职责划分不清，导致任务分配逻辑混乱
- 配置文件错误：openclaw.json 手工配置出错率高达 80%
- 执行规则缺失：子 Agent 不知道何时发群、何时回传，消息流向不清
- 超时和状态管理：没有明确的超时处理和状态回传机制
三步解决方案
第一步：自动生成机器人基础配置
与其手工编辑 openclaw.json（容易出错），不如用提示词让大模型自动生成。
操作流程：
- 准备以下信息：
- 飞书 App ID
- 飞书 App Secret
- 确认该机器人是否为 Boss 节点
- 将这些信息输入到提示词中
- 大模型会自动输出标准的 openclaw.json 配置
- 直接复制到项目中使用
优势：避免手工配置的语法错误，确保字段完整性。
第二步：配置 Boss Agent 的 Agents.md
Boss 的核心职能是任务分配和结果汇总，配置时需要明确两个部分：
2.1 明确成员分工
在 Agents.md 中列出所有子 Agent 及其职责，格式如下：
## 成员分工
- yu-redian：资料收集、外部信息、热点判断、事实整理、风险提醒
- yu-writer：改稿、成文、公众号内容、标题优化、正式输出
- yu-qa：答疑、解释概念、补充说明、裁判型总结这样做的目的是让 Boss 明确知道每个子 Agent 的能力边界，避免任务分配错误。
2.2 建立 Boss 的执行规则（关键）
这是防止中断的核心。设定"红线任务"规则：
| 触发条件 | 必须执行的动作 |
| 用户在群里说"收到""开始分配""我来安排""请稍等" | 必须在同一轮立即调用至少一个子 Agent |
| 多人协作任务 | 将上一个 Agent 的正式输出结果作为素材转给下一个 Agent |
| 对外宣布"已分配""正在推进" | 只有当至少一个子 Agent 调度已成功返回时才能说 |
| sessions_send 超时或失败 | 明确说明：卡在第几步、当前状态、重试方案（不能假装成功） |
第三步：配置子 Agent 的 Agents.md
子 Agent 的职责是执行任务，并将结果同时发到群里和回传给 Boss。这里的关键是理清消息流向。
3.1 群 ID 获取规则（按优先级）
- 优先级 1：Boss 消息正文中明确写了群 ID
示例："群 ID：-5225805751" 或 "发到群 -5225805751"→ 用这个 - 优先级 2：Boss 消息中没有群 ID，但 sourceSession 元数据包含
示例：`sourceSession=agent:yu-wiki:telegram:group:-5225805751`→ 从中提取 - 优先级 3：两处都没有群 ID→ 不发群，只回传 Boss
3.2 执行顺序（严格按照）
步骤 A：先发群
{
"action": "send",
"channel": "telegram",
"target": "<动态获取的群ID>",
"message": "🔥 瑜见热点：\n\n资料清单..."
}步骤 B：再回传 Boss
已发群：是
群：<群ID>
核心结果：...
状态：可进入下一步
[已完成，请boss进行下一步工作安排。]步骤 C：announce step
返回 ANNOUNCE_SKIP 状态
3.3 群任务强制规则
| 规则 | 说明 |
| 凡是标记为"群任务"的指令 | 必须直接发到群里（不是可选动作） |
| 执行顺序 | 必须先发群，再回 Boss |
| 回传 Boss 时 | 必须明确写出：已发群状态、群 ID、核心结果、当前状态 |
| 输出内容 | 必须是正式内容，不是流程说明或思路阐述 |
| 禁止行为 | 不要只回复"收到""稍等"等占位语 |
实施效果
按照上述三步配置后，我的测试环境现在可以稳定运行，不管怎么提问都能正常回复和传递。需要注意的是，token 消耗会比较大，这是多 Agent 协作的成本代价。
总结与建议
从产品角度看，OpenClaw 多 Bot 协作的核心是明确的职责划分和严格的执行规则。不是工具问题，而是配置方法论的问题。
如果你也在尝试类似的系统：
- 第一优先级：确保 Boss 的红线任务规则清晰（这决定了可靠性）
- 第二优先级：子 Agent 的消息流向规则要写死（先群后 Boss，先发后确认）
- 第三优先级：配置用自动化工具生成，减少人工错误
如果你有更优的实现方案，也欢迎评论区交流。