botmux：把飞书变成 AI 编程 CLI 的遥控器，每个会话一个独立进程

它解决什么问题：CLI 在开发机，人在手机上

AI 编程 CLI 通常跑在开发机上，你人在会议室或者地铁上，看不到输出，也没法打断。botmux 的定位就是把这个缺口补上。它不重造 Agent 能力，而是桥接你已经在用的工具。README 里列了 20 多个适配器，包括 claude-code、codex、gemini、opencode、cursor 等。核心场景是：把机器人拉进群，@ 一句就在你本机的代码库里开跑，每轮输出推成飞书卡片，手机、电脑、终端三端同步。它还支持把会话用 /relay 原样搬到另一个群，上下文不丢。这个设计对 oncall 群特别有用，任何成员 @ 机器人就能在项目目录里排查问题。

机制：每个会话一个独立 CLI 进程，实时流式回传

botmux 是一个 daemon，监听飞书消息。每来一条新会话消息，它就 spawn 一个独立的会话进程，这个进程跑的是你配置的 AI 编程 CLI。输出通过 PTY 捕获，实时流式回传成飞书卡片。卡片不是静态的，而是每轮对话一张实时刷新的卡片，终端画面可以原样截图回传。你可以在卡片上一键显示/隐藏输出、翻屏、重启、关闭或接管会话。它还提供一个可交互的 Web 终端，浏览器或手机可以直接操作 CLI，移动端带悬浮快捷键栏，比如 Esc、Ctrl+C、方向键。这意味着你不只是看输出，还能真正干预 CLI 的运行。

多机器人协作与多话题编排：让不同模型互怼

单个 Agent 不够用时，botmux 支持在同一个群里放多个不同 CLI 的机器人。通过 @mention 路由，@ 谁谁干活。比如让 Claude Code 和 Codex 一起 review 同一个 MR，各自独立分析，观点不同自动互怼。这种设计利用不同模型背后的多样性，适合方案评审、代码 review、技术选型。更进一步，它支持多话题并行编排：给编排者一个大任务，它自动在群里种话题，拉各 bot 起独立会话跑流水线，飞书任务面板可以一眼看完所有子任务进度。这个机制把飞书的话题功能当成了任务队列，思路很直接。

安装与配置：一条命令扫码建应用，但 Windows 只能 WSL2

安装很简单，npm 全局装或者直接下自包含二进制。npm 包内带了对应平台的自包含二进制，按 os/arch 只装匹配的那一个，安装时会把 ~/.botmux/bin/botmux 指向它。这样不会出现两个 Node 版本各带一份 botmux 互相打架的问题。安装过程不编译任何原生模块，不需要 Python、node-gyp 或编译器。支持 linux 和 macOS 的 x64/arm64，Windows 请在 WSL2 里安装，因为 daemon 依赖 PTY、tmux 和 Unix 信号，原生 Windows 跑不了。配置方面，核心是 bots.json 文件，里面放非敏感元数据和密钥文件路径。比如 ebsd 适配器要求三个密钥文件必须是 0600 权限的普通文件，不能是符号链接，内容不能写进 bots.json。还有会话级 CLI 选择，用 /cli <cliId> 可以在会话启动前切换 CLI，但只切换裸适配器，不继承 wrapperCli、model 或 startupCommands。

高级功能：会话接管、定时任务、Webhook 与反馈机制

除了基本桥接，botmux 提供几个实用功能。会话接入与接力：本地 tmux 里跑到一半，手机用 /adopt 接管，或者用 /relay 把整个会话搬进团队群。定时任务：用自然语言配置周期任务，比如报警分析或群总结。外部触发：通过 Webhook 或 API 任务触发，可以从其他系统编程式启动会话。Oncall 模式：拉进 oncall 群，任何成员 @ 即在项目目录排查。语音总结：配好 TTS 后，每张卡片页脚会多一个语音总结按钮，让模型说人话。最终回答反馈：在 bots.json 条目里设置 feedback.enabled 为 true，可以在最终回答卡片上收集 positive、progress、negative 三态反馈，数据落在本机 botmux-feedback.sqlite，可选 webhook 投递 turn.completed 和 feedback.revised 事件。反馈策略支持本地团队、bot、bot-scoped chat 分层，优先级是 chat > bot > team。

限制与失败模式：飞书依赖、Windows 不支持、密钥管理复杂

botmux 的依赖链很明确：它依赖飞书开放平台，需要扫码建应用、配权限、发版。虽然 setup 命令可以自动完成这些，但如果你用 --no-open-platform-auto，就得手动配置权限和发版，这一步容易出错。Windows 原生不支持，只能 WSL2，这对 Windows 用户是个硬门槛。另外，某些适配器如 ebsd 的配置很繁琐，需要外部服务身份、Diag Gateway token、ByteCloud service account，密钥文件必须是 0600 权限，不能是符号链接，部署方必须严格遵守。如果隔离建立失败，Linux 上开启 sandbox 前需要安装 bubblewrap，否则会拒绝启动。这些约束意味着 botmux 不是开箱即用的玩具，而是需要一定运维能力的工具。

替代方案对比：tmux 直连 vs Web 终端 vs 其他桥接工具

如果你不需要飞书，只是想远程操作 CLI，最简单的替代是直接在终端里用 tmux attach 连到开发机的会话，这也是 botmux 自己支持的底层机制。但 tmux 没有移动端推送，没有卡片式交互。另一个替代是直接用 AI CLI 厂商自带的 Web 界面，比如 Claude Code 的 Web 版或 Codex 的云端 IDE，但这些通常只能操作云端环境，不能桥接你本机的代码库。更接近的替代是像 SSH 加一个 Web 终端工具，比如 ttyd，它能把任意命令行程序暴露成 Web 页面，支持浏览器操作，但没有飞书卡片流式回传，也没有多机器人协作。botmux 的差异在于它把飞书当成了控制面，把 CLI 会话当成可搬运的实体，这种设计在团队协作场景里更自然。

维护与升级成本：自包含二进制，但需关注飞书 API 变化

botmux 的发布频率看起来很高，最近一次是 v3.18.6，几天内连续发了几个小版本，说明项目在快速迭代。安装方式保证了只有一个版本，升级就是重新安装 npm 包或重新拉取二进制。由于不编译原生模块，升级不会遇到编译问题。但维护成本主要在飞书侧：飞书开放平台的 API 和权限配置可能变化，botmux 的 setup 自动化可能需要跟着调整。另外，适配器列表依赖各个 CLI 的启动方式和输出格式，如果某个 CLI 更新了交互协议，botmux 的适配器可能需要更新。采用前建议先看 registry.ts 确认你用的 CLI 是否在列表里，以及文档里关于 wrapper 和网关的说明。许可证是 MIT，商用和修改都自由，但要注意不要把你自己的密钥写进 bots.json 或提交到公开仓库。

编辑结论

botmux 适合那些已经重度使用 AI 编程 CLI、并且团队日常在飞书里协作的开发者。它解决了 CLI 跑在开发机上、人不在旁边的核心痛点，尤其是 oncall 群和移动端操作场景。不适合 Windows 原生用户，也不适合不想引入飞书依赖、只想要一个纯 Web 终端的个人用户。采用前先确认：你的飞书应用能完成扫码授权和发版，你的 Linux/macOS 机器能跑 PTY 和 tmux，以及你要桥接的 CLI 是否在 registry.ts 的适配器列表里。对于 ebsd 这类需要外部服务身份和密钥文件的适配器，务必按文档配置受限权限的密钥文件，不能把密钥写进 bots.json。

官方来源

1. Official documentation
2. Official README
3. Project repository
4. Release notes