boo：基于 libghostty 的终端复用器，让 AI Agent 也能「看懂」屏幕

你有没有遇到过这种情况：AI Agent 帮你跑一个构建命令，结果它只能看到命令的原始输出流，却不知道屏幕上的光标在哪、哪个区域是错误信息、TUI 界面显示了什么？

这就是终端复用器的盲区。GNU screen 和 tmux 都是几十年前的设计，它们的终端仿真器跟不上现代程序的输出，更别提让脚本或 Agent 精确读取屏幕状态了。

boo 是 Coder 公司上周刚开源的终端复用器，用 Zig 写的，核心用了 Ghostty 的终端仿真库 libghostty-vt。它的核心卖点不是「比 tmux 多几个快捷键」，而是每个会话的屏幕状态都是精确的——内容、样式、光标位置、滚动区域、终端模式，全部由 libghostty 维护。你 detach 之后再 attach，看到的画面和你离开时一模一样，不会丢字符、不会错位。

更关键的是，boo 提供了 send、peek、wait 三个原生命令，让脚本和 AI Agent 可以在没有 TTY 的情况下操控终端、读取屏幕、等待输出稳定。这不是 hack，是设计目标。

一、为什么需要一个新的终端复用器

终端复用器的核心工作很简单：在后台运行程序，断开连接后重新接回来，屏幕内容不丢。

GNU screen 做这件事做了 30 多年，但它的终端仿真器太老了。现代程序（Neovim、htop、btop、各种 TUI 框架）会发出大量 VT 序列——256 色、真彩色、鼠标追踪、Unicode 宽字符、图形协议。screen 的仿真器不认识这些序列，要么忽略、要么乱码。你 detach 再 attach，看到的画面可能和离开时不一样。

tmux 比 screen 好得多，但它解决的是另一个问题：窗口分割和标签页。tmux 的架构是「一个服务端管多个窗口，每个窗口可以分成多个面板」，这很灵活，但也更复杂。对于「一个任务一个会话，后台跑着就行」的场景，tmux 的概念模型有点重。

boo 走的是 screen 的路线：一个任务一个会话，简单直接。但它把 screen 最弱的一环——终端仿真器——换成了 libghostty-vt，这是 Ghostty 终端的仿真核心。Ghostty 是目前最现代的终端仿真器之一，对 VT 序列的支持非常完整。

boo 继承了这个能力，所以它的屏幕状态精度是像素级的。

二、架构：Client-Daemon 模型

boo 的架构很清晰：

Client 负责把你终端的 TTY 放进 raw mode，然后通过 Unix socket 把字节流转发给 daemon。它处理 Ctrl-A 前缀键，但不做任何终端仿真——那是 daemon 的事。

Session Daemon 是每个会话独立的进程，它持有：

• 一个 PTY，上面跑着你的子进程（bash、make、python，随便什么）
• 一个 ghostty-vt 的 TerminalStream，解析子进程的所有输出

当你 attach 的时候，daemon 把 PTY 输出原样转发给你的终端，同时 ghostty-vt 在后台维护着完整的屏幕状态。当你 detach 的时候，daemon 继续接收子进程的输出，ghostty-vt 继续更新状态。你重新 attach 时，daemon 用 ghostty-vt 的 TerminalFormatter 从状态重建屏幕，而不是回放原始字节流。

这意味着：

• Detach 不丢内容：状态是精确的，不是「尽量还原」
• 终端查询在 detach 时也能响应：DSR、DA、XTWINOPS 这些查询，daemon 会用 ghostty-vt 的状态回答，不会让 TUI 程序卡住
• Attach 时不会双重回复：当你在线时，查询由真实终端回答；detach 时由 daemon 回答

三、Agent 友好：send、peek、wait

这是 boo 最有意思的部分。传统的终端复用器自动化靠的是 -X stuff（screen）或 send-keys（tmux），配合 capture-pane 或 hardcopy 读取屏幕。这些命令是为人设计的，不是为脚本设计的——输出格式不稳定，需要 sleep-and-poll 来等输出稳定，读取的屏幕内容可能和实际显示不一致。

boo 提供了三个原生命令，所有命令（除了 attach）都可以在没有 TTY 的环境下运行：

send：发送输入

1

boo send build --text 'make' --enter

--text 是字面量，不做转义处理，不自动加换行。--enter 提交。--key Enter,C-c,Up 可以发送控制键。stdin 模式是二进制安全的。

peek：读取屏幕

1
2

boo peek build --scrollback
boo peek build --json

peek 输出的是从 ghostty-vt 状态重建的屏幕内容，不是原始字节日志。--scrollback 包含历史，--json 额外输出尺寸、光标位置和窗口标题。

对于 AI Agent 来说，--json 输出意味着它可以用结构化数据理解屏幕：哪些行是新的、光标在哪里、窗口标题是什么。不需要用正则从文本里猜。

wait：等待条件

1
2
3

boo wait build --idle          # 输出静默 2 秒后返回
boo wait build --text "Done"   # 屏幕包含指定文本后返回
boo wait build --idle --timeout 30s  # 最多等 30 秒

这是最 Agent 友好的命令。不用再写 sleep 2 && boo peek ... 的轮询循环了。wait --idle 在输出静默后返回，--text 在屏幕包含指定文本后返回。超时返回 exit code 4。

完整的 Agent 循环

1
2
3
4
5

boo new build -d -- bash               # 创建无头会话
boo send build --text 'make -j8' --enter  # 发送命令
boo wait build --idle --timeout 5m      # 等构建完成
boo peek build --json --scrollback      # 读取结果
boo kill build                          # 清理

这个循环完全不需要 TTY，可以在 CI、脚本、AI Agent 中直接使用。ls --json 和 peek --json 的输出是机器可读的，exit code 语义明确（0 成功、1 错误、2 用法错误、3 会话不存在、4 等待超时）。

四、boo ui：全屏会话管理器

除了命令行操作，boo 还有一个全屏的会话管理界面：

1

boo ui

左侧是会话列表，右侧是选中会话的屏幕预览。可以用快捷键切换、调整大小、隐藏侧栏、创建和终止会话。

对于人类用户来说，这比 boo ls + boo attach 的组合更直观。对于 Agent 来说，boo ls --json 就够了。

五、和 GNU screen、tmux 的对比

boo 和 screen 的哲学最接近：一个任务一个会话，Ctrl-A 前缀键，简单直接。但 screen 的终端仿真器太老了，现代 TUI 程序在 screen 里经常出问题。boo 用 libghostty-vt 替换了这个层，解决了 screen 最大的痛点。

tmux 的优势在于窗口分割和标签页，这是 boo 没有的功能。boo 的设计是「一个会话跑一个任务，用 boo ui 管理多个会话」。如果你需要在一个终端里同时看多个面板，tmux 仍然是更好的选择。

boo 真正的差异化在于 Agent 友好性。send、peek --json、wait --text/--idle 这些命令是为自动化设计的，不是为人设计的。屏幕状态是精确的，输出是结构化的，等待是声明式的。这对 AI Agent 来说是刚需——Agent 需要精确地知道屏幕上显示了什么，而不是从原始字节流里猜。

六、安装和使用

目前 boo 只支持 Linux 和 macOS：

1
2
3
4
5

# 一键安装
curl -fsSL https://raw.githubusercontent.com/coder/boo/main/install.sh | sh

# 或者从 GitHub Releases 下载预编译二进制
# https://github.com/coder/boo/releases

基本操作：

1
2
3
4
5
6
7
8

boo new                    # 创建新会话（以当前目录命名）
boo new work               # 创建命名会话
boo new work -d -- make    # 创建后台会话，运行 make
boo ls                     # 列出会话
boo attach work            # 重新连接
boo rename work api        # 重命名
boo kill work              # 终止会话
boo kill --all             # 终止所有会话

快捷键（前缀 Ctrl-A，和 GNU screen 一致）：

构建需要 Zig 0.15.2：

1
2
3
4

git clone https://github.com/coder/boo.git
cd boo
zig build                       # 编译
zig build test-all              # 运行所有测试

七、局限性

boo 是一个年轻的项目（3 天），有一些明确的限制：

• 每个会话只能有一个 attach：不支持 -x 共享，attach 会「偷走」连接
• 每个会话只有一个窗口：没有分割或标签页，一个任务一个会话
• Ctrl-A 前缀不可配置：粘贴包含 0x01 的字节会被解释为前缀（boo ui 不受影响，因为用了 bracketed paste）
• TERM=xterm-256color：所有会话都用这个 TERM 值
• 只支持 Linux 和 macOS：Windows 不支持

这些限制大部分是设计选择，不是 bug。boo 的定位不是「tmux 的替代品」，而是「screen 的现代化版本，加了 Agent 友好的自动化接口」。

八、为什么 Coder 要做这个

Coder 是做云端开发环境的公司，他们的核心产品是让你在浏览器里连接到远程开发机。终端复用器是这个场景的基础设施——你需要在远程机器上跑程序，断开浏览器后程序继续运行，重新打开时看到完整的屏幕状态。

但现有的终端复用器对自动化不够友好。Coder 的产品需要精确地读取终端状态、程序化地发送输入、可靠地等待输出稳定。这些需求在 screen 和 tmux 里都需要 hack，boo 把它们做成了原生功能。

同时，libghostty-vt 的终端仿真精度意味着 Coder 可以在浏览器里精确地重建远程终端的画面，不会出现 screen 那种「detach 再 attach 画面变了」的问题。

九、写在后面

boo 不是要取代 tmux。如果你需要窗口分割、标签页、复杂的布局管理，tmux 仍然是最好的选择。但如果你的需求是「一个任务一个会话，后台跑着，能精确读取屏幕状态，能被脚本和 Agent 控制」，boo 值得试一试。

它的 Agent 友好性设计尤其值得关注。随着 AI Agent 越来越多地参与开发工作流，「Agent 能精确地读写终端屏幕」会成为一个基础需求。boo 的 send、peek --json、wait 三件套，可能就是这个方向上目前最好的实现。

相关链接：

• boo GitHub 仓库
• Ghostty 终端
• libghostty
• Coder 官网
• boo Releases 下载