Cumora 解读：把 Agent 放进群聊后，真正难的是别让它们互相撞车
Cumora 把人和 Agent 放进同一套群聊、看板、日历与邮件系统。它真正有意思的地方，是用确定性规则约束多个 Agent 的主动性。
文章目录
假设你把 7 个 Agent 拉进一个群，要求它们依次接完“千里之行始于足下”这 8 个字。
其中 1 个 Agent 故意不响应。剩下 6 个需要自己判断谁先说、什么时候轮到自己，以及发现同伴缺席后要不要多承担一步。它们还不能重复、抢答或把顺序打乱。
这不是我虚构的场景，而是开源项目 Cumora 在协调文档中保留的一组真实模型实验。
前 6 轮测试里，团队最好只完成 7 个字。有的 Agent 认为“我已经贡献过一次”，不愿再接；有的把一次特殊游戏学成长期记忆，之后继续保持沉默。开发者加入“团队要适应成员缺席”的原则后，所有字终于出现了，但结果一度变成 10 个、11 个——Agent 太积极，重复也跟着来了。
直到第 10 轮，系统才得到 8 个字、顺序正确、没有重复的结果。一个名叫 Nova 的 Agent 补了 3 次位，那名离线成员从头到尾都没有恢复。
这个实验很适合解释 Cumora，因为它暴露了多 Agent 产品最容易被低估的问题：让多个 Agent 都能行动不难，难的是让它们在共享状态不断变化时，既愿意接手，又不会一起撞上去。
Cumora 不是多人聊天室里多放几个机器人
Cumora 是一个 MIT 开源的跨平台团队协作应用。人类与 Agent 出现在同一成员列表中，使用同一套私聊、群聊、看板和日历。Agent 还能拥有独立人格、记忆、状态与邮箱，主动发起对话或认领工作。
截至 2026 年 8 月 31 日，GitHub 页面显示这个项目约有 3.3k Stars、410 Forks，最新版本为 v0.9.0。客户端覆盖 Electron、PWA 和 iOS；Android 源码已经存在，但 README 说明尚未正式发布。官网仍标注 preview 与 invite-only，因此这些数字更适合说明它正在快速获得关注，不能直接当成生产成熟度证明。
下面这张官方截图更直观地展示了它的产品假设：Agent 不是藏在侧边栏里的问答入口，而是和人类一起出现在团队空间里。
这会改变系统需要解决的问题。
普通聊天机器人只在收到 Prompt 后生成一次回答。团队成员却需要知道谁在场、谁负责什么、房间里刚发生了什么、什么时候应该主动开口，以及什么时候沉默反而更好。
移动端延续了同一套成员结构。官方截图中，Agents、Humans、群聊与私聊出现在同一个会话入口，Agent 还会显示正在输入和在线状态。
因此，我更愿意把 Cumora 理解成一个面向 Agent 团队的协作层。它当然包含聊天产品，但它真正要管理的是 Agent 的身份、唤醒、任务、共享状态、执行入口与行为边界。
它先把“脑”和“工作场所”拆开了
Cumora 给 Agent 提供两条运行路径。
第一条是 Cumora Cloud。每个 Agent 运行在独立的 Kubernetes Pod 中，由服务端通过 OpenAI Responses API 执行多轮工具调用。
第二条是 BYOA，也就是 Bring Your Own Agent。用户在自己的 Mac 或 VPS 上运行 npx cumora agent computer，再让本地 Claude Code、Codex CLI 或其他兼容 CLI 充当 Agent 的推理引擎。模型费用和限额属于用户自己的账号，Cumora 服务端不保存对应的模型供应商密钥。
这两条路径的重点不是支持了多少模型，而是它们共用同一套行动接口。
无论“脑”在云端 Pod，还是用户自己的机器，Agent 最终都通过 cumora CLI 回复消息、读取记忆、更新看板、创建文档或操作日历。也就是说，模型负责判断下一步做什么，Cumora 负责把动作变成可授权、可记录的系统请求。
一条 BYOA 消息大致会经过下面这条链路：
这层解耦带来两个实际好处。
一是模型可以替换，团队协作界面不必跟着重写。二是动作不会因为来自本地 CLI 就绕过服务端。项目的安全文档明确把服务端定义为授权边界：Agent 身份来自签名 JWT，而不是请求正文；租户隔离在 SQL 层完成，客户端一律不被信任。
多 Agent 撞车，至少有两种不同原因
Cumora 的协调文档把问题拆成两类，这个区分很有工程价值。
第一类是并发竞争。两个 Agent 在同一时刻看到数字“2”，都决定发送“3”。它们的判断各自都合理，只是写入数据库时互相不知道对方也在行动。
第二类是模型误判。Agent 已经看见最新消息，却仍然重复、跳步或抢在更早认领任务的同伴前面行动。这时状态并不陈旧，错的是模型在正确上下文中做出的决定。
把这两类问题分开后，修复位置也会变得清楚：
前者适合用代码解决，后者只能靠更清楚的原则、反馈与验收约束。把两者混在一起，常见结果就是不断往 Prompt 里加规则，却没有真正关闭数据库竞争窗口。
Cumora 现在采用的是多层防线。
消息先经过约 2.5 秒的 debounce，也就是把短时间内连续到达的唤醒合并成一次。接着，一个便宜的小模型只判断“这件事值不值得叫醒正式模型”。只要有人类参与或等待，默认就进入正式处理；纯 Agent 对 Agent 的寒暄、附和和无任务闲聊则可以被压掉。
正式模型准备回复时，服务端会比较它最后看见的消息序号。如果房间里已经出现更新内容，这次回复不会直接写入，而是返回一个 HELD 结果，把新消息交给 Agent 重新判断。
仅靠发送前检查还不够。两个请求可能同时通过检查，再先后写入，这就是典型的 TOCTOU（检查时与使用时状态不一致）问题。Cumora 又在数据库事务里锁住会话序号，重新比较上一条非本人消息；如果正文逐字相同，就回滚并拦截。
任务认领也不是一句“我来做”。看板卡片使用原子更新，只有一个 Agent 能把真实任务认领到自己名下。项目甚至删除了通用字符串锁，因为 Agent 曾把“我是第三个认领的人”错误理解成“我应该发送第 3 个数字”。现在，认领只服务于真实交付物，而不是让模型把锁本身当成游戏规则。
这些做法背后有一条很清楚的原则：模型负责判断，代码负责维护不能被协商的事实。
主动性不能只靠定时器，还需要停止条件
Cumora 强调 Agent 不必等人点名。它们可以根据日程、看板或停滞会话主动醒来。
但“主动”如果没有停止条件，很快会变成另一种故障：多个 Agent 互相追问、确认、附和，持续消耗模型额度，却没有推动任何真实工作。
Cumora 为此把“是否有人类在关注”和“是否存在已认领工作”作为服务端事实传给 triage 小模型。对已经认领的会话，系统允许 Agent 围绕任务多交互一段时间；对没有任务、也没有人类关注的会话，一旦消息数量超过参与 Agent 数量，说明至少有人开始第二轮发言，系统就把它视为可能的循环。Agent 私聊也不是永远放行，而是每 8 条消息重新检查一次。
停滞任务则走另一条路径。安静 5 分钟到 6 小时的会话会进入主动唤醒判断，但同一停滞状态只允许一个 Agent 赢得提醒资格。如果分类模型不可用，系统只为一个非常窄的情况启用确定性兜底；连续 3 个被唤醒的 Agent 都认为不该行动后，系统停止继续烧 Token，直到会话状态真正改变。
这比“每隔 5 分钟让所有 Agent 看一眼”复杂很多，却更接近一个可长期运行的团队系统。主动性不是唤醒次数，而是系统能否证明这次唤醒有新的决策价值。
最值得看的，其实是它公开记录的失败方案
很多开源项目只展示最后留下来的架构。Cumora 的 COORDINATION.md 还记录了多种已经撤掉的方案，以及它们为什么失败。
例如，开发者曾向 BYOA 的常驻 Prompt 塞入完整人格规则和 CLI 命令目录，希望云端与本地 Agent 的表现更一致。结果 Agent 回复变得更花哨，协调规则反而更难被模型注意；计数实验从零碰撞退化到每轮出现一到三次碰撞，首条消息也明显变慢。
他们也试过随机延迟，让同时被唤醒的 Agent 各自等待 0 到 1.5 秒。但随机数不能保证错峰，几个 Agent 完全可能一起抽到较小值。最终方案改成确定性最小间隔，并在遇到限流后自动把间隔翻倍，连续成功后再逐步缩短。
另一个更典型的教训来自 --send-anyway。它原本用于 Agent 看过 HELD 的新消息后，仍确认自己的回复应该发送。但 Agent 为了减少工具往返，学会了在第一次发送时就预先加上这个参数，安全门槛等于被架空。
现在，只有服务端先返回过一次 HELD，才会生成一个短期、绑定当前消息序号的许可。房间状态一旦继续变化，旧许可立刻失效。
这几个失败指向同一个结论：Agent 会优化你提供的接口，而不一定遵守你对接口用途的想象。可绕过的软规则，迟早可能变成默认捷径。
BYOA 降低了密钥托管压力，但没有消灭本地风险
Cumora 的 BYOA 设计值得肯定的一点，是模型进程不接触运行时 JWT，也不知道服务端 URL。固定的本地桥接程序把模型发出的有限命令交给 daemon，再由 daemon 在沙箱外附加内存中的凭据。
下面这张图把三层边界分开了。模型只能调用固定桥接工具；真正持有短期 JWT 并访问服务端的是本地 daemon。
不过，这里的安全边界需要读细。
当前“安全默认”主要覆盖满足版本和平台要求的 Claude Code 与 Codex。Claude Code 使用受限模式，禁止 Bash、PowerShell 和 Web 工具访问宿主机；Codex 使用自定义权限配置，忽略用户配置和规则，关闭命令网络、远程插件和多 Agent 工具，并只开放 Agent 自己的目录。
Grok、Cursor Agent、OpenCode、pi、Gemini、Qwen 等适配器虽然存在，但需要显式设置 CUMORA_BYOA_ALLOW_UNSANDBOXED=1 才能运行。官方把它标为高风险兼容模式，并建议只在额外的容器或虚拟机边界内使用。
另外，Agent 本地的记忆、笔记与 Skills 不会自动镜像到服务器，也不能直接在 Cumora UI 中查看。要让队友共享结果，Agent 仍需把内容写入工作区、文档或看板。
所以，BYOA 更准确的价值是：模型供应商凭据留在用户已有的本地工具链里，同时把 Agent 的外部动作收束到 Cumora 的授权接口。它并不意味着“只要本地运行就天然安全”。
Cumora 还不能证明什么
读完源码与文档后，我认为有几条边界必须保留。
首先，项目仍然很新。v0.9.0 的发布说明仍在补 Gemini 选择、triage 沙箱、进程生命周期和运行审计等问题。快速迭代说明维护活跃，也说明接口和边界还在变化。
其次，文档中的计数、狼人杀和接龙结果来自维护者自己的真实模型测试。它们比没有实验更有价值，但测试模型、配额、Prompt 和场景都很特殊，不能直接推出“任意多 Agent 任务都能稳定完成”。
再次，Cumora 解决的是协作基础设施，不是组织智能本身。原子锁能阻止两个人认领同一张卡，却不能判断这张卡是否值得做；新鲜度检查能阻止过期回复，却不能保证最新判断就是正确判断；人格和记忆能形成连续体验，也可能把一次错误经验固化成长期偏见。
最后，自托管并不轻。完整服务仍需要 Postgres、Redis、模型 API，以及按需配置 OAuth、邮件、对象存储、推送和 Kubernetes。它目前更适合愿意研究 Agent 协作机制的开发者与小团队，而不是希望下载后立刻替换 Slack 的普通公司。
它给 Agent 开发最有用的提醒
Cumora 最吸引人的口号是“AI teammate”，但源码真正提供的价值更朴素。
如果你想让多个 Agent 长期协作，不要先从“它们分别应该有什么性格”开始。先回答几个更硬的问题：什么事件可以唤醒它们？谁来判断这件事值得消耗正式模型？写入共享状态前，系统怎样发现状态已经变化？同一份工作如何只允许一个执行者认领？怎样判断对话已经停止推进？所有动作、费用和失败能否被追踪？
这些问题没有一个能靠更长的系统 Prompt 单独解决。
Cumora 目前也远没有证明 AI 已经能像成熟同事一样工作。但它至少把“同事”这个比喻落实成了一组可以检查的工程约束：有自己的身份和工作空间，能接任务，也会缺席；可以主动提出行动，但要面对权限、冲突、成本和停止条件。
这可能是 Cumora 最值得关注的地方。Agent 真正进入团队，不是因为聊天界面里多了几个头像，而是因为系统终于开始认真处理：当这些头像同时决定做事时，谁应该继续，谁应该等待，谁又必须被代码拦下来。
参考资料
-
Cumora GitHub Repository
https://github.com/yetone/cumora -
Cumora Official Website
https://cumora.ai/ -
Cumora, BYOA — Bring Your Own Agent
https://github.com/yetone/cumora/blob/main/docs/BYOA.md -
Cumora, Agent Coordination
https://github.com/yetone/cumora/blob/main/docs/COORDINATION.md -
Cumora, Shipping in Cumora
https://github.com/yetone/cumora/blob/main/docs/SHIPPING.md -
Cumora v0.9.0 Release Notes
https://github.com/yetone/cumora/releases/tag/v0.9.0 -
Cumora Security Policy
https://github.com/yetone/cumora/blob/main/SECURITY.md -
Cumora MIT License
https://github.com/yetone/cumora/blob/main/LICENSE