多 Agent 协作配置引导

要解决什么问题

在 QClaw / openclaw 上跑「主 Agent + 多个子 Agent」时，常见失败并不是模型不够聪明，而是配置没对齐：allowAgents 白名单、sessions.visibility、agentToAgent.enabled 任一缺失都会直接 forbidden；webchat 通道又不能用 sessions_spawn mode="session"，只能走 sessions_send 加用户在 UI 里预先建的持久会话。更麻烦的是 agent-to-agent 的 announce 双向管道容易形成主从互掐回环，文件类任务若长时间 sessions_send 等待还会把主会话堵死。

技能如何工作

本技能把实施拆成 7 个严格顺序阶段（Phase 0～6），核心原则是：不检测不动手，不确认不动手，不备份不改配置。

• Phase 0：用脚本检测 Python、openclaw.json 路径、磁盘与写权限、现有 Agent 列表、allowAgents / visibility / agentToAgent、channel 类型等，并列出需用户决策的冲突（例如 allowAgents 只能合并不能覆盖）。
• Phase 1～2：逐项规划 Agent 清单、委派路径、技能分配与模型需求，输出实施清单，等用户明确「确认执行」。
• Phase 3～4：备份 openclaw.json 后 patch 三项关键配置，为子 Agent 配 skills，并区分持久 sessionKey（agent:...:session-...）与临时 subagent key。
• Phase 5～6：端到端测试并输出报告；沉淀委派规则。跨 Agent 任务默认异步轮询（短超时 + 约定结果文件 + cron），极轻量任务才直接等待；结果只从 tool response 取，对 announce 必须 ANNOUNCE_SKIP，且 sessions_send 后应结束当前 turn。

适用边界与注意点

• 当前架构是主→子单向委派，子 Agent 之间不能直连，需主 Agent 中转。
• 仅 webchat 时无法 spawn 持久子会话，必须 UI 手动建会话再委派。
• 本技能能降低回环风险，不能替代网关层修复，也无法保证 100% 消除互掐；连续异常应熔断并改用异步轮询或人工中转。
• 附录含技能分类参考、实施/测试/委派模板及常见 forbidden 与 sessionKey 误用排查。