herdr 實戰指南：一個終端機管好所有 AI Coding Agent（2026）
同時跑 Claude Code 和 Codex CLI，你是怎麼知道哪個在等你 approve？多數開發者的答案是：一個個 tab 切換，看看有沒有提示訊息。這個做法在只有一個 agent 的時候還行，但同時管三個、四個 agent 時，tab 切換的心智負擔會快速累積。
herdr 是一套給 coding agent 使用的開源 runtime。它把 agent 留在持久化的 terminal pane，再將執行狀態集中到同一個 workspace，讓你看出誰正在工作、等待輸入或閒置。
TL;DR
- herdr 是 Rust 寫的 terminal agent 多工器，讓你在一個視窗裡同時管理 Claude Code、Codex、Devin 等多個 AI Agent，並即時看到每個 agent 的 blocked/working/done/idle 狀態
- 核心差異：tmux 是通用終端多工，完全不知道 agent 在等你還是在跑；herdr 是 AI agent 時代的終端機，狀態感知是原生功能
- 安裝一行搞定（
brew install herdr），對 tmux 用戶學習曲線低；目前穩定版 v0.8.2 仍屬 pre-1.0
多個 AI Agent 同時跑，你現在是怎麼管的？
同時開著多個 coding agent 時，每次確認狀態都要切換 pane，重新閱讀 terminal 輸出。持久化 runtime 能減少這種輪詢：process 留在原本的 pane，herdr 則把狀態集中到同一個畫面。
這個 tab 切換的成本比看起來更高。每次切換都需要讀取 terminal 輸出來判斷狀態，然後再切回原本的工作。如果 agent 恰好剛進入等待狀態，你一切過去就要馬上互動；如果還在跑，這次切換就是浪費。更糟的是，如果你關掉筆電或網路斷線，正在跑的 session 可能就消失了。
多 agent 並行開發已經是很多人日常的一部分，但管理工具還停留在 AI agent 出現之前的設計。tmux 解決了 session persistence 和 pane 分割，但它對「Claude Code 目前在等你 approve 還是還在思考」這件事一無所知。
真正該問的問題：不是「我要不要從 tmux 換到 herdr？」而是「我需不需要即時知道每個 agent 的執行狀態？」如果答案是需要，tmux 無論多熟都解決不了這個問題。
如果你想先了解多 agent 並行工作流的整體設計，Claude Code 平行作業完整指南有更完整的 git worktree 隔離策略。
herdr 是什麼：從 tmux 到 AI-native 終端機
herdr（讀音：herd-er，即「牧群管理者」）是由 Rust 寫成的 terminal agent 多工器。它把每個 agent 留在獨立的真實 terminal pane 中，再把 working、blocked、idle 等狀態彙整到同一個 workspace。
功能定義上，herdr = PTY multiplexer + agent state awareness + persistent session + Socket API。比較重要的是每一項都有具體意義：
PTY multiplexer：和 tmux 一樣，可以分割 pane、建立 tab、detach/reattach，agent process 會留在各自的 terminal pane。
Agent state awareness：這是 tmux 沒有的核心功能。herdr 的 sidebar 即時顯示每個 agent 的狀態：blocked（等待輸入）、working（正在執行）、done（完成）、idle（閒置）。不用切 tab，一眼確認。
Persistent session：背景 server 模式，筆電合蓋或 SSH 斷線後，session 仍然存活，重新連線後可直接 reattach。支援 SSH remote attach，遠端伺服器上的 agent 也能從本機監控。
Socket API：本地 Unix socket 讓 agent 可以主動呼叫 herdr，建立 pane、spawn 子 agent、讀取其他 agent 的 output、subscribe 狀態變化事件。這個功能讓 herdr 從「viewer」升級為「orchestrator」（後面 H2-6 詳述）。
| 功能 | herdr | tmux |
|---|---|---|
| Pane 分割 / Tab 管理 | ✅ | ✅ |
| Session persistence (detach/reattach) | ✅ | ✅ |
| SSH remote reattach | ✅ | ✅ |
| Agent state tracking (blocked/working/done) | ✅ | ❌ |
| Agent Socket API | ✅ | ❌ |
| AI agent 原生設計 | ✅ | ❌ |
一個值得注意的細節：中文社群（moewah blog）對 herdr vs tmux 的定位是「互補而非取代」。這個說法有道理，herdr 本身就包含 tmux 的多工功能，對 tmux 老手而言是升級路徑，對新手來說則可以直接從 herdr 開始。
五分鐘裝好並跑起第一個 Claude Code session
Step 1：安裝（三選一）
Mac 用 Homebrew（最快，官方 formula 已確認）：
brew install herdr
Linux 或通用平台用安裝腳本：
curl -fsSL https://herdr.dev/install.sh | sh
從原始碼建置（需要 Rust 環境）：
cargo install herdr
也支援 mise 和 Nix，詳細說明見 herdr 官方安裝文件。
Step 2：啟動 herdr
herdr
進入後你會看到類似 tmux 的介面，但多了右側的 agent 狀態 sidebar。基本按鍵：
Ctrl+B啟動前置鍵（和 tmux 一樣）Ctrl+B V垂直分割 paneCtrl+B C建立新 tabCtrl+B Qdetach（背景持續執行）
Step 3：啟用 Claude Code 整合
在 herdr 環境裡執行：
herdr integration install claude
這個指令安裝 Claude Code 的 hook 腳本，讓 herdr 能接收 session 身份資訊。安裝完成後，在 pane 裡直接啟動 claude，sidebar 就會出現 Claude Code 的狀態顯示。
Step 4：驗證
啟動 Claude Code 並讓它開始執行任務。herdr sidebar 會顯示目前狀態，等待你輸入時顯示 blocked，執行中顯示 working。
重要：在 herdr pane 裡再開 tmux session 會導致 agent 狀態偵測失效。建議直接在 herdr pane 裡執行 agent，不要巢狀 tmux。
Agent 狀態追蹤：它怎麼知道 Claude Code 在等你？
herdr 的狀態偵測有兩套機制，準確度截然不同，選擇哪個 agent 直接影響你拿到的資訊品質。
機制一：Lifecycle hooks / plugins（精確）
Agent integration 透過 hook 或 plugin 向 herdr 回報 idle、working、blocked 等 lifecycle 狀態。依 agent 執行 herdr integration install <agent> 安裝對應整合；這類明確回報比畫面推斷可靠。
機制二：Screen Manifest TOML rules（自動但較不精確）
herdr 定期讀取 terminal 底部的 buffer 截圖，用 TOML 規則比對 UI pattern 來推斷狀態。不需要任何設定，zero-config，但準確度低於 lifecycle hooks。blocked 偵測故意設計偏嚴格，避免把正在執行的 agent 誤判為 blocked。
哪些 agent 用哪種機制？
| 支援層級 | 代表 Agent |
|---|---|
| Full lifecycle hooks / plugins（精確） | Pi、OMP、Kimi Code CLI、OpenCode、Kilo Code CLI、MastraCode |
| Screen manifest only（自動，準確度較低） | Claude Code、GitHub Copilot CLI、Codex、Devin CLI、Cursor Agent CLI、Hermes Agent、Droid、Grok CLI、Amp |
| 部分/實驗性 | Gemini CLI、Cline |
Claude Code 目前是 screen manifest only。herdr integration install claude 安裝的 hook 只負責回報 session 身份（讓 herdr 知道哪個 pane 是哪個 Claude Code session），但 blocked/working 等狀態仍然靠 screen manifest 視覺解析。
Screen manifest 對 blocked 的判定刻意較嚴格，以免把仍在執行的 agent 誤判成等待輸入。未被規則辨識的 prompt 可能先顯示為 idle；有時序要求的自動化應採用具 lifecycle integration 的 agent，或讓 agent 明確回報狀態，不應假設所有畫面提示都會立即被辨識。
herdr vs tmux vs Warp vs Zellij，應該用哪個？
在決定工具之前，先問自己一個問題：「我是否需要即時知道每個 AI agent 的執行狀態？」
如果答案是「不需要，我只是需要分割視窗和 session 持久化」，tmux 完全夠用，沒有理由換。如果答案是「需要，我同時跑多個 agent 而且需要知道誰在等我」，那 tmux 無論多熟都無法解決這個問題。
| 功能維度 | herdr | tmux | Zellij | Warp |
|---|---|---|---|---|
| Terminal native（CLI 環境可用） | ✅ | ✅ | ✅ | ❌（GUI app） |
| Session persistence / Detach-reattach | ✅ | ✅ | ✅（部分） | ✅ |
| SSH remote reattach | ✅ | ✅ | ❌ | ❌ |
| Agent state tracking | ✅ | ❌ | ❌ | ❌ |
| Socket / Agent API | ✅ | ❌ | ❌ | ❌ |
| macOS / Linux 支援 | ✅ | ✅ | ✅ | ✅ |
| Windows 支援 | ✅（plugins preview；不可作為 --remote target） | ✅ | ✅ | ✅ |
選擇建議：
- 只需要 terminal 多工 → tmux 或 Zellij 就夠，不需要換
- 同時跑多個 AI agent 且在意狀態可見性 → herdr
- 不想離開 GUI、prefer macOS native 體驗 → Warp（但沒有 agent state tracking）
- 已有 tmux 習慣 → herdr 和 tmux 語法相近（都是 Ctrl+B prefix），遷移成本低
進一步的 AI agent 框架選型思路，可以參考AI Agent 框架怎麼選？LangGraph vs CrewAI vs Google ADK 2026 實戰選型指南。
Socket API：讓 Agent 自己管 Agent
大多數介紹 herdr 的文章聚焦在 state visibility（sidebar 看到 blocked/working），但 Socket API 才是 herdr 最有潛力、也最被低估的能力。
herdr 暴露本地控制介面：Unix 預設 socket 路徑是 ~/.config/herdr/herdr.sock，Windows 則使用 named pipe。多數自動化先用 CLI wrapper 即可；需要直接 request/response 或長連線事件訂閱時，再使用 JSON-RPC。支援的操作包括：
- spawn pane：在指定 tab 建立新 pane
- spawn agent：在新 pane 裡啟動特定 agent
- read pane output：讀取任意 pane 的 terminal 輸出
- subscribe state events：訂閱 agent 狀態變化事件（agent A 進入 done 狀態時觸發）
這讓 herdr 從「多視窗監控板」升級為「agent orchestration layer」。
一個具體的應用場景：Claude Code 完成 collect 任務後，透過 hook 呼叫 socket API 通知 herdr 啟動下一個 Claude Code instance 執行 synthesize。整個流程不需要人工切換，herdr 負責串接。
# 建立 pane，再在該 pane 啟動一個 Codex agent
herdr pane split w1:p1 --direction right
herdr agent start reviewer --kind codex --pane w1:p2
要說清楚的是：Socket API 需要你有基本的 shell scripting 或程式能力，不是點幾個按鍵就能設定的功能。FossEngineer 的實測有展示具體呼叫方式，但端對端的 orchestration workflow 需要自己組裝。對想把 herdr 變成 pipeline 觸發器的開發者，這是最值得深挖的方向。
限制與你應該知道的注意事項
herdr v0.8.2 仍是 pre-1.0 工具。以下限制會直接影響平台選擇與自動化設計：
1. Windows：可當 client，不可當 --remote target（影響：跨平台遠端工作流）
Windows 已支援本機持久 session、ConPTY pane，以及從 Windows client 用 herdr --remote 連到 Linux 或 macOS host；但 Windows 目前不能作為遠端 target host。Windows plugins 仍屬 preview，正式採用前應逐項測試需要的 plugin 與 terminal 組合。
2. pre-1.0 protocol version bump（影響：生產環境 CI/CD）
升級若遇到 protocol 不相容，herdr 會詢問是否停止仍在執行的舊 server。停止 server 也會終止其中的 pane process，因此升級前應先保存工作並安排停機；Unix 平台可另行評估實驗性的 herdr update --handoff，但不應把它當成無中斷保證。
3. Claude Code 是 screen manifest only（影響：仰賴精確 blocked 偵測的用戶）
如同前面說明，Claude Code 的 blocked 狀態靠視覺解析而非 lifecycle 回報。未知 prompt 可能先顯示為 idle，因此不適合直接作為時序敏感自動化的唯一觸發條件。
4. tmux inside herdr pane：agent 偵測失效（影響：既有 tmux 工作流的用戶）
在 herdr pane 內再開 tmux session，herdr 無法 inspect 裡面的內容。Docker/VM 內的 agent 需要額外設定 HERDR_AGENT=<agent> 環境變數。
5. Apache-2.0 授權（影響：修改或散布 herdr 的團隊）
herdr repo 採 Apache License 2.0。此授權允許使用、修改與散布，也允許商業使用；散布時仍須遵守授權與 NOTICE、著作權聲明等要求。若產品包含其他依賴或 plugin，仍要分別檢查其授權。
結論：誰應該現在就裝 herdr？
herdr 解決的問題很具體：多 agent 並行時的 visibility 混亂，而且安裝門檻低。但不是所有人都需要它。
立即值得裝
同時跑 2 個以上 AI coding agent，且需要知道哪個在 blocked 等你輸入的開發者。特別是已有 Claude Code + Codex 並行工作流、或正在建 agent pipeline 的場景，herdr 的 state sidebar 和 Socket API 都有直接價值。
建議觀望
需要把 Windows 當成遠端 target host、依賴仍在 preview 的 Windows plugins，或要把 pre-1.0 工具放入長期 CI/CD 的團隊。先在 staging 試跑並確認升級、重連與回復流程，再決定是否納入正式環境。
暫時不需要
只用單一 AI agent 的開發者，tmux 的 session persistence 已經夠用。或者，對「哪個 agent 在等我」這件事完全不在意、工作流以同步為主的開發者。
要不要試試？最快的方式就是直接裝起來感受一下 sidebar 的差異：
brew install herdr
herdr
官方文件在 herdr.dev/docs，自動化介面以 Socket API 文件為準；串接 pipeline 前，先用 herdr api schema 讀取目前安裝版本隨附的協定 schema。
FAQ
herdr 怎麼安裝？
Mac 用 `brew install herdr`，Linux 或通用平台用 `curl -fsSL https://herdr.dev/install.sh | sh`，也可用 `cargo install herdr` 從原始碼建置，或透過 mise 安裝。
herdr 需要付費嗎？
herdr 目前以 Apache License 2.0 開源，可依授權條款使用、修改與散布。若要把它納入商業產品，仍應保留授權與著作權聲明並檢查自身散布方式。
herdr 跟 tmux 可以一起用嗎？
可以共存，但要注意：在 herdr pane 內再開 tmux session，herdr 的 agent 狀態偵測會失效。建議直接在 herdr pane 裡執行 agent，讓 herdr 負責多工和狀態追蹤。
herdr 支援 Windows 嗎？
支援 Windows 本機持久 session、ConPTY pane，以及從 Windows 用 `herdr --remote` 連線到 Linux 或 macOS 主機；但 Windows 目前不能作為 `--remote` 的目標主機，plugins 仍屬 preview。
herdr 目前穩定嗎？
截至 2026 年 8 月 23 日，官方最新穩定版為 v0.8.2。它仍是 pre-1.0 工具；日常使用前先確認需要的 agent integration、平台功能與升級流程，正式工作流則應先在可回復的環境測試。
這篇文章對你有幫助嗎？
