同一台机器可运行多个飞书机器人，每个机器人绑定不同的 CLI（如 Claude Code、Codex）。把它们拉进同一个群，即可让不同模型围绕同一任务协作甚至互相”斗蛐蛐”。配置极简：每个机器人对应一个飞书应用，进程完全隔离。
消息路由规则
- 单人群 + 单 bot：无需 @，bot 自动响应。默认 @ 策略下必须严格满足「1 个人 + 1 个 bot」；多人群即便只有一个 bot 也必须 @。
- 多 bot / 多人群：用
@mention指定接收方，只有被 @ 的 bot 会处理消息。 @botA @botB /t <prompt>：每个被 @ 的 bot 各自在这条消息上开一条独立会话。所有 bot 都以这条/t消息为线程锚点、共用同一线程，但会话彼此独立、各跑各的——适合同题对比。
路由分发机制的源码视角见 im-routing。
bot 互相发现
主路径不再需要手动 /introduce：botmux 默认通过飞书群机器人列表自动发现当前群里的 bot。
跨部署互相识别有两条路径，且都进入同一道团队信任闸、免 /grant：
- Dashboard「团队」面板的联邦——把别人的部署拉进同一团队、跨部署拉群；
- 中心平台的 team-sync——由平台下发团队与群。
注意：普通 /group、Dashboard「新建群」建的是本部署内的普通群，不走这两条路径，不带跨部署团队信任。
协作时模型侧有两个信息来源：
botmux bots list：列出当前群可协作的 bot、能力标签、openId、mentionable；- 消息上下文中的
<available_bots>块：提示哪些 bot 可被接力。
触发对方 bot：必须 —mention
bot 在自己会话里用 botmux send --mention <对方 openId> 显式 @ 对方，才能触发对方接力。
硬性事实：不
--mention对方 bot，对方完全不会被触发。
/introduce 仅保留为旧版 / 外部 bot 的兜底：只有当 botmux bots list 里目标 bot 缺失或 mentionable=false 时，才在群里发 @botA @botB /introduce 手动登记一次。
典型场景：多 bot 评审 / 互怼
- 代码 review：Claude Code 与 Codex 一起看同一个 MR，观点不同时互相挑刺；
- 方案评审：两个 AI 分别出方案，互相找漏洞；
- 写审分离：一个写、一个审，迭代收敛。
进阶玩法：用 multi-topic 让主 bot 拆任务、开多话题并行推进；用 roles 给每个 bot 设人设与能力标签（谁写、谁审）；需要把会话搬到协作群时用 session-handoff。