[AI 分享] 用 Herder 管理多個 Coding Agent
摘要 : Herder 以狀態感知、終端持久化與 CLI,降低多 Agent 開發的切換成本。
內容:
現在寫程式時,最廉價的擴充資源就是 Agent:開一個 Codex 修改頁面,再啟動另一個做 Code Review,旁邊同時掛著開發與測試服務。帳面上的吞吐量看似拉滿了,人的注意力卻先爆了顯示記憶體。
你得在不同終端之間輪流查看:誰還在執行、誰卡在授權、誰早已完成?視窗一多,名稱很快就失去辨識作用。傳統終端只能顯示字元與日誌,無法理解其中的 Agent 究竟處於什麼狀態,因此大家只能手動巡查。
每次切換可能只花幾秒,累積起來卻會消耗大量心力,真正被破壞的是思考的連續性。Herder 想消除的,正是這筆隱形的排程成本。
為 Coding Agent 重新設計的 tmux
你可以把 Herder 理解成一套為 Coding Agent 重新設計的 tmux。它保留真正的偽終端窗格與持久化工作畫面,同時能辨識窗格裡執行的 Agent。
接入之後,Codex、Claude Code 等工具仍維持原生介面,測試腳本也能照常執行。若說 tmux、Zellij 擅長管理終端與版面,圖形化平台適合處理審批流程及環境隔離,那麼 Herder 剛好位於兩者之間,替終端補上 Agent 狀態感知、CLI 控制及本地 API。
整套程式只是一個 Rust 二進位檔,不強制建立帳號,沒有雲端控制面板,也不收集惱人的遙測資料。它沒有試圖吞下整套開發流程,而是專注於管理終端與 Agent。
Herder 的五層核心模型
Herder 的核心模型可分為五個物件:
Session
管理整套執行環境。日常使用一個預設 Session 通常就足夠,需要隔離時再建立具名 Session。
Workspace
通常對應一個程式碼倉庫,用來組織不同專案。
Tab
類似瀏覽器分頁,代表專案裡的特定工作視角。可以將 Agent、開發服務及測試工作分開。
Pane
真正的偽終端,可以執行任意命令。
Agent
在 Pane 中被 Herder 辨識出的 Coding Agent 程序。
測試腳本只算 Pane;Codex 則同時是 Pane 與 Agent。Pane 負責字元流,Agent 負責生命週期。底層狀態會一路向上彙整至 Tab 與 Workspace,因此即使同時開啟許多專案,也能快速找到卡住的節點。
程序、版面與對話是三種持久化
從架構來看,Herder 採用典型的 Client-Server 模式。伺服器掌握 PTY 程序與視窗版面,客戶端則負責顯示畫面及傳遞輸入。
正常 Detach 時,關閉的只有客戶端,背景中的 Agent、測試與開發服務都會繼續執行,也能讓多個客戶端連入同一個工作畫面。
但必須注意,伺服器才是狀態的唯一來源。Herder 伺服器一旦停止,其管理的程序也會終止。再次啟動時,雖然可以恢復目錄、版面與焦點,原本的程序卻無法復活。
官方整合可以保存 Agent 原生的 Session ID,協助接回對話,但無法讓已終止的建置程序重新執行。實驗性的 Pane History 也只是保存螢幕文字的緩衝區。
因此,不能把「持續執行」理解成所有狀態都會永久保存。程序、版面與對話的持久化是三件不同的事。
真正節省時間的是狀態追蹤
Herder 側邊欄會追蹤幾種主要狀態:
Working:Agent 正在執行工作。
Blocked:Agent 卡住,正在等待授權或使用者輸入。
Done:Agent 已在背景完成,但使用者還沒切過去查看,類似未讀訊息。
Idle:Agent 目前閒置,或完成結果已被查看。
Unknown:系統無法確定狀態,不能視為成功或失敗。
這些狀態會向上聚合。即使某個 Workspace 被放在背景,只要裡面出現 Blocked 狀態,Workspace 層級也會亮起提醒。
這才是關鍵:讓人的注意力跟著事件移動,而不是每隔幾分鐘手動巡查一次。
Herder 如何偵測 Agent 狀態
Herder 會先取得 Pane 的前景程序。遇到支援的 Agent 時,還會掃描終端底部畫面,透過 Screen Manifest 比對已知的 UI 特徵。
這種方式不要求每項工具都主動提供整合介面,因此 Codex、Claude Code 與 OpenCode 等工具可以低成本接入。不過,這種做法也有代價:如果 Agent 修改了提示介面,舊規則可能立即失效;若在 Herder 裡再套一層 tmux,也可能干擾前景程序的判斷。
官方整合則能利用原生 Session ID 補強辨識。遇到誤判時,可以執行:
herder agent explain
藉此查看究竟是哪一條規則命中。面對 Unknown 狀態時,不應盲信自動化,直接切到現場確認通常最可靠。
本機與遠端開發
安裝 Herder 後,在專案根目錄執行 herder,即可啟動預設工作畫面。使用者可以用滑鼠切換窗格及調整大小;習慣鍵盤操作的人,也能使用類似 tmux 的前綴鍵,不需要重新背誦大量快捷鍵。
遠端開發可直接使用原生 SSH。程式碼與 Herder 伺服器都留在遠端,即使 SSH 中斷,背景任務仍會繼續。網路恢復並重新連線後,原本的 Pane 仍會留在原位。
Herder 也針對窄螢幕做了調整,臨時使用手機終端查看部署結果或點選確認相當方便。若需要桌面端能力,也能在本機執行 Herder 客戶端連至遠端,甚至可將本機剪貼簿中的圖片傳入遠端工作畫面。
建議的 Workspace 配置
實務上,可以讓每個活躍倉庫使用獨立 Workspace,再依職責劃分 Tab:
Agent:程式碼生成與 Code Review。
Dev:執行熱更新開發伺服器。
Checks:編譯、靜態檢查與單元測試。
Deploy:監看發布流程。
切換 Workspace 時,目錄、Pane 與 Agent 狀態會一起切換,才能做到接近無損的上下文切換。
不要把所有程序都硬塞給 Agent 管理。基礎服務、測試與日誌最好獨立執行。Agent 完成後可以關閉,但開發環境仍要保留以便除錯;程式碼出錯時,到 Checks 查看錯誤,再到 Dev 重新整理頁面,各項工作互不干擾。
穩定的基礎目錄與版面配置,通常比背下大量快捷鍵更有價值。
雙 Agent 的高效陣型
一種典型配置是在同一個工作環境裡放兩個 Agent:
Builder:負責修改程式碼。
Reviewer:使用唯讀模式檢查 Diff。
旁邊另外執行開發伺服器與測試輸出。
Builder 完成修改後,Reviewer 直接接手檢查差異。如果 Reviewer 進入 Blocked,通常代表工作已到達需要人類判斷的系統邊界,此時再由人介入。
審查任務必須嚴格限制檔案範圍、測試腳本及寫入權限,否則一旦出問題,很難釐清責任。
Herder 不負責檔案隔離
必須注意,Workspace 只負責邏輯組織,不提供檔案隔離。兩個 Pane 如果指向同一目錄,仍然可能同時讀寫並產生衝突。
遇到大型需求時,應使用不同 Git 分支或 git worktree。Agent 之間的交接也應透過 Commit 或 Patch 完成。
Herder 提供的是執行容器與工作視角,Git 管理的是變更記錄,而最終驗收仍然必須由人負責。
CLI 才是真正的控制介面
不要只注意圖形介面,CLI 才是 Herder 控制面的真正入口:
layout:一次建立 Workspace、Tab 與 Pane。
pane:管理測試、服務與一般終端程序。
agent:啟動 Agent、傳遞 Prompt 並等待生命週期狀態。
透過腳本建立物件時,CLI 會回傳 JSON。應保存並使用其中穩定的 ID 操作,不要猜測新 Pane 的編號,也不要對目前焦點盲目發送命令。
利用這套能力,可以建立外部協調器:動態啟動 Reviewer、分派受限任務,再等待 Idle、Done 或 Blocked 等語義狀態。普通腳本若沒有 Agent 狀態,也能使用 Pane 的輸出等待功能捕捉關鍵字。
只要能等待語義狀態,就不要在腳本裡寫死 sleep 30。依靠固定時間猜測工作是否完成的流程非常脆弱,只要執行速度稍有變化,整條自動化管線就可能失效。