tmux 從通用狀態列、分屏、遠端
到多 agent 分工
2026 年 2 月被 openclaw 啟發開始用 tmux，從狀態列、分屏、遠端開發一路堆疊到多 agent 分工。
先把狀態列搞好#
2026 年 2 月被 openclaw 啟發開始用 tmux，跟著 YouTube 上 《tmux 使用和基礎配置 從入門到加班 一個視頻全搞定！》 一路敲指令熟手感。
那時候我已經同時在用一堆 AI agent CLI——固定班底加偶爾換來試的，多開幾個 terminal 視窗就一團亂。tmux 是來把這層整理乾淨的工具。
我不是「想好整個架構再開始」型的，是一步一步堆疊累積。第一步是把每個 CLI 的狀態看清楚——從 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 佈局#
學完基本指令後，收斂出三種反覆用的佈局。
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 時，ssh 一斷，build 從頭來。改成這個流程之後就沒再被斷過：
那一瞬間我意識到：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 在路上#
這個流程穩了之後，家裡的 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#
這個想法早於 Claude Code 自己出 remote 模式。後來 remote 出來，我也還是用 tmux 居多——這條路我已經堆疊到很自然了，容我從頭講起。
Blink Shell（自編譯）#
App Store 版要錢，GitHub 有開源版可以自編譯。完全沒碰過 iOS 開發，整個 sideload 流程交給 Claude Code 輔助。free developer account 每 7 天要重簽一次。
所以才轉頭做 tmux-webui——把 tmux pane 直接搬進瀏覽器，跳過所有 ssh client / mosh 的折騰。
選 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，而不是把所有事都丟給單一 CLI？
主 context 不被壓縮#
派給其他 agent 處理的細節（搜資料、跑 test、寫 boilerplate），不會把 main 的 context 塞滿；留下來的空間給真正需要主腦推理的部分。
並行加速（搭 git worktree）#
同一個 task 能拆成可平行的子任務（多分支試錯、N 個 PR 同時走），每個 pane 配一個 git worktree，工作目錄互不干擾。把原本單線的時間軸壓平。
多視野辯論#
不是分工而是合議。讓不同 CLI（或同款 CLI 配不同角色 prompt）對同一個問題各自表態，再交叉反駁，最後挑或讓其中一個收斂。對「該不該重構」「要選哪個架構」這種沒標準答案的決策最有用。
理由清楚之後，再盤點現有方案的限制，由淺到深三個。
Headless 模式#
claude -p、codex -p 之類。跑得快、好寫腳本，但能力打折——skill 不會載入、MCP 不會接、自己寫的 agent 也拿不到。每次呼叫從零起，沒有連續對話脈絡。獨立 task OK，有狀態協作不夠。
Claude Code sub agent#
Task tool 派出去的子代理。typed schema、prompt / 結果結構化，skill / MCP 可繼承。但溝通是單向——sub 沒辦法主動回頭叫主 agent，主 agent 只能等。
Claude Code team agent#
experimental。多個 agent 跑在獨立進程，靠 Anthropic 內建 message protocol 互通。雙向、可並行、中途能交換訊息。最像我要的，但綁在 Claude Code 自己——其他 CLI 進不來。
我要的是「跨 CLI 全裝模式的 multi-agent」——同一場 task 看哪個 CLI 擅長哪塊就分給誰，每個都用自己的 skill / MCP，彼此能互通。三個現有方案都辦不到，所以選 tmux pane 當底，自己疊一套。我把這套東西叫做 tmux-relay，後面段落講的「中繼系統」都是它。
做法分三層#
最底是一個工作 window，pane 不常駐——主 agent 看 task 適合哪款 CLI（強項是社群評價加我自己用下來的偏好），才開 pane 把那款 CLI 啟動起來。用完保留待用，閒置太久就回收。
挑 idle 的判斷是看 pane 畫面當下狀態——agent 在等輸入還是在跑，從輸出內容辨識。不維護 lock、不留歷史，每次重看。
這層目前只在 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#
multi-agent 那一套是「task 來了才派工」。但日常還有一種使用情境是 QA——不是要 agent 幹活，是要它幫我查、幫我想、整理當下狀態。如果這層走 API（Anthropic / OpenAI / Google API），按 token 計費，問越多花越多。
所以我在 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 天 額度跑滿就跑滿，不會有意外帳單。代價是配額硬性限制、不能無限堆並行。
對「日常 QA」這種非高吞吐情境，訂閱算下來便宜很多。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⋯把每個工具切乾淨、文件寫清楚、依賴砍到能單獨裝為止。沒設定具體時程，做完一個放一個。
先選一條線，別同時動四條#
文章列了 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 解切網路斷線問題；對記憶體需求大，主力機跑不順最後放棄。 |