TUIOS：知道你的 Agent 在干什么的终端窗口管理器

一、先从一个具体场景说起

假设你现在同时开着六个终端窗格：一个跑开发服务器，一个看日志，一个跑测试，还有三个分别挂着 Claude Code、Codex 和 Gemini CLI。每个 Agent 都在干活，看起来很热闹。

然后问题就来了。

哪个 Agent 在真正干活？哪个卡在权限审批上傻等？哪个已经跑完了你还没去看结果？哪个刚报了个错但错误信息已经被后续日志冲走了？tmux 一概不知——它勤勤恳恳管理着六个窗格，但对窗格里的进程是什么、处于什么状态，完全没有概念。你只能靠自己逐个窗格肉眼巡视，像车间主任巡视流水线。

这大概是当下终端复用器最尴尬的结构性缺陷：它们管理的是「窗格」，而不知道窗格里的进程会不会自己思考。

另一边，市面上管多 Agent 的工具倒是不少，可大多数做在浏览器里，是 Dashboard、是 Web 面板、是另一套需要切出去的界面。但开发者一天到晚泡在终端里，切出去看面板，再切回来敲键盘，注意力的损耗就在这一次次切换里。

tuios 想解决的就是这件事：把 Agent 的感知能力直接长进终端窗口管理器里。

二、这个项目是什么

TUIOS，全称 Terminal UI Operating System，是一个用 Go 编写的终端复用器加平铺式窗口管理器，构建在 Charm 全家桶（Bubble Tea v2 与 Lipgloss v2）之上，MIT 协议开源。官方 README 第一句话就把定位说得很直白：一个知道你的 Agent 在干什么的终端窗口管理器（a terminal window manager that knows what your agents are doing）。

它不是 tmux 的插件，也不要求你先装 tmux。如果你听过 tmux，可以把两者理解为同一类工具：都能在终端里管理多个会话和窗格。不同的是，TUIOS 把窗口平铺和导航做成了更直观的模态界面，同时把编码 Agent 的状态做成了窗口管理器的一等公民。

用一句话概括它的解决思路：当窗格里的进程会自己思考，窗口管理器就必须理解进程的意图。

三、核心功能拆解

3.1 Agent 状态：窗格标题栏上的四种形状

跑着 coding agent 的窗格，标题栏会显示它处于什么状态——工作中、等待你处理、已完成、还是出错了。侧边栏的 Session Rail 同样给每个 Agent 一行摘要，扫一眼就知道全局。

这个能力怎么来的？TUIOS 用了两条腿走路：

  • 集成上报：tuios integration install 为 19 种 Agent 线程（harness，包括 Claude Code、Codex、Gemini CLI、opencode 等）安装挂钩，让它们主动报告状态；
  • 进程探测：对没装集成的场景，TUIOS 通过进程信息和屏幕内容识别 24 种 Agent CLI，尽力推断状态。

双来源设计在我看来非常务实。状态上报这种事，等所有 Agent 厂商统一标准是不现实的；先用启发式兜底保住覆盖面，再让愿意配合的线程做到精确，这是一条合理的渐进路径。

TUIOS 界面总览：四个平铺窗格与侧边栏中的 Agent 状态

3.2 Inbox：把审批从「同步阻塞」变成「队列处理」

这是整个项目里我最喜欢的设计。

按 Prefix+i 打开收件箱，所有会话、所有机器上等待你处理的事项汇总成一个列表：审批请求、提问、报错、已完成的回合。按 Prefix+o 直接跳到最旧的一条。更关键的是，审批可以在收件箱里直接应答，不必切到对应窗格——配置 [agents.approvals] 之后，Claude Code、opencode、Kilo、Qwen Code 的权限请求可以一键批准。

这个交互模型改变的是人的工作方式：从「盯着 Agent」变成「批量处理待办」。当你并行运行五六个 Agent 时，这是注意力管理上的实质改进，不是锦上添花。过去每个审批都要打断你当前的心流，现在它们排队等你翻牌子。

TUIOS 收件箱：审批、提问与报错汇总在一个列表里

3.3 舰队模式：一个提示，多个 Agent 赛马

tuios fan 把同一条提示词分发到多个 Agent，允许混用不同线程，每个 Agent 各自跑在独立的 git worktree 里，天然互不踩脚。同一任务、多种实现路线同时开工，横向对比后再决定采纳哪个。

配套的还有寻址能力：像 group:fan/retry needs:you 这样的选择器，可以一次性给一整组 Agent 下指令。tuios start-agent 则可以在你旁边启动一个辅助 Agent，TUI 形态或无头形态（走 ACP 或 Codex app-server）都支持。

3.4 Agent 之间怎么说话

tuios ask-human 让 Agent 向人类提一个带固定选项的问题，直接进你的收件箱；tuios send-agent-message 和 tuios ask-agent 负责 Agent 之间互发消息、互相提问。

这里有个值得一提的细节：设计上避免了「往一个正在等待提示符的窗格里盲打字」这一经典事故，而且来自人类的回复会被标记为已验证。别小看这件事——把消息精确投递给等待中的会话，和往终端里瞎敲键盘，是自动化与破坏的区别。

3.5 权限与 MCP：默认最小化

Pane Grants 让你按窗格声明 Agent 可以通过 TUIOS 做什么：read、write、fan、respond、admin 五档，辅助 Agent 可以用 --grants 拿到比主 Agent 更少的权限。tuios mcp 则把同样的能力以 MCP 工具形式暴露给外部，默认只读，且限定在 Agent 自己的会话内。

一个愿意把权限默认关到最小的工具，比一个承诺「绝对安全」的工具更值得信任。

四、容易被忽略的设计取舍

4.1 tmux Shim：承认迁移成本是最大的敌人

TUIOS 提供了一个 tmux 垫片（tuios tmux-shim），让那些依赖 tmux 做编排的工具——README 点名了 Claude Code agent teams——能在 TUIOS 上运行，它们的 tmux 窗格被映射为 TUIOS 窗格。

为什么重要？因为 TUIOS 的配置体系是 TOML 而非 tmux.conf，键位习惯也需要重新建立。shim 解决的是「工具链兼容」，它不迁移你的肌肉记忆，但它把「试试看」的成本降到了接近于零。作者清楚：这类工具最大的敌人不是功能不够，是迁移太痛。

4.2 事件驱动渲染：空闲时 CPU 占用为零

TUIOS 没有固定频率的轮询 tick。PTY 读取 goroutine 通过缓冲 channel 通知 Bubble Tea 渲染，只有数据到达或交互发生时才重绘。官方 README 明确宣称空闲时 CPU 占用为零，另外风格缓存使用带序列变化检测的 LRU 缓存，可减少 40%–60% 的内存分配（这是官方数据）。

对长时间挂机的多 Agent 场景，这不是炫技指标——你挂了六个 Agent 过夜，风扇安静本身就是功能。

4.3 不止 Agent 会说话：OSC 7501 让任何程序上墙

通过 Program Status 协议（OSC 7501），任何程序都可以报告自己在干什么，比如 tuios status working --app build --progress 40。一次编译、一次部署脚本、甚至 brew，都能像 Agent 一样显示在侧边栏和收件箱里。

这意味着「状态上墙」不是 Agent 的特权，而是 TUIOS 的通用能力。你的构建进度条第一次拥有了和 Agent 平起平坐的曝光位。

4.4 会话真的活得下去

daemon 模式下会话存活于终端窗口之外，这不算新鲜。但 TUIOS 做了 Session Resurrection：daemon 重启甚至机器重启之后，会话的结构和工作目录会回来，收件箱还会主动询问是否恢复此前正在运行的每个 Agent 会话。再往上一层，tuios hosts add 通过 SSH 接入其他机器，tuios hosts tailnet 直接列出 Tailscale 网络里的机器；远程会话可以画在本地客户端里，Agent 也可以跑到别的机器上，收件箱条目回流本地，tuios worktree pull 把成果取回来。「本地开发 + 远程算力」这条工作流，覆盖是完整的。

五、安装与上手

# macOS / Linux 最省事
brew install tuios

# 或者官方安装脚本（Linux/macOS）
curl -fsSL https://raw.githubusercontent.com/Gaurav-Gosain/tuios/main/install.sh | bash

# 启动（默认挂到 daemon，会话存活于终端窗口之外）
tuios

Arch 用户可以用 yay -S tuios-bin，Nix 用户直接 nix run nixpkgs#tuios，Docker 有 docker run -it --rm ghcr.io/gaurav-gosain/tuios:latest。GitHub Releases 提供 Linux、macOS、Windows、FreeBSD 和 OpenBSD 的预编译包，tuios update 可以自更新。从源码构建需要 Go 1.26.6 或更新版本。

跑 Agent 之前先装集成：tuios integration install，然后给窗格里的 Agent 看 tuios --skill 输出的简短指南，它就知道怎么驱动 TUIOS 了。

几个救命键位：Ctrl+P 命令面板（记不住键位时的万能出口）；Prefix+i 收件箱；WM 模式下 n 新建窗格、z 缩放（默认占 95% 屏幕）；Prefix+[ 进入 vim 风格复制模式。前缀键默认是 Ctrl+B。

两个注意点：完整体验（图形协议等）依赖 Ghostty、Kitty、WezTerm 这类现代终端，要求真彩色；项目还挂在 0.x 版本号，API 和配置格式仍在变动，生产环境重度使用前建议先在次要场景试跑一两周。不想引入 daemon 的话，tuios --standalone 可以单次运行；不想装的话，tuios.dev/learn 有编译成 WebAssembly 的在线版，每个窗格里都配了练习 shell。

六、适合谁用

第一类，并行跑多个 coding Agent 的开发者。 这是核心受众，你的收益和并行 Agent 数量严格正相关——只跑一个 Agent 的话，这套东西的价值兑现不了一半。

第二类，被 tmux 折磨多年的终端老手。 你已经会 prefix 键和分屏，迁移的只是肌肉记忆；而 Agent 状态、收件箱、权限授予这些增量，是 tmux 无论如何配置都给不了的。

第三类，键盘流与 vim 原教旨主义者。 模态界面、命令面板、100 多个可配置键位、vim 风格滚动回滚（支持一万行 scrollback，/ 和 ? 搜索，y 复制）——这套交互是从你的直觉里长出来的。

第四类，「本地开发 + 远程算力」工作流的人。 SSH 与 Tailscale 多机管理、远程会话、跨机 Agent 编排，一条链路完整覆盖。

不适合的人也很明确：一个终端窗口一个 Agent 逐个照看的用户，用不上它；追求生产级稳定性的团队，等它出了 1.0 再说。

七、结尾：窗口管理器的新职责

历史上，终端复用器回答的问题是「怎么在一个屏幕里塞下更多会话」。窗口管理器回答的问题是「怎么安排窗口的位置和大小」。这两个问题都有一个共同前提：窗口里的东西是听话的进程，你让它干什么它干什么，不干就报错退出。

Agent 打破了这个前提。窗格里的东西会自己思考、自己决定下一步、自己卡在权限上等你。这时候，管理窗格和管理进程的旧范式就不够用了——你需要的是一个理解进程意图的窗口管理器。

TUIOS 是这个方向上目前完成度最高的尝试之一：不是给 tmux 加个状态脚本，而是把 Agent 可观测性、审批路由、跨机协同做进了窗口管理器的内核。即便你暂时不迁移，它的 Inbox 与 Pane Grants 设计，也值得任何在做多 Agent 编排工具的人认真研究一遍。

相关链接：