multi-agent-shogun：用 tmux 與 YAML 串起 8 個 CLI 代理的封建指揮鏈
Samurai-inspired multi-agent system for Claude Code. Orchestrate parallel AI tasks via tmux with shogun → karo → ashigaru hierarchy.
秒懂
- 它是什麼？
- 這個專案把多個 AI 編碼 CLI 塞進 tmux 分割視窗，用將軍、家老、足輕三層架構分派任務，協調成本壓到只剩磁碟上的 YAML 檔案。它解決的是平行代理的調度問題，代價是你得接受一套相當特殊的執行環境。
- 適合誰用？
- 如果你已經有 Claude Code 或其他支援的 CLI 訂閱，而且願意讓多個代理在同一台機器的 tmux session 裡長時間並行，multi-agent-shogun 提供了一條不需要額外基礎設施的路徑。若你只在單一代理內處理短任務，或無法接受 --dangerously-skip-permissions 這種權限設定，那它不適合你。
- 可以商用嗎？
- 可以。MIT 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 41 天前。
- 用什麼語言寫的？
- 主要是 Shell（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它要解決的是調度，不是模型能力
多代理系統的常見瓶頸不在單一代理的推理品質，而在代理之間怎麼分工、怎麼回報、怎麼避免互相踩線。README 把這個問題講得很直白：多數框架把 token 花在協調上，而這個專案聲稱協調成本為零，因為代理之間透過磁碟上的 YAML 檔案溝通，API 呼叫只用在實際工作。
目標使用者是已經在用 Claude Code 之類 CLI 工具、但覺得一次只能跑一條線的人。README 的訴求是「一次指令生出 7 個 worker 加 1 個 strategist」，而且你在任務跑背景時可以繼續下一個指令。這對需要同時推進多個獨立子任務的人有意義，例如同時改 API、寫測試、更新文件。
反過來說，如果你的任務本質上是序列的，或者你只需要一個代理幫你改幾行設定，這套架構帶來的複雜度高於它省下的時間。
將軍、家老、足輕：指令如何往下流
架構是三層。最上層是 Shogun，接收你輸入的自然語言指令，立即往下分派。中間是 Karo，負責把任務拆解並分配給 worker。最底層是 7 個 Ashigaru 加 1 個 Gunshi，前者執行，後者扮演策略角色。README 的示意圖標示 Shogun 與 Karo 之間的通道是 YAML 加 tmux。
v5.1.0 的版本名稱是 Karo as Traffic Controller，說明家老這一層在後期版本被強化為流量控制角色。v5.0.0 則是 OpenCode First-Class Support，代表多 CLI 支援是逐步長出來的，不是一開始就有的設計。
每個代理跑在自己的 tmux pane 裡，這是可觀測性的來源：README 說每個指令、報告與決策都是一個純 YAML 檔案，可以讀、可以 diff、可以進版本控制。這件事對除錯的價值比聽起來高，因為多代理系統最難查的就是某個代理為什麼做出某個決定。
README 也強調階層設計本身防止衝突：所有權清楚、每個代理有專屬檔案、事件驅動而非輪詢。這是設計主張，不是我能從素材驗證的執行結果，但至少方向明確。
啟動流程與實際指令
需求是 tmux、bash 4 以上，以及下列 CLI 至少一個：Claude Code、Codex、Copilot、Kimi、OpenCode、Antigravity。README 的 Quick Start 給出這串指令：
git clone https://github.com/yohey-w/multi-agent-shogun cd multi-agent-shogun bash first_setup.sh source ~/.bashrc claude --dangerously-skip-permissions bash shutsujin_departure.sh
first_setup.sh 負責一次性設定：config、相依套件、MCP。source ~/.bashrc 是為了重載 PATH。claude --dangerously-skip-permissions 標註為只在首次執行時需要，用途是完成 OAuth 並接受 Bypass Permissions，之後用 /exit 離開。最後 shutsujin_departure.sh 啟動全部代理。
這裡有個該講清楚的點：--dangerously-skip-permissions 這個旗標的名稱本身就說明了風險，它讓代理跳過權限確認。在一個會同時跑 8 個代理、而且代理之間透過檔案互相傳遞指令的系統裡，這個設定值得你在按下 Enter 前想一下。README 沒有在這裡多做討論。
啟動後的操作方式是在 Shogun pane 輸入指令，例如 README 舉的「Build a REST API for user authentication」，然後 Shogun 分派、Karo 拆解、7 個 Ashigaru 平行執行。
為什麼綁定 CLI 而不是 API
README 用一整節解釋這個選擇。論點是 API 按 token 計費，跑 8 個 Opus 等級代理每小時約 100 美元以上，而 CLI 訂閱是固定月費，約 200 美元。表格把兩者放在一起比較：成本可預測性、用量焦慮、實驗預算。
這個算術的邏輯成立，但它同時是這個專案最大的結構性約束。整套系統的經濟性建立在「你已經有 CLI 訂閱」這個前提上。如果你用的是按量計費的 API key，README 自己算出來的數字就是勸退理由。
另一個約束是 CLI 訂閱條款。README 沒有討論各家服務對自動化並行使用的規定，而這是你採用前必須自己確認的事，不是專案能替你回答的。
支援的 CLI 有 7 種：Claude Code、OpenAI Codex、GitHub Copilot、Kimi Code、OpenCode、Cursor、Antigravity。README 的表格只列出部分 CLI 的強項與預設模型，Claude Code 那欄寫的是 tmux 整合與 Memory MCP，其餘內容在提供的素材中被截斷，我不會替它補完。
作者自己解散了這支軍隊
README 開頭有一段少見的聲明。2026 年 8 月的續作說明指出，作者已經把自己那支 10 代理軍隊縮減為單一代理，理由是那個單一代理承載了他的判斷。後繼專案是 kagemusha，README 描述它提供的是「judgment loop」的形式，也就是修正到原則再到常設規則的流程，而不是代理本身。作者把解散過程寫成了一篇日文文章。
這段聲明值得單獨拿出來講，因為它直接影響採用判斷。專案本身仍在運作，README 明說 multi-agent-shogun itself continues to work as-is，最後推送時間是 2026 年 8 月。但主要作者已經把注意力轉向別處，這對長期維護預期是有意義的資訊。
我不會替作者推測他為什麼縮減規模。README 給的理由是判斷的承載問題，這是一個關於代理數量與決策品質之間張力的陳述，而不是關於技術故障。
不適合的場景與該對照的方案
最明顯的失敗模式是環境依賴。整套系統建立在 tmux 與 bash 4 以上，README 另外提到 Windows 的完整安裝步驟要看 Quick Start 章節。如果你的開發流程在容器或遠端 IDE 裡，tmux pane 的可視性優勢就不成立，剩下的只有檔案傳遞這一層。
第二個限制是任務顆粒度。7 個 worker 平行執行的前提是任務能被切成 7 份互不重疊的工作。如果你的任務有強序列依賴，切出來的子任務會互相等待，平行度換不到時間。
要對照的方案，README 自己列了幾個。Claude Code 內建的 Task 工具是單一 process 內跑 subagent，序列執行，一次一個。Claude Code Agent Teams 是多個獨立 session 加 JSON mailbox，README 描述它 token 較重，因為每個 teammate 都是獨立 context。LangGraph 是圖狀狀態機，平行節點需要搭配 Postgres 或 Redis 這類基礎設施。CrewAI 是角色型代理，README 說它的平行能力有限。
差異的核心在協調層的材質。LangGraph 把狀態放在資料庫，Agent Teams 放在 JSON mailbox，multi-agent-shogun 放在磁碟上的 YAML 檔案。YAML 的好處是可直接閱讀與 diff，代價是它沒有資料庫的交易保證，多個代理同時寫入時的處理方式在提供的素材裡看不到。
授權、維護與升級成本
授權是 MIT，這對採用來說是最寬鬆的一類，你可以修改、商用、再散布，只要保留授權聲明。README 沒有提到任何額外的商業條款或服務綁定。這不是法律意見，實際條款請看 repository 裡的 LICENSE 檔案。
維護成本要分成兩塊看。第一塊是這個專案本身，主要語言是 Shell，這意味著升級通常就是 git pull 加上重跑 first_setup.sh，沒有編譯步驟，也沒有套件管理器介入。第二塊是它依賴的外部 CLI，這些工具各自的版本更新頻率不低，而 multi-agent-shogun 的相容性取決於這些 CLI 的命令列介面是否穩定。README 沒有描述版本鎖定機制。
從版本節奏看，v4.6.0 在 2026 年 4 月，v5.0.0 與 v5.1.0 都在 5 月，主要版本之間相隔約一個月。最後推送是 2026 年 8 月。這些是倉庫層級的事實，不是品質判斷。
README 提到 AI 會透過 Memory MCP 跨 session 記住你的偏好。這是需要額外設定的元件，first_setup.sh 的說明裡有 MCP 這一項，但具體設定內容在提供的素材中沒有展開。
編輯結論
如果你已經有 Claude Code 或其他支援的 CLI 訂閱，而且願意讓多個代理在同一台機器的 tmux session 裡長時間並行，multi-agent-shogun 提供了一條不需要額外基礎設施的路徑。若你只在單一代理內處理短任務，或無法接受 --dangerously-skip-permissions 這種權限設定，那它不適合你。動手前先確認三件事：first_setup.sh 在你的 bash 版本下能跑完、你的 CLI 訂閱條款允許這種並行用法、以及 shutsujin_departure.sh 啟動後的 pane 佈局符合你的螢幕與工作習慣。作者本人已把 10 代理縮減為單一代理並另開 kagemusha 專案，這件事本身就是採用前該納入考量的訊號。
社群筆記