OpenAgents：把散落在各台機器上的 agent 收進同一個 workspace

多台機器、多個 runtime，卻沒有一個共同的對話串

README 開頭把痛點寫得很具體：一個 agent 在伺服器上顧資料庫，另一個在 Discord 上回使用者，還有幾個分別在不同終端機、不同機器上開發不同專案。你沒有單一位置能看到全部，也沒有辦法讓它們一起工作。當使用者回報 bug，你想讓行銷 bot 先從對方身上問到細節，再把 infra agent 拉進同一條對話去查 log，而今天的做法是在終端機之間複製貼上、SSH 進不同機器、手動把上下文縫起來。

這個描述對應到一類特定的使用者：手上已經有多個 CLI agent（不是只有一個聊天視窗），而且這些 agent 分散在本地與雲端。OpenAgents 的目標客群是這種人，不是第一次接觸 LLM 的一般使用者。它給的兩個核心主張是統一 workspace 與 agent 之間的協作，並強調開源、Apache 2.0、不需要帳號。

workspace 作為 hub：共享的是執行緒、檔案與瀏覽器

README 把 workspace 比喻成「給 agent 用的 Slack」，這個比喻抓住了架構重點：workspace 是一個持續存在的 hub，agent 連上去之後共享同一批 threads、files 與 browser。每個 workspace 有一個像 workspace.openagents.org/abc123 的固定位址，可以加書籤、分享、隨時回來。

共享瀏覽器與共享檔案是兩個比較少見的設計決定。前者讓 agent 能開頁面、點元素、截圖、填表單，而且同一個 workspace 裡的人與 agent 都看得到；後者讓 agent 把程式碼、文件、報告上傳到 workspace，任何 agent 或人都能讀、改、下載。這意味著協作的媒介不是訊息傳遞，而是共用狀態：agent 不需要互相呼叫 API，只要把產物放進同一塊空間。README 也提到 tunnels，用一個指令把本地 dev server 曝露成公開 URL，方便從任何裝置預覽 agent 的產出。

架構圖與截圖放在 docs/assets/images 底下，README 只給了圖，沒有在文字裡描述內部通訊協定或資料儲存方式。這部分無法從現有材料確認。

agn：create、env、connect、up 四個指令撐起安裝流程

安裝走一行腳本。macOS 與 Linux 用 curl -fsSL https://openagents.org/install.sh | bash，Windows 用 irm https://openagents.org/install.ps1 | iex。裝完之後的入口是 launcher，指令名為 agn，不帶參數執行會打開互動式 dashboard，用來安裝 runtime、設定 API key、連接 workspace，並讓 agent 以背景 daemon 的形式持續執行。

README 給的指令順序是：agn create <name> --type <type> --install 建立 agent 並安裝 runtime；agn connect <name> <workspace-token> 把 agent 接進 workspace；agn env <type> --set LLM_API_KEY=sk-... 設定憑證；agn up 啟動 daemon。這裡有一個容易踩到的細節，README 明確寫了：agn create 只會寫入 agent 設定，不會順便裝 runtime。你要嘛先跑 agn install <type>，要嘛在建立時加上 --install，否則 agent 建好了卻跑不起來。

不想用 CLI 的人可以下載桌面版 launcher，官網提供 macOS、Windows 與 Linux AppImage 三種下載連結。launcher 的版本節奏可以從 release 看出來：launcher-v0.9.25 與 launcher-v0.9.26 都落在 2026-08-31，launcher-v0.9.27 在 2026-09-06，六天內三個版本，這個頻率對照著「先確認你裝的是哪一版」這件事是有意義的。

支援清單裡有三種成熟度，不要一律當成可用

README 的支援表把 agent 分成幾個層級，這個分層比表格本身更重要。標為 Supported 的有 OpenClaw、Claude Code、Codex CLI、Hermes Agent、Cursor、OpenCode、GitHub Copilot CLI、Gemini CLI 與 Amp，其中 Amp 註明是 CLI execute mode。Cline 標為 Supported (Beta)。DeepSeek Harness 是 Preview，走 headless 模式，而且文件寫明是 pinned to a preview release。Aider 與 Goose 都是 Beta。

Aider 的說明值得單獨看。README 說完整離線測試套件（provider resolution、sessions、Git safety、install detection）通過，但對真實模型 provider 的端到端執行還沒有完成，並直接寫「Launcher create/connect flow is available so you can run that verification yourself」。這句話等於把驗證責任交回使用者手上。如果你打算把 Aider 放進正式流程，先自己跑一次真實 provider 的端到端，不要只看表格上的勾。

Goose 同樣是 Beta，走 CLI 與 headless。DeepSeek Harness 是 Preview 且綁定特定 preview release，這代表升級時可能遇到上游變動。把這三類 agent 混進同一個 workspace 並非不行，但你得接受它們的行為可能與 Supported 那批不一致。

hub 模型的代價：中心化與 token 邊界

OpenAgents 的設計把協作放在一個持續存在的 workspace 上，這換來的是可見性與共享狀態，代價是中心化。agent 要出現在同一個 workspace，就得連上那個 workspace 位址，而 workspace 由 openagents.org 提供。README 強調開源、Apache 2.0、沒有 vendor lock-in、不強制註冊帳號，但「不強制帳號」不等於「不經過伺服器」。共享檔案與共享瀏覽器的畫面要讓所有成員看到，就必須有一個共同的落點。

這對某些情境是硬限制。如果 agent 處理的是不能離開內網的程式碼或資料，把產物上傳到 workspace 再讓其他 agent 讀取，這條路徑本身就需要先確認。另一種不適合的情況是單一 agent 的使用者：你只有一個 Claude Code，沒有第二個 agent 要拉進對話，那 workspace 帶來的共享 threads 與共享瀏覽器幾乎沒有用處，反而多了一層要維護的連線與 daemon。

還有一個操作面的限制寫在 create 指令的行為裡：create 與 install 是分開的步驟。這在批次建立多個 agent 時會讓流程變長，你得自己記得補上 --install，或先跑一次 agn install <type>。

跟 tmux 加 SSH 的手動流程差在哪裡

README 描述的現況做法，本質上就是 tmux 加 SSH 加複製貼上：每個 agent 在自己的終端機裡跑，跨機器靠 SSH，跨 agent 的上下文靠人手搬。這個做法沒有額外依賴，也不需要把任何東西送到外部服務，對單機、單 agent 或高度敏感的工作負載來說仍然是合理的選擇。

差別在共享狀態。tmux 工作階段裡的兩個 agent 看不見彼此的檔案，也不會自動出現在同一條對話裡；你要把 infra agent 拉進行銷 bot 正在處理的那條對話，只能自己把內容貼過去。OpenAgents 把這件事變成 workspace 層級的能力：agent 在同一個 workspace 裡看得到彼此的工作，可以用 @mentions 指派任務，也可以讓 agent 自己接手。共享瀏覽器與共享檔案則是 tmux 完全沒有的東西，因為 tmux 只共享終端機畫面。

反過來說，tmux 不需要 workspace token，不需要 daemon，也沒有 runtime 支援清單這種東西，任何能在終端機跑的東西都能用。OpenAgents 換來協作能力，同時引入一份必須維護的支援矩陣。這個交換值不值得，取決於你實際有幾個 agent 需要互相看見。

授權、版本節奏與升級成本

授權是 Apache-2.0，README 與 badge 都這樣標示。Apache-2.0 允許商用與修改，並包含專利授權條款，但這裡不提供法律意見；如果你的組織對開源授權有既定流程，照流程走。README 提到 no vendor lock-in，這與 Apache-2.0 的組合意味著程式碼層面你可以自己 fork 或自架，但 workspace 服務本身的可自架程度，材料裡沒有說明，這是採用前應該先查清楚的一點。

升級成本主要來自 launcher 的釋出頻率與 agent 支援狀態。從 release 清單看，launcher-v0.9.25 到 launcher-v0.9.27 集中在 2026-08-31 到 2026-09-06 之間，屬於 0.9.x 的快速迭代期，代表介面或行為還可能變動。agent 端則有 pinned to a preview release 這種情況（DeepSeek Harness），上游一動你就得跟著動。

實務上的做法是把 launcher 版本與 agent runtime 版本一起記錄下來，因為兩邊都會動。agn 本身是 daemon 模式，agn up 之後 agent 在背景持續執行，這表示升級不是重開一個終端機那麼簡單，你得先停掉 daemon、更新、再起回來。這條流程 README 沒有逐步寫出來，需要自己驗證。

誰該採用，以及動手前先確認什麼

OpenAgents 的適用範圍相當明確：你已經有多個不同 runtime 的 CLI agent，它們分散在本地與遠端，而且你需要它們在同一條對話裡看到彼此的檔案與輸出。這種情況下，agn create 加 --install 建 agent、agn env 設 LLM_API_KEY、agn connect 接進 workspace、agn up 起 daemon，是一條比手動 SSH 加複製貼上更短的路徑。桌面版 launcher 對不想待在終端機的人也是現成選項。

不該採用的情況同樣清楚。只有一個 agent 的人不需要 hub。不能把 agent 工作內容送到外部 workspace 的團隊，得先確認 workspace 是否可自架，而材料裡沒有這方面的說明。想用 Beta 或 Preview 階段 runtime（Aider、Goose、DeepSeek Harness、Cline）的人，要接受 README 自己寫的「real provider E2E pending」，也就是驗證責任在你身上。

動手前先確認三件事：第一，你要用的 runtime 在支援表上是 Supported、Beta 還是 Preview，Beta 與 Preview 的行為不保證與 Supported 一致；第二，workspace token 的權限範圍，因為 agn connect 就是拿這組 token 把 agent 接進去；第三，workspace 上的共享檔案與瀏覽器狀態實際落在哪裡。這三點確認完，再決定要不要把日常的 agent 工作流搬進去。

編輯結論

如果你手上同時跑著兩三個不同 runtime 的 coding agent，而且需要它們在同一個對話串裡看到彼此的檔案與輸出，OpenAgents 值得先在自己的機器上試一輪：用 curl 安裝、agn create 加 --install 建一個 agent、agn env 設好 LLM_API_KEY、再 agn connect 接進 workspace。如果你只需要單一 agent，或你的團隊不能把 agent 的工作內容送到外部 workspace URL，這套 hub 模型就不適合。動手前先確認三件事：你要用的 runtime 在支援表上是 Supported 還是 Beta 或 Preview、workspace token 的權限範圍、以及 workspace 上的檔案是否會經過 openagents.org 的伺服器。

官方來源

1. License: Apache-2.0
2. openagents-org/openagents on GitHub
3. Project website
4. README
5. Releases