大多數代理工具仍圍繞單一對話建構：一個代理、一個任務、一個終端機、單一流需要照看。適合小任務，但不適合真正的工程工作。
Herdr 的有趣之處在於，它將這種模式視為工作的預設形式。
最簡單的描述是：Herdr 是 coding agents 的 tmux。更精確地說，它是一個在你現有終端機內執行的代理多工器。它為每個代理提供真正的 PTY，保持工作所在的程序持續運作，顯示代理狀態，並提供 CLI 及本機 socket API。
這個差異很重要。Herdr 不是另一個桌面代理應用程式。它是一個在程式碼與終端機所在位置執行的二進位檔：伺服器、Mac Mini、VM、或你桌子下的開發機。關閉筆電、斷開連線、稍後透過 ssh 重新連線、重新附加，甚至從手機操作。工作不會因為終端機視窗關閉而消失。
吞吐量問題
編碼代理改變了開始工作的成本。我可以要求一個代理探索錯誤，另一個撰寫失敗的測試，另一個起草遷移計畫。瓶頸在於監督。
問題是，一般終端機並不理解監督。tmux 與 Zellij 提供持久性與窗格，但它們不知道代理是卡住、工作中、已完成、閒置，還是三個畫面之前印出問題後就靜靜地坐在那裡。桌面應用程式通常更了解代理狀態，但工作流程就會被綁在有 GUI 的機器上。工作樹編排器可以協調平行任務，但它們通常想要擁有整個工作流程。
Herdr 處在一個有用的中間位置：終端機模型，加上代理感知。
效能倍增不是魔法。它來自四個實際特性：
- 多個代理在真實的 PTY 中執行，每個都有自己的 shell、日誌、提示與程序狀態。
- Herdr 彙整語意狀態，讓你可以看到哪些代理卡住、工作中、已完成或閒置。
- 伺服器擁有窗格，因此工作階段能存續於客戶端斷線、筆電睡眠與終端機死亡之後。
- CLI 與 socket API 允許腳本或代理直接控制多工器。
第四點是我最在意的。人類監督三個窗格是有用的。一個代理能夠啟動輔助代理、讀取輸出、等待狀態轉換，並整合結果，才是複合效應開始的地方。
Herdr 的文件對此有明確說明。socket API 可以管理工作區、標籤、窗格與代理。建議的路徑是先使用 CLI 包裝器，然後再用原始 socket API 進行直接請求回應控制或訂閱。還有一個代理技能檔，由 HERDR_ENV=1 守護，教導代理如何在窗格內使用 Herdr。
具體工作流程
想像一位資深工程師在監督重構：替換內部客戶端、調整測試，並檢查部署。我會將它拆分。
一位主管負責規劃與審查。它建立三個窗格：
herdr
進入全螢幕模式 退出全螢幕模式
在 Herdr 內部，它可以分割窗格並啟動代理：
split=$(herdr pane split --current --direction right --no-focus)
api_pane=$(printf '%s\n' "$split" | jq -r '.result.pane.pane_id')
herdr agent start api-change --kind codex --pane "$api_pane"
herdr agent prompt api-change "Replace the legacy client in the API layer. Keep the diff minimal."
進入全螢幕模式 退出全螢幕模式
然後它啟動另外兩個代理：
test_split=$(herdr pane split --current --direction down --no-focus)
test_pane=$(printf '%s\n' "$test_split" | jq -r '.result.pane.pane_id')
herdr agent start tests --kind codex --pane "$test_pane"
herdr agent prompt tests "Add or update tests for the new client behavior."
deploy_pane=$(herdr pane split --current --direction right --no-focus | jq -r '.result.pane.pane_id')
herdr agent start deploy-review --kind codex --pane "$deploy_pane"
herdr agent prompt deploy-review "Review config, deploy scripts, and rollback implications."
進入全螢幕模式 退出全螢幕模式
主管等待狀態而非輪詢終端機：
herdr agent wait api-change --until blocked --timeout 120000
herdr agent read api-change --source recent-unwrapped --lines 80
進入全螢幕模式 退出全螢幕模式
或是針對一般程序輸出：
herdr pane run w1:p3 "just test --watch"
herdr pane wait-output w1:p3 --regex "passed|failed" --timeout 120000
進入全螢幕模式 退出全螢幕模式
人類則提升到更高層級：審查差異、回應卡住的代理、拒絕不好的方法、判斷測試，並在進入生產環境前阻止災難範圍。
平行處理加上零上下文遺失
僅有平行處理是不夠的。開啟五個終端機很容易，但在午餐後仍能理解它們才是困難的部分。
Herdr 的運作原理，是結合平行執行與持久性及狀態。如果代理卡住，該狀態是可見的。如果另一個代理在你審查第一個代理時完成，它會被標記為已完成，直到檢查為止。如果 ssh 中斷，伺服器仍擁有窗格與程序。
沒有持久性，每增加一個代理就會增加額外負擔。有了持久窗格與狀態，額外負擔就會下降。你可以為每個倉庫、假設或策略執行一個代理，只在需要時才注意。
比較與權衡
Herdr 在心智模型上最接近 tmux 或 Zellij。它提供持久窗格與遠端重新附加，但增加了代理狀態與代理形狀的控制介面。如果你已經使用 tmux，你就是在為那一層採用一個較新的工具。
與桌面代理應用程式相比，Herdr 較不精緻，但更誠實地反映工程工作的發生地點。工作機器上的終端機多工器能存續於筆電關閉之後。
與工作樹編排器相比，Herdr 較不主觀。如果你想要一個擁有任務指派、工作樹生命週期、審查流程與合併政策的產品，請使用編排器。如果你想要一個靈活的執行環境，讓代理、shell、測試監視器、日誌與主管腳本共存，Herdr 是更好的形式。
存在真正的風險。平行代理意味著平行的災難範圍。如果你以廣泛的繞過權限執行代理，它們可能同時進行錯誤的編輯。你仍然需要 git 紀律、小型提示、隔離的工作樹、差異審查與測試優先的檢查。
我最強烈推薦給有經驗的工程師。任何人都可以開啟幾個窗格，但 API 會獎勵那些知道如何分割工作、定義界限、審查補丁並注意可疑變更的人。
我的看法
當前的編碼代理世代不僅受限於模型品質。它也受限於執行時的人體工學。
單一聊天代理工作流程讓每個任務都感覺是線性的。真正的工程工作是調查、測試、審查、失敗嘗試、日誌與決策的圖形。Herdr 的賭注是，正確的介面不是更漂亮的聊天視窗。而是一個具備持久性、狀態與 API 的終端機原生執行環境。
Herdr 不會取代判斷、程式碼審查或品味。它不會讓每位工程師預設快三倍。但對於已經大力推動代理的工程師來說，它能讓多個工作流保持活躍、可見且可控，而不失去上下文。
這就是吞吐量的來源。不是假裝一個代理就是一個團隊。而是給一位工程師一個合理的控制介面來管理許多代理，然後有足夠的紀律去使用它。
0 Comments
Log in to join the conversation.No comments yet. Be the first to share your thoughts.