什麼是 CCManager？為什麼多 Agent 時代需要它

你有沒有過這種時刻：同時開著好幾個 Claude Code，一個在幫你寫測試、一個在改 API、一個在 review PR——然後突然不知道該去看哪個視窗，因為三個都在動，但又不確定哪個在等你回應。

這不是工作流問題，是工具問題。CCManager 就是來填這個洞的。

CCManager 到底是什麼

用一句話說：CCManager 是一個 TUI 介面的 AI 工作階段管理器，讓你在終端機裡用一個統一介面，同時管理多個 AI Agent 在不同 Git Worktree 跑的工作階段。

它不是模型、不是 AI——它是那個讓你知道「誰在跑、誰在等你、誰已經閒下來」的管理層。

目前支援的 AI 工具包括：

每個工作階段都有即時狀態顯示：busy（在跑）、waiting（等你回應）、idle（閒著）。不用一個一個視窗切換去猜，狀態就在清單旁邊。

單一 Agent 的時候，一個終端機視窗就夠了。問題出在你開始跑兩個、三個、四個的時候——

每個 Agent 跑在同一個 branch，互相搶同一份程式碼，改到衝突是遲早的事。就算你用不同視窗分開跑，切換起來還是亂，而且你根本不知道哪個 Agent 在等你、哪個還在跑、哪個已經出錯在那邊等了你十分鐘。

CCManager 的解法是把每個 Agent 放進獨立的 Git Worktree——每個 Worktree 是同一個 repo 的獨立工作目錄，有自己的 branch，互不干擾。然後用一個統一介面管理所有工作階段，讓你在清單裡一眼看狀態、切換、操作。

很多人會拿 CCManager 和 Claude Squad 比較，因為兩個都在解多 Agent 管理這個問題。

差異很清楚：

Claude Squad 是基於 tmux 的方案。如果你本來就重度依賴 tmux，這是自然選擇——它把多個 Claude Code 工作階段掛進 tmux，操作邏輯和你熟悉的 tmux 一致。

CCManager 不依賴 tmux，完全自帶管理層。最關鍵的差異是狀態顯示——CCManager 在選單裡直接顯示每個工作階段的即時狀態（busy / waiting / idle），Claude Squad 沒有這個。你不用靠直覺猜，看清單就知道現在誰需要你。

另一個差異是 CCManager 有 Auto Approval（實驗性功能），可以讓 Claude Haiku 自動判斷哪些 prompt 不需要手動審核。Claude Squad 的解法是 AutoYes，直接跳過確認——這個比較暴力，對某些操作風險比較高。

說直白一點：如果你一次只跑一個 AI Agent，CCManager 對你的幫助有限。

但如果你的工作流已經是「多個 Agent 並行」——比如一個在寫功能、一個在跑測試、一個在整理文件——然後你開始覺得：切視窗很煩、不知道誰在等我、在同一個 branch 改來改去會打架……這就是 CCManager 的使用情境。

它讓多 Agent 並行從「勉強可以用」變成「可以順順地跑」。

看完這篇，你大概已經知道 CCManager 適不適合你了。如果答案是「適合」，下一篇就是裝起來：安裝 CCManager：三分鐘跑起來。

如果你還沒搞清楚 Git Worktree 是什麼，可以先跳去 Git Worktree 是什麼？為什麼 CCManager 要用它把概念建好，再回來繼續。