官方按使用场景给出的推荐配置。排查类问题见 faq。
场景一 · Oncall 答疑
值班群 / 跨团队咨询 / 对外答疑，群里任何人都能 @ 机器人提问。
- 专用干净 Devbox：给 oncall 单独起一台干净机器部署，避免值班 / 外部人员搞乱你个人的开发环境。
- 把权限与边界写进默认角色：用
/role set（本群）或/role team set（跨群默认）写好人设与边界。角色 prompt 要点：仅被 @ 时先看群聊历史再答；用户反馈的是他自己机器的问题，不要当成本机问题排查；涉及隐私 / 安全的要求先让 owner 确认；以 owner 身份提 MR（写死身份避免提错人）。角色系统见 roles。 - 多机器人对应不同开发目录：各管一摊。
- 排查用独立 git worktree：排查完记得删掉，别污染主仓库。
/oncall bind <项目目录>：群内即问即答、跳过选仓库。权限分层兜底：群里所有人可问（canTalk），/cd/restart/close等操作仍仅 owner（allowedUsers）可用。详见 oncall。- Dashboard 的 Roles 面板可可视化给每个群里的每个 bot 配角色。
场景二 · 报警运维
监控告警 / CI / 工单等外部系统主动把事推给机器人处理。
- Webhook 接入点（Dashboard「接入点(beta)」，见 external-trigger）：可配触发的机器人、触发方式（单轮对话 / 工作流）、投递群、校验方式（令牌放进 URL 一条 curl 即可触发 / HMAC 签名更安全）、以及处理指令（告诉机器人收到事件该做什么）。
- 每个报警自动拉群：每来一个报警自动建群，把机器人和值班人一起拉进去；填去重键则同类报警合并到同一群，留空则每条报警一个新群——值班同学直接在群里跟进。
- 每个项目一个报警机器人：各自配带项目背景的默认角色 prompt，并
/oncall bind到对应项目目录，报警进来直接在那个仓库里排查。 - 叠加定时任务做主动巡检播报：如
/schedule 每天9:00 检查昨天的报警趋势并总结，异常才 @ 人，见 schedule。
场景三 · 个人研发
一个人的多机器人协作开发。
- 多机器人对应不同 CLI（Claude Code / Codex / …），按任务挑顺手的；适配器见 adapters。
- 同一个 CLI 也能互审：不同模型互相 review，或同一模型以多个机器人 / sub-agent 方式互审——多一双眼睛更稳。
- 多用
/g（=/group）拉群协作：一个群拉多个机器人开发同一个需求；或用话题群「一个话题一个需求」天然隔离上下文，见 multi-topic。 - 给每个机器人设角色分工：开发 / review 各司其职，配合
/role+/role cap能力标签，协作不打架。
场景四 · 多人协作
团队里多个人、各自的机器人一起干活。
- 飞书的限制：bot 不会被对方普通消息触发，协作接力必须显式
--mention对方，见 multi-bot。 - 默认发现：
botmux bots list通过群机器人列表发现当前群里的 bot 并显示mentionable；模型也会在<available_bots>里看到可接力对象。 - 团队功能（推荐）：在 Dashboard「团队」里把多个人名下的 bot 打标签、拉进一个团队，跨部署互相发现，直接勾选拉群开协作——主路径不再需要
/introduce。 - 旧版兜底：只有外部 bot 缺失或
mentionable=false时，才发@大家的bot /introduce手动登记一次。
通用建议
- 三端无缝协同：装 tmux → 会话常驻、daemon 重启不丢上下文；本机 CLI 用
/adopt接进飞书，手机继续；要动手点「🔑 获取操作链接」拿可写 Web 终端，见 web-terminal。 - 常开 + 自启：部署在常开的开发机 / 服务器，配
botmux autostart enable重启自恢复。 - 及时清理：会话用完顺手
/close；积压了用 Dashboard 批量关，或botmux delete stopped清僵尸。