1. 飞书群里塞进多个智能体到底难在哪OpenClaw 智能体应用第一集我想先把最容易劝退人的那一步讲透在飞书群聊里跑多智能体协作。OpenClaw 是一个可以自托管的智能体运行框架它能把飞书、Telegram、Discord 这类聊天渠道接进来让每个机器人背后挂一个独立的 Agent。所谓多智能体配置就是让「写作助手」「工作助手」「开发助手」各自拥有独立的工作目录、独立的人设、独立的模型通道然后在同一个飞书群里按账号分流谁被 谁回答互不串味。它适合谁适合已经在用飞书做团队协作、又想让 AI 真正参与日常流程的人。比如运营群要一个会写文案的机器人研发群要一个能读代码的机器人管理群要一个只做汇总的机器人。如果只用一个机器人硬扛所有场景你会发现它的记忆是乱的、人设是飘的、权限是没法隔离的。我踩过的坑集中在三块第一飞书应用的事件订阅和权限没配对机器人收不到群消息第二多个飞书应用账号在 OpenClaw 里没有做 Binding 路由消息全被 main 吃掉第三模型调用鉴权分散在好几个地方每个 Agent 都要单独配一遍 Key维护起来很痛苦。这一篇就按「角色划分 → 飞书应用准备 → TaoToken 统一接入 → 配置文件 → 验证 → 排障」的顺序走一遍配置片段都可以直接复制改。先明确一个概念边界后面才不会乱。Agent 是独立的「大脑」有模型、记忆、人设、工具、运行环境agentId 是它的唯一标识单 Agent 模式下默认叫 mainaccountId 是渠道层面的账号标识比如你在飞书里建了两个机器人应用就有两个 accountIdBinding 是把「渠道 账号 对等方」映射到某个 agentId 的桥。理解了这四个词多智能体配置就只是填空题。2. 用 TaoToken 统一模型通道先把 Key 这件事收口多智能体最烦的不是写配置是每个 Agent 都要配一遍模型鉴权。OpenClaw 的 agents 配置里defaults 可以设一个主模型但一旦你想让 writer 用写作向模型、coding 用代码向模型就得在 providers 里分别写 baseUrl 和 apiKey。如果每个 Agent 都直连不同厂商Key 会散落在 openclaw.json 的各个角落改一次要翻半天。我的做法是用 TaoToken 做统一接入层。它提供 OpenAI 兼容的 API 通道你只需要一个 Base URL 和一个 Key就能在 OpenClaw 里把模型 provider 指向它然后按模型 ID 切换。这样 agents 的 defaults 和各个 Agent 的模型覆盖都走同一条通道鉴权只维护一份。具体操作先到 TaoToken 控制台创建一个 API Key。打开 https://taotoken.net/api-keys 登录后新建 Key复制出来。注意这个 Key 只在创建时完整显示一次先存到你的密码管理器或者临时文件里。然后确认你要用的模型 ID。OpenClaw 的 models.providers 里每个模型是一个对象id 和 name 要和你实际调用的模型名一致。你可以先在模型对话页面试一条确认通道通不通https://taotoken.net/model-chat 。在对话页面选一个模型发一句「你好」能正常返回就说明 Key 和通道没问题。接下来是 OpenClaw 侧的 provider 配置。OpenClaw 的模型配置在 openclaw.json 的 models 字段下mode 设为 merge 表示和内置 provider 合并。你要做的是新增一个 OpenAI 兼容的 providerbaseUrl 指向 TaoToken 的 API 地址apiKey 填你刚创建的 Key。这里有个细节OpenClaw 的 provider 配置里 api 字段决定用哪种协议适配OpenAI 兼容通道一般写 openai 或对应适配值具体以你 OpenClaw 版本的 provider 文档为准。注意不要把 Key 直接写进会提交到 Git 的配置文件。OpenClaw 支持用环境变量或独立的 secrets 文件生产环境建议走环境变量注入openclaw.json 里只留占位符。配好 provider 之后agents.defaults.model.primary 指向你选的主模型比如taotoken/glm-4.7-flash这种「provider/modelId」的写法。各个 Agent 如果要用不同模型在它自己的 model 字段里覆盖。这样一套 Key 支撑所有 Agent后面加机器人只需要加 agentId 和 Binding不用再碰鉴权。如果你后面要跑长期编码类 Agent或者想让多个 Agent 共享额度做持续任务可以了解下 Coding Planhttps://taotoken.net/coding-plan 。它的定位是给需要长期、稳定调用通道的编码和 Agent 场景用的和按量 Key 是两种用法按你的实际负载选。3. 可复制的多智能体配置agents、bindings、channels 三件套这一节是全文的核心我把 OpenClaw 里多智能体 飞书多账号的配置拆成三块讲agents 定义大脑bindings 定义路由channels 定义飞书账号。三块缺一不可少一块消息就进不来或者进错人。先看 agents。每个 Agent 需要 id、name、workspace、agentDir 四个关键字段。workspace 是它的工作目录所有文件操作都在这里agentDir 是它的会话和状态目录。我习惯按用途命名writer 对应写作coding 对应代码work 对应工作事务。用命令行添加最省事openclaw agents add writer openclaw agents add coding openclaw agents add work openclaw agents add alerts执行openclaw agents add writer时向导会问你工作目录、是否从 main 复制 auth profiles、是否现在配置模型。工作目录我填/home/gpu3090/.openclaw/workspace-writerauth profiles 选 Yes 从 main 复制模型配置可以先跳过后面统一在 openclaw.json 里改。完成后它会打印Agent writer ready.并提示 Workspace OK 和 Sessions OK。写入 openclaw.json 后agents 段大概长这样{ agents: { defaults: { model: { primary: taotoken/glm-4.7-flash }, models: { taotoken/glm-4.7-flash: {} }, workspace: /home/gpu3090/.openclaw/workspace }, list: [ { id: main }, { id: coding, name: coding, workspace: /home/gpu3090/.openclaw/workspace-coding, agentDir: /home/gpu3090/.openclaw/agents/coding/agent }, { id: work, name: work, workspace: /home/gpu3090/.openclaw/workspace-work, agentDir: /home/gpu3090/.openclaw/agents/work/agent }, { id: writer, name: writer, workspace: /home/gpu3090/.openclaw/workspace-writer, agentDir: /home/gpu3090/.openclaw/agents/writer/agent } ] } }再看 bindings。Binding 的 match 里三个字段channel 固定 feishuaccountId 对应 channels 里的账号 keypeer 可选用来限定具体群或联系人。如果你不写 peer这个账号收到的所有消息都路由到指定 agentId。我一般先不写 peer等验证通了再按群细化。{ bindings: [ { agentId: main, match: { channel: feishu, accountId: main } }, { agentId: work, match: { channel: feishu, accountId: feishu-work } }, { agentId: writer, match: { channel: feishu, accountId: feishu-writer } } ] }最后是 channels 里的飞书账号。每个账号需要 appId、appSecret、botNamegroupAllowFrom 是允许的群成员 open_id 白名单。appSecret 在飞书开放平台创建应用后拿到填进配置时不要用占位符要填真实字符串。groupPolicy 设 allowlist 表示只响应白名单内的群dmPolicy 设 pairing 表示私聊需要配对码。{ channels: { feishu: { enabled: true, domain: feishu, accounts: { main: { appId: cli_a9172c074e619cd3, appSecret: 你的主助手应用密钥, botName: 主助手, groupAllowFrom: [ou_620d372bdc5b000b98b5f6213670d976] }, feishu-work: { appId: cli_a9303e54a678dbc2, appSecret: 你的工作助手应用密钥, botName: 工作助手, groupAllowFrom: [ou_620d372bdc5b000b98b5f6213670d976] }, feishu-writer: { appId: cli_a93157510938dcc4, appSecret: 你的写作助手应用密钥, botName: 写作助手, groupAllowFrom: [ou_620d372bdc5b000b98b5f6213670d976] }, default: { groupPolicy: allowlist, dmPolicy: pairing } } } } }飞书开放平台侧每个应用都要开事件订阅回调地址指向你的 OpenClaw gateway。gateway 默认端口 18789bind 是 loopback也就是说默认只监听本机。如果你把 OpenClaw 跑在服务器上飞书回调需要一个公网可达的地址这一步按你的部署方式处理核心是让飞书能把事件推到 gateway。权限清单至少要包含接收群消息、发送消息、读取用户信息、读取群信息。事件订阅里勾选「接收消息」相关事件。注意三个飞书应用要分别建appId 不能复用。同一个应用挂两个 accountId 会导致消息重复或路由混乱。4. 验证一条消息触发多智能体分工回复配置写完重启 gateway 让配置生效。OpenClaw 的 gateway 是 systemd 服务的话执行sudo systemctl restart openclaw-gateway.service重启后看日志确认飞书插件注册成功。正常会看到类似feishu_doc: Registered feishu_doc, feishu_app_scopes、feishu_chat: Registered feishu_chat tool、feishu_wiki: Registered feishu_wiki tool、feishu_drive: Registered feishu_drive tool、feishu_bitable: Registered bitable tools的输出。这些说明飞书相关的工具都加载了。然后到飞书群里做验证。第一步 主助手发「你好」看它是否回复。正常返回类似「你好很高兴和你聊天。有什么我可以帮忙的或者你想聊聊什么」。第二步 写作助手发「你的工作目录」它应该返回/home/gpu3090/.openclaw/workspace-writer这说明 writer 这个 Agent 的 workspace 生效了消息确实路由到了它而不是 main。第三步验证分工。在同一个群里 工作助手发一条工作相关的请求 写作助手发一条写作请求观察两个机器人的回复风格和工作目录是否不同。如果两个机器人都回了且各自的工作目录正确说明多智能体路由通了。这里有个容易忽略的点飞书群里多个机器人 的时候要 对具体的机器人。飞书的事件推送里会带被 的机器人标识OpenClaw 根据 accountId 匹配 Binding再路由到 agentId。如果你 了 A 机器人但 B 机器人也回复了多半是 Binding 的 accountId 配重了或者某个账号没配 Binding 落到了默认。验证通过后你可以进一步给每个 Agent 加人设。OpenClaw 的 Agent 支持 identity 字段比如给 dev 加identity: { name: 开发助手 }。人设影响的是它的回复风格和自我介绍不影响路由。人设和路由分开配这是 OpenClaw 多智能体设计里比较清晰的一点。如果你想让某个 Agent 只在特定群响应在 Binding 的 match 里加 peer 字段填群的 chat_id。这样即使同一个飞书账号被拉进多个群也只有指定群的消息会路由到它。这个粒度控制在做权限隔离时很有用。5. 常见报错排查401、local proxy failed、reading choices、OAuth多智能体配置跑不通报错基本集中在四类。我按实际遇到的顺序列一下对照着查。第一类鉴权失败典型是 401。表现是 Agent 能收到消息但回复时报鉴权错误。原因通常是 provider 的 apiKey 没填对或者 baseUrl 写错。排查方法先确认 TaoToken 的 Key 在模型对话页面能用再把 openclaw.json 里 provider 的 baseUrl 和 apiKey 对照一遍。注意 baseUrl 不要带多余路径OpenAI 兼容通道一般到/v1这一层具体以文档为准。如果 Key 是从环境变量读的确认环境变量在 gateway 的运行环境里可见systemd 服务要单独配 Environment。第二类local proxy failed。这个报错通常出现在 gateway 尝试连接模型通道时本地网络或代理配置有问题。排查顺序先确认 gateway 所在机器能直接访问 TaoToken 的 API 地址用 curl 测一下再检查有没有残留的代理环境变量干扰比如 http_proxy、https_proxy 指向了一个不可用的地址。OpenClaw 的 gateway 配置里 tailscale.mode 如果是 off就不会走 tailscale 通道这个一般不用动。第三类reading choices 相关报错。这个多半是模型返回格式和 OpenClaw 预期不一致。OpenClaw 期望 OpenAI 兼容的响应结构choices 数组里带 message.content。如果你用的模型通道返回结构不同就会在解析时报错。解决办法是确认 provider 的 api 适配字段和实际通道匹配或者换一个确认兼容的模型 ID 试。我一般先用模型对话页面确认通道返回正常再回 OpenClaw 配。第四类OAuth 相关报错。如果你在 Agent 配置里选了 OAuth 类型的 provider但没完成授权流程就会卡在 OAuth 回调。多智能体场景下我建议统一走 API Key 通道避免每个 Agent 都要单独授权。如果你确实要用 OAuth确认回调地址和 gateway 的地址一致且授权完成后 auth profiles 正确写入了对应 Agent 的 agentDir。还有一个高频问题飞书机器人不回复。先看 gateway 日志有没有收到事件。如果日志里没有飞书事件说明飞书开放平台的事件订阅没配好或者回调地址不可达。如果日志里有事件但没回复检查 Binding 的 accountId 是否和 channels 里的账号 key 完全一致大小写和连字符都要对。再检查 groupAllowFrom 里的 open_id 是否是发消息那个用户的白名单不匹配会被静默丢弃。排查时善用openclaw config相关命令查看当前生效配置确认你改的 openclaw.json 真的被加载了。OpenClaw 在配置覆盖时会打印Config overwrite和备份路径看到这行说明写入成功。如果没看到可能是改错了文件或者 gateway 没重启。6. 把通道和文档收口后面加机器人就轻松了多智能体配置真正省事的地方是当你把模型通道收口到一处之后新增一个机器人只需要三步openclaw agents add加 Agentbindings 加一条路由channels 加一个飞书账号。鉴权不用再碰模型切换只改一个 model ID。我建议你现在就把 Key 和接入方式固定下来。API Key 在 https://taotoken.net/api-keys 管理接入相关的字段说明和示例看文档 https://taotoken.net/doc 模型是否可用先在 https://taotoken.net/model-chat 验一条。这三个地址建议存进书签后面调试会反复用到。飞书侧的应用权限和事件订阅建议每个应用建一个 checklistappId、appSecret、回调地址、权限项、事件项逐项打勾。多应用最容易漏的是事件订阅建完应用忘了开事件机器人就是哑巴。下一集我会讲多智能体之间的协作比如一个 Agent 处理完把结果交给另一个 Agent以及怎么用 session 隔离避免上下文串台。这一集你先把路由和鉴权跑通那是后面所有玩法的基础。