详细解析了 OpenClaw 中多 Bot 与多 Agent 协作的三种核心机制：多 Agent 路由、子代理（Sub-agents）和 Agent-to-Agent 会话互发。文章指出个人开发者应优先采用 1 个协调 Bot 配合内部并行子任务的架构，而非盲目增加 Bot 数量。内容涵盖配置核心关系（channels/accounts/bindings/agents）、Workspace 与 agentDir 的区别、Bot 互聊的局限性以及 SOUL.md 等文件的分工规范。通过实战 Demo 和落地路线图，帮助开发者构建高效、低成本且易维护的多智能体系统。
面向经常把 subagents、agent-to-agent、多个 bot 分工 混在一起的用户。本文提供一套可执行的判断框架：先分清机制，再选架构，再做最小可用落地。
在 OpenClaw 里，常见'多智能体协作'其实有 3 层机制：
bindings 路由到不同 agent。agents.list、bindings、accountId、peer。sessions_spawn）
sessions_spawn、maxConcurrent、maxSpawnDepth、announce。sessions_send）
sessions_send、tools.agentToAgent、maxPingPongTurns。一句话区分：
你说的'一个项目开发，多 agent 协作，不一定是 bot 给 bot 下指令，而是一个 bot 对接多个 agent 干活'，在 OpenClaw 语境里是完全成立且推荐的起步架构。
更具体地说：
sessions_spawn 分派并行子任务（需求、架构、前端、后端、测试）。这比一开始就上'5 个 bot 对外'更易控、成本更低、治理更简单。
| 需求 | 机制 | 是否需要多个 bot |
|---|---|---|
| 我只想一个入口，内部并行拆任务 | sessions_spawn（Sub-agents） | 不需要 |
| 不同团队/群聊要不同人格、不同权限、不同账号 | Multi-agent routing | 常需要 |
| 两个长期会话要结构化互发信息/回合讨论 | sessions_send（Agent-to-Agent） | 不一定 |
| 我只想'让某个 agent 跑一轮并可投递' | openclaw agent（Agent Send） | 不需要 |
经验法则：
从工程视角再补一条硬核理由：
拆 agent 不只是为了'分工'，更是为了'上下文压缩'。
一个 agent 全包所有角色时，系统提示词和历史会越来越臃肿，模型更容易遗忘约束、推理漂移、成本上升。把任务用 sessions_spawn 拆给专业 agent，相当于把上下文按职责切片，通常会更稳、更便宜。
如果你遇到下面任意 2 条，基本就该上多个 bot 了：
如果你是个人开发者，且主要诉求是'做事更快'，通常先不用多个 bot，先把 1 个 PM bot + subagents 跑顺。
channels、accounts、bindings、agents这 4 个概念不分清，最容易误配：
channels：渠道类型（telegram/feishu/discord…）channels.<channel>.accounts：这个渠道下的'机器人账号实例'（可理解为 bot 身份）agents.list：AI 大脑（工作区、会话、规则、技能）bindings：把'哪路入站消息'路由到'哪个 agent'可以记成一句话： bot 负责接消息，agent 负责思考，bindings 负责连线。
最小关系图（逻辑上）：
用户消息 -> channel/account(bot) -> binding 匹配 -> agentId -> 对应 agent 执行
再强调一次，避免误导：
如果你在做多 agent，agents.list[] 里每个 agent 常用可配项有这些：
id：唯一标识（必填）default：是否默认 agentname：展示名workspace：该 agent 的文件工作区（代码、文档、产物）agentDir：该 agent 的状态目录（认证、会话状态等）model：该 agent 默认模型（可配主模型 + 回退）params：模型参数覆盖（如 temperature、maxTokens）identity：身份信息（name/theme/emoji/avatar）groupChat：群聊规则（例如 mentionPatterns）subagents：子代理策略（常用 allowAgents、model）tools：工具权限策略（profile/allow/deny/elevated）sandbox：沙箱策略（是否沙箱、scope、workspaceAccess）skills：该 agent 可用技能清单memorySearch：记忆检索配置heartbeat：该 agent 的心跳任务配置你可以先记一条'起步最小集'：
idworkspacemodelidentitytoolssubagents.allowAgents一个可复制的最小示例：
{
"agents": {
"list": [
{
"id": "pm",
"default": true,
"workspace": "~/.openclaw/workspace-pm",
"model": "anthropic/claude-sonnet-4-6",
"identity": { "name": "PM Bot", "emoji": "🧭" },
"tools": { "profile": "coding", "deny": ["gateway"] },
"subagents": { "allowAgents": ["req"
这段配置表达的是：
pm 是'协调大脑'req/arch/... 是'专业大脑'channels.<channel>.accounts，通过 bindings 把入口接到 pmworkspace 和 agentDir 不是一回事很多人把这两个路径配反，结果协作异常。你可以这样理解：
workspace = 文件空间（代码/文档产出）agentDir = 状态空间（会话、认证、运行状态）实战建议：
workspace 或同仓不同子目录）。agentDir 要保持隔离，避免状态串扰。一句话： 可以共享文件视图，不要共享状态目录。
bindings 没有 priority 字段，但有'匹配优先级'OpenClaw 的 bindings 不是靠 priority: 1/2/3 这种字段排序，而是：
default: true，若多个则取首个）所以配置时建议：
default: trueopenclaw agents bindings 持续核对路由结果先说结论：不建议把'bot 对 bot 互聊'当主方案，尤其在 Telegram/飞书群组里。
channel_post。所以：在 Telegram 群组里，设计'机器人 A @ 机器人 B 然后 B 自动回'通常不稳定或直接不可行；如果一定要 bot-to-bot，只有频道路径更有机会。
allowBots 开关用于放开 bot-authored 消息触发，说明它不是默认设计目标。多数场景 没有必要。更稳妥的做法是：
sessions_spawn 并行调度专业 agentsessions_send（按白名单控制）这比'群里机器人互相喊话'更可控、可审计、可维护。 也可以理解为：优先内存级通信（sessions），避免网络级互喊（群里互 @）。
建议从 3 个开始，而不是一口气 6 个：
pm：协调、拆解、整合builder：实现（前后端都先放一起）qa：测试与验收稳定后再拆：builder -> frontend + backend，再加 arch、req。
目标：你一个人开发'电商网站 MVP'。对外只有 PM bot；内部有需求/架构/前端/后端/测试 agent。
pm（唯一 bot）req、arch、fe、be、qa{
"channels": {
"telegram": {
"accounts": {
"pm": {
"botToken": "TELEGRAM_BOT_TOKEN_PM"
}
}
}
},
"agents": {
"list": [
{ "id": "pm", "default": true, "workspace": "~/.openclaw/workspace-pm" },
{ "id": "req", "workspace": "~/.openclaw/workspace-req" },
{ "id": "arch", "workspace"
这段配置里，
channels.telegram.accounts.pm是'机器人入口账号'，agents.list[].id是'AI 大脑'。两者通过bindings连接。这样更不容易把 bot 和 agent 混为一谈。
你给 PM 的任务：
开发一个电商网站 MVP：
- 先拆解为需求、架构、前端、后端、测试 5 个子任务
- 并行执行
- 统一输出：里程碑、风险、下一个可执行动作
PM 执行策略：
sessions_spawn(agentId=req, task=...)sessions_spawn(agentId=arch, task=...)sessions_spawn(agentId=fe, task=...)sessions_spawn(agentId=be, task=...)sessions_spawn(agentId=qa, task=...)多 agent 协作最容易引发'消息刷屏焦虑'。推荐两种模式：
实现层面说明（按当前 OpenClaw 机制）：
sessions_spawn 本身是非阻塞，并带 announce 回传链路。announce: false 参数；应通过编排提示词约束 announce 输出（必要时使用 ANNOUNCE_SKIP 语义）并由 PM 统一对外口径。sessions_send）仅在下面情况建议上：
qa 会话持续追问 be 会话，形成多轮自动对齐并且需要配置：
{
"tools": {
"sessions": { "visibility": "all" },
"agentToAgent": {
"enabled": true,
"allow": ["pm", "qa", "be"]
}
},
"session": {
"agentToAgent": {
"maxPingPongTurns": 3
}
}
}
如果你只是'任务拆分 + 回收结果'，subagents 就够了，不需要急着开 agent-to-agent。
新手常见坑是 agent 之间无意义确认来回（谢谢/收到/不客气），白白烧轮次。
建议在 AGENTS.md 增加硬规则：
TERMINATE 或业务定义信号）session.agentToAgent.maxPingPongTurns 是最后一道保险丝，但不是最优治理手段；最省钱的方案仍是前置规则。
一个好用的实战配比：
这就是多 agent 架构的关键优势之一： 不是所有环节都要用最贵模型。
SOUL.md、AGENTS.md、skills/ 到底怎么分工这部分最容易踩坑：把所有规则都塞进 SOUL.md，结果提示词又长又乱。
SOUL.md：人格与边界（少而稳）适合放：
不适合放：
AGENTS.md：运行规则与执行偏好（中等稳定）适合放：
skills/xxx/SKILL.md：可复用'战术动作'（高复用）适合放：
判断标准：
SOUL.mdAGENTS.mdskills/*/SKILL.mdSOUL 只放稳定人格；流程和能力分别放 AGENTS 与 skills。sessions_spawn，不启用 agent-to-agent。builder + qa 两个内部 agent，固定输出模板。tools.agentToAgent。如果你是'一个人做项目'，最佳起点通常不是'多 bot 群聊编队'，而是：
这条路径兼顾了上手速度、成本和可维护性，也最符合 OpenClaw 的工程化演进方式。
避坑金句：
把 Bot 当成你的手机号（入口），把 Model 当成思考引擎（大脑），把 Agent 当成带记忆与规则的执行岗位（手 + 流程）。 你可以用一个手机号按事情转接给不同 Agent，也可以给每个 Agent 配独立专线（多 Bot）。 但除非你想把内部协作过程公开展示，否则优先用
sessions_spawn做内部传球，而不是在群里互相@。
sessions_send / sessions_spawn）：https://docs.openclaw.ai/concepts/session-tool
微信公众号「极客日志」，在微信中扫描左侧二维码关注。展示文案：极客日志 zeeklog
生成新的随机RSA私钥和公钥pem证书。 在线工具，RSA密钥对生成器在线工具，online
基于 Mermaid.js 实时预览流程图、时序图等图表，支持源码编辑与即时渲染。 在线工具，Mermaid 预览与可视化编辑在线工具，online
解析常见 curl 参数并生成 fetch、axios、PHP curl 或 Python requests 示例代码。 在线工具，curl 转代码在线工具，online
将字符串编码和解码为其 Base64 格式表示形式即可。 在线工具，Base64 字符串编码/解码在线工具，online
将字符串、文件或图像转换为其 Base64 表示形式。 在线工具，Base64 文件转换器在线工具，online
将 Markdown（GFM）转为 HTML 片段，浏览器内 marked 解析；与 HTML转Markdown 互为补充。 在线工具，Markdown转HTML在线工具，online