3 天 2683 star：cumora 把 Claude Code 拉进群聊，6 个 Agent 抢活不打架
你开两个终端，左边 Claude Code，右边 Codex，让它们一起改同一个仓库。两分钟后你收获的不是双倍效率，是两坨互相覆盖的代码和一堆冲突。
这是所有想"多个 AI 一起干活"的人都撞过的墙。本周开源的一个项目说：换个思路，别让 Agent 抢终端，让它们进群聊。
一句话：给 Agent 们开的微信群
cumora，开源 3 天，2683 star（8 月 17 日创建，作者 yetone，就是写过 openai-translator 那位）。它是个跨平台团队聊天软件——Electron 桌面端、iOS、Android、Web 都有，长的像 Slack，但聊天列表里坐着一排 AI Agent。
群里的人看到什么，Agent 就看到什么：同样的会话、同样的私聊、同样的看板。Agent 不是被 @ 才出来答一句的聊天机器人，它有人设、有记忆、会主动认领任务，还会互相派活。
关键是大脑可以自己选，两条路：
- Cumora Cloud：官方托管，每个 Agent 一个独立 pod，跑的是 OpenAI Responses API 的多轮工具调用（bash、文件、浏览器、邮件、记忆、技能都能碰）
- BYOA（Bring Your Own Agent）：在你自己的 Mac 或 VPS 上跑一个守护进程，Agent 的大脑变成你本地的 Claude Code 或 Codex，走你自己的订阅。服务器永远看不到你的 API key
第二条路是很多人 star 它的原因：不用改 workflow，npx cumora agent computer 把现有 agent 接进群聊就能试。
架构：一套 UI，两种大脑
技术栈很常规：前端 React 18 + Vite + TypeScript，后端无状态 Node 服务（Express + WebSocket），Postgres 存数据，Redis 做 pub/sub 广播，任何数量的后端实例靠 Redis 总线保持同步。Cloud Agent 跑在 Kubernetes pod 里，用 Go FUSE 驱动挂载工作区；BYOA Agent 跑在你指定的机器上。
真正值钱的部分不在栈，在协调层——这是所有人做多 Agent 都会翻车的地方。
干货：三个防打架机制，可以照抄
cumora 的 COORDINATION 文档把多 Agent 协作的问题拆成两类，这个分类本身就有价值：
- 竞态冲突：两个 Agent 同时醒来，都决定发同一条消息，都 INSERT 进数据库——服务端能在写入前拦截（“我上次看到之后有新消息吗？"）
- 大脑误判：Agent 看到的状态是最新的，但脑子还是做出了错误决定（发重复内容、跳步）——服务端拦不住，只能靠 prompt 引导，而 prompt 是软机制，有天花板
作者的原话值得记下来：“永远不要用 prompt 规则去修本该用代码机制修的问题，也永远不要在脑子基于正确状态做明确决定时，加一个代码机制去干预。”
对应三层防御：
- 陈旧消息拦截（freshness gate）：Agent 看到的是旧消息、正要回复时，服务端把回复 HOLD 住，把新消息推给它让它重新决定。相当于人类开会时被提醒"诶，这刚才已经说过了”
- 任务原子认领：真实工作单元上做原子认领，两个 Agent 不会同时抢同一张卡
- 小脑分流（small-brain triage）：小模型先筛一遍，只有值得的才唤醒大模型，省 token 也防打扰
实测数据：8 字符接龙测试，6 个活跃 Agent + 1 个故意缺席，最后 8/8 顺序正确、0 重复、complete=true，缺席成员被另一个 Agent 代答了 3 次。并发上限默认 6——测试发现并发 2 时，7 个 Agent 的广播房间要排队 215-359 秒，尾部的 Agent 在用户面前沉默半天；提到 6 之后整队能并行思考。
对比：和现有方案差在哪
| 方案 | Agent 数量 | 协作方式 | 大脑 | 门槛 |
|---|---|---|---|---|
| Claude Code / Codex | 1 个 | 独占终端 | 官方模型 | 低 |
| Agent 编排框架（如 LangGraph） | 多个 | 代码写死流程 | 自己接 | 高，要改代码 |
| cumora | 多个 | 群聊 + 看板，自由协作 | 云端或自带 | 低，装个客户端 |
Claude Code 单兵作战很强，但多开就打架；编排框架能把流程写死，但改一次逻辑要动代码。cumora 的生态位是中间：不写流程，靠"群聊 + 认领 + 拦截"把多个现成 Agent 撮合到一起。它解决的不是"怎么让 Agent 干活"，而是"怎么让一堆 Agent 不互相踩脚"。
坦白说
- 协调机制再稳，Agent 群聊的本质仍是概率系统——文档自己承认 prompt 是软机制有天花板，重要任务别完全放手
- 自部署要 Postgres + Redis + OpenAI key，不是一条命令就能跑的玩具
- 项目 3 天龄，架构文档比代码成熟，生产环境请先小范围试
想试的话
- 有 Mac 或 VPS：
npx cumora agent computer，把本地 Claude Code 接进去 - 不想碰命令行：直接用官方 Cloud，注册就有托管 Agent
- 想抄协调机制：读
docs/COORDINATION.md，那篇文档本身就是多 Agent 工程的反模式清单
给 Agent 开个群，比给它们写调度器容易得多。 至少现在，这个思路值 2683 个 star。
搬砖程序员带你飞，专注 Golang / AI / 后端。每天一篇，讲清楚一个技术真相。
