想把任務丟給別家 CLI，沒地方丟

這一站的產物是 tmux-relay：對可用的 tmux pane 派命令，保留 task、role、完成訊號跟結果讀取的路徑。tmux pane 從「我用滑鼠切過去看的視窗」變成「可以被程式呼叫的 worker」，前一篇裡那個還沒取名的 dispatcher 就是它。

會走到自己寫，是因為額度常常見底——主力是 Claude Code，同時訂了好幾家模型的方案、也接了幾家的 API，還是不夠用。當時最先浮出來的念頭不是換一個更強的模型，是「這些雜務為什麼要佔用主 agent 的 context」：那時候 context window 只有 20 萬 token，1M 是後來才開放的，讓主 agent 逐字讀完一堆 grep 結果太浪費。

Claude Code 推出 sub-agent 那陣子，「把工作丟出去」第一次變得具體，但 sub-agent 是 Claude 內部的 worker，送不到 Codex、送不到別家 CLI。翻了一圈沒找到能直接用的做法：要跨 CLI 派工，得先有個地方能把一段任務送到真正在跑的 terminal，還要知道它做完了、結果在哪。

worker 能跑了，但彼此不會說話

這一站補的是 session-channel（前一篇寫過）：pane 之間靠它直接互通，不必把每次轉述都塞回同一個對話。

tmux-relay 能派工之後，下一個問題馬上冒出來——一個 agent 做完事，沒有地方能告訴另一個 agent。Claude 的 Team Agent 只在同一家模型內部傳訊息，Codex 做完的事 Claude 這邊收不到。

本機在忙，另外兩台電腦閒著

這一站補的是 fleet，依機器能力分派任務：掛了顯卡的 Windows 接 TTS、ASR 這類要訓練或跑推論的工作，老 Intel MacBook 只接輕量任務，日常主力留給 Mac mini M4。

派工跟跨 pane 通訊都通了之後，再卡住的地方不是模型，是機器——本機跑 agent 跑到發燙的時候，那兩台大部分時間閒著，而那時候我看到的幾個多 agent 工具，多半預設跑在同一台機器上。

worker 的定義補完 fleet 才長齊——一開始想成 tmux 裡的另一個 pane，後來發現它也可以是另一個模型、另一個 session，甚至另一台電腦。這裡的 worker 比前一篇「跑便宜模型的那一層」用得更廣。

同一句任務，每家 CLI 的開法都不一樣

這一站補的是 cli-rosetta：把各家 CLI 的差異收進一份宣告式的 registry，到 2026 年 8 月為止登記十個——Claude Code、Codex、Copilot、Antigravity、Qwen Code、Kimi Code、OpenCode、Hermes、Pi、Grok。

worker 的種類長齊之後，麻煩換了個方向：派得出去，但同一句任務交給 Codex 跟交給 Copilot，headless 怎麼開、模型怎麼指定、有哪些工具可用全都不一樣，每要換一家執行就得重新翻一次文件。

cli-rosetta 這份 registry 後來包成了 plugin，格式是照 Codex CLI 的 plugin 規格填的。它要的 metadata 比我原本自己想的完整得多——顯示名稱、分類、能力清單、給使用者的預設 prompt 都要寫，等於逼你把「這東西到底能做什麼」講清楚。填完之後同一套 skill 跟 command，Claude Code 跟 Antigravity 那邊也裝得起來。這是這幾站裡第一次不是自己發明格式，而是照別人定好的規格走，省下來的力氣比想像中多。

同一種任務一直重做，每次都手動兜

這一站補的是 agentctl：把一次性目標跟可重跑流程分開，加上 checkpoint、預算上限、權限閘跟獨立的 judge——獨立 judge 這一項，是為了讓「它說做完了」不是唯一的驗收依據。

我派工的次數一多，同一種任務會反覆出現，每次都手動兜一次流程，開始不划算。補這一站的時候 workflow 這個概念剛開始被討論，我沒找到能直接套用的。

最近這次卡住，先找到了現成的

這一站我沒動手——2026 年 8 月查的時候，現成工具比前面那四次多，而且解得比我自己補的那版完整，所以改成借點子回來補既有的東西。

Claude Squad 用 tmux session 加 git worktree 隔離多個任務，用 TUI 統一管理切換。Herdr 把多個 coding agent 放進真實 terminal pane，從前景 process、畫面內容等多重訊號判斷 blocked、working、done、idle。Orca 把 worktree、agent terminal、diff 跟 browser 全放進同一個 task 範圍，做成一套完整的 Agent Development Environment。Claude 官方也在 2026 年推出雲端的 remote 模式，工作直接跑在他們的機器上。

任務要隔離、狀態要看得見、離開電腦要能接回來——這幾件事 Claude Squad、Herdr、Orca 都解了。用 agent 的方式本來就那幾種，會卡的地方自然也就那幾個，只是這次運氣好，卡住的時候剛好已經有人把它做完了。所以查到現成工具之後，要問的就只剩「哪些可以直接拿來用」：通用的 terminal 隔離、pane 狀態偵測、遠端接回，別人做得比自己重寫划算，那就用他們的；剩下那些貼著自己工作習慣的規則——任務怎麼分派給不同模型、CLI 之間的語意怎麼對齊、長任務怎麼驗收跟續跑——目前還沒看到剛好合用的，先自己留著。

派工這條線我又多翻了一輪。2026 年 8 月在 GitHub 上搜，名字裡有 agentmux 的 repo 五十幾個、有 amux 的八十幾個，彼此互不相干。其中 thevibeworks/amux 的 README 寫了動機：claude -p 轉為額外計費，所以改用真實 tmux session 驅動互動 TUI，把用量留在原訂閱額度內——跟這篇開頭卡的是同一件事。我實際點開的那幾個裡，派工、task 記錄、完成偵測、結果讀回四樣齊全的都在幾十顆星以內，好幾個停更超過半年。這個領域星數真正高的那幾個，做的其實是別的事——有的是 prompt 出來的 agent 自己去敲鍵盤，有的方向反過來，是 AI 看著你的畫面幫你下指令。

所以這次借的是點子，不是重寫一套

我在 tmux-webui 上補了兩個東西，來源分別是 Herdr 跟 Orca：跟 Herdr 借樹狀 pane 狀態，把 workspace、tab、pane 的階層列出來，誰在忙、誰在等人確認、誰做完了一眼掃完，不用逐個點開；跟 Orca 借 dash window，agent deck 跟 session log 放進同一個畫面，不用切分頁。tmux-webui 原本只做一件事：把 tmux pane 搬進瀏覽器，讓人不在主機前也能看到原始終端畫面。

跟 Orca 不一樣的是選擇——Orca 造了一套完整的開發環境，用它就等於換掉工作介面；tmux-webui 沒有另外造一種畫面，deck 跟 log 是外加的總覽層，點進去看到的還是原本 pane 裡真實在跑的東西。兩種都成立，差別在願不願意把終端機交出去。

operonlab 底下這些 tmux 工具沒有一個是規劃出來的，都是踩到某個具體摩擦才補的：見底的額度逼出 tmux-llm-usage，抓不準的 agent 狀態逼出 tmux-agent-status，重開機後對話斷線逼出 tmux-agent-resume，一個專案要開一堆視窗逼出 tmux-workdesk，不在主機前看不到 pane 逼出 tmux-webui。operonlab 底下 tmux- 開頭的公開專案，寫這篇的 2026 年 8 月是十三個，加上 session-channel 是十四個。

換個場景，同一個爭論在吵 nginx

我的判準因此多了一條：那東西要是真的比較好，不是比較新。這條是從一支叫〈I Replaced Nginx With Caddy… And I'm Never Going Back〉的影片底下、一則留言來的。

那則留言講的「二十年的存在是優點不是缺點」，跟我在 tmux 這邊面對的是同一個形狀的問題。tmux 也活了將近二十年，介面老、設定難讀，但 send-keys 跟 capture-pane 這些原語幾年沒變過——正因為沒變，上面疊的東西才不用一直跟著改。新的 ADE 把 worktree、terminal、diff、browser 收進同一個畫面，體驗好得多，代價是整個工作介面綁在它的生命週期上。

年份本身是中性的。同樣二十年，可能變成纏累——設定檔沒人敢動、繞路的 workaround 一層疊一層、後來的人看不懂為什麼要這樣；也可能變成資產——坑都被人踩過了，程式碼被 review 過無數次。差別在這些年是拿來累積，還是拿來背債。

換一套 harness，不只是換模型

決定產出品質的不只是模型本身。Wisely Chen 那篇文章把這個差異量化過：同一顆 Kimi K3 模型，官方 harness KCode 只拿 59.6%，換成開源的 Maka 能到 69.7%。harness 不是模型的外殼，是決定模型實際表現的變因。

Pi 跟 Claude Code 剛好是兩種路線——Claude Code 把模型跟 harness 綁在一起，開箱就能用；Pi 可以換 provider、換模型，靈活但要自己拼。

前面那幾站補的東西，是把「harness 是變因」這句話往外推一步：一個模型的時候，harness 決定它怎麼做事；模型變多之後，還需要一個東西決定工作怎麼分、怎麼接、怎麼驗。各家模型擅長的事本來就不一樣，機械式的批次修改交給便宜的模型跑就夠——再前一篇把工作拆成規劃、worker、驗收三層跑在不同模型上，就是這件事的第一版。

自己補的那幾站，帳單來得比較晚

先講代價，不然這篇讀起來會像在鼓吹自己動手：這幾站的維護帳單來得比較晚。上游 CLI 改一次 flag，我就要把 cli-rosetta 的 registry 跟著校一次；Claude Code 換一版 TUI，tmux-webui 判斷 agent 在忙還是在等人的規則就可能誤判。這些工具沒有社群幫忙盯著相容性，壞了只有自己會修，跑得越久，維護花的力氣越是超過當初寫它的成本。

所以換個情境，結論可能完全不同。只用一兩個 agent、任務也不需要跨機器分派時，直接挑一個 Claude Squad 或 Orca 這樣的成熟工具，會比自己拼一套划算得多——那些工具有人維護，自己補的這幾站沒有。

會走到自己動手，都是卡的那站夠痛、當下又剛好沒找到能用的。現在社群裡的答案多了，能少補一站是一站。

先量自己，再決定要不要動手

下面兩個判定器要你自己填，填完才有結果。第一個照症狀定位你卡在哪一站，第二個用一份公開實測的兩個錨點，估這次任務派出去划不划算。兩個都在瀏覽器裡算，沒有任何資料送出去。

延伸閱讀