面向经常把subagents、agent-to-agent、多个 bot 分工混在一起的用户。本文给你一套可执行的判断框架先分清机制再选架构再做最小可用落地。背景我为什么写这篇前两天我和“产品经理机器人”聊 多智能体 协作聊着聊着就卡住了我到底该做“一个 PM bot 多个内部 agent”还是“每个角色都配一个 bot”subagents、agent-to-agent、multi-agent routing看起来都像“协作”但实际用法和成本完全不同。如果你也有同样困惑——比如想提高开发效率但不想把系统复杂度拉满不确定什么时候该上多个 bot担心在 Telegram/飞书群里做 bot 互 会踩坑那这篇就是写给你的。目标很直接10 分钟读完能做出正确架构选择。一、先给结论这三件事不是一回事在 OpenClaw 里常见“多智能体协作”其实有 3 层机制多 Agent 路由Multi-agent routing解决的是「入口分流」哪条入站消息由哪个 agent 接。常见形态一个或多个 bot 账号按bindings路由到不同 agent。关键词agents.list、bindings、accountId、peer。子代理Sub-agentssessions_spawn解决的是「并行执行」当前 agent 在后台拉起子任务做完后回报。常见形态用户只对话一个“协调者”协调者内部并发调度多个子任务。关键词sessions_spawn、maxConcurrent、maxSpawnDepth、announce。Agent-to-Agent会话互发sessions_send解决的是「会话间通信」把消息发到另一个 session可跨 agent可有回合往返。常见形态两个长期会话互相协作偏“协议化对话”。关键词sessions_send、tools.agentToAgent、maxPingPongTurns。一句话区分多 Agent 路由 “谁对外接活”Sub-agents “谁在后台干活”Agent-to-Agent “两个会话如何互相发消息”二、你当前的认知是否正确你说的“一个项目开发多 agent 协作不一定是 bot 给 bot 下指令而是一个 bot 对接多个 agent 干活”在 OpenClaw 语境里是完全成立且推荐的起步架构。更具体地说你可以只保留1 个 PM bot协调入口。PM 在同一会话内通过sessions_spawn分派并行子任务需求、架构、前端、后端、测试。用户只和 PM 对话专业 agent 在后台完成并汇总。这比一开始就上“5 个 bot 对外”更易控、成本更低、治理更简单。三、什么时候用哪种机制决策表需求机制是否需要多个 bot我只想一个入口内部并行拆任务sessions_spawnSub-agents不需要不同团队/群聊要不同人格、不同权限、不同账号Multi-agent routing常需要两个长期会话要结构化互发信息/回合讨论sessions_sendAgent-to-Agent不一定我只想“让某个 agent 跑一轮并可投递”openclaw agentAgent Send不需要经验法则个人用户先1 bot subagents。小团队入口仍可 1 bot但可按需要增加 1–2 个专业 bot。组织级隔离多 bot 多 agent 明确 bindings。从工程视角再补一条硬核理由拆 agent 不只是为了“分工”更是为了“上下文压缩”。一个 agent 全包所有角色时系统提示词和历史会越来越臃肿模型更容易遗忘约束、推理漂移、成本上升。把任务用sessions_spawn拆给专业 agent相当于把上下文按职责切片通常会更稳、更便宜。3.1 什么时候“必须考虑多个 bot”如果你遇到下面任意 2 条基本就该上多个 bot 了多人共用不同人/不同团队同时在用同一个 bot 容易串话、串上下文。要隔离责任比如“客服 bot”和“研发 bot”必须分开避免误发和误操作。要隔离权限某个 bot 只允许查信息另一个 bot 才能执行高风险动作。要隔离身份你希望在 Telegram/飞书里显示不同机器人身份名字、头像、账号对接不同场景。要隔离成本与模型高价值入口用高质量模型普通入口用便宜模型。如果你是个人开发者且主要诉求是“做事更快”通常先不用多个 bot先把1 个 PM bot subagents跑顺。3.2 配置核心关系channels、accounts、bindings、agents这 4 个概念不分清最容易误配channels渠道类型telegram/feishu/discord…channels.channel.accounts这个渠道下的“机器人账号实例”可理解为 bot 身份agents.listAI 大脑工作区、会话、规则、技能bindings把“哪路入站消息”路由到“哪个 agent”可以记成一句话bot 负责接消息agent 负责思考bindings 负责连线。最小关系图逻辑上用户消息 - channel/account(bot) - binding 匹配 - agentId - 对应 agent 执行 AI写代码text1再强调一次避免误导bot ! agent一个 bot 可以只绑定一个 agent最常见也可以多个 bot 绑定同一个 agent多个入口共用一个大脑也可以一个渠道内多个 account 分别绑定不同 agent多角色隔离3.3 每个 agent 还能配置什么实用清单如果你在做多 agentagents.list[]里每个 agent 常用可配项有这些id唯一标识必填default是否默认 agentname展示名workspace该 agent 的文件工作区代码、文档、产物agentDir该 agent 的状态目录认证、会话状态等model该 agent 默认模型可配主模型回退params模型参数覆盖如 temperature、maxTokensidentity身份信息name/theme/emoji/avatargroupChat群聊规则例如 mentionPatternssubagents子代理策略常用allowAgents、modeltools工具权限策略profile/allow/deny/elevatedsandbox沙箱策略是否沙箱、scope、workspaceAccessskills该 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, arch, fe, be, qa], }, }, { id: req, workspace: ~/.openclaw/workspace-req, model: openai/gpt-5.2-codex }, { id: arch, workspace: ~/.openclaw/workspace-arch, model: anthropic/claude-opus-4-6 }, ], }, } AI写代码json512345678910111213141516171819202122这段配置表达的是pm是“协调大脑”req/arch/...是“专业大脑”真正的 bot 入口还在channels.channel.accounts通过bindings把入口接到pm3.4 关键纠正workspace和agentDir不是一回事很多人把这两个路径配反结果协作异常。你可以这样理解workspace 文件空间代码/文档产出agentDir 状态空间会话、认证、运行状态实战建议协作开发场景如果你希望 PM 能直接看到子 agent 产出的代码相关 agent 应该共享同一代码仓库视图同一workspace或同仓不同子目录。状态隔离场景agentDir要保持隔离避免状态串扰。一句话可以共享文件视图不要共享状态目录。3.5bindings没有priority字段但有“匹配优先级”OpenClaw 的bindings不是靠priority: 1/2/3这种字段排序而是先按匹配“具体程度”决策peer/guild/team/account/channel同一层级冲突时按配置顺序“先出现先命中”都没命中时回退到默认 agentdefault: true若多个则取首个所以配置时建议只设置一个default: true把更具体的绑定写在前面用openclaw agents bindings持续核对路由结果四、一个高频误区群里让机器人互相 对话行不行先说结论不建议把“bot 对 bot 互聊”当主方案尤其在 Telegram/飞书群组里。4.1 Telegram群组里基本不可依赖频道里才可能在 OpenClaw 的 Telegram 处理逻辑里已明确说明Telegram bot 在群组里看不到其他 bot 的消息但在频道channel可以处理channel_post。这不是 OpenClaw 单独限制底层是 Telegram Bot API 的事件可见性约束常见与 Privacy Mode 一起表现出来。即使两个 bot 都是管理员也通常无法形成稳定闭环互聊。所以在 Telegram 群组里设计“机器人 A 机器人 B 然后 B 自动回”通常不稳定或直接不可行如果一定要 bot-to-bot只有频道路径更有机会。4.2 飞书Lark工程上不推荐走 bot 互聊链路飞书插件当前主路径是“用户消息触发 提及 路由策略”不是“bot 消息驱动 bot”。配置层也没有像 Discord/Slack 那样的allowBots开关用于放开 bot-authored 消息触发说明它不是默认设计目标。在企业群里强行做 bot 互聊还会带来循环触发、噪声刷屏、成本不可控。4.3 有必要做机器人互相 吗多数场景没有必要。更稳妥的做法是对外一个协调入口 botPM对内用sessions_spawn并行调度专业 agent真要跨会话协作再用sessions_send按白名单控制这比“群里机器人互相喊话”更可控、可审计、可维护。也可以理解为优先内存级通信sessions避免网络级互喊群里互 。五、单人场景的推荐架构最小可用5.1 你需要几个 bot阶段 1推荐1 个 botPM就够。阶段 2可选当你发现“你自己经常想直接找某个专家聊天”再给专家加独立 bot。5.2 你需要几个 agent建议从 3 个开始而不是一口气 6 个pm协调、拆解、整合builder实现前后端都先放一起qa测试与验收稳定后再拆builder - frontend backend再加arch、req。六、实战 Demo1 个 PM bot 5 个专业 agent内部协作目标你一个人开发“电商网站 MVP”。对外只有 PM bot内部有需求/架构/前端/后端/测试 agent。6.1 Agent 拓扑对外入口pm唯一 bot内部专业 agentreq、arch、fe、be、qa6.2 配置要点核心片段{ channels: { telegram: { accounts: { // 对外入口 botPM pm: { botToken: TELEGRAM_BOT_TOKEN_PM }, // 可选专家 bot你未来需要再开 // fe: { botToken: TELEGRAM_BOT_TOKEN_FE }, }, }, }, agents: { list: [ { id: pm, default: true, workspace: ~/.openclaw/workspace-pm }, { id: req, workspace: ~/.openclaw/workspace-req }, { id: arch, workspace: ~/.openclaw/workspace-arch }, { id: fe, workspace: ~/.openclaw/workspace-fe }, { id: be, workspace: ~/.openclaw/workspace-be }, { id: qa, workspace: ~/.openclaw/workspace-qa }, ], defaults: { subagents: { maxConcurrent: 6, maxSpawnDepth: 2, runTimeoutSeconds: 900, }, }, }, bindings: [ // 关键把 Telegram 的 pm 账号入口绑定到 pm 这个 agent对外一个入口 { agentId: pm, match: { channel: telegram, accountId: pm } }, ], // 关键允许 pm 定向 spawn 到指定 agentId // 若不设默认通常只能 spawn 到自己 //也可在具体 agent 上单独配置 allowAgents } AI写代码json5123456789101112131415161718192021222324252627282930313233343536373839这段配置里channels.telegram.accounts.pm是“机器人入口账号”agents.list[].id是“AI 大脑”。两者通过bindings连接。这样更不容易把 bot 和 agent 混为一谈。6.3 PM 的编排提示词示例你给 PM 的任务开发一个电商网站 MVP - 先拆解为需求、架构、前端、后端、测试 5 个子任务 - 并行执行 - 统一输出里程碑、风险、下一个可执行动作 AI写代码text1234PM 执行 策略 sessions_spawn(agentIdreq, task...)sessions_spawn(agentIdarch, task...)sessions_spawn(agentIdfe, task...)sessions_spawn(agentIdbe, task...)sessions_spawn(agentIdqa, task...)汇总结果给你一个“可发布的交付包”6.3.1 少刷屏策略可见协作 vs 静默协作多 agent 协作最容易引发“消息刷屏焦虑”。推荐两种模式可见模式让用户看到阶段性进展适合耗时任务静默模式后台完成后只发最终结果适合短小任务实现层面说明按当前 OpenClaw 机制sessions_spawn本身是非阻塞并带 announce 回传链路。如果你要“静默”不要依赖不存在的announce: false参数应通过编排提示词约束 announce 输出必要时使用ANNOUNCE_SKIP语义并由 PM 统一对外口径。6.4 什么时候引入 Agent-to-Agentsessions_send仅在下面情况建议上你要让qa会话持续追问be会话形成多轮自动对齐你要跨会话异步协作不只是一次性子任务并且需要配置{ tools: { sessions: { visibility: all }, agentToAgent: { enabled: true, allow: [pm, qa, be], }, }, session: { agentToAgent: { maxPingPongTurns: 3 }, }, } AI写代码json5123456789101112如果你只是“任务拆分 回收结果”subagents 就够了不需要急着开 agent-to-agent。6.5 防死循环父子通信要有“终止协议”新手常见坑是 agent 之间无意义确认来回谢谢/收到/不客气白白烧轮次。建议在AGENTS.md增加硬规则每次回复必须包含“实质性产出”或“明确终止信号”禁止纯礼貌回合需要结束时输出统一终止词例如TERMINATE或业务定义信号session.agentToAgent.maxPingPongTurns是最后一道保险丝但不是最优治理手段最省钱的方案仍是前置规则。6.6 模型混用多 agent 的成本控制核心手段一个好用的实战配比PM/协调 agent高质量模型负责拆解、权衡、集成执行型 subagents按任务难度选择性价比模型格式整理、基础检查、批量转换可用低成本模型高风险节点架构决策/最终验收再切回高质量模型这就是多 agent 架构的关键优势之一不是所有环节都要用最贵模型。七、SOUL.md、AGENTS.md、skills/到底怎么分工这部分最容易踩坑把所有规则都塞进SOUL.md结果提示词又长又乱。7.1SOUL.md人格与边界少而稳适合放角色身份例如“你是技术项目经理”沟通语气简洁/专业/偏业务红线边界安全、合规、拒绝策略不适合放具体 SOP 流程细节频繁变化的工具参数7.2AGENTS.md运行规则与执行偏好中等稳定适合放任务拆解策略默认交付格式先结论再行动项何时 spawn、何时直接回答7.3skills/xxx/SKILL.md可复用“战术动作”高复用适合放重复动作模板比如“生成测试计划”“发布说明生成器”依赖某些工具或外部命令的固定流程跨多个 agent 共用的能力包判断标准这是“人格原则”吗放SOUL.md这是“协作规则”吗放AGENTS.md这是“可复用操作手册”吗做成skills/*/SKILL.md八、常见误区与修正误区 1多 agent 必须多 bot不是。多 agent 可以纯内部协作对外仍一个 bot。误区 2subagents 和 agent-to-agent 一样不是。subagents 是“后台子任务”agent-to-agent 是“会话间消息通信”。误区 3先把架构做满再用建议反过来先 1 bot 2~3 agent 跑通再按瓶颈拆分。误区 4所有个性化都写 SOULSOUL只放稳定人格流程和能力分别放AGENTS与skills。误区 5多个 bot 就等于高级不一定。很多情况下只是把系统复杂度提前了。先跑通“一个 bot 内部分工”再按真实痛点扩展通常更快更稳。九、你的一页落地路线图个人开发者版第 1 周1 个 PM bot先启用sessions_spawn不启用 agent-to-agent。第 2 周增加builderqa两个内部 agent固定输出模板。第 3 周把高频动作沉淀成 2–3 个 skills。第 4 周若出现“长期跨会话协商”需求再小范围启用tools.agentToAgent。持续优化按成本和质量调模型主协调高质量、子任务性价比模型。十、结语如果你是“一个人做项目”最佳起点通常不是“多 bot 群聊编队”而是一个协调入口PM bot多个内部专业 agentsubagents 并行必要时再引入 agent-to-agent这条路径兼顾了上手速度、成本和可维护性也最符合 OpenClaw 的工程化演进方式。避坑金句把 Bot 当成你的手机号入口把 Model 当成思考引擎大脑把 Agent 当成带记忆与规则的执行岗位手流程。你可以用一个手机号按事情转接给不同 Agent也可以给每个 Agent 配独立专线多 Bot。但除非你想把内部协作过程公开展示否则优先用sessions_spawn做内部传球而不是在群里互相。如果文中有理解偏差、版本差异或你有更好的工程实践欢迎各位大佬指出和补充。我会持续修订这篇文章让它更准确、更好用。十一、参考链接OpenClaw 文档首页https://docs.openclaw.ai/Multi-agent routinghttps://docs.openclaw.ai/concepts/multi-agentSub-agentshttps://docs.openclaw.ai/tools/subagentsSession toolssessions_send/sessions_spawnhttps://docs.openclaw.ai/concepts/session-toolAgent Sendhttps://docs.openclaw.ai/tools/agent-sendSkillshttps://docs.openclaw.ai/tools/skillsAgent workspacehttps://docs.openclaw.ai/concepts/agent-workspaceAnthropic行业参考https://www.anthropic.com/OpenAI行业参考https://openai.com/