Multica

開源的多智慧體團隊協作平臺，將 AI 程式設計助手轉變為團隊成員

Vibe Coding

https://github.com/multica-ai/multica

前往官網

深度報告

Multica 是一款開源的多智慧體團隊協作平臺，致力於將 Claude Code、Codex、OpenCode、OpenClaw、Gemini 等主流 AI 編碼智慧體接入統一的任務管理和執行體系中，使 AI Agent 像真正的團隊成員一樣工作。該專案於 2026 年 1 月 13 日在 GitHub 開源，截至 2026 年 4 月 17 日已累積超過 1.54 萬顆星和 1900 個 Fork，僅用三個月就成為 GitHub 增長最快的開源 AI Agent 管理平臺之一。
Multica 由獨立團隊開發，是一個 vendor-neutral（供應商中立）的開源專案，支援多種主流 AI 編碼工具的接入。專案採用自託管設計，企業可以將服務部署在自己的基礎設施上，保證資料隱私和安全。在 AI Agent 領域，單個 AI 程式設計助手雖然強大，但始終是「單打獨鬥」的模式。Multica 的出現填補了市場空白，它是將多個 AI 助手提供統一的管理和協作平臺。
第一個核心功能是任務分配與進度追蹤。使用者可以在 Multica 上建立 Issue，像分配任務給同事一樣分配給 AI 員工。AI 會自動領取任務、執行程式碼、報告進度、在任務下評論、建立子任務。第二個核心功能是多 AI 接入支援。Multica 支援接入多種主流 AI 編碼工具，包括 Claude Code、Codex、OpenCode、OpenClaw、Hermes 等。vendor-neutral 的設計保證了靈活性。第三個核心功能是技能沉澱。當 AI 解決了一個複雜問題後，其解決方法和思路可以被沉澱為可複用的技能，供其他 AI 或後續任務使用。第四個核心功能是實時進度推送。透過 WebSocket 實時推送進度，AI 像同事一樣彙報工作狀態。技術架構上，Multica 採用 Next.js + Go + PostgreSQL 的技術棧。
Multica 是開源免費專案，採用自定義開源許可證。使用者可以免費在 GitHub 上部署和使用。商業模式可能包括：企業版提供更強大的管理功能和專業技術支援；託管服務提供 SaaS 部署選項；定製開發服務滿足特定需求。
從社群反饋看，Multica 獲得積極評價。主要優勢包括：創新地將 AI 視為團隊成員而非工具；Task-Board 介面直觀易用；多 AI 接入靈活；技能沉澱機制有價值。潛在問題包括：作為新專案，文件和生態仍在完善中；需要技術背景部署和維護；對團隊協作流程有一定要求。
Multica 的出現填補了 AI Agent 管理平臺的空白。與 DeerFlow 等深度研究框架相比，Multica 更側重於程式設計協助場景的多智慧體協作。兩者形成互補而非直接競爭關係。技術社群對 Multica 給予高度關注，知乎、掘金、CSDN、騰訊雲開發者社群等平臺都有深度解析文章。
新專案風險：作為 2026 年初的新專案，長期維護性有待觀察。學習曲線：需要理解和適應人機協作的新模式。技術門檻：自託管部署需要一定的技術能力。
Multica 適合以下場景：軟體研發團隊希望引入 AI 成員；需要管理多個 AI 程式設計助手的企業；對 AI 開發工作流有組織化需求的開發者。不推薦場景：個人開發者使用單個 AI 助手已足夠；沒有技術團隊的支撐來維護系統。
Multica 是一款創新的人機協作平臺，將 AI 從工具轉變為團隊成員。雖然是新專案，但其核心理念和增長速度值得關注。隨著 AI Agent 在開發工作中扮演越來越重要的角色，類似 Multica 的協作平臺可能會有更廣闊的發展空間。

使用者評論

Christo_pherRoss

—

試了一下,確實比開五個終端視窗強多了。Agent跑完了會自己更新狀態,不用我去輪詢。

KylePerez520

—

之前用Claude Code寫程式碼,每次都要在終端裡盯著它跑,中間還不能切去做別的。現在把任務丟給Multica,它在後臺跑,我該幹嘛幹嘛,跑完了會通知我。這種從「保姆」到「管理者」的角色轉變,用過的都懂。

黃雪浩

—

用了兩週,回不去了。

Donald_Phillips0071

—

豆瓣沒評論,我來這裡說一句:Daemon不能斷,斷了Agent就失聯,建議tmux伺候。

KimberlyRuiz_20208

—

用了三週,實際體驗下來有幾個點想補充。第一,技能複用確實是個好功能,但還沒有宣傳的那麼成熟——目前更像是個高階版的issue template,還不是真正的「能力複利」。第二,多Agent並行的時候偶爾會出現排程衝突,兩個Agent被分配到同一個程式碼庫的不同任務時,程式碼衝突還是要人來解決。第三,自託管部署對技術能力有要求,小白建議直接用Cloud版。總的來說,方向正確,但還處於PMF早期。

薛明陽

—

深度用了三週,說點真實感受。先說好的:第一,Agent as teammate這個理念執行得很到位——看板、assignee、comment、status,Agent在這些協作介面上的出現方式跟人類成員完全一致,上手非常自然。第二,Runtime抽象做得好,一臺MacBook Pro、一臺Linux伺服器、一臺ARM雲例項,都能註冊成Runtime,統一排程。第三,Squad機制讓多Agent編排有了雛形,雖然不是完美的編排引擎,但在v0.x版本已經夠用了。說說不足:License是改過的Apache 2.0,不是純開源,商業化前要仔細看條款。Skills系統目前還是基於關鍵詞匹配,不是真正的向量語義檢索,pgvector基本處在「已部署未啟用」的狀態。另外文件雖然寫得不錯,但部分操作細節(比如自託管版本更新流程)還是靠猜。總的來說,作為專案管理型的Agent平臺,Multica是目前最成熟的選項,但距離「AI-native production system」還有距離。

Samantha_Green520

—

我是做後端開發的,團隊裡三個人加五個Agent並行開發。以前最頭疼的是上下文管理——Agent A修完的bug,Agent B不知道,又踩一遍。現在Multica把技能沉澱下來,A學過一次的東西B也能用,確實省了不少重複勞動。

MaryGomez_88

—

看板加Agent,絕了。

RFosterJr

—

產品定位很清晰,就是給已經用Claude Code這些工具的人用的,小白慎入。

袁雲

—

我是獨立開發者,一個人管五個Agent,Multica對我來說簡直是神器。以前我得在五六個終端視窗之間來回切,記不住哪個Agent在幹什麼。現在一塊看板全看完,誰在跑、誰空閒、誰卡住了,一目瞭然。而且Agent跑完了自己更新狀態,我不用一直盯著。省下來的精力可以專注在更需要創造力的部分,比如架構設計。

LoganMartin

—

Squad的Leader Agent分配機制挺有意思。之前我得手動判斷每個任務分給誰,現在直接丟給Team,它自己排程。雖然偶爾分配不太合理,但大部分時候比我自己分的還準。

David_Jenkins007

—

安裝還挺簡單的,brew一行搞定。

DRcla

—

Squad功能不錯,把小隊長設好之後,任務直接@前端組就行了。

purplemouse387

—

試了幾個小時,我個人的感覺是:如果你只是偶爾用AI寫個指令碼,沒必要上Multica。但如果你同時管著好幾個Agent,每天開五六個視窗來回切,那它確實能救命。門檻是有,但值得花那個時間。

LubbertNeuteboom

—

對比了一下同類產品:Vibe Kanban更適合單人在本地跑多個Agent,Paperclip想做的是把人類移出流程的無人公司,而Multica走的是折中路線——人和Agent在同一塊看板上協作。三種思路各有優劣。我選Multica的原因很簡單:我既不想當保姆(人的精力有限),也不放心完全交給AI自己跑(現在的Agent還沒那麼可靠)。中間路線最適合當前的階段。

NancyJackson62

—

作為一個技術負責人,我來聊聊Multica在團隊裡的落地情況。我們團隊6個人,之前用Claude Code完全是散養狀態——每個人自己開終端視窗,誰也不知道別人的Agent在幹什麼。引入Multica之後,最大的變化不是效率提升(當然也有),而是可見性。現在我在看板上能看到每個Agent的狀態、進度、阻塞點,甚至能追溯一週前的執行記錄。這對於我們這種強調「團隊協作」而不是「個人英雄主義」的團隊非常重要。但也遇到了幾個問題:第一,不是所有人都願意改變工作習慣——有人覺得直接敲命令列更快。第二,團隊規模大了之後,許可權管理還不太夠用。第三,Agent執行結果的質量參差不齊,還是需要人工review。我的建議是:先在一個專案組試點,跑通了再推廣,不要一上來就全面鋪開。

EliKristensen

—

終於不用再盯著終端了。

RaymondRivera_998

—

自託管黨狂喜,Docker一把梭,資料不用出自己伺服器。

JJohnson_77

—

看了Jiayuan的訪談,他之前的Devv和DevCode都失敗了,第三次才找到PMF。挺佩服這種打法的——不是去造更聰明的Agent,而是做Agent的管理層。這個切入角度確實刁鑽。

AlexanderHarris_9965

—

技能複用這個設計很妙。

Rachel_Murphy_20226

—

看完矽星人那篇深度報道才發現Multica背後的故事挺有意思。創始人Jiayuan之前做的Devv(開發者搜尋引擎)和DevCode(AI程式設計)都失敗了,第三次創業才找到這個方向——不造Agent,而是做Agent的管理層。他說了一句話很觸動我:產品功能和技術本身已經沒壁壘了,Coding已經被商品化了。確實,現在拼的不再是模型能力,而是怎麼把AI真正嵌入到工作流裡。

ul1xsvrnzw

—

那個andrej-karpathy-skills引流操作是真的騷,但確實有效。

AFoster

—

我覺得最大的短板是編排能力還太弱。目前基本上是人來拆任務,Agent只管執行。如果真的要做到複雜工作流自動編排,還有很長的路。不過作為v0.x版本,方向是對的。

Gregory_Mendoza_2024

—

跟GitHub Issue #815那個深度分析的觀點基本一致。Multica目前最大的問題不是功能不夠多,而是它本質上還是在「用管理人的方式管理AI」。Issue的狀態流轉是扁平的——backlog、todo、in_progress、in_review、done、blocked、cancelled,這些狀態跟人用的Jira沒區別。但AI的工作流跟人的工作流本質上是不同的——AI可以同時處理多個任務、可以24小時不間斷執行、不需要休息。把AI塞進為人類設計的狀態機裡,其實是一種「削足適履」。不過我理解這是團隊打的「安全牌」——先做人類熟悉的東西,再逐步演進到AI原生。作為MVP,Mutica的方向是對的,但我很期待看到它什麼時候能真正從「AI teammate manager」進化到「AI orchestrator」。

WolfWalletChavez

—

感覺像僱了一群免費牛馬。

EugeneHicks_Max5

—

裝完發現Codex支援不太好,官方說支援實際有坑,後來切Claude Code就好多了。

Garrett294

—

說幾個問題吧。第一,License不是純Apache 2.0,是改過的,加了商業限制,採購前要看清楚。第二,標稱支援8種CLI,實際第一梯隊只有Claude Code和Codex,其他的穩定性參差不齊。第三,Skills系統還沒有向量記憶,檢索靠人手工掛載。第四,624個open issues說明還在快速迭代期,生產環境使用需謹慎。但作為開源專案,迭代速度和質量在同體量專案裡算很不錯了。

月光_11

—

用Docker自託管部署的,過程還算順利,就是版本更新太頻繁了,幾乎每天都有新release。好處是迭代快bug修得快,壞處是我隔兩天就得pull一次新映象。

Betty.GomezII25

—

623個open issues,說明還在快速迭代。

zOEYoLSEN

—

部署的坑:如果你選的海外伺服器,Agent呼叫大模型API延遲會低很多。我一開始用的國內伺服器,Claude Code經常超時。後來切到香港節點就好多了。另外API Key要提前在對應的CLI裡配好,不是配在Multica裡,這個文件沒說清楚,很多人在這上面卡住。

Multica

深度報告

使用者評論

相關連結

同類產品