選型結論與試用建議
依團隊「真人看得到進度、Claude 與 Codex 都能接手、任務與文件留在同一處」的核心需求，建議優先選擇 Paca 進行兩週試用。從單一專案、兩組 Agent 啟動，通過驗收標準後再擴大部署。
首選方案
Paca · 人與 Agent 共用 Scrum PM
原生 MCP、Sprint 管理、專案文件與 ACP bridge 執行橋接最貼合人機協同需求。Apache-2.0 授權利於客製化；主要限制為專案年輕且核心維護者高度集中。
穩健替代
Plane CE · 先行建立組織工作流程
若近期目標為取代正式專案管理系統，優先考慮 Plane。Agent 透過官方 MCP 讀寫任務；自動派工與成本治理需額外串接，且 Community Edition 功能與商業版存在邊界差異。
自主執行
Paperclip · 管理持續運作的 Agent 團隊
若核心痛點在於非同步派工、排程喚醒、執行審批與預算控制，Paperclip 為最佳解。若僅需共用任務追蹤看板，其組織設定與執行開銷偏高。
關鍵架構與協作交接
評估 AI PM 看板不可僅詢問是否具備 MCP 介面。選型關鍵在於四項核心問題：任務指派對象、Agent 觸發啟動機制、執行過程狀態可視性，以及最終驗收判定權限。能連線呼叫模型，與具備端到端交付工作能力，屬於不同層次的工程驗收項目。
| 能力層級 | 實際作業行為 | 選型檢核重點 |
|---|---|---|
| 任務讀寫層 | 在 Claude Code 或 Codex 中查詢任務、追加註解、更新狀態 | MCP server 工具集完整度、權限控制粒度、版號相容性與讀回資料正確性 |
| 啟動執行層 | 於看板完成任務指派後，Agent 自主啟動執行工作 | 是否具備 runner、bridge、adapter 或獨立執行守護程序；MCP 協定本身不代管作業系統行程 |
| 驗收追蹤層 | 檢視規劃內容、程式碼變更、測試結果與 Token 費用，判定是否驗收 | 任務是否關聯實際 run 紀錄與產物；失敗中斷後能否續跑；完成狀態是否經過獨立審查 |
架構差異上，Paca 提供 ACP 與 CLI 執行橋接；Paperclip 內建 adapters 與 heartbeats 治理機制；It’s a Plan 包含內部 runner；Plane 官方 MCP 則聚焦於任務與專案資料操作。
四大方案決策總表
累積 Stars 數據代表查核當下之社群關注度，非商業客戶數、系統可靠度或成長率排名。四大專案於 2026 年 10 月均維持活躍開發活動。
| GitHub 專案 | 核心定位 | Stars 與 Forks | 專案建立日 | 最新預設分支 Commit／正式版 | 開源授權 | MCP 與執行機制 | 建議用途 |
|---|---|---|---|---|---|---|---|
Paca<br>Paca-AI/paca | 人＋Agent 敏捷 Scrum 看板 | 1,923 stars<br>166 forks | 2026-03-20 | 2026-10-12<br>v0.19.0（2026-10-12 UTC） | Apache-2.0 | 原生 MCP；支援 ACP bridge 與 CLI 執行 | 首選：兩週試用驗證 |
Plane CE<br>makeplane/plane | 通用團隊專案管理主系統 | 60,799 stars<br>6,055 forks | 2022-11-19 | 2026-10-08<br>v1.4.2（2026-08-23 UTC） | AGPL-3.0 | 官方獨立 MCP server；CE 建議 stdio | 穩健：全公司組織導入 |
Paperclip<br>paperclipai/paperclip | Agent 團隊執行與成本治理 | 101,638 stars<br>17,045 forks | 2026-03-02 | 2026-10-14<br>v2026.1012.0（2026-10-12 UTC） | MIT | 原生 MCP；adapters 與 heartbeats 喚醒 | 自主派工與預算控制 |
It’s a Plan<br>croffasia/itsaplan | Linear 式看板＋Agent runner | 963 stars<br>160 forks | 2026-07-14 | 2026-10-13<br>v1.5.0（2026-10-13 UTC） | AGPL-3.0 | 內建 MCP；支援內部 Agent 與外部 CLI runner | 潛力方案：同題對照 |
| 評估面向 | Paca | Plane CE | Paperclip | It’s a Plan |
|---|---|---|---|---|
| 真人團隊日常專案管理 | 強：Sprint 規劃、多視圖看板 | 強：通用專案管理、外圍生態成熟 | 具備基本任務與真人指派；核心偏向 Agent 組織管理 | 強：多視圖切換與 Dashboard 彙整 |
| Claude 與 Codex 共用任務 | 原生 MCP 支援完整 | 官方 MCP；CE 版需逐項檢驗相容性 | 原生 stdio MCP；另有實驗性遠端 HTTP 路徑 | 原生內建 MCP 服務 |
| 看板指派後自動啟動執行 | 支援；需配置 ACP bridge 或外部 runner | 需另外自行搭建外部執行調度層 | 核心能力；支援 adapter 排程與 heartbeat 喚醒 | 支援；支援指派觸發、@mention 與定時排程 |
| 專案知識與架構文件 | 整合 SDD／BDD 規格與 Markdown 文件庫 | 具備 Pages 文件功能；MCP 讀寫能力依版號而定 | 任務附加文件、執行產物、技能庫管理 | 支援樹狀階層文件與版本變更紀錄 |
| 執行審批與成本治理 | 具備 Policy 權限與操作復原；預算治理未證實具備獨立模組 | 延用專案角色權限；無 Agent 執行費用管控模組 | 最聚焦：具備組織／專案預算上限、審批流與 Token 暫停 | 具備角色與執行設定；單次 run 之深入可視性待強化 |
| 主要採納代價 | 專案年輕、核心維護貢獻高度集中 | CE 與商業版存在功能斷層；自動執行需額外整合 | 系統設定複雜、監督負擔大、多模型調度開銷高 | 專案初期；MCP 協定與底層操作介面處於快速變動期 |
四大專案深入評估
01 · Paca {#paca}
定位與判斷：人＋Agent 共用 Scrum PM 首選方案。最值得優先投入試用資源，先確立跨人機協同工作流程，再逐步開放自動化派工。
優勢分析：
資料層整合直接：原生 MCP 完整支援任務、Sprint、技術文件、成員身分與 GitHub Repo 關聯，Agent 能完整存取相同專案上下文。
支援本地端執行：透過 ACP bridge 串接本機 Claude Code 與 Codex CLI，沿用開發者本機環境已配置之工具鏈與金鑰憑證。
具備細粒度權限控制：v0.19.0 引進基於 Policy 之角色權限機制，可精細限制資源存取條件，利於落實需求規劃、程式碼實作與驗收審核三權分立。
開放架構具高客製彈性：採用 Apache-2.0 開源授權，架構設計模組化，便於團隊針對專屬開發流程擴充客製工具。
代價與限制：
維護者高度集中：GitHub API 貢獻紀錄顯示單一核心帳號累計 1,655 次 commit，其餘真人開發者貢獻比例顯著偏低，存在長期維護延續性風險。
輕量架構仍需完整維運：完整部署涵蓋資料庫、快取、物件儲存及核心應用服務；備份策略需同時覆蓋關聯資料與檔案附件。
ACP bridge 缺乏本機檔案沙箱：bridge 文件載明無人值守模式將抑制互動式確認提示，並繼承本機 Git 與作業系統權限；平台之 PM 角色限制無法自動約束宿主機檔案系統。
大規模生產環境案例尚少：Hacker News 社群討論熱烈，但尚未形成多團隊長週期企業部署的成熟驗證案例。
02 · Plane CE {#plane}
定位與判斷：正式團隊專案管理的保守穩健選擇。適合優先鞏固真人團隊專案流程與組織資料資產，再行將 Agent 接入協同作業；自架環境務必以 Community Edition 實際能力為準。
優勢分析：
專案管理基礎完整：完整涵蓋 Issues、Cycles、Modules、Roadmaps 與 Pages 文件，提供成熟結構化之團隊協作架構。
維護歷史悠久且貢獻分散：Repo 始於 2022 年，前列有多個持續活躍之核心貢獻帳號，組織生命週期與延續性表現優異。
官方維護獨立 MCP Server：提供標準 Python MCP 伺服器，允許外部 AI 客戶端連線自建 Plane 實例；舊版 npm 套件已明確標註棄用。
真正的開源核心：Community Edition 採用 AGPL-3.0 授權，程式碼與商業版明確分離，具備高度自架自由度。
代價與限制：
商業版功能不可直接計入 CE：Commercial Edition 屬於專有商業授權；自架、免費與開源三者定義不同，需確認所需功能是否落於 CE 範圍。
CE 之 MCP 工具支援度非 100% 對等：官方建議 CE 採用 stdio 模式連線；社群實測指出核心任務讀寫完整可用，但 PQL 查詢與進階屬性操作存在落差。
缺乏內建 Agent 執行調度器：從「變更負責人」至「Agent 自主啟動編程、提交程式碼、發起審查」，需自建外部工作流；雖增加串接工作，但利於保留既有 CLI 工具鏈。
維運配置開銷較高：以官方 Docker Compose 部署 CE v1.4.2 通常涉及約 13 個容器組件，整體系統維運成本高於輕量看板。
版本查核澄清：不可因早期社群之 404 回報判定 Plane 不支援 CE。Issue #172 已由維護者於 v1.4.0 補齊端點並關閉；Issue #171 亦於 2026 年 9 月在 CE v1.4.2 搭配 MCP 0.3.2 驗證通過 12 項核心操作。選型風險在於特定功能邊界，而非協定層完全無法運作。
03 · Paperclip {#paperclip}
定位與判斷：四案中關注度最高、Agent 治理特色最鮮明之方案。當核心目標為管理持續性自主工作流程、調度審批與模型開銷，而非單純任務清單追蹤時，其價值方能充分體現。
優勢分析：
跨 Agent 統一調度與治理：透過 adapters 整合 Claude Code、Codex 等不同 runtime，集中監控 runs、目標對齊與審批節點，並支援真人協同指派。
提供官方標準 MCP：原生 stdio 套件支援讀寫 issues、專案文件、審查項目，並提供任務 checkout 與 release 工具，利於避免人機競爭領工。
以成本控制為核心架構：內建組織級、專案級與 Agent 級預算管控機制，具備額度超限強制熔斷保護，直接應對自主 Agent 之失控開銷風險。
開源生態熱度顯著：累積 Stars 突破 10 萬，維持高頻正式版本發布節奏，採用寬鬆之 MIT 授權。
代價與限制：
工作流設計門檻極高：若角色定義、喚醒觸發、上下文邊界與驗收標準未妥善規劃，多 Agent 協同易退化為反覆交談無產出。
遠端 Public MCP 仍處實驗階段：需手動於設定檔開啟，預設關閉；內部具名 Agent gateway 與外部助理之真人連線身分屬不同安全路徑。
版號與部署模式需嚴格檢驗：過往安全公告曾揭露未授權匯入與本機 DNS rebinding 風險；切忌將網路教學之本機配置直接裸露於內部網路。
傳統專案管理體驗非其重心：系統重心在於 Agent 組織樹與執行狀態治理，對於傳統 Scrum 衝刺、燃盡圖或跨部門非工程報表需進一步評估。
安全公告查核現狀：匯入授權繞過漏洞公告列出受影響版本為
< 2026.416.0，修正版本為2026.416.0；DNS rebinding 公告標示影響< 0.3.1，其修復紀錄與現行日期版號系統不易直接比對。評估時應針對特定目標部署版本進行安全複核。
04 · It’s a Plan {#itsaplan}
定位與判斷：快速演進之現代化產品候選。最適合與 Paca 進行同題目平行對照驗證；現階段不建議僅憑功能清單即行全公司主力系統遷移。
優勢分析：
專案管理介面與 Agent 深度融合：具備 Linear 風格之多視圖、Cycles、Dashboard 與文件系統，將具備身分角色之 Agent 與真人成員平級呈現，非工程團隊上手阻力低。
原生整合 Coding CLI：官方文件明列外部 runner 可對接 Claude Code 與 Codex；支援指派事件、@mention 呼叫或排程定時啟動。
緊密串接軟體工程資產：內建 Git 服務 PR 關聯、API、Webhooks 與原生 MCP，程式碼變更與審查紀錄可自動回寫任務看板。
開發迭代極為活躍：專案建立於 2026 年 7 月，維持頻繁正式發布，最新正式版本標註為 v1.5.0，採用 AGPL-3.0 開源授權。
代價與限制：
執行過程可視性存在落差：社群 Issue #544 反映團隊導入 Codex 進行規劃與實作時，難以在任務頁面直觀檢視每次執行的詳細進程與日誌。
MCP 連線穩定性待修復：Issue #498 指出 API Key 限流回應可能被誤轉換為 401 Unauthorized，導致 Claude Code 誤判驗證失敗而中斷連線；查核當下該 issue 仍在處理中。
文檔聲明與版號存在差距：版本號雖已升至 1.5.0，但 README 仍保留「首個穩定版前可能存在 breaking changes」之警告，不可單純依版號判定 API 穩定性。
社群規模與長期驗證不足：具備真實生產使用反饋與推廣討論，但尚不足以確立為大規模團隊之公認標準解法。
社群討論與落地證據
以下彙整公開社群討論之可追溯樣本。專案作者宣傳、外部工具盤點、單一使用者心得與可重現之 Issue 回報具備不同證據權重；早期版本之問題不應直接外推至最新版本。
| 專案與來源管道 | 正面訊號與推廣反饋 | 疑慮、反方意見與已知阻礙 | 實務分析與解讀 |
|---|---|---|---|
| Paca<br>Hacker News 2026-06-13 | 獲 174 points 關注；社群認同其視覺化規劃介面符合 AI 輔助開發之協同需求。 | 討論指出各團隊之開發流程差異大、現有 Compose 部署架構偏重，且缺乏自動判定任務完成之機制。 | 產品定位引發共鳴，但討論多集中於概念設計；作者內部使用經驗不等於獨立第三方企業之落地背書。 |
| Plane<br>Reddit & GitHub Discussions | CE 1.0 發布獲創始團隊詳細說明；2026 年 9 月有社群提供 CE＋MCP 核心讀寫成功運作之實測回報。 | Open-core 模式之功能劃分引發爭議；Community Edition 與 Cloud/Commercial 版本之 API 覆蓋度存在落差。 | 具備最成熟之長週期社群與版號修復紀錄；選型評估應以 CE 實際具備之 API 與功能為依據，排除行銷宣傳功能。 |
| Paperclip<br>Reddit r/LocalLLaMA 等 | 數名使用者在妥善設定 Triggers、Skills 與 QA 驗收條件後，成功實現多個 Coding Agent 之分工流水線。 | 亦有多名使用者回報 Token 大量浪費於 Agent 間互相派工交談、忽視上下文記憶或安裝設定困難；多數經驗源自數月前版本。 | 產出效果高度取決於任務拆解細緻度與 Runtime 環境；部分正面分享伴隨販售設定模板，需適度調降其客觀性權重。 |
| It’s a Plan<br>GitHub Issues 2026-10 | 出現真實團隊將雙 Codex Agent（規劃者與實作者）串接至內部正式流程之使用紀錄。 | 相同案例反映任務內無法直接審閱各次 run 之執行過程；另有 Issue #498 回報 MCP 連線遭 API 限流中斷問題。 | 真實問題回報較宣傳推廣更具參考價值；目前事證支持其作為潛力試用對象，但不足以支持貿然全面遷移。 |
| Mission Control<br>Reddit 工具盤點報告 | 被評為功能架構相對完整、能橫跨對接多種 Runtime 之統一操作面板。 | 屬於盤點者之個人主觀評估，無法證明各外接 adapter 均具備相同之生產級穩定性。 | 契合 Agent 營運監控方向；評估時仍應正視官方明確標記之 Alpha 狀態。 |
| Backlog.md<br>Hacker News 2025-07 | 主帖獲 254 points 與 62 則討論；受到推崇的核心為任務與程式碼納入同一 Git 版本管理。 | 社群頻繁詢問能否對接既有 Jira 或 Linear；作者亦將其定位於「原本不採用重型專案管理系統」之輕量專案。 | 極適合 Git 原生之小型敏捷工程團隊；不可因 CLI 易用而將其視為多人線上 SaaS 專案管理系統之直接替代品。 |
延伸搜尋與候選查核
以開源授權、標準 MCP 介面、近期版本維護紀錄與需求吻合度為標準，篩選三組延伸候選專案；缺乏充足獨立口碑者均明確標註，不將 Stars 數包裝為成熟背書。
| GitHub 專案與連結 | 關注度、授權與版本紀錄 | 核心解決問題 | 方案優勢 | 潛在代價與選型建議 |
|---|---|---|---|---|
Mission Control<br>builderz-labs/mission-control | 約 6,300 stars<br>MIT 授權<br>v2.3.0（2026-07-25） | 將多種 Agent 之任務、執行 runs、審核流與費用集中於單一控制面板；支援官方 MCP、CLI 與 REST API。 | 基於 SQLite、支援本機自架；Claude Code 與 Codex 可直接連線，無須強制行經閘道代理。 | 官方明確標記為 Alpha 階段，不同 Runtime 支援深度不一。若首要痛點為 Agent 營運可視性，值得與 Paperclip 對照；作為全公司專案管理則次於 Paca 與 Plane。 |
Backlog.md<br>MrLesk/Backlog.md | 7,025 stars<br>MIT 授權<br>v1.53.0（2026-09-24）<br>commit 10-13 | 將任務儲存為 Markdown 檔案，與程式碼同庫納管；提供本機 Kanban 介面與官方 Claude Code／Codex MCP 指引。 | 檔案完全可攜、零額外資料庫部署負擔；對於小規模 Agent 原生專案極為順手。 | 現有 Web UI 僅限本機執行；跨成員協作依賴 Git pull/push 與衝突解決機制。適合純工程小隊，不適合非技術職能團隊共用。 |
Agent Teams AI<br>777genius/agent-teams-ai | 約 2,300 stars<br>AGPL-3.0 授權<br>v2.17.10（2026-10-09） | 桌面客戶端應用，管理多個 Agent 團隊、任務指派、交談與互評；內建 MCP 伺服器模組。 | 操作介面高度整合，支援多種 Coding Runtime；利於單一工程師集中調度。 | 桌面端「Agent 團隊」不等於多人企業共用 PM。目前缺乏長期多人協同驗證，列入觀察名單，需先行驗證成員權限與多人共享模式。 |
| 專案名稱與連結 | 查核現況與重大變更 | 選型決策與排除原因 |
|---|---|---|
Multica<br>multica-ai/multica | 約 52,700 stars。現行 LICENSE 在 Apache-2.0 基礎上增加商業限制條款，官方歸類為 Source-available；內部自架免費，但對外提供託管或嵌入產品具額外限制。 | **若「純粹開源（OSI Compliant）」為硬性條件，應排除現行版本。**功能高度貼合需求，但授權不可簡化宣稱為純 Apache-2.0。 |
Vibe Kanban<br>BloopAI/vibe-kanban | 28,350 stars。原維護公司於 2026-04-10 宣布終止營運（Goodbye bloop），專案交由開源社群維護。API 顯示近期雖有零星 commit，但最新正式 release 停留於 4 月。 | **不建議採納為企業協作主系統。**可供架構設計參考；近期零星 commit 不足以抵銷原廠團隊解散之維護模式轉變事實。 |
Automaker<br>AutoMaker-Org/automaker | 3,227 stars。GitHub API 顯示最新 commit 為 2026-05-22，已超過三個月無代碼活動。 | **不列入近期活躍推薦。**專案維護處於停滯期，未進一步檢驗其特殊授權條款。 |
Archon<br>coleam00/Archon | 23,684 stars。專案現已全面轉型為基於 YAML 之 Coding Workflow Engine；舊版任務管理與 RAG 功能已封存於 archive/v1-task-management-rag 分支。 | **產品定位與用途已變更。**適合作為自動化工作流引擎，不可沿用舊資料將現行版本推薦為共用 PM 看板。 |
具體採用與兩週驗收
建議試用規模：配置 1 位 PM／驗收者、1 位協同工程師、Claude 負責架構規劃、Codex 負責程式實作，選取 10 張真實但範圍受控的開發任務，於兩週內完成一次完整的需求定義至驗收循環。
1. PM 定義需求
建立清晰之單一句目標、限制條件與具體可量化之驗收標準。
2. Claude 展開規劃
透過 MCP 讀取專案文件、補齊實作計畫、標註潛在風險並提出釐清問題。
3. Codex 執行編程
認領任務卡片、進行程式碼變更、執行自動化測試並提交 PR 關聯產物。
4. 同事驗收審查
檢閱測試紀錄、截圖或成果證據，判定接受合併或退回補正。
| 試用階段 | 實際執行重點 | 建議通過標準 |
|---|---|---|
| 第 1–2 天：資料層打通 | 在 Paca 建立專案、技術規格文件與兩組 Agent 專用身分；透過具身分識別之憑證連線 MCP，真人保留最終驗收權限。 | Claude 能順利建立任務與計畫，Codex 能即時讀取完全相同之資料；真人 Web 介面能清晰檢視變更紀錄與操作者身分。 |
| 第 3–5 天：接手與回寫驗證 | 完成 3 張常態任務，期間刻意於中途強制中斷一次 Agent 行程，改由真人或其他 Agent 接手。 | 接手者無須複製貼上完整對話歷史紀錄即可接續工作；回報紀錄完整包含任務 ID、產物連結與遭遇阻礙。 |
| 第 6–8 天：並行競爭與例外復原 | 令兩組 Agent 同時嘗試認領同一張任務；實測權限被拒、連線逾時、自動重試與密集連續工具呼叫情境。 | 不發生雙方互相覆寫產物；領工失敗時能立即終止；重試機制不重複建立幽靈任務；Agent 不可自行核准自身產物。 |
| 第 9–10 天：全量驗收與災難復原 | 完成累積 10 張任務，進行一次完整資料庫與附件之備份還原作業；由未參與提示詞編寫之第三方同事進行審查。 | 至少 8/10 張任務無須人工介入修正追蹤欄位；10/10 均附帶完整驗收證據；非授權寫入與無人核准結案率為 0；附件資料完全可還原。 |
決策條件轉移路徑
| 試用反饋或團隊特定需求 | 建議調整之下一步決策 |
|---|---|
| 需立即讓非工程背景同事全面轉移至新專案管理系統 | 改以 Plane CE 為首選；優先檢驗官方 MCP 核心任務與 Pages 文件覆蓋度，再行外掛自動派工模組。 |
| 核心需求為 Agent 長時間自主巡檢運作，急需精細預算控制、審核流與執行追蹤 | 改以 Paperclip 為首選；同時將 Mission Control 作為營運可視性之對照組。 |
| Paca 之看板互動不符合團隊習慣；It’s a Plan 於目標版本修復 MCP 斷線與執行日誌問題 | 以相同 10 張試用任務對照測試 It’s a Plan；若真人協作效率更佳則採納。 |
| 團隊僅有 1–2 名工程師，全員精通 Git，無需對外暴露多人 Web 專案管理介面 | 改採 Backlog.md；將任務與代碼庫同庫管理，大幅降低維運與工具切換成本。 |
研究範圍與查核來源
本評估依據官方 README、MCP 協定規格、部署手冊、Release 紀錄、GitHub Issues／Discussions、安全公告、Hacker News 與 Reddit 公開討論進行交叉比對。
查核專案 GitHub 原始 API 端點
| 專案名稱 | Repository Metadata | 最新預設分支 Commit | Releases 紀錄 | 核心貢獻者清單 |
|---|---|---|---|---|
| Paca-AI/paca | Repo Metadata | 最新 Commit | Releases | Contributors |
| makeplane/plane | Repo Metadata | 最新 Commit | Releases | Contributors |
| paperclipai/paperclip | Repo Metadata | 最新 Commit | Releases | Contributors |
| croffasia/itsaplan | Repo Metadata | 最新 Commit | Releases | Contributors |
| MrLesk/Backlog.md | Repo Metadata | 最新 Commit | Releases | Contributors |
| BloopAI/vibe-kanban | Repo Metadata | 最新 Commit | Releases | Contributors |
| AutoMaker-Org/automaker | Repo Metadata | 最新 Commit | Releases | Contributors |
| coleam00/Archon | Repo Metadata | 最新 Commit | Releases | Contributors |