所有頂尖廠商的 Agent，
一個客戶端，各自沙箱。

兩者都給你一個 shell，但都不給你一個活得下去的 session。exec 進行中關掉終端，程序就跟著連線一起死。這裡的 session 活在容器裡，關掉 app 只是關掉一條 WebSocket，其他什麼都沒發生 —— 下次啟動從輸出中斷的那個位元組接回來，並還原同一個分割版面。部署模型也不同:客戶端上沒有 kubeconfig、不需要 port-forward，而且憑證授權的是一個 session，不是你的整個叢集。此外你要的往往不是「一個 shell」，而是「那個運行環境」裡的 shell —— 同一個映像、同一個 workspace、同一批檔案，不是在筆電上重現一次。

Herdr 是 agent multiplexer —— coding agent 版的 tmux。它給每個 agent 一個真實 PTY、斷線後仍活著、把每個窗格分類成 working／blocked／idle，還有 CLI 和 socket API。持久性和艦隊視圖這兩點和這個 app 幾乎完全重疊。不同的是 agent 跑在哪裡:

• Herdr 把它們跑在你叫它的那台機器上，共用你的使用者、你的檔案系統、你的憑證 —— 風險與爆炸半徑就是那台機器，以及你的帳號碰得到的一切。它的持久性是針對斷線而非主機關機，所以跑在筆電上時，筆電關了就什麼都沒了。（SSH 遠端模式可以避開這點，代價是爆炸半徑換成那台遠端主機。）
• OpenAB Connect 每個 session 是你叢集裡自己的容器 —— uid 1000、沒有 sudo、沒有主機憑證、根檔案系統唯讀、workspace 用完即棄 —— 經 WireGuard tailnet 連上，不開任何連接埠。爆炸半徑就是那個容器，而不是你的機器;你的筆電關了、睡了、換了一台，它都還在跑。

分野是沙箱化，不是多工。Herdr 也做得到一些 OpenAB Connect 做不到的事:窗格狀態判定、可腳本化的本機 API，以及完全不需要任何基礎架構。如果你希望什麼都不用部署，Herdr 是更好的答案。

在你 Mac 上的 agent 是以你的身分執行的。它碰得到你的 SSH 金鑰、你的雲端憑證、你的 npm 和 GitHub token，以及磁碟上每一個 repository —— 所以一個下錯的指令，是在你的機器上下錯。這裡的 shell 什麼都沒有，workspace 隨 session 一起丟掉，而且好幾個 agent 可以同時工作而不必爭同一個 working tree 或同一組連接埠。你的筆電也可以睡眠或闔上，什麼都不會停。代價是真的:agent 看不到你本機的檔案，工作要透過 git 送過去;某個映像第一次拉取要幾分鐘;而且你需要一個叢集或一個 AWS 帳號。如果只是在一個已經開著的 repo 裡改一行，在本機跑更簡單，這個東西沒有任何幫助。

兩者是刻意互補的兩種模式，差別在你在意什麼:

• OpenAB 仲介 ACP —— 你從聊天客戶端下指令，在意的是 agent 交付的結果，而不是它怎麼做到的。你是下指令的人，session 是一問一答的回合制。
• openab-pty 走 PTY —— 完整的可觀察性，原生終端體驗。你在意的是現在正在發生什麼，即時觀看、檢視、動手。你是坐在鍵盤前的操作者，session 是無界的位元組流。

互補是結構上的，不是比喻:PTY 的映像是 FROM ghcr.io/openabdev/openab，所以 shell 開在和 agent 同一個映像裡，同一個 CLI、同一個 workspace。agent 把事情做到一半，你就地接上去看。兩者互不依賴，session 模型也刻意不共用 —— 位元組流的存活由位元組和 socket 定義，不是由回合定義。

完整說明在 openab-pty 的 設計文件。而 OpenAB Connect 是 openab-pty 客戶端契約的第一個客戶端實作 —— 契約是公開的，任何能持有憑證並講 WebSocket 的東西都可以是下一個。

刻意很少。它以 uid 1000 開啟，沒有 sudo、沒有 service-account token、沒有主機憑證，根檔案系統唯讀，workspace 用完即棄。session 的 shell 可以經 loopback 連到 runtime —— 這正是管理憑證從不放進容器的原因:attach token 只授權一個 session，而且會過期。

不需要。runtime 綁在 127.0.0.1，本身不持有 TLS 金鑰。同一個 pod 裡的 Tailscale sidecar 是唯一擁有網路身分的東西，兩者在 pod 的網路命名空間內經 loopback 通訊。流量走 WireGuard tailnet 到你手上，加密由它承擔。

什麼都沒有。這裡沒有任何服務 —— app 連上的每一台伺服器都是你自己部署的，在你自己的叢集或你自己的 AWS 帳號裡。不需要帳號、不需要註冊、沒有分析、沒有遙測。你輸入的憑證留在 macOS Keychain，除了你自己的 runtime 之外不會送到任何地方。

可以。runtime 是 MIT 授權的 openabdev/openab-pty，而且 客戶端契約是公開的，所以你可以不用這個 app、自己寫一個客戶端。這個 app 只是那份契約的一種實作，它不是開源的。

可以。應用程式選單裡的 Demo Mode 會跑兩個範例連線和一個預錄的終端，完全不建立任何網路連線。它的存在就是為了讓你在部署任何東西之前先評估這個 app。

你點三下，然後是八個步驟:產生憑證存進你的 Keychain、確認 namespace、建立 secret 與儲存、套用 pod，然後 app 等它就緒、等它加入你的 tailnet、驗證管理端。不必寫 manifest。某個映像第一次部署可能要幾分鐘,因為叢集正在拉取它。

workspace 會被丟掉，這部分是確定的:它只存在於那個 session，刪除就沒了。

不確定的是程序。刪除 session 時，runtime 會終止這個 session 的 process group，但一個刻意脫離那個 group 的程序 —— 例如用 nohup 或 setsid 啟動的背景工作 —— 可能活下來，直到那個 pod 或 task 被替換。它仍然關在同一個沙箱裡，不會因此碰到任何新的東西，但它會繼續佔用那個 pod 的 CPU 和記憶體。

所以這件事在 app 裡標示為 best-effort，而不是聲稱乾淨結束。要確定什麼都不剩，刪掉那個 pod 或 task。

還不行 —— 這正在開發中。今天每個 session 是獨立的:你對每個 agent 下指令，它們不會互相委派工作。

設計已經公開。它基於 OpenAB 的 Agent Control Plane ADR —— 一個 hub-and-spoke 的註冊與路由服務，讓 agent 直接經 ACP over WebSocket 互相委派，而不是繞道聊天平台(那會撞上速率限制、延遲，以及把編排噪音倒進人看的頻道裡)。裡面有三個部分:Registry 記錄誰活著與它的標籤、Router 按名稱／標籤／namespace 轉送、Policy 管委派深度、環路、namespace 與 allowlist。

其中一個決定和這個 app 的模型剛好一致:agent 是向外撥出連到控制平面的，所以跨網路運作不需要在任何一端開入向連接埠。

ADR 已經合併，實作還沒出貨。歡迎一起做 —— 那份文件就是討論的起點。