Brigade：把多代理團隊裝進 ~/.brigade 的自治執行環境

Brigade 想解的是單一聊天視窗裝不下的問題

多數人用 LLM 的方式是一個對話框從頭問到尾。專案變複雜之後，這個模式會出現兩個具體毛病：不同任務的上下文互相污染，以及每次開新對話就忘光前面累積的事實。Brigade 的定位是把這件事拆開，讓多個代理各自有工作區與憑證，再靠一套組織圖決定誰能把工作交給誰。README 的說法是「one owner, a whole crew」，一個擁有者對上一整組代理。

目標讀者寫得很清楚：已經在用 Claude Code 或 Codex CLI 的人。README 提到，如果你已經登入這兩個 CLI，可以直接沿用該登入狀態，不必再開瀏覽器重新授權。這代表 Brigade 假設你手上已經有模型訂閱或 API key，它不負責提供模型，只負責調度。

它同時把手機端算進來，終端機之外還能從 WhatsApp、Telegram、Slack、Discord、iMessage 與 BlueBubbles 接觸同一組代理，README 甚至列到手錶、Meta 智慧眼鏡與 Meta Quest。這些通道是否全部可用，取決於你願不願意把代理接上真實的通訊帳號，這一點後面會再談。

org chart 加上 Tideline：Brigade 的兩層協作機制

Brigade 的架構可以拆成兩個獨立但互相依賴的層次。第一層是代理之間的關係：README 描述代理有各自的 persona、憑證與記憶，並被接進一張 org chart，由這張圖決定誰能指揮誰。第二層是記憶：所有代理共用一套名為 Tideline 的長期記憶引擎，README 給的關鍵字是 origin scoping、decay 與 hybrid recall，也就是關鍵字檢索與向量檢索混用。

兩層分開看都很常見，合起來才是 Brigade 的特徵。org chart 決定任務往哪裡流，Tideline 決定知識往哪裡沉澱。README 的說法是「what one agent learns, the rest can use」，一個代理學到的東西其他代理能用。這在實務上意味著記憶的寫入時機與範圍需要設計，否則某個代理在特定專案裡學到的偏好，會滲進其他代理的判斷。origin scoping 這個機制顯然就是為了處理這件事，但 README 沒有展開它實際的粒度，這一點在採用前值得先確認。

另一條支線是模型切換。README 說代理可以在任務中途換模型而不失去脈絡。對照它支援 Claude、GPT、Gemini、Llama 與本地 Ollama 的清單，這個能力對成本控制有實際意義：便宜的前段處理用一個模型，關鍵推理換另一個。README 沒有交代切換時上下文如何轉換，如果你要靠這個功能省錢，得自己先量測。

安裝只有兩行，但 ~/.brigade 是唯一的所有權邊界

官方安裝路徑是 macOS 與 Linux 上的一行 shell 指令，README 標註它會視需要安裝 Node，且不需要 sudo：

curl -fsSL https://brigade.spinabot.com/install.sh | sh brigade

執行 brigade 之後進入的是終端機聊天介面。README 把這個介面形容為 flicker-free TUI，並且明確說不走瀏覽器、不用 Electron。所有狀態放在 ~/.brigade/ 之下，README 的說法是「all under one ~/.brigade/ directory you fully own」。

這個設計的優點是備份與遷移都只有一個目錄，缺點也一樣明顯：所有代理的憑證與記憶混在同一個路徑底下。README 提到代理有「自己的」憑證，但沒有說明這些憑證在檔案系統上如何分隔。如果你打算在同一台機器上跑多個獨立用途的代理團隊，或是讓不同人共用一台主機，這個單目錄模型會成為你要自己解決的問題。

儲存後端有兩種模式。預設是小型檔案系統安裝，README 說想換成單一資料庫時可以切到自架 Convex。這是一個需要事先決定的岔路，因為它影響的是資料落地方式，不是安裝完再改的設定。

brigade expose 與 bloody benchmark：對外開放的那條路

Brigade 有一個把本地代理推到公開網路的子命令。README 給了三個形式：brigade bloody benchmark、brigade expose、brigade expose stop。前者是同一件事的戲謔名稱，README 說它「also answers to the buttoned-up brigade expose」，兩個名字指向同一個功能。

機制是 HTTPS 邊緣加上一條隧道，預設走 Cloudflare，也可以自備中繼，README 列出 bore、frp、sish 三個開源選項。README 說不需要帳號、不需要設定，並且有一個密鑰會隱形地隨行，闖入者會在 401 上被擋下。

這裡有兩個需要讀者自行判斷的地方。第一，README 把這個功能包裝成「把你的代理丟到開放網路上讓陌生人半夜戳」，語氣是刻意的。但實際上這是一條對外暴露的通道，代理一旦接上外部訊息，它的行為就不再只受你控制。第二，README 聲稱沒有帳號、沒有遙測、金鑰留在自己機器上，同時又提供一個預設走 Cloudflare 的對外通道。這兩件事不必然衝突，但預設中繼是誰、流量經過哪裡，README 沒有交代，這是採用前該自己查清楚的部分。

MCP、技能系統與排程：擴充面的實際形狀

Brigade 的擴充不是靠外掛市集，而是靠幾個內建機制。README 在功能清單裡列出 skill system、cron scheduler、sub-agent fan-out，以及一個 MCP memory server。這四項各自解決不同問題：技能系統處理可重複的作業流程，cron 處理定時觸發，sub-agent fan-out 處理把一個任務展開成多個平行子任務，MCP memory server 則是把 Tideline 的記憶以 MCP 協定暴露出去。

MCP memory server 這一項值得單獨看。它意味著記憶層可以被 Brigade 以外的 MCP 客戶端讀取，等於把長期記憶從執行環境裡抽出來變成一個獨立服務。對已經在用其他 MCP 工具的團隊來說，這是漸進採用的切入點：先只用記憶層，不搬整個代理團隊。

README 也提到 1,000+ app connectors。這個數字來自專案自己的描述，本文無法核實其實際覆蓋率與維護狀態。連接器這種東西的品質落差通常很大，數量本身不是判斷依據。若你的工作流程依賴某個特定 SaaS，直接去找對應連接器的實作檔案會比看總數有用。

不適合 Brigade 的情況

第一個明確的排除條件是合規稽核。Brigade 的設計前提是單一擁有者、單機目錄、無帳號、無遙測。這對個人與小團隊是優點，但對需要留存操作軌跡、需要區分角色權限、需要向第三方證明資料流向的組織來說，這個模型沒有對應的機制。README 提到的「privileged actions wait for your approval」是一道人工確認關卡，不是稽核日誌。

第二個是共用主機。前面提過 ~/.brigade 的單目錄結構，README 沒有給出多使用者或多團隊在同一台機器上隔離的作法。若你的情境是多人共用一台伺服器，這個前提要先解決。

第三個是通訊軟體整合的風險面。Brigade 可以接上 WhatsApp、Telegram、iMessage 等通道，這意味著代理會以你的身分出現在這些平台上。README 沒有描述這些通道的權限邊界，例如代理能否主動發訊、能否讀取歷史訊息。在你把個人通訊帳號接上去之前，這些是需要自己從原始碼確認的問題。

最後是硬體。README 說同一組代理可以跑在 Raspberry Pi 或伺服器上，但同時列出向量檢索、多代理、Convex 後端這些元件。Pi 能跑到什麼程度，取決於你啟用哪些功能，README 沒有給出分級建議。

替代方案：OpenClaw 與其他代理框架的差異

Brigade 的 topics 清單裡同時出現 openclaw、clawdbot、moltbot、hermes-agent 等名稱，顯示它與這批專案處在同一個生態圈。以 OpenClaw 這類代理執行環境為對照，兩者的分歧點在協作模型：Brigade 把 org chart 當成第一級概念，代理之間的隸屬與委派是設定的一部分；多數同類工具則是平面的一組代理，靠任務描述決定誰做什麼，沒有內建的階層關係。

這個差異在什麼時候有意義？當你的流程本身就有審批層級，例如一個代理產出草稿、另一個代理審核、第三個才執行，org chart 能把這個結構寫進設定而不是寫進提示詞。當你的流程是平行的、每個代理各做各的，這層階級反而是多餘的抽象。

另一個對照點是記憶。Brigade 把 Tideline 做成共用層並附帶 MCP server，其他框架通常讓每個代理自己管上下文，或把記憶委外給向量資料庫。共用記憶的優點是知識複用，缺點是前面提過的污染風險。選擇哪一邊，取決於你的代理之間是應該互相知道對方學到什麼，還是應該保持獨立。

授權方面，Brigade 採 MIT，這是寬鬆授權，修改與商用都沒有額外限制條款。本文不提供法律意見，實際條文請以 LICENSE 檔案為準。

維護節奏與升級成本

從釋出紀錄看，brigade-v1.37.1 在 2026-09-09 發布，前一版 v1.37.0 是 2026-09-02，再前一版 v1.36.1 是 2026-08-31。這是一個以週為單位的節奏，中間還有 patch 版。對採用者來說，這代表兩件事：功能推進快，以及你需要一套自己的升級驗證流程。

升級的實際成本落在兩處。一是 ~/.brigade 底下的設定與資料，如果版本之間改變了記憶或儲存的格式，你的既有資料就必須遷移，README 沒有提供遷移工具的說明。二是模型供應商介面，Brigade 支援 Claude、GPT、Gemini、Llama 與 Ollama，任何一家的 API 變動都會反映在後續版本裡。

若你選的是自架 Convex 儲存模式，升級還牽涉資料庫 schema 的同步。這是檔案系統模式沒有的額外步驟，也是選擇該模式時應該一併計算的成本。

專案沒有封存，預設分支是 main，首頁與 npm 套件都存在。這些是可從外部確認的事實。至於實際的維護人力與回應速度，本文沒有足夠材料判斷。

編輯結論

如果你要的是一組跑在自己機器上、彼此能分工並共用記憶的代理，而且願意接受資料全部集中在 ~/.brigade 這個前提，Brigade 值得裝起來試；如果你需要多租戶隔離、合規稽核軌跡，或不想讓代理直接接觸你的通訊軟體帳號，那它現階段的設計方向與你的需求相反。動手前先確認三件事：Node 版本是否符合 npm 上的 engines 宣告、你的儲存模式要選檔案系統還是自架 Convex、以及 brigade expose 對外開放時你打算用 Cloudflare 還是自備 bore、frp、sish 中繼。這三項決定之後，其餘設定都只是 ~/.brigade 底下的檔案編輯。

官方來源

1. License: MIT
2. Project website
3. README
4. Releases
5. spinabot/brigade on GitHub