多個 agent 同時跑，你要怎麼管理？
一個很蠢但每天都在發生的場景
我這陣子的桌面大概長這樣。
一個 Claude Code 在改部落格的樣式，一個 Codex 在跑資料回填，第三個分頁裡還有一隻 agent。前兩隻我知道在幹嘛，第三隻我以為它在跑。
結果它在等我。
它三十分鐘前就跳出「要不要 deploy 到 staging？1. Yes 2. No」，然後就停在那裡。我在另外兩個分頁忙進忙出，完全沒發現。三十分鐘，不是它在算，是它在等我按 Enter。
這件事我一週要遇到好幾次。而我「解決」它的方式，說出來有點好笑：每隔一陣子就用 Cmd+1~9 把所有分頁掃一遍，看看有沒有人在等我。
人肉輪詢。我變成了一個 polling loop。
問題其實有三個，不是一個
同時跑多隻 agent 之後，痛的地方分得很開：
第一，你的筆電是它們的生命線。agent 跑在你的終端機裡，你關蓋、網路斷掉、SSH 掉線，那個 process 就沒了。一個跑了兩小時的任務，因為你要出門而中斷，這件事本身就很荒謬——它明明是台機器在跑，卻要你陪著。
第二，你不知道誰卡住了。前面那個場景。終端機分頁只會告訴你「這裡有個 process」，不會告訴你「這隻在等你」。要知道狀態，只能一個一個切過去用眼睛看。
第三，agent 之間互相不認識。你想讓 A 寫完之後叫 B 來 review，現在的做法通常是你當中間人：複製 A 的輸出，切到 B 的視窗，貼上去。你變成兩隻 agent 之間的 message queue。
這三件事，Herdr 想一次處理掉。
Herdr 是什麼：它不是一個 app
先講最容易搞混的地方，因為這決定了它跟其他工具的差別。
大部分「管 agent」的工具是 app：你開一個視窗，agent 在那個視窗裡跑，視窗關掉、程式當掉，工作就跟著沒了。
Herdr 走的是另一條路。它官網自己的講法是「the runtime your coding agents live on」，agent 住在上面的那個 runtime。實際上是一個背景 server 持有真正的終端機（真的 PTY，不是模擬），agent 活在裡面；而所有 UI，包含它自己附的那個 TUI，都只是「連上去看」的 client。
這個分法的重點，是那條虛線畫在哪裡：
flowchart TB
C1["TUI client"] -. "attach / detach" .-> S
C2["SSH 進來的另一台機器"] -. "attach" .-> S
C3["herdr CLI / socket API"] -. "attach" .-> S
S["herdr server（背景常駐）"] --> P1["pane: Claude Code"]
S --> P2["pane: Codex"]
S --> P3["pane: dev server"]
實線是「持有」，虛線是「連上去看」。你平常盯著的那個 TUI 在虛線那一側，所以它斷線、當掉、被你整個關掉，agent 都不知道發生了什麼事——抓著它們的是 server，不是你看到的那個視窗。
換成現在的做法，這張圖會塌成一條直線：終端機視窗直接抓著 agent，視窗一關，下面全部一起死。
它的比較頁面上有一句話我覺得整篇最值得記：真正能把這類工具分類的問題，是 當你正在看的那個東西消失時，agent 會怎樣。
有感的三件事
下面三張圖都是我實際裝起來跑出來的畫面：同一個 session 裡兩個 workspace、三隻 agent（兩隻 Codex 一隻 Claude Code），加上一個真的 Astro dev server。不是官網的示意圖。
一、關筆電不會死
安裝完之後在專案目錄下打 herdr，它會啟動（或接上）背景 session，然後你就在裡面跑你原本的 agent。
要走的時候按 Ctrl+b 放開再按 q，detach。或者更暴力一點，直接把終端機視窗關掉，一樣。回來再打一次 herdr 就接回原本的畫面。
真正要停掉所有東西，是 herdr server stop。這個區分很重要——「我不看了」跟「我不跑了」是兩件事，一般終端機沒有這個區分。
我實際驗過一次：三隻 agent 跑著、dev server 跑著，然後我把整個終端機 app 直接 quit 掉，再從外面用 CLI 問：
$ herdr status
server:
status: running
version: 0.8.2
socket: /Users/bobochen/.config/herdr/herdr.sock
$ herdr agent list
blog claude idle w2:p1
critic codex idle w2:p3
reviewer codex idle w3:p1
$ curl -s -o /dev/null -w "%{http_code}" http://localhost:4323/
200終端機已經不在了，三隻 agent 還在，pane 裡那個 dev server 也還在服務。重新開一個終端機打 herdr，畫面長這樣：
版面、每個 pane 的歷史輸出、agent 的對話紀錄，全部原樣回來。
遠端也吃得下。SSH 到 VPS 上跑 herdr，行為跟 tmux 一樣；或者用 herdr --remote user@host，它會自己在對面裝好，你本機只是個薄 client。
二、它會直接告訴你誰在等你
這是我最想要的功能，也是我這次實測最有感的一個。
Herdr 會去讀每個 pane 的畫面，判斷裡面那隻 agent 現在是什麼狀態，然後在側邊欄標出來：
stateDiagram-v2
[*] --> idle
idle --> working: 你送出 prompt
working --> blocked: 跳出確認框或提問
blocked --> working: 你回答了
working --> done: 你沒在看的時候跑完
done --> idle: 你切過去看了一眼
working --> unknown: 認得出是 agent 但判不出在幹嘛
blocked 就是「它在等你」，done 是「背景跑完了但你還沒看到」。這兩個狀態一標出來，開頭那個三十分鐘的蠢事就不會再發生了。
實際跑起來是這樣。我故意讓 Claude Code 去做一件需要授權的事，同時讓另一個 workspace 的 Codex 跑一份唯讀分析：
重點在左邊那兩個圓點。我沒有切過去任何一個 pane，光看側邊欄就知道：粉紅色那個在等我，黃色那個還在跑。開頭那個場景要的就是這個。
它的 agent guide 裡對 unknown 有一句話寫得很老實：unknown 表示認得出 pane 裡有 agent，但無法有把握地分類，它不代表任務完成。會把自己判斷不準的地方寫進文件的工具，我通常比較信得過。
順帶一提，這裡有個小細節值得注意：從 CLI 讀狀態不會把 done 標記成「已看過」，只有你真的把那個 tab 切到前景才算。所以你不能用「狀態變 idle」來當自動化的完成訊號騙自己。
三、agent 可以自己開 pane、自己叫 agent
這部分是我覺得 Herdr 跟純多工終端機真正拉開距離的地方。
Herdr 的 CLI 跟 socket API 是同一套介面，agent 自己就能用。它甚至有一份 SKILL.md 是專門寫給 agent 讀的，教它怎麼操作 Herdr。
所以「A 寫完叫 B 來 review」這件事，可以變成 A 自己做：
sequenceDiagram
participant You as 你
participant A as agent A 寫 code
participant H as herdr server
participant B as agent B reviewer
You->>A: 寫完之後找人 review
A->>H: pane split --current --no-focus
H-->>A: 回傳新 pane id
A->>H: agent start reviewer --kind codex
H->>B: 在新 pane 啟動
H-->>A: ready
A->>H: agent prompt reviewer "..." --wait
H->>B: 送出 prompt
Note over H,B: 一直等到 B 真的 idle / done / blocked
H-->>A: B 的狀態
A->>H: agent read reviewer
H-->>A: B 的輸出
A->>You: 回報結果
重點在 --wait 那一段。它不是 sleep 幾秒然後賭一把，是真的等到對方的生命週期狀態穩定下來。而且 API 設計得滿謹慎的：如果目標 agent 正卡在確認框，agent prompt 會直接回 agent_blocked 拒絕送出，而不是把文字硬塞進一個正在問「Yes/No」的對話框裡——後者是你自己寫腳本控 agent 時最容易踩的坑。
另外 --no-focus 這個 flag 也很體貼：背景幫你開的東西不會把你的游標搶走。
這串我自己用 CLI 從外面跑了一遍——就是上面那張圖裡 agent A 會替你做的事：
$ herdr pane split w2:p1 --direction right --ratio 0.5 --no-focus
{"result":{"pane":{"pane_id":"w2:p3", ...}}}
$ herdr agent start critic --kind codex --pane w2:p3
{"result":{"agent":{"name":"critic","agent":"codex","agent_status":"idle", ...}}}
$ herdr agent prompt critic "簡述 src/components 底下的資料夾結構，唯讀分析。" --wait跑完之後，同一個 tab 裡就多了一隻不同廠牌的 agent：
左邊 Claude Code、右邊 Codex、下面一個 dev server，三個都在同一個 herdr session 裡。要注意的是這三格不是「一個 app 畫出來的三個面板」，是三個真的終端機——所以 Codex 那格自己跑了一次 npm install -g @openai/codex 自動更新、然後要求重啟，跟它在一般終端機裡的行為完全一樣。Herdr 沒有插手，它只是持有那個 pane。
那它跟 tmux 差在哪？
如果你已經在用 tmux 或 zellij，你可能會覺得前兩點聽起來很耳熟——持久化的終端機、detach、SSH 進去接回來，這些 tmux 二十年前就有了。
沒錯。Herdr 自己也承認這份繼承，它的比較頁面寫得很直白：
tmux 給了人類持久性，Herdr 保留了整份繼承：真正的 PTY、detach、SSH。它加上去的是多工器從來沒有的那部分——知道哪個 pane 是 agent、它是不是卡住了、以及怎麼「等」它而不是「輪詢」它。
tmux ls 會告訴你有三個 session。哪一個在等你回答？它不知道，它也沒有理由知道，因為 tmux 面對的是「終端機」這個抽象，不是「agent」。
用一句話總結這個差別：tmux 讓終端機活著，Herdr 讓 agent 被看見。
還有一個實務差別：Herdr 是滑鼠優先的。點 pane、拖分割線、右鍵選單，全部可以用滑鼠來。prefix key 預設一樣是 Ctrl+b，但你可以完全不學快捷鍵就開始用。這對「知道 tmux 很好但一直懶得學」的人來說，門檻低很多。
怎麼開始
curl -fsSL https://herdr.dev/install.sh | shWindows 是 irm https://herdr.dev/install.ps1 | iex。不想 pipe to shell 的話，brew install herdr、mise use -g herdr，或直接去 GitHub Releases 抓 binary 都可以。單一執行檔，macOS / Linux / Windows 都有。
然後：
cd ~/your-project
herdr進去之後就跑你原本的 agent，claude、codex、隨便哪個，Herdr 會自己認出來並在側邊欄標狀態。官方說開箱偵測 20 種 agent CLI。
幾個第一天會用到的：
| 動作 | 怎麼做 |
|---|---|
| 往右／往下切 pane | Ctrl+b 然後 v ／ -，或右鍵選單 |
| 開新 tab | Ctrl+b 然後 c |
| 離開但讓它繼續跑 | Ctrl+b 然後 q，或直接關視窗 |
| 接回來 | herdr |
| 看所有快捷鍵 | Ctrl+b 然後 ? |
| 真的全部停掉 | herdr server stop |
想讓你的 agent 自己會操作 Herdr，可以裝那份 skill：npx skills add herdrdev/herdr --skill herdr -g。
還有一招我覺得很聰明：官網提供一份 agent-guide.md，你可以直接叫你的 agent 讀它，讓 agent 帶你做完設定。文件本身就是寫給 AI 讀的格式，裡面甚至有一條規則是「不要編造快捷鍵、設定欄位或 CLI flag」。工具作者知道自己的使用者有一半是 AI，這個時代感有點強烈。
社群最常抱怨的三件事，我一條一條試了
社群上關於 herdr 的討論其實不少，而且有個問題問得特別好：不是「好不好用」，而是「用過一陣子的人，後來為什麼不用了」。
這個問法比任何評測都誠實。我把底下被重複提到的抱怨挑出來，在自己這台機器上一條一條試。
一、「切 workspace 沒辦法用 cmd+數字」
這是被提最多次的一個。從 cmux 換過來的人習慣 cmd+1/2/3 直接切，到了 herdr 翻半天找不到；也有人因此直接下結論，說優點沒高過轉換成本。
我先去翻預設設定：
$ herdr --default-config | grep -E "switch_tab|switch_workspace|focus_agent"
# focus_agent = "" # optional indexed binding, e.g. "prefix+alt+1..9"
# switch_tab = "prefix+1..9"
# switch_workspace = "" # optional indexed binding, e.g. "prefix+shift+1..9"答案在這三行裡，而且分成兩件事：
- 切 tab 用
prefix+1..9，本來就是預設。有人測出來可以用但不確定是不是預設值，是的，就是。 - 切 workspace（大家口語講的「切 session」）預設是空的。不是沒做，是沒綁。所以你翻遍快捷鍵表也找不到——它根本沒出現在表上。
那綁上去會怎樣？我寫了一份 ~/.config/herdr/config.toml 實測：
[keys]
switch_workspace = ["prefix+shift+1..9", "ctrl+alt+1..9"]
focus_agent = ["prefix+alt+1..9"]陣列語法是重點：保留原本的 prefix 版本，同時加上一組免 prefix 的直接和弦。存檔之後：
$ herdr config check
config: ok
$ herdr server reload-config
{"result":{"diagnostics":[],"status":"applied","type":"config_reload"}}不用重啟。我當時三隻 agent 正跑著，status: applied 之後 herdr agent list 三隻原封不動。這點我覺得比功能本身還值得記：改鍵位不用付「重來一次」的代價。
然後我實際按了三次，記錄 focus 跑到哪個 workspace：
| 按下去 | 結果 |
|---|---|
ctrl+alt+1 | 切到 workspace #1 ✅ |
cmd+2 | 完全沒反應 ❌ |
ctrl+alt+2 | 切到 workspace #2 ✅ |
所以大家想要的功能一直都在，只是你想要的那組按鍵永遠不會成功。
二、為什麼偏偏是 cmd 不行
這點 herdr 文件講得比我清楚，而且我覺得寫得很誠實：一個和弦要活著抵達 herdr，得先穿過三層——作業系統、你的外層終端機、以及 pane 裡正在跑的程式。cmd 系列在 macOS 幾乎都被前兩層吃光了，alt 系列則會被 macOS 合成成特殊字元。
文件裡提到他們把 Ghostty、iTerm2、Terminal.app、kitty、WezTerm、Alacritty、Warp、Windows Terminal、GNOME Terminal、Konsole 十種終端機的預設鍵位、加上 GNOME 與 KDE 的全域快捷鍵全部對照過一遍，結論是只有 ctrl+alt 這一家幾乎沒人佔用。上面那張表就是這句話的實驗結果。
另一種常見的回報是「有些 keymap 會無法生效」——而那個情境是在 tmux 裡面再開 herdr。那就是第四層攔截，tmux 自己的 prefix 會先咬一口。這不是 herdr 壞掉，是和弦沒穿過去。
（順帶一提，那個「在 tmux 裡面開 herdr」的用法我覺得滿聰明的：外層 tmux 切 Neovim 跟 herdr，內層 herdr 管 agent。兩個工具不用二選一。）
三、「本質上還是 TUI」——然後他們跑去 Orca 了
這是最大的分流，好幾個人都提到 Orca。講得最完整的一種說法是：用了兩天還是不習慣這個介面，號稱滑鼠可以用但骨子裡仍是 TUI，所以改用 Orca；並且補了一句我認為最準的判斷——herdr 適合原本就習慣 tmux 的人。
Orca 是桌面 Agent IDE，MIT、大約 39k stars，自帶終端機、檔案編輯器、git worktree 隔離，還有手機 app。跟 herdr 是完全不同種的東西。
我覺得這個分流不是「誰比較好」，而是 herdr 自己 compare 頁那一列的實際演出：Runs inside your existing terminal。你要的是「終端機什麼都不用變」，那是 herdr；你要的是「給我一個完整的 app」，那是 Orca。社群的人流方向，完全照這條線走。
有趣的是問出那個問題的人自己結論相反：研究完 Orca 之後發現反而不是自己要的，笑說沒想到已經默默變成習慣 TUI 的人，到現在還在用 herdr。
附帶：一個到處在流傳的錯誤資訊
查 herdr 的中文資料時，我看到不只一處寫著「AGPL-3.0 雙授權，商業組織需要購買商業授權」。
這是過期資訊。 作者在 YC 公告裡明講換掉了，他的說法是希望每個人都能自由使用；我也直接查了 GitHub API 確認：
$ curl -s https://api.github.com/repos/herdrdev/herdr | grep -A2 '"license"'
"license": { "key": "apache-2.0", "spdx_id": "Apache-2.0" }Apache-2.0。如果你正要拿這個工具去說服公司，別引到那份舊資料。
誰做的
Herdr 是 Can Celik 一個人用 Rust 寫的，GitHub repo 2026 年 3 月 27 日開張，到我寫這篇的今天（8 月 24 日）約三萬兩千顆星。五個月。
8 月 6 日他發文宣布 加入 Y Combinator F26 batch，那篇文章我建議直接讀原文，因為起心動念的那段很好：
四個月前我在找下一份工作，想著職涯要往哪走，想著軟體工程的未來、我的業餘專案、投出去的履歷、白板面試（我到現在還是不敢相信我們在做這種事）。然後某個瞬間我意識到：我就是那個瓶頸。
以及他對「每家公司都在出自己的 agent」這件事的態度：
你知道現在每家公司都在發表自己的 agent 吧？不要這樣做。讓我的 agent 去整合你的產品，別再給我一個新的 agent。
Herdr 本身就是這句話的實作——它不做 agent，不包裝 agent，不取代 agent，它只是給你已經在用的那些 agent 一個住的地方。
license 從 AGPL 換成了 Apache-2.0，他的說法是「我希望每個人都能自由地使用 Herdr」。目前版本 0.8.2。
我的判斷：誰該裝，誰其實不用
先講不用的，有兩種。
第一種，你一次只跑一隻 agent，而且都在自己筆電上開著螢幕盯。多一層 runtime，你得到的主要是「關蓋不死」，而你本來就沒在關蓋。
第二種比較關鍵：你其實想要的是一個 app，不是一個終端機。前面那段社群回饋已經把這條線畫得很清楚了——覺得「滑鼠能點但骨子裡還是 TUI」很彆扭的人，最後都走去 Orca 了。這不是誰比較爛，是兩種人。你如果打開終端機會覺得鬆一口氣，herdr 是你的；你如果覺得終端機是不得已才開的東西，那你要的是 Orca 那類東西，而且你會比較快樂。
值得裝的情況大概是這三種：
- 你固定同時跑兩隻以上的 agent，而且常常忘記某一隻在等你
- 你有跑幾小時起跳的任務，不想被自己的作息綁住
- 你有遠端機器（VPS、公司的開發機），想在筆電跟遠端之間無痛切換
還有一個我覺得要先講清楚的期待管理：Herdr 不是 agent orchestrator。它不會幫你設計 multi-agent 分工、不會幫你拆任務、不會決定誰做什麼。它做的是更底層的兩件事——讓 agent 有地方住，讓你（跟其他 agent）看得到它們的狀態。編排的邏輯還是你自己或你的 agent 要寫。
這個定位我覺得反而是它的優點。作者在 YC 那篇裡有句話講到我心坎裡：
在一個「多加一個功能幾乎沒有成本」的時代，決定什麼東西可以進核心，才是最重要的決定。
這次實測我只跑在本機。真正想試但還沒試的是把長時間任務推到 VPS 上跑——目前我的做法是開著筆電硬撐，這顯然不是個做法。至於本機這段，「把終端機整個 quit 掉、agent 照跑」這件事我是真的驗過了，上面那段 herdr status 就是當下的輸出。
真的要一句話講完 Herdr 為什麼存在，我會說：agent 已經強到可以自己跑好幾個小時了，但我們給它的容身之處，還是那個「你一關蓋就消失」的終端機視窗。這中間的落差，總得有人去補嘛(笑 XD)。
參考連結
- herdr.dev — 官網，首頁那個 hero 是可以點的互動 mock
- herdr.dev/compare — 跟 tmux、zellij、cmux、Warp 等九個工具的對照表
- herdrdev/herdr — 原始碼（Rust，Apache-2.0）
- Herdr is joining Y Combinator — 作者 Can Celik 的公告全文
