tmux 從通用狀態列、分屏、遠端
到多 agent 分工
2026 年 2 月被 openclaw 啟發開始用 tmux，從狀態列、分屏、遠端開發一路堆疊到多 agent 分工。
先把狀態列搞好
第一件補的東西是狀態列，把手上一堆 AI agent CLI 的狀態收進同一條 bar。2026 年 2 月被 openclaw 啟發開始用 tmux，這是落地的第一步。
開始用 tmux 那陣子我已經同時在用固定班底加偶爾換來試的好幾個 CLI，多開幾個 terminal 視窗就一團亂；跟著 YouTube 上 《tmux 使用和基礎配置 從入門到加班 一個視頻全搞定！》 敲熟指令後，先動手的是 Claude Code 的 statusline。
~/.claude/settings.json 設 statusLine.command 指向自己寫的 statusline.sh：
statusline.sh 裡做的事很雜——抓 session ID、cwd、git branch + 改過的檔案數、model display name、session cost、context 佔比，全部用一支 jq 一次抽完（避免每秒 fork 15 次的 overhead）：
寫熟以後我想看更多東西——Claude / Codex / Gemini 各自的 5 小時、7 天額度，還有 CPU、MEM、DISK、NET。但 Claude Code statusline 只看得到當前 session，跨 session 的累積額度看不到。我把這層拉出來放進 tmux 的狀態列。
~/.tmux.conf 寫了一條長 status-format[1]，逐欄叫一支自己寫的 tmux_status.sh 拉資料、配 catppuccin 配色：
status-interval 5 每 5 秒刷一次。最早這支 script 我用 Python 寫，每 5 秒 fork 一個 interpreter、13 欄就 13 個 process。tmux server 崩過一次之後改成 shell + jq，省掉 interpreter 的 startup overhead。
到這裡 tmux 對我還只是「漂亮的狀態列容器」。接下來才開始用它的本業——分屏。
三種反覆用的 pane 佈局
三種 pane 佈局反覆在用，最兇的是垂直四欄均分寬度。基本指令學完之後就收斂成這幾種。
1. 垂直四欄均分寬度
4 個 AI agent CLI 真的同時在跑：每欄一個獨立對話，dispatch 一個 task 出去，掃過去四欄就知道誰跑完、誰還在 thinking、誰要回覆。寬度均分，眼睛從左掃到右一秒就完成，不用記哪個在哪。
2. 中心十字四分法
螢幕大的時候用——四象限各放一個固定角色。我目前的擺法是左上主對話、右上 code 或檔案樹預覽、左下對比資訊（CLI 能力表、provider/model 規格），右下放輔助 CLI（qwen 或其他）。
跟垂直四欄相比，多了「縱向」的資訊密度——有些 pane 適合長條（log），有些適合方塊（表格、code）。十字佈局兩種都吃得下。
3. 主 + 副的 sub-agent 佈局
左邊一個大 pane 跑 main agent（多數時間是 Claude Code），右邊水平切 4 個小 pane 跑 sub-agent 或子 task。main 派任務出去，右邊那幾個 pane 平行跑、平行看得到狀態，跑完往左邊回報。
這個佈局是後面那套中繼系統的雛形——只是把「我手動 dispatch」換成「skill 自動 dispatch」。
連線一斷就重來，太蠢了
沒裝 tmux 時，ssh 進開發機跑長 build，一斷線就從頭來；改成 tmux 之後，這個流程就沒再斷過：
那一瞬間我意識到：tmux 不是分屏工具，是 process 的容器。
之後遠端 session 全部走 tmux：每個 host 一個 default session、ssh 進去先 tmux a || tmux new -s default、永不直接在裸 shell 跑東西。
加上 tmux-resurrect + tmux-continuum 兩個 plugin，每 15 分鐘自動 snapshot 整套 layout。重開機後 tmux 起來自動 restore。~/.tmux.conf 裡只要兩行：
家裡那台 mac mini 重開機，回來 session 還在原來的位置。
Mac mini 在家、MacBook 在外、iPhone 在路上
tmux-resurrect + tmux-continuum 穩定之後，家裡的 mac mini 24/7 開機，變成主力開發機。
永遠有 tmux 跑著我的 default session，雲端硬碟同步檔案的需求也跟著降了——反正源碼都在那台。帶 MacBook 出門 → ssh 回家 → tmux a → 接續上午沒寫完的 prompt；通勤路上想到一個 idea，不用筆記，直接打進去那個 session。
「直接打進去那個 session」在筆電上很順，換成手機就卡關。
我習慣用垂直四欄均分的佈局看 4 個 agent。手機 ssh 過去寬度根本擺不下，要看任何一欄都得 prefix + z zoom in 把它撐滿，看完還得 zoom out 切下一個。每跟一個 agent 互動就多兩道工序，做點事就累了。
做了個 tmux-webui
手機連 tmux 這件事，我先動手試了三個現成方案，都不夠用：
Blink Shell（自編譯）
App Store 版要錢，GitHub 有開源版可以自編譯。完全沒碰過 iOS 開發，整個 sideload 流程交給 Claude Code 輔助。free developer account 每 7 天要重簽一次。
三個都卡關之後，轉頭做的是 tmux-webui——把 tmux pane 直接搬進瀏覽器，跳過所有 ssh client、mosh 的折騰。這個想法早於 Claude Code 自己出 remote 模式；後來 remote 出來，我還是用 tmux 居多。
選 web 不做 native iOS app 的原因很現實：不用碰 Xcode、不用 TestFlight、不用每年 99 美金。任何一台有瀏覽器的裝置都能用。代價是 auth 跟流量加密要自己處理，這層丟給 Cloudflare Tunnel。
它做的事就幾樣：列出所有 sessions / windows / panes、點哪個 pane 看哪個 pane 的即時輸出、觸控手勢左右滑切、雙指縮放、PWA 裝主畫面當 app 用。觸控的部分是從 Blink Shell 學來的——前面用過一個多月，知道哪些 gesture 真的天天會用、哪些是 demo 用。打字端配了個 skill 補全 palette，掃過去就知道有什麼可以叫。
意外最好用的反而是上傳圖片。手機拍照或截圖後拖進 webui，後端存進 uploads/ 回傳一個本機路徑，我把路徑貼進當下那個 agent pane，agent 直接 Read 就讀得到。通勤路上看到有趣的設計、有 bug 的截圖、白板上的草圖，當下丟給 agent 接著問，不用等回家。
回頭做 multi-agent，這次用 tmux pane 當 cell
會做 multi-agent 是五個理由撐住的決定，最大那個是主 context 不能被雜務塞滿。
主 context 不被壓縮
派給其他 agent 處理的細節（搜資料、跑 test、寫 boilerplate），不會把 main 的 context 塞滿；留下來的空間給真正需要主腦推理的部分。
並行加速（搭 git worktree）
同一個 task 能拆成可平行的子任務（多分支試錯、N 個 PR 同時走），每個 pane 配一個 git worktree，工作目錄互不干擾。把原本單線的時間軸壓平。
理由清楚之後，再盤點現有方案的限制，由淺到深三個。
Headless 模式
claude -p、codex -p 之類。跑得快、好寫腳本，但能力打折——skill 不會載入、MCP 不會接、自己寫的 agent 也拿不到。每次呼叫從零起，沒有連續對話脈絡。獨立 task OK，有狀態協作不夠。
我要的是「跨 CLI 全裝模式的 multi-agent」——同一場 task 看哪個 CLI 擅長哪塊就分給誰，每個都用自己的 skill / MCP，彼此能互通。三個現有方案都辦不到，所以選 tmux pane 當底，自己疊一套。我把這套東西叫做 tmux-relay，後面段落講的「中繼系統」都是它。
做法分三層
最底是一個工作 window，pane 不常駐——主 agent 看 task 適合哪款 CLI（強項是社群評價加我自己用下來的偏好），才開 pane 把那款 CLI 啟動起來。用完保留待用，閒置太久就回收。
挑 idle 的判斷是看 pane 畫面當下狀態——agent 在等輸入還是在跑，從輸出內容辨識。不維護 lock、不留歷史，每次重看。
idle 判斷這層目前只在 Claude Code pane 上驗證過。prompt 跟處理中提示的字樣是 CLI-specific 的，要支援其他 CLI 得各自寫一份判斷規則。
完成通知不靠 polling，走 tmux 自己的 hook 機制——pane 結束時把 block 著的 dispatcher 叫醒。
這套還缺 team agent 的最後一塊：pane 跟 pane 之間沒辦法直接互相叫。我另外做了個 publish/subscribe 的小服務 session-channel 補這層，pane 之間靠 channel 互通，不必走中間人。
tmux 變成跨 CLI agent 的橋樑
send-keys + capture-panewait-for + Stop hooktmux a 任何裝置都接得上trade-off 必須講清楚
send-keys是純文字，沒 typed schema——用 stdout JSON Lines 補。- pane buffer 有 history-limit（我設 10000 行）——長 task 中間輸出會被截掉。
- tmux 不是天生的 message bus——message reliability 要自己處理（signal file + retry）。
- 全裝模式吃資源比 headless 多——幾個 pane 各跑一個全裝 CLI，記憶體很快被吃掉。
附帶一個訣竅：context 快滿時的 handoff
這只在「多 pane 同時跑得起來」的環境才能做：某個 session context 用到 70-80%，再寫下去 compact 之後品質會掉。這時打開新的 tmux pane 啟動同款 CLI，回到快滿那個 session 對它說：
寫完之後讓新 pane 讀 handoff.md 接續工作，原 session 自然 compact 或結束。單一 CLI session 自己 compact 自己時，丟失的 nuance 沒地方接；多 pane 環境就有人接得住。
整套換來的是「我永遠看得到現在誰在做什麼」+「不挑 CLI」+「context 接力不丟手」。multi-agent debug 卡住時打開 tmux，每個 agent 卡在哪一行 prompt 一眼就看到。
常駐一個 QA agent，吃訂閱不吃 API
日常 QA 用訂閱版 CLI 掛在 tmux pane 裡，比按 token 計費的 API 便宜很多。multi-agent 那一套是「task 來了才派工」，QA 是另一種情境——不是要 agent 幹活，是要它幫我查、幫我想、整理當下狀態；這層走 API（Anthropic / OpenAI / Google API）的話，問越多花越多。
我在 tmux 裡常駐一個 pane 跑著訂閱版的 CLI（Claude Code、Codex、Gemini 都有月費方案），手機透過自己做的 dashboard widget 把問題打進去。背後一樣是 send-keys 進那個 pane，但跑的是「訂閱定額」而不是「按 token 計費」。
圖裡那個立繪是 Live2D 做的——滑鼠移動視線會跟著走，agent 的回答 streaming 時嘴巴會跟著開合。純粹是視覺細節，但聊久了確實有點陪伴感。
API 付費 vs 訂閱 + tmux pane
- 走 API：每次問題按 token 計費，問太多帳單會飛起來。優勢是沒有時段配額、可以無限並行。
- 走 tmux pane + CLI 訂閱：固定月費，5 小時 / 7 天 額度跑滿就跑滿，不會有意外帳單。代價是配額硬性限制、不能無限堆並行。
tmux pane 是這條路的關鍵——它把 CLI 的「互動模式」變成可被遠端 send-keys 觸發的端點，跨裝置都戳得到。
現在這套 stack 長這樣
家裡那台 mac mini 24/7 跑著 default session：早上書房開機 ssh attach、出門 detach、通勤手機 PWA 接、外面換 MacBook——一路沿用同一個 session 沒斷過。狀態列把跨 CLI 的額度跟系統狀態擺清楚，要 multi-agent 的 task 派給中繼系統去調度，我自己看結果作決策就好。
回頭看這 3 個月，從狀態列、分屏、遠端到 multi-agent 編排，每一層都不是規劃出來的——當下的痛點要解就動手，做完才看下一個痛點是什麼。tmux 一直待在底下沒換過，是因為它每次都剛好夠用。
這套東西本來只給自己用。之後會陸續整理開源——tmux-webui、tmux-relay、session-channel⋯把每個工具切乾淨、文件寫清楚、依賴砍到能單獨裝為止。沒設定具體時程，做完一個放一個。
勾你的硬需求，看哪幾種先出局
headless、sub agent、team agent 那三張卡寫的是我自己用下來卡住的地方，換成你的條件，先出局的可能是別的幾種。勾下面幾條硬需求，會得到一張五列的表——本文點名過的五種承載機制各一列，出局的那格直接印出淘汰它的本文原句。全部在瀏覽器裡跑，不用貼任何東西進來，也沒有資料送出去。
常數出處都在本文：每一格的淘汰理由都是本文原句——headless 那兩條在〈Headless 模式〉那張卡，sub agent 與 team agent 在它們各自那張卡，中繼系統那幾條在〈trade-off 必須講清楚〉與 idle 判斷那段。引文原本在講別的機制、被套到另一列時，那一格會加括號說明。這些限制是 2026 年 2 月起算的那 3 個月、一個人在自己的 mac 上用那幾款 CLI 的觀察，不是各家 CLI 的規格書；本文沒寫的格子一律標「查不到」，不會替它補一個預設值；那幾格印出來的字沒有加引號，是在說明本文沒寫什麼，不是本文原句。
先選一條線，別同時動四條
文章列了 4 條應用線。多數人一次導入全部會卡住——選錯順序的代價是把環境弄亂後，連回頭都麻煩。
把你的開發環境和當下最痛的地方告訴 AI，讓它幫你挑哪條最適合先試，以及第一週具體要做的 3 件事：
延伸閱讀
這 3 個月實際參考過、影響過設計決策的資源。
| 資源 | 為什麼重要 |
|---|---|
| tmux man page | 從頭讀一遍會發現太多平常沒用到的功能。pipe-pane / capture-pane -p / wait-for 這些被忽視的 primitive 是後來跨 CLI 編排的基礎。 |
| 《tmux 使用和基礎配置 從入門到加班 一個視頻全搞定！》 | 我這 3 個月 tmux 基礎手感主要從這支來。中文、實作導向、不囉嗦。 |
| openclaw | 我接觸 tmux 的起點。它本身用 process spawn 不是 tmux，但「讓多個 agent 一起做事」這件事是它給我的。 |
| Blink Shell | iOS 高品質 SSH client + 好的觸控手勢設計，後來搬進了 tmux-webui。 |
| iSH | iPhone 上免費的 Linux shell；ssh attach mac mini 第一個試的工具。 |
| mosh | 想替換 ssh 解切網路斷線問題；對記憶體需求大，主力機跑不順最後放棄。 |