1. 飞书群里多个 Agent 各说各话问题到底出在哪如果你正在做 openclaw 多 agent 自主交互配置目标场景是飞书群内让多个 agent 自主协作那么大概率你已经踩过这个坑单个 agent 接飞书很顺一旦把项目、产品、技术、前端、后端、测试这些角色都塞进同一个群消息就开始乱飞——要么所有 agent 都抢着回要么只有 main 一个在回其他角色像没上线一样沉默。openclaw 的多 agent 能力本质上是「一个网关 多个独立 workspace 多条 channel 绑定」的组合。每个 agent 有自己的身份文件、模型、会话目录飞书侧则通过不同的机器人应用AppID/AppSecret把消息路由到对应 agent。配置没对齐时最常见的结果就是 binding 匹配不上消息全落到默认 agent 上。这篇给你一份可以直接复制的config.toml骨架覆盖 agent 角色定义、触发规则、飞书事件订阅字段以及一次群内消息触发验证多 agent 交互链路是否生效的完整流程。适合已经跑通单 agent、准备扩展到多角色协作的开发者。下面所有配置都基于 openclaw 的openclaw.json新版也支持config.toml写法字段名一致你可以按自己的目录结构调整。2. 前置准备TaoToken 接入与模型可用性确认多 agent 协作对模型的稳定性和并发要求比单 agent 高因为一次群内消息可能触发多个 agent 同时推理。我建议先把模型接入层统一好再动 agent 配置。TaoToken 在这里的角色是统一的模型接入入口你可以在控制台创建 API Key然后在 openclaw 的模型配置里指向它。具体操作先到 TaoToken 控制台 创建密钥拿到sk-开头的 token。然后在 openclaw 的 provider 配置里填入 base URL 和 key。openclaw 的模型列表可以用命令确认openclaw models list输出里会列出当前已配置的模型比如qwen/qwen3.5-plus、qwen/qwen3-coder-plus等。如果列表为空说明 provider 没配好先补上再继续。模型对话能力可以先在 模型对话页 快速验证一次确认 key 和模型都通再回到 openclaw 做多 agent 编排。注意多 agent 场景下每个 agent 都会独立发起请求建议先用一个模型跑通链路确认路由正确后再按角色分配不同模型比如 coder 类角色用 coder 模型管理类角色用通用模型。3. 可复制的 config.toml 骨架3.1 agent 角色定义段openclaw 的 agent 列表决定了有哪些角色存在。每个 agent 需要id、name、workspace、agentDir、model五个核心字段。下面这份骨架定义了 9 个角色你可以按项目规模删减[[agents.list]] id main name main workspace /root/.openclaw/workspace agentDir /root/.openclaw/agents/main/agent model qwen/qwen3.5-plus [[agents.list]] id project-expert name project-expert workspace /root/.openclaw/workspace-project-manager agentDir /root/.openclaw/agents/project-expert/agent model qwen/qwen3.5-plus [[agents.list]] id business-expert name business-expert workspace /root/.openclaw/workspace-business-manager agentDir /root/.openclaw/agents/business-expert/agent model qwen/qwen3.5-plus [[agents.list]] id product-expert name product-expert workspace /root/.openclaw/workspace-product-manager agentDir /root/.openclaw/agents/product-expert/agent model qwen/qwen3.5-plus [[agents.list]] id tech-expert name tech-expert workspace /root/.openclaw/workspace-tech-manager agentDir /root/.openclaw/agents/tech-expert/agent model qwen/qwen3.5-plus [[agents.list]] id ui-expert name ui-expert workspace /root/.openclaw/workspace-ui-manager agentDir /root/.openclaw/agents/ui-expert/agent model qwen/qwen3.5-plus [[agents.list]] id frontend-expert name frontend-expert workspace /root/.openclaw/workspace-frontend-manager agentDir /root/.openclaw/agents/frontend-expert/agent model qwen/qwen3.5-plus [[agents.list]] id backend-expert name backend-expert workspace /root/.openclaw/workspace-backend-manager agentDir /root/.openclaw/agents/backend-expert/agent model qwen/qwen3.5-plus [[agents.list]] id test-expert name test-expert workspace /root/.openclaw/workspace-test-manager agentDir /root/.openclaw/agents/test-expert/agent model qwen/qwen3.5-plus每个 workspace 目录下需要放身份文件openclaw 会读取这些文件来构建 agent 的人格和职责边界。最小集合是AGENTS.md团队列表和触发条件、IDENTITY.md角色身份、SOUL.md核心原则、TOOLS.md可用工具、USER.md服务对象画像。以 project-expert 为例AGENTS.md里要写清楚它属于哪个团队、团队里还有谁## Agents List 你属于一个 AI 助手团队团队成员包括 - 项目经理project-expert负责整个项目 - 业务经理business-expert负责业务需求 - 产品经理product-expert负责产品设计 - 技术经理tech-expert负责技术架构 - UI设计师ui-expert负责UI设计 - 前端开发frontend-expert负责前端设计 - 后端开发backend-expert负责后端设计 - 测试经理test-expert负责系统测试 # 触发条件 收到项目需求、排期询问、进度跟踪、风险识别相关指令时激活。这段团队列表很关键它让每个 agent 知道「队友」是谁后续自主交互时才能正确 到对应角色。3.2 飞书 channel 与事件订阅字段飞书侧的核心是channels.feishu段。多 agent 场景下每个 agent 对应一个飞书机器人应用用accounts子对象区分。下面是骨架[channels.feishu] enabled true connectionMode websocket domain feishu [channels.feishu.accounts.main] appId cli_xxxxxxxxxxxx appSecret xxxxxxxxxxxxxxxxxxxxxxxx requireMention true groupPolicy open [channels.feishu.accounts.feishu-project] appId cli_xxxxxxxxxxxx appSecret xxxxxxxxxxxxxxxxxxxxxxxx requireMention true groupPolicy open [channels.feishu.accounts.feishu-business] appId cli_xxxxxxxxxxxx appSecret xxxxxxxxxxxxxxxxxxxxxxxx requireMention true groupPolicy openrequireMention true表示群里必须 机器人才响应这是多 agent 群避免刷屏的关键。groupPolicy open允许机器人被拉进任意群如果你要限制改成allowlist并配groupAllowFrom。飞书开放平台侧每个机器人应用需要订阅的事件字段包括im.message.receive_v1接收消息、im.message.reaction.created_v1表情回复可选、im.chat.member.bot.added_v1机器人被拉群。权限方面至少开im:message、im:message.group_at_msg、im:chat。这些在飞书开发者后台「事件订阅」和「权限管理」里勾选保存后需要发布版本才生效。3.3 binding 路由规则binding 决定「哪条飞书消息交给哪个 agent」。骨架如下[[bindings]] agentId main match { channel feishu, accountId default } [[bindings]] agentId project-expert match { channel feishu-project, accountId project } [[bindings]] agentId business-expert match { channel feishu-business, accountId business } [[bindings]] agentId product-expert match { channel feishu-product, accountId product } [[bindings]] agentId tech-expert match { channel feishu-tech, accountId tech } [[bindings]] agentId ui-expert match { channel feishu-ui, accountId ui } [[bindings]] agentId frontend-expert match { channel feishu-frontend, accountId frontend } [[bindings]] agentId backend-expert match { channel feishu-backend, accountId backend } [[bindings]] agentId test-expert match { channel feishu-test, accountId test }这里有个容易踩的坑match.channel的值要和accounts里的 key 对应。比如feishu-project这个 account 对应channel feishu-project而不是feishu。如果写错消息会全部落到 main 上其他 agent 永远收不到。4. 验证请求一次群内消息触发多 agent 链路配置写完后先重启网关让配置生效openclaw gateway restart openclaw agents listagents list应该列出所有 agent每个都有独立的 workspace 和 agentDir。如果某个 agent 没出现检查config.toml里[[agents.list]]的语法是否正确。然后逐个配对飞书机器人。每个机器人在群里发一条消息openclaw 会生成一个配对码用命令批准openclaw pairing approve feishu NNB7CAK5批准后在飞书项目群里 项目机器人发一条测试消息比如「帮我拆解一个登录功能的需求」。同时开一个终端跟踪日志openclaw logs --follow日志里应该能看到类似这样的输出feishu[feishu-project]: received message from ou_xxxx in oc_xxxx (group) feishu[feishu-project]: routing to agent project-expert如果看到group not in groupAllowFrom (groupPolicyallowlist)说明群策略是白名单但群 ID 没加进去要么改groupPolicy open要么把群 ID 加到groupAllowFrom。验证多 agent 自主交互的关键一步在群里 项目机器人让它「把需求同步给产品和技术」。如果 project-expert 的AGENTS.md里定义了团队列表它应该会尝试 其他角色或生成协作指令。此时观察日志里是否有多个 agent 被触发。如果只有 project-expert 响应其他 agent 没动静检查两点一是其他机器人的 binding 是否匹配二是群内是否 了对应机器人requireMention true时必须 。5. 本篇常见错排查错误一所有消息都落到 main。最常见原因是 binding 的match.channel写成了feishu而不是具体的 account key。检查accounts下的 key 名和 binding 里的channel值是否一一对应。错误二agent 列表为空或缺少角色。config.toml里[[agents.list]]是数组表语法每个角色一个块。如果写成[agents.list]单表只会保留最后一个。用openclaw agents list确认数量。错误三飞书机器人不响应。先确认connectionMode websocket且飞书后台已开启长连接模式。再确认事件订阅里勾了im.message.receive_v1。最后确认requireMention和群内 行为一致。错误四配对码批准后仍无响应。检查appId和appSecret是否和飞书后台一致尤其是多应用场景下容易复制错。可以用openclaw channels status --probe看实时健康状态。错误五多 agent 同时回复造成刷屏。这是requireMention没开或groupPolicy太宽松。建议所有非 main 的 agent 都设requireMention truemain 可以设false作为兜底。如果你在接入过程中遇到 API Key 或模型调用报错可以到 TaoToken 接入文档 对照排查需要新建或轮换密钥时直接在 API Keys 页面 操作。6. 长期编码与 Agent 协作的下一步多 agent 跑通后下一步通常是让它承担更长期的编码任务比如让 frontend-expert 和 backend-expert 持续协作一个模块。这种场景对模型的上下文长度和调用稳定性要求更高建议用 Coding Plan 来统一管理长期编码会话的模型配额避免单个 agent 把额度吃满导致其他角色排队。配置层面你可以给每个 agent 的AGENTS.md加上更细的触发规则比如「收到包含『接口』关键词的消息时先输出接口草案再 backend-expert 确认」。这样多 agent 的自主交互就从「被动响应」变成「主动编排」飞书群里的协作链路才算真正跑起来。