cumora 深度研究：把 AI Agent 当“同事”拉进群聊的 yetone 新作

深度研究｜cumora：把 AI Agent 当'同事'拉进群聊的 yetone 新作 研究日期：2026-08-21 ｜ 来源：github.com/yetone/cumora ｜ 作者：yetone（avante.nvim 作者） 写法说明：本文依「去 AI 味」之诀——长短句交错、口语落地、不堆套话，间以文白。 一句话定性 cumora 想干的事很直白：让 AI agent 不再是「你 @ 一下它才动」的工具，而是跟你坐在同一间办公室的同事——同一个花名册、同一个群、同一个 DM、同一块看板、同一个日历。它会认人设、记记忆、抢活干、互相协调不撞车，还能收发真邮箱。 来路考：别被「四天」骗了 这仓库公开时间写着 2026-08-17，四天攒了 2817 星、336 fork。但根子不在这四天。 release 记录往前能追到 2026-05-29（v0.1.60），COORDINATION 文档里还标着 2026-05-28 的 prompt 基线。agent-cli 已经迭代到 v0.1.127。也就是说，私下里打磨了快三个月才掀盖子开源。星标涨得猛，秘密在这——它不是一个周末项目，是几个月成品的首次亮相。 它到底在解决什么 多 agent 协作的坑，文档里归成两类，归得很准： 竞态撞车：两个 agent 同一刻醒来，都决定发「3」，双双 INSERT。经典案例是 Iris 和 Marcus 在数数游戏里同发一个「3」。 脑判误判：看到的都是最新的，脑子却选了错动作（发重了、回退了、跳步了）。 前者靠代码机制兜，后者只能靠 prompt 塑形——文档有句实在话：「脑子在正确状态下做了清晰决策时，永远别加代码机制去管它；反之，别拿 prompt 去补本该用代码兜的洞。」这句话值钱，是踩过真坑才说得出的。 两条「脑路」——它最妙的设计 第一条，Cumora Cloud。 每个 agent 住一个托管 pod，脑子走 OpenAI Responses API 的多跳工具循环（bash、文件、浏览器、邮件、记忆、技能……）。平台替你管，永远在线。 第二条，BYOA（Bring Your Own Agent）。 你拿自己的 Mac 或 VPS，跑一条 npx cumora agent computer 守护进程，agent 的脑子就换成你本地的 Claude Code / Codex / 最新加进来的 Grok Build，用的是你自己的订阅——服务器从头到尾碰不到你的密钥。 这块便宜，是因为 cumora 把「输入输出」和「脑子」彻底解耦了：agent 干任何事都走同一个 cumora CLI 壳，壳把参数 POST 给 /runtime/cli，唤醒走 SSE。换脑子、换宿主，其余全复用。 说白了，它把「机器」抽象成了一等公民的概念叫 Computer：云上有一个托管 Computer，你自己的 Mac、VPS 是另一些。建 agent 就是「挑它住在哪台机器上」。哪台机器掉了，agent 显示「睡着」而不是「坏了」。没有特殊的 BYOA agent，只有住在不同机器上的 agent。 架构一览 层 技术 要点 前端 React 18 + Vite + TS + Tailwind desktop / web / mobile / admin 四壳共用一套组件 后端 Node 无状态：Express + ws Postgres 当唯一真源（pg 池 + Drizzle），Redis 管 pub/sub 与在线状态 伸缩 多实例挂负载均衡 靠 Redis 总线同步，实例间不打架 云 agent k8s pod 服务器用 kubectl 编排；Go 写 FUSE 驱动把工作区挂进 pod BYOA agent 用户机器上的守护进程 本地引擎常驻，走同一套 cumora CLI 协议 边缘 Cloudflare Workers email-gate（收件）、r2-gate（签名 CDN） 成本 统一账本 不论云路还是 BYOA，每次 LLM 调用都进同一张 llm_calls 协调防御层：真功夫在这里 它不是靠一句「大家排好队」就完事，而是叠了好几层，从「永远在线、不耗脑子」到「软的、靠脑子」： 每 agent 模型钉死（prod 上 claude-opus-4-7）。为啥？本地 claude CLI 曾在一次会话中途把默认从 opus-4-7 悄悄翻到 opus-4-8，多 agent 行为当场变样。不钉，Anthropic 一发模型全员漂移。 大脑子并发上限（默认 6）。早先设 2，7-agent 广播房排队排到第六深，尾部的 agent 干等 215–359 秒才出声。改 6，整队能并行想事。 出生间隔硬卡 500ms（MIN_SPAWN_INTERVAL_MS）。之前用 0–1500ms 随机抖动，结果四个同时醒能全滚到低值、照样锁死打 API。改成定长间隔，突发速率在数学上就是 1/间隔，不再靠运气。 小脑子（triage）并发上限 8。教训是 2026-06-02 刚踩的：光限大脑子忘了限 triage，全员 triage 超时 → SIGTERM → 守护进程当速率限制处理 → 整台机器静默。 新鲜度闸门（seen-cursor）：一条过时回复会被 HOLD 住，喂给它更新的消息让它重新决定。原子抢占真实工作单元。小脑子 triage 闸门替大模型挡前排。 层与层之间，是文档里反复出现的同一个哲学：能用代码兜的别用 prompt，能用 prompt 塑的别上代码。 这套东西看得出是血泪总结，不是 PPT 架构。 基准测试：敢拿真 LLM 验自己 它有一套真 LLM 多 agent 协调基准（chain / counting / werewolf / kanban），每周跑一次抓回归——专抓单元测试看不见的：竞态、社交推断陷阱、分类器宕机回退。 文档点破一个巧妙设计：chain 和 counting 是「形状对偶」。 chain：N 字顺序接龙、故意缺席一人，考「队友缺席时团队会不会补位」（nova 曾补位连发三次）。 counting：每个 agent 只说一个数、序到 K，考「有明确上限时守不守得住」。 一个考该补位时补，一个考该停时停。任一方向回归，只会在其中一个暴露。判分走统计而非逐次：要求「≥67% 试次精确完成 且 中位逐字碰撞 = 0」——既抓真回归，又不让随机噪声误报。这条思路，比大多数项目「跑通 demo 就算赢」强太多。 邮件是真的，不是摆设 每个 agent 有真地址（<participantId>.<companySlug>@<EMAIL_DOMAIN>），能发能收。收件经 Cloudflare Email Routing 进 email-gate worker，唤醒对应 agent 像处理普通消息一样。它让 agent 跟外部世界真打通了，而不只是群里自嗨。 社区信号速览 信号 数值 读法 星标 2817 四天，涨势凶 fork 336 反常地高（通常约星 1/20，这儿近 1/8） 未关 issue 9 很少，社区还在围观期 提交频度 数小时前仍有 PR 合并 极活跃 引擎 Cloud + Claude Code + Codex + Grok Build（#23 刚并） 多引擎路线在快速铺 fork 比高得反常，结合 BYOA 自托管属性，基本能断定：一大票人 fork 是为自己跑一份。 这恰恰是 BYOA 结构想点燃的那类群体。 我的判断，直说 新鲜的地方。 「agent 即同事」这条产品主线想得通，尤其 BYOA 把成本与密钥风险转给用户、又把 I/O 与脑子解耦——这是能把自托管群体点着的结构。协调防御层更是踩过真坑的血泪总结。 要泼的冷水，有三盆。 第一，云路脑子绑死 OpenAI Responses API，BYOA 才放 Claude/Codex/Grok——两头路线不一，长期是维护债。 第二，协调至今靠「prompt 塑形 + 一堆启发式闸门」，文档自己承认 prompt 是有天花板的软机制。基准只跑了小团队（6–7 个 agent），大房间的撞车率会不会非线性上涨，目前没数据。 第三，私钥永远不碰服务器是真优点，可本地守护进程的安全面（谁都能 npx cumora agent computer）得自个儿负责，文档里安全边界还写得薄。 适合谁？ 想给团队塞几个 7×24 不眠的「数字同事」、又不想把数据钥匙交出去的团队，BYOA 路线很香。只想开箱即用的，等云路上稳定性再跑一阵再说。 参考材料（仓库内） README.md — 总览与本地起法 docs/BYOA.md — 自带 agent：本地 Claude Code / Codex / Grok 当脑子 docs/COORDINATION.md — agent 如何不撞车协作（防御层 + 反模式，最值一读） docs/email.md — 每 agent 真邮箱机制 docs/SHIPPING.md — 人 agent 共用的证据驱动功能生命周期 benchmarks/ — 真 LLM 多 agent 协调基准（chain / counting / werewolf / kanban） agent-cli/ — 发布的 npm 包 cumora（BYOA 守护进程，现 v0.1.127） agent-fuse/ — 把 agent 工作区挂进云 pod 的 Go FUSE 驱动