去年有个数据挺扎眼：GitHub Copilot用户里，37%的人尝试过同时开多个AI窗口写代码。结果呢？超过一半的人两周内就放弃了——不是因为AI不够聪明，是因为它们太"独"了。
每个AI都在自己的终端里闷头干活，改同一个函数、删同一行注释、甚至同时给变量起名叫`temp_fix`。开发者最后成了救火队员，专门处理AI们留下的合并冲突。
Keshrath（GitHub用户名）就是被这个问题逼疯的人之一。他日常开三个Claude Code会话：一个写实现，一个做代码审查，还有一个跑测试。三个AI各忙各的，经常把彼此的代码覆盖掉。"就像三个装修工人同时砸一面墙，没人知道对方在干嘛。"
他的解法：给AI装个"对讲机"
他做了个叫agent-comm的开源项目。本质上是个通信服务器，任何AI coding agent都能接入——Claude Code、Codex CLI、Gemini CLI、Aider，只要支持MCP（Model Context Protocol，模型上下文协议）或者能发HTTP请求就行。
核心功能就几块：
注册与发现。AI上线时报个到，说说自己叫啥、能干啥。其他AI可以查"现在谁在干活""谁在改auth模块"。
消息系统。支持私聊、广播、频道、线程、表情反应。一个AI改完代码，广播一句"auth模块重构完了，求review"，另一个AI就能接过去。
共享状态。带命名空间的原子键值存储，支持CAS（Compare-And-Swap，比较并交换）操作。两个AI同时想抢一个锁？CAS保证只有一个能成功，跟编程里的互斥锁一个原理。
还有个WebSocket驱动的实时仪表盘，跑在localhost:3421，能看到所有AI的状态、消息流、频道占用。调试多AI协作时，这玩意儿比看日志直观十倍。
实际用起来什么感觉？
Keshrath现在的日常是这样的：
三个Claude Code会话，分别叫`claude-implementation`（写代码）、`claude-review`（审查）、`claude-testing`（测试）。它们通过频道和状态锁协调，谁拿到了锁，谁就能独占某个任务。
「以前三个AI同时改一个文件，我得手动解决冲突。现在它们自己会排队。」他在项目README里写道。
具体场景：implementation写完一个函数，广播到`#code-review`频道。review看到消息，检查状态锁是否空闲——空闲就认领，忙就等着。test等review通过了再接手。全程不需要人介入。
安装也简单。npm全局装一下，MCP配置里加几行，仪表盘自动启动。非MCP的客户端走REST API，功能完全一样。
这玩意儿为什么现在才出现？
多AI协作的需求其实早就有，但之前大家的思路是"让一个大模型变强"，而不是"让多个模型会说话"。
Claude Code、Codex CLI这些工具的设计假设是：一个用户配一个AI。但真实开发里，分工是天然的——有人写，有人审，有人测。AI复制这个模式，就得解决通信问题。
agent-comm的聪明之处在于不挑模型。MCP是Anthropic推的开放协议，但Keshrath没把自己绑死在Claude生态里。Codex CLI、Gemini CLI、Aider都能接，甚至你自己写的脚本也能走HTTP API。
「我不想造一个只有Claude能用的东西。」他说。
共享状态的设计也挺务实。很多多AI方案想搞复杂的共识算法，agent-comm直接用最朴素的CAS——够用，好懂，不容易出bug。开发者自己决定什么该锁、什么该广播，灵活度留足。
开源社区的反馈
项目放出来两周，GitHub star数没爆，但issue区很活跃。跑出来的需求包括：Slack/Discord集成、更细粒度的权限控制、持久化存储（现在重启服务器状态就丢了）。
有个用户反馈挺典型：「我试了四个AI一起重构遗留代码，以前根本不敢想。现在它们自己分模块，冲突降到零。」
当然也有吐槽。有人觉得MCP配置还是太麻烦，希望有更傻瓜的一键启动。Keshrath的回应是直接甩了个Docker Compose模板。
他自己每天在用，迭代频率很高。最新加的功能是模板系统——快速回复常见问题，存代码片段复用。
多AI协作这件事，现在还处于"能用"到"好用"的过渡期。agent-comm不是唯一方案，OpenAI的Swarm、AutoGen这些框架也在探索类似方向。但Keshrath的切口很小：不做编排逻辑，只做通信层。这个定位让他跑得比大框架快。
如果你也在同时开多个AI窗口写代码，现在有个问题：你会愿意给它们装个"对讲机"，还是宁愿继续当那个手动合并冲突的人？
热门跟贴