去年有個數(shù)據(jù)挺扎眼：GitHub Copilot用戶里，37%的人嘗試過同時開多個AI窗口寫代碼。結果呢？超過一半的人兩周內(nèi)就放棄了——不是因為AI不夠聰明，是因為它們太"獨"了。

每個AI都在自己的終端里悶頭干活，改同一個函數(shù)、刪同一行注釋、甚至同時給變量起名叫`temp_fix`。開發(fā)者最后成了救火隊員，專門處理AI們留下的合并沖突。

Keshrath（GitHub用戶名）就是被這個問題逼瘋的人之一。他日常開三個Claude Code會話：一個寫實現(xiàn)，一個做代碼審查，還有一個跑測試。三個AI各忙各的，經(jīng)常把彼此的代碼覆蓋掉。"就像三個裝修工人同時砸一面墻，沒人知道對方在干嘛。"

他的解法：給AI裝個"對講機"

他做了個叫agent-comm的開源項目。本質(zhì)上是個通信服務器，任何AI coding agent都能接入——Claude Code、Codex CLI、Gemini CLI、Aider，只要支持MCP（Model Context Protocol，模型上下文協(xié)議）或者能發(fā)HTTP請求就行。

核心功能就幾塊：

注冊與發(fā)現(xiàn)。AI上線時報個到，說說自己叫啥、能干啥。其他AI可以查"現(xiàn)在誰在干活""誰在改auth模塊"。

消息系統(tǒng)。支持私聊、廣播、頻道、線程、表情反應。一個AI改完代碼，廣播一句"auth模塊重構完了，求review"，另一個AI就能接過去。

共享狀態(tài)。帶命名空間的原子鍵值存儲，支持CAS（Compare-And-Swap，比較并交換）操作。兩個AI同時想搶一個鎖？CAS保證只有一個能成功，跟編程里的互斥鎖一個原理。

還有個WebSocket驅(qū)動的實時儀表盤，跑在localhost:3421，能看到所有AI的狀態(tài)、消息流、頻道占用。調(diào)試多AI協(xié)作時，這玩意兒比看日志直觀十倍。

實際用起來什么感覺？

Keshrath現(xiàn)在的日常是這樣的：

三個Claude Code會話，分別叫`claude-implementation`（寫代碼）、`claude-review`（審查）、`claude-testing`（測試）。它們通過頻道和狀態(tài)鎖協(xié)調(diào)，誰拿到了鎖，誰就能獨占某個任務。

「以前三個AI同時改一個文件，我得手動解決沖突?，F(xiàn)在它們自己會排隊。」他在項目README里寫道。

具體場景：implementation寫完一個函數(shù)，廣播到`#code-review`頻道。review看到消息，檢查狀態(tài)鎖是否空閑——空閑就認領，忙就等著。test等review通過了再接手。全程不需要人介入。

安裝也簡單。npm全局裝一下，MCP配置里加幾行，儀表盤自動啟動。非MCP的客戶端走REST API，功能完全一樣。

這玩意兒為什么現(xiàn)在才出現(xiàn)？

多AI協(xié)作的需求其實早就有，但之前大家的思路是"讓一個大模型變強"，而不是"讓多個模型會說話"。

Claude Code、Codex CLI這些工具的設計假設是：一個用戶配一個AI。但真實開發(fā)里，分工是天然的——有人寫，有人審，有人測。AI復制這個模式，就得解決通信問題。

agent-comm的聰明之處在于不挑模型。MCP是Anthropic推的開放協(xié)議，但Keshrath沒把自己綁死在Claude生態(tài)里。Codex CLI、Gemini CLI、Aider都能接，甚至你自己寫的腳本也能走HTTP API。

「我不想造一個只有Claude能用的東西?！顾f。

共享狀態(tài)的設計也挺務實。很多多AI方案想搞復雜的共識算法，agent-comm直接用最樸素的CAS——夠用，好懂，不容易出bug。開發(fā)者自己決定什么該鎖、什么該廣播，靈活度留足。

開源社區(qū)的反饋

項目放出來兩周，GitHub star數(shù)沒爆，但issue區(qū)很活躍。跑出來的需求包括：Slack/Discord集成、更細粒度的權限控制、持久化存儲（現(xiàn)在重啟服務器狀態(tài)就丟了）。

有個用戶反饋挺典型：「我試了四個AI一起重構遺留代碼，以前根本不敢想。現(xiàn)在它們自己分模塊，沖突降到零?！?/p>

當然也有吐槽。有人覺得MCP配置還是太麻煩，希望有更傻瓜的一鍵啟動。Keshrath的回應是直接甩了個Docker Compose模板。

他自己每天在用，迭代頻率很高。最新加的功能是模板系統(tǒng)——快速回復常見問題，存代碼片段復用。

多AI協(xié)作這件事，現(xiàn)在還處于"能用"到"好用"的過渡期。agent-comm不是唯一方案，OpenAI的Swarm、AutoGen這些框架也在探索類似方向。但Keshrath的切口很小：不做編排邏輯，只做通信層。這個定位讓他跑得比大框架快。

如果你也在同時開多個AI窗口寫代碼，現(xiàn)在有個問題：你會愿意給它們裝個"對講機"，還是寧愿繼續(xù)當那個手動合并沖突的人？