别再把多 Bot 和多 Agent 搞混了：OpenClaw 协作全景与架构避坑指南（TaoToken 配置篇）

1. 先把概念掰开多 Bot 和多 Agent 到底差在哪很多人第一次接触 OpenClaw 时会把「多 Bot」「多 Agent」「子代理」「Agent 互发消息」全塞进一个叫“协作”的筐里。结果配置写完消息要么串台要么在群里两个机器人互相 到天荒地老要么一个 Agent 把上下文撑爆开始胡说。问题不在工具在于一开始就没分清这几层机制各自解决什么。用一句话先立住边界Bot 是入口身份Agent 是思考大脑bindings 是连线规则。多 Bot 解决的是“对外谁接活”多 Agent 解决的是“内部谁干活”。你可以只有一个 Bot 却挂五个 Agent也可以五个 Bot 共用一个 Agent这两件事完全正交。我试过在一个电商 MVP 项目里同时开三个 Bot 对外结果用户消息在群里互相触发成本翻了三倍还没跑通。后来退回“一个 PM Bot 内部多 Agent”的架构反而一周就把需求、架构、前端、后端、测试的并行链路跑顺了。这篇就把这套判断框架和可复制的配置骨架交给你顺带把 TaoToken 作为统一 Key/API 通道接进来省得你在多个模型供应商之间来回切。适合谁看正在用 OpenClaw 做多角色协作、纠结要不要加 Bot、被 subagents 和 agent-to-agent 绕晕的开发者。读完你能做出架构选择并拿到一份能直接改的config.toml与settings.json骨架。2. 三层协作机制路由、子代理、会话互发OpenClaw 里常被混为一谈的“协作”其实是三层不同机制关键词和用途都不一样。多 Agent 路由Multi-agent routing解决入口分流哪条入站消息交给哪个 Agent。核心字段是agents.list、bindings、accountId、peer。典型形态是一个或多个 Bot 账号按 bindings 把消息路由到不同 Agent。子代理Sub-agentssessions_spawn解决并行执行当前 Agent 在后台拉起子任务做完回报。核心字段是sessions_spawn、maxConcurrent、maxSpawnDepth、announce。用户只跟一个协调者对话协调者内部并发调度。Agent-to-Agentsessions_send解决会话间通信把消息发到另一个 session可跨 Agent可有回合往返。核心字段是sessions_send、tools.agentToAgent、maxPingPongTurns。一句话区分多 Agent 路由是“谁对外接活”Sub-agents 是“谁在后台干活”Agent-to-Agent 是“两个会话如何互相发消息”。需求机制是否需要多个 Bot一个入口内部并行拆任务sessions_spawn不需要不同群聊要不同人格/权限/账号Multi-agent routing常需要两个长期会话结构化互发sessions_send不一定让某 Agent 跑一轮并可投递openclaw agent不需要从工程视角补一条硬理由拆 Agent 不只是分工更是上下文压缩。一个 Agent 全包所有角色时系统提示词和历史越来越臃肿模型容易遗忘约束、推理漂移、成本上升。用sessions_spawn把任务按职责切片通常更稳更便宜。2.1 什么时候“必须”考虑多个 Bot如果你遇到下面任意两条基本就该上多 Bot 了多人共用同一 Bot 容易串话串上下文客服 Bot 和研发 Bot 必须隔离责任某个 Bot 只允许查信息、另一个才能执行高风险动作需要在 Telegram/飞书显示不同机器人身份高价值入口用高质量模型、普通入口用便宜模型。个人开发者且主要诉求是“做事更快”先别上多 Bot把 1 个 PM Bot subagents 跑顺。2.2 channels、accounts、bindings、agents 的关系这四个概念不分清最容易误配。channels是渠道类型telegram/feishu/discordchannels.channel.accounts是该渠道下的机器人账号实例也就是 Bot 身份agents.list是 AI 大脑工作区、会话、规则、技能bindings把哪路入站消息路由到哪个 Agent。逻辑链路是用户消息 - channel/account(Bot) - binding 匹配 - agentId - 对应 Agent 执行。注意Bot 不等于 Agent。一个 Bot 可以只绑一个 Agent最常见也可以多个 Bot 绑同一个 Agent还可以一个渠道内多个 account 分别绑不同 Agent 做角色隔离。2.3 workspace 和 agentDir 不是一回事很多人把这两个路径配反协作就异常。workspace是文件空间代码、文档产出agentDir是状态空间会话、认证、运行状态。协作开发场景下希望 PM 能看到子 Agent 产出的代码相关 Agent 应共享同一代码仓库视图但agentDir要保持隔离避免状态串扰。一句话可以共享文件视图不要共享状态目录。3. 用 TaoToken 统一 Key/API 通道多 Agent 架构里模型调用会分散到多个 Agent如果每个 Agent 各配一套供应商 Key管理成本会爆炸。更省事的做法是走一个统一的 API 通道把 Key 收敛到一处。TaoToken 就是干这个的官网 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 入口 https://taotoken.net/api 。它的定位是统一 Key/API 通道让你在 OpenClaw 的多个 Agent 里用同一套接入方式调用不同模型不用为每个 Agent 单独维护供应商凭证。对多 Agent 场景尤其友好因为协调 Agent 和执行型子 Agent 往往要用不同档位的模型统一通道能让你在一处切换。操作路径很直接先到控制台创建 Key再在 OpenClaw 的模型配置里把 base URL 指向 TaoToken 的 API 入口。控制台地址 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite API Keys 管理页 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 。注意Key 只放在服务端配置或环境变量里不要写进会提交到仓库的明文文件。多 Agent 共用时建议按 Agent 角色分 Key方便单独限流和排查。如果你只是想先验证模型通不通可以直接用模型对话页 https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentchatutm_campaignrewrite 发一条消息确认链路。长期做编码或 Agent 编排可以看 Coding Plan https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 。4. 可复制的 config.toml 与 settings.json 骨架下面这份骨架对应“1 个 PM Bot 5 个专业 Agent”的最小可用架构。对外只有 PM Bot内部有需求、架构、前端、后端、测试五个 Agent。先看config.toml的渠道与绑定部分[channels.telegram.accounts.pm] botToken TELEGRAM_BOT_TOKEN_PM # 未来需要专家 Bot 时再开 # [channels.telegram.accounts.fe] # botToken TELEGRAM_BOT_TOKEN_FE [[bindings]] agentId pm [bindings.match] channel telegram accountId pm再看settings.json里的 Agent 列表与子代理策略{ 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 }, { 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 } } } }这段配置表达的是channels.telegram.accounts.pm是机器人入口账号agents.list[].id是 AI 大脑两者通过bindings连接。这样就不容易把 Bot 和 Agent 混为一谈。起步最小集只需记id、workspace、model、identity、tools、subagents.allowAgents。4.1 bindings 的匹配优先级OpenClaw 的 bindings 没有priority: 1/2/3这种字段而是先按匹配“具体程度”决策peer/guild/team/account/channel同一层级冲突时按配置顺序先出现先命中都没命中就回退到默认 Agentdefault: true多个则取首个。所以配置时只设一个default: true把更具体的绑定写在前面用openclaw agents bindings持续核对路由结果。4.2 需要 Agent-to-Agent 时再加这段只在“qa 会话要持续追问 be 会话形成多轮对齐”或“跨会话异步协作”时才上{ tools: { sessions: { visibility: all }, agentToAgent: { enabled: true, allow: [pm, qa, be] } }, session: { agentToAgent: { maxPingPongTurns: 3 } } }如果只是任务拆分加回收结果subagents 就够了不用急着开 agent-to-agent。5. 验证协作链路从发消息到拿到交付包配置写完别急着上生产按下面步骤验证。第一步确认路由命中。发一条测试消息给 PM Bot然后执行openclaw agents bindings输出里应能看到 telegram 的 pm 账号命中agentId: pm。如果命中的是别的 Agent检查 bindings 顺序和default设置。第二步验证子代理能拉起。给 PM 发一条编排任务开发一个电商网站 MVP - 先拆解为需求、架构、前端、后端、测试 5 个子任务 - 并行执行 - 统一输出里程碑、风险、下一个可执行动作PM 内部会执行sessions_spawn(agentIdreq, task...)等五次调用。观察日志里是否出现五个子任务并发maxConcurrent: 6允许同时跑六个。第三步确认结果回收。PM 汇总后应给你一个“可发布的交付包”包含里程碑、风险和下一步动作。如果只看到部分子任务结果检查subagents.allowAgents是否漏了某个 Agent。第四步验证模型通道。在 TaoToken 模型对话页发一条消息确认 Key 和 API 通道正常再回到 OpenClaw 看 Agent 调用是否走同一通道。5.1 少刷屏可见协作 vs 静默协作多 Agent 协作最容易引发消息刷屏焦虑。可见模式让用户看到阶段性进展适合耗时任务静默模式后台完成后只发最终结果适合短小任务。sessions_spawn本身是非阻塞并带announce回传链路。要静默不要依赖不存在的announce: false参数应通过编排提示词约束 announce 输出必要时用ANNOUNCE_SKIP语义由 PM 统一对外口径。5.2 防死循环父子通信要有终止协议新手常见坑是 Agent 之间无意义确认来回白白烧轮次。在AGENTS.md加硬规则每次回复必须包含实质性产出或明确终止信号禁止纯礼貌回合需要结束时输出统一终止词。session.agentToAgent.maxPingPongTurns是最后一道保险丝但最省钱的方案仍是前置规则。6. 本篇常见错排查报错一消息串台多个 Bot 抢同一个 Agent。检查 bindings 是否把不同 account 都指向了同一个 agentId。要隔离就分别绑不同 Agent。报错二子代理拉不起来。多半是subagents.allowAgents没写目标 Agent或maxSpawnDepth太小。默认通常只能 spawn 到自己跨 Agent 必须显式允许。报错三workspace 和 agentDir 配反导致协作异常。记住 workspace 共享文件视图、agentDir 隔离状态。配反会出现子 Agent 看不到产出或状态串扰。报错四群里两个 Bot 互相 不闭环。Telegram 群组里 Bot 看不到其他 Bot 的消息底层是 Bot API 事件可见性约束即使都是管理员也通常无法稳定闭环。飞书主路径是用户消息触发加 提及不是 Bot 消息驱动 Bot。多数场景没必要做机器人互 优先用 sessions 内部通信。报错五模型调用 401 或通道不通。检查 TaoToken Key 是否有效、base URL 是否指向 https://taotoken.net/api 以及 Key 是否按 Agent 角色分开配置。报错六上下文越来越长、成本飙升。这是没做上下文切片的典型症状。把任务用sessions_spawn拆给专业 Agent按职责切片。6.1 SOUL.md、AGENTS.md、skills 的分工把所有规则塞进SOUL.md是高频坑。判断标准人格原则放SOUL.md角色身份、沟通语气、红线边界协作规则放AGENTS.md任务拆解策略、默认交付格式、何时 spawn可复用操作手册做成skills/xxx/SKILL.md重复动作模板、固定流程、跨 Agent 共用能力包。6.2 模型混用是成本控制核心一个好用的配比PM/协调 Agent 用高质量模型负责拆解、权衡、集成执行型 subagents 按任务难度选性价比模型格式整理、基础检查、批量转换可用低成本模型高风险节点如架构决策、最终验收再切回高质量模型。这就是多 Agent 架构的关键优势之一不是所有环节都要用最贵模型。7. 按需接入模型对话、Coding Plan 与接入文档链路跑通后按你的实际场景选入口。只是验证模型通不通用模型对话页 https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentchatutm_campaignrewrite 。长期做编码或 Agent 编排看 Coding Plan https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 。接入配置和排障细节查接入文档 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 。Key 管理在 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 。回到架构本身个人开发者的最佳起点通常不是“多 Bot 群聊编队”而是一个协调入口 PM Bot、多个内部专业 Agent 用 subagents 并行、必要时再引入 agent-to-agent。这条路径兼顾上手速度、成本和可维护性。把 Bot 当成手机号入口把 Model 当成思考引擎大脑把 Agent 当成带记忆与规则的执行岗位。你可以用一个手机号按事情转接给不同 Agent也可以给每个 Agent 配独立专线。但除非你想把内部协作过程公开展示否则优先用sessions_spawn做内部传球而不是在群里互相 。