yetone/cumora 深度体验：2.6k stars 的「AI Agent 团队聊天室」，把 Claude Code / Codex 装进 Slack 同款 Kanban + 真收发邮件

发表于 分类于
2669 stars · yetone 新作 Cumora：AI Agent 作为一等公民的跨平台团队聊天工具，原生集成 Claude Code / Codex，支持真收发邮件与 Kanban/日历协作。

前两天刷 GitHub Trending 的时候，我看到一个名字特别眼熟 ——yetone/cumora。点进去一看，2,669 stars，整个 repo 创建于 2026 年 8 月 17 日，距离现在也就三天，commit 却已经滚了 30 多条，issue 列表里 32 个 fix 全是同一个礼拜内开的。

「这不就是 yetone 又开新坑了吗？」我心里咯噔一下。

熟悉中文开源圈的朋友大概都知道 yetone：openai-translator、avante、bailian-cli，哪个不是他一个人扛出来的。openai-translator 最早把 ChatGPT 翻译塞进 macOS 菜单栏，avante 在 Neovim 里复刻 Cursor 体验，bailian-cli 是阿里云百炼的命令行封装 —— 他的项目永远带着「让 AI 真正进入我的工作流」这股劲。

cumora 的副标题是 Where agent teams gather——「Agent 团队的聚集地」。打开 README 第一眼，它写着：

Cumora is cross-platform team chat where AI agents are first-class participants alongside humans — same roster, same DMs, same group conversations, same Kanban board and calendar.

说人话：它是一个跨平台团队聊天工具，AI Agent 在这里和人类有完全一样的身份、一样的 DM、一样的群聊、一样的 Kanban 看板和日历。

换句话说，它不是「给 AI 接一个 IM」的 wrapper，它是把 Agent 当成和老板同事一样的「同事」来设计的产品。

这篇文章，我就想认真拆一下它到底做了什么、怎么做到的、适合谁用、又有哪些坑。

一、为什么我们需要「Agent 一等公民」的聊天工具

1.1 当下的问题：Agent 还在「客座」状态

过去两年我把 Claude Code、Codex、各种 Coding Agent 当成工具用。它们很猛，但本质上还是「一个进程」，你 @ 它，它回，你不动它，它就在后台睡。

问题是：团队协作不是这种单点行为。

假设我现在的博客写作工作流是这样的：

  • 上午 9 点：和小伙伴对一遍今天的选题
  • 上午 10 点：调研 GitHub Trending，挑一个项目
  • 上午 10:30：和设计同学过一遍排版
  • 下午：写正文、贴图、配链接
  • 晚上：commit、push、回复评论

如果我想让一个 Agent 接管其中某些环节 —— 比如「调研 Trending」，我其实希望这个 Agent 是常驻的、有记忆的、能在我开会的时候把结论推进 Kanban、能在群里主动 ping 我的。

但现实是：

  • Claude Code 是一个 CLI 工具，你启动它就醒，不启动就睡；
  • 它没有「同事身份」，我在 Slack 里 @ 它，Slack 不认识它；
  • 它没有「真人协作的边界感」—— 它不知道我现在是不是在开会，是不是在 review 代码，是不是在想别的事。

cumora 想解决的就是这件事。它不是「又一个聊天工具」，而是把 Agent 提升到和人类同事完全对等的座位。

1.2 yetone 的切入点：他不想做 Slack 替代品

如果你只看 README 表面，「cross-platform team chat」很容易让人误读成又一个 Slack/Discord 替代品。

但 cumora 不是。它的差异点写得很清楚：

Agents don’t just answer when poked: they hold personas and memory, claim work, coordinate with each other without colliding, send and receive real email, and run on either Cumora’s cloud or your own machine.

四个关键词：personas（人设）、memory（记忆）、claim work（认领工作）、coordinate with each other（互相协作）。这些都是 Slack 不会主动做的。

而且项目仓库名 cumora 也暗示了它的定位 ——Cumora 是太平洋上的一座火山岛（库莫拉岛），既是团队「聚集地」，又有「沉静 + 爆发」的气质。

1.3 我为什么这次选它写

近一个月博客我已经写过：

  • cloudflare/computer（Cloudflare 给 agent 提供云端 sandbox）
  • omniroute（AI 网关，统一 237 家 provider）
  • cordiverse/paper（agent 元框架）
  • multica（Claude Code 团队管理平台）

它们都在做「Agent 基础设施」：沙箱、网关、框架、调度。但「Agent 在团队里到底以什么身份存在」这件事，没有人认真做过产品级设计。

cumora 是我看到的第一个敢把 Agent 摆到「团队成员」位置上的开源项目。再加上 yetone 的品控、对 CLI 的执念、对 AI 工作流的直觉 —— 我觉得它值得一篇长文。

二、核心功能：六块积木搭起一个「Agent + 人类」的混合团队

cumora 的产品形态我读完文档后画成六个层次：

2.1 第一块：Computer——「Agent 永远跑在一台机器上」

这是 cumora 最反直觉的设计。它引入了一个概念叫 Computer：

Rather than bolt BYOA on as a special case, Computer is a first-class product concept that every agent shares: an agent always runs on some Computer.

也就是说，任何 agent 都属于某个 Computer。Cumora 内置两种：

  • ☁ Cumora Cloud：官方托管的 Computer，每个企业租户自带一个，agent 跑在 K8s pod 里
  • 💻 Your Computers：你自己 pair 的机器（Mac、VPS），跑 daemon 接管 agent

示意图（来自 BYOA.md）：

1
2
3
4
5
6
7
8
9
10
11
Computers
──────────────────────────────
☁  Cumora Cloud      ● online
   engine: managed · 4 agents

💻 MacBook Pro        ● online
   Claude Code · 3 agents
   "Iris is thinking…"

🖥  prod-vps-01        ○ offline
   Codex · 2 agents

这种抽象有个隐藏好处：把「云 agent」和「本地 agent」统一成一个心智模型。你不用关心一个 agent 是云端跑还是本地跑 —— 它就在那个 Computer 上，Computer 在线它就醒，Computer 离线它就睡。

2.2 第二块：BYOA—— 把 Claude Code / Codex 接进 daemon

BYOA（Bring Your Own Agent）是 cumora 最实用的入口。它的逻辑是：

你的 Claude Code 订阅是自己的，你不想把 API key 交给任何平台。Cumora 在你的机器上跑一个 daemon，daemon 把你的本地 Claude Code / Codex CLI 当成「大脑」，Cumora 服务端永远见不到你的 key。

在 BYOA 模式下，整个协作链路是这样的（精简版）：

1
2
3
4
5
6
msg.new → scheduler.wakeOne → (BYOA host: SKIP pod) → publish wake
                                                            │
        cumora agent computer (daemon, laptop/VPS) ◄────────┘ SSE
        debounce → small-brain triage → persistent engine session turn
        the engine IS the loop (its own context, tools, compaction)
        bash → `cumora` shim → /runtime/cli → DB   (unchanged)

注意一个细节：daemon 不是用每条消息去 spawn 一个新的 claude CLI 进程。它跑的是「persistent engine session」—— 一个常驻的 claude/codex CLI 子进程，daemon 通过 --input-format stream-json --output-format stream-json 跟它对话。

这个设计带来三个直接好处：

  1. 延迟：常驻 session 不需要每次冷启动，几百毫秒就能开始推理；
  2. 上下文：engine 自己的上下文管理（compaction、memory）能 work；
  3. 成本：每次只有「真正需要发言」时才让大模型跑一轮，平时 daemon 自己的 small-brain（triage 模型）做门卫。

2.3 第三块：双重「脑」路径：Cloud 和 BYOA

我前面提到 Cumora 有两种 brain 模式，这里详细对比：

Cumora Cloud（managed loop）：

  • 服务端跑 turn.ts，一个多 hop 的 tool-calling loop
  • 每个 agent 住在一个 K8s pod 里（agent-computer 镜像）
  • 引擎是 OpenAI Responses API，工具包括 bash、files、browser、email、memory、skills
  • 一句话：服务端全包

BYOA（user loop）：

  • 服务端绕过 turn.ts，只负责把 wake 事件推送到 daemon
  • daemon 自己的 persistent engine session 跑 turn
  • 大脑就是用户本地的 Claude Code 或 Codex CLI
  • 用户订阅、用户 key、用户配额
  • 一句话：服务端只做「事件投递 + 仲裁 + UI」

两种模式的 agent 在 Cumora UI 里看起来完全一样：都是 kind='agent' 的 participant，都出现在 roster、DM、群聊、Kanban 里。你只看到一个「Iris」，看不到她住哪个 Computer。

2.4 第四块：真收发邮件 ——Agent 不只是「聊天框里的角色」

这是我看到 cumora 时最惊艳的功能之一。Agent 不是只在 Cumora App 里发言，它能真发、真收邮件。

技术栈是这样搭的（来自 README + email.md）：

  • 发出：服务端通过 Resend API 发邮件，每个 agent 有独立 mailbox
  • 收信：Cloudflare Email Routing 把 *@your-team.cumora.ai 全部转发到一个 Cloudflare Worker
  • Worker（email-gate）：解析邮件、识别是哪个 agent、推 SSE 到 daemon、写入 Postgres

这意味着一个真实的客户写邮件给 iris@your-team.cumora.ai，Iris 真的能收到并回复 —— 而这件事完全不需要 Claude Code 在前端暴露 IM 接口。

文档里有一句很冷静：

per-agent real email (Resend out, Cloudflare Email Worker in)

它把这件事当作 first-class 功能，而不是 demo。

2.5 第五块：Kanban / Calendar / DM / 群聊 —— 日常协作的四件套

README 上说得很朴实：

same roster, same DMs, same group conversations, same Kanban board and calendar

翻译过来就是：Slack 的核心组件它都有，但多了两件事：

  • Agent 也能 claim Kanban card：agent 不是被动「被 @ 才动」，它能主动 claim 一张 ticket、自己推进、最后 comment
  • Agenda 唤醒：agent 不只是被动响应消息，它能从 Kanban due date /calendar slot 主动被唤醒（maybeAgendaTurn 走 /runtime/agenda，stall-nudge 节流）

benchmarks/ 目录下还有真实的 LLM 多智能体协作 benchmark——chain /counting/werewolf /kanban。这说明 cumora 团队真的在做可复现的 agent 行为测试。

2.6 第六块：跨平台 —— 同一份 React 组件，5 个壳

技术栈选型上 cumora 很工程化：

路径 是什么
src/ React 渲染层，desktop/mobile/web/admin 复用同一套组件
server/ API + WebSocket + agent runtime（Express + ws + Postgres + Redis）
electron/ 桌面壳，自动更新走 yetone/cumora-releases
ios/, android/ Capacitor 原生壳，包名 io.cumora.app
agent-cli/ 发布的 npm 包 cumora，BYOA daemon 用户本地跑的就是它
agent-fuse/ Go FUSE driver，把 agent 的工作目录挂载进 cloud pod
workers/ Cloudflare Workers：email-gate（入站邮件）、r2-gate（签名 CDN）
benchmarks/ 真实 LLM 多智能体协作 benchmark

GitHub 语言统计也很说明问题（按字节数）：

  • TypeScript: 4,697,689 字节（主体）
  • JavaScript: 155,190
  • CSS: 68,217
  • Swift: 19,493（iOS）
  • Shell: 15,002
  • Go: 13,524（FUSE driver）
  • Dockerfile: 12,741

这是一个「正经工程」而不是「demo 拼凑」的项目。既有 Web 全栈，又有原生壳，又有 system-level Go 驱动，又有边缘 Workers。

三、技术架构：把 7 层防御讲清楚

cumora 最让我佩服的部分是它处理「多 agent 在同一房间里不撞车」的方式。README 上一句话轻飘飘带过，但 BYOA.md + COORDINATION.md 一共加起来 6 万多字节，几乎全是工程细节。

3.1 多 agent 协作的两个失败模式

COORDINATION.md 一上来就定义了多 agent 协作的两类失败：

  1. Race collisions—— 两个 agent 同时醒来，决策一模一样，都 INSERT 进 messages。经典案例：Iris 和 Marcus 在 counting game 里同时发 "3"。服务端能做的是 INSERT 前的「我上次看到的」新鲜度检查。
  2. Brain misjudgment——agent 看到的状态是对的，但大脑做了错误决策（重复发、跳号、倒退）。这种只能靠 prompt 软约束，服务端抓不到。

关键洞见：

Distinguishing these matters: never add a prompt rule when a code mechanism is the right fix, and never add a code mechanism when the brain’s making a clear decision in front of correct state.

这句话翻译过来：能用代码解决的，不要加 prompt 约束；大脑在正确状态前做错决策的，不要加代码机制。这条原则贯穿整个 cumora 的防御体系。

3.2 十一层防御（来自 COORDINATION.md）

我把 cumora 的「防御层」按硬 / 软列出来，按从硬到软排：

硬约束（代码层）

  1. Per-agent model pin（部署层）：服务端用 CUMORA_DEFAULT_CLAUDE_MODEL=claude-opus-4-7 固定模型，避免本地 claude CLI 默认模型在 2026-05-31 那次悄悄从 opus-4-7 切到 opus-4-8 导致行为漂移。
  2. Per-computer big-brain concurrency cap（daemon 层）：CUMORA_BYOA_MAX_CONCURRENT_BIG_BRAIN，默认 6；之前是 2，7-agent 群聊排队 215-359s。BigBrainSemaphore 在 spawn 前 acquire，finally release。
  3. Deterministic spawn spacing：500ms 的最小 spawn 间隔，替代了原来的 random (0..1500ms) jitter。原因：随机 jitter 在 4 个同时醒来时可能都落在低值上，仍然 burst 到 provider；间隔是构造上 1/interval 的硬上限。
  4. Per-computer small-brain triage concurrency cap：triage 模型也有 cap，避免大模型和小模型互相挤占。
  5. Seen-cursor freshness gate：服务端在 agent 真正 INSERT 之前做「你上次看到的更新 vs 现在」的对比，过期的回复被 HOLD 并喂回新消息让 agent 重新决策。
  6. Atomic claims：agent 对 Kanban card / 工作单元用 SELECT ... FOR UPDATE 拿锁，atomic claim 后才能修改。

软约束（prompt / UI 层）

  1. Small-brain triage：daemon GET /runtime/inbox-triage/payload，先让 haiku /gpt-5.4-mini 跑 triage 决定是不是真要唤醒大模型。rate limit 时 fail-closed 指数退避。
  2. GLANCE_YIELD_RULES：每次大模型 turn 都被要求「glance before posting」—— 发消息前先看一遍最新 unread digest。
  3. memory/ MEMORY.md digest：每轮把 agent 自己的 memory 摘要喂进去，避免「我忘了我叫什么」。
  4. Same-turn steering：DM / @mention / 人类消息在 turn 中到达时，在下一个安全 stream 边界注入；群聊普通活动只发 content-free nudge。
  5. invariant scaffold（一次性）：CLI 用法、共享的 GLANCE_YIELD_RULES、memory 规则、隐私边界通过 --append-system-system-prompt-file（Claude）或 developerInstructions（Codex）一次性塞进 session，不占每轮 token。

这一套防御体系不是营销话术，是真的在 COORDINATION.md 里有「chain-with-absent-member」基准测试的数据支撑：

T10 of the “千里之行始于足下” chain test (8-char relay, 6 active agents, 1 deliberately absent) landed 8/8 in-order, 0 dups, complete=true, with nova covering the absent member by contributing three times.

8 字符接力，6 个 active agent 加 1 个故意缺席 ——8/8 正确顺序、零重复、complete=true。这种 benchmark 不是 toy，是真的在压测 Cumora 的协作能力。

3.3 真实问题：本地 Claude CLI 池共享 account 的 burst 限制

cumora 文档里有一个非常具体的失败复盘：

when N agents on the same computer wake on the same SSE fanout, without this they all hit Anthropic’s short-window burst limit and get “Server is temporarily limiting requests · Rate limited” in lockstep (observed: 130 rate-limit hits in 17 minutes during a 7-agent counting game).

这段描述直接告诉读者：「在 17 分钟内，130 次 rate limit 命中，发生在 7-agent counting game 里」。

它没有藏着掖着，而是把真问题暴露出来，再一步步告诉你怎么解决。

这就是 yetone 一贯的工程态度：先承认你的失败模式，再讲怎么修。

3.4 成本账本：每一次 LLM 调用都被记账

README 里有一个看似不起眼的细节：

every LLM call — cloud or BYOA — lands in one llm_calls cost ledger

所有 LLM 调用（云端和 BYOA）都进同一本账。

这条在企业级 AI 落地里非常关键。我自己用 Claude Code 一直苦于「agent 在我的机器上跑了多少 token、花了多少钱」看不到 —— 除非你本地自己起 Prometheus。Cumora 把这件事做成了「基础设施」：

  • /runtime/llm-calls 接收每次 hop 的 token usage
  • 统一写入 llm_calls 表
  • 跟 cloud turn 的数据放在一个视图里查询

这意味着运营一个 AI 团队，财务透明度是 by-design 的。这一点对于要把 Agent 团队引入公司的人，太重要了。

四、怎么用 / 快速上手

cumora 的快速启动分两条路：Cumora Cloud（最快）和 BYOA（最实用）。

4.1 Cumora Cloud 试用（5 分钟）

如果只是想看 demo，最快是直接到 cumora.ai 注册。文档提到：

  • 注册后会自动 seed 一个 starter team：6 agents、3 humans、9 conversations
  • 空数据库 seed，所有 chat 里看到的消息都是实时产生的 —— 不是回放
  • 这是一个「让产品自己说服你」的设计：上来就看到一个真实运转中的多 agent 团队

4.2 BYOA 本地启动（30 分钟）

如果你有自己的 Claude Code / Codex 订阅，想让 daemon 接管你本地的 agent：

前置依赖（macOS）：

1
2
3
brew install postgresql redis node
brew services start postgresql
brew services start redis

创建数据库：

1
2
createdb -h localhost cumora
export OPENAI_API_KEY=sk-...

克隆 cumora 仓库：

1
2
3
4
git clone https://github.com/yetone/cumora.git
cd cumora
npm run setup          # install root + Email Worker dependencies
npm run dev:all       # Vite renderer on :5180 + API server on :5181

打开浏览器 http://localhost:5180 就能看到 PWA 模式。要桌面端就：

1
npm run electron:dev

环境变量（只有 OPENAI_API_KEY 是 hard-required）：

变量 默认
DATABASE_URL postgres://$USER@localhost:5432/cumora
REDIS_URL redis://localhost:6379
OPENAI_MODEL / OPENAI_MODEL_SUPPORT big-brain /support-brain 模型
PORT 5181

可选功能（OAuth 登录、Resend + Cloudflare Email Routing、R2 storage、APNs/FCM push、sub2api per-user LLM gateway、waitlist、metrics）都在 .env.example 和 server/src/env.ts 里。

装 BYOA daemon 到你的机器：

1
2
npm install -g cumora
cumora agent computer

Daemon 启动后会生成一个 pairing code，你在 Cumora web app 里输入就能把你的 Mac 加为「Your Computer」。之后你在 Cumora UI 上创建的 agent 可以选住在 cloud 还是你的 Mac 上。

4.3 跑 benchmark（看 cumora 怎么测自己）

1
2
3
4
npm test                  # unit tests (node:test) for server + workers
npm run test:integration  # integration suite (needs local Postgres/Redis)
npm run typecheck && npm run server:typecheck
npm run guard:big-brain   # CI guard: only agent turns may use the big model

最后一条 guard:big-brain 非常有趣：CI 守卫，确保只有「agent turn」能调用大模型 —— 这是 cumora 在控制成本上的硬约束。

五、总结：cumora 适合谁？局限在哪？

5.1 适合谁

我把 cumora 的目标用户分成几层：

第一层：AI 重度玩家 / 独立开发者

你已经在用 Claude Code / Codex，但苦于它们没有「协作感」。cumora 让你把多个 agent 装进一个 IM 视图，看它们互相 ping、claim Kanban、推进工作流。这件事在 2026 年的工具链里仍然非常罕见 —— 因为大多数 agent 工具还停留在「一个 agent 对一个用户」的模型。

第二层：内容创作者 / 数字游民

如果你像我一样同时在做：写博客、运营社交、做调研、维护项目，cumora 的 Kanban + Calendar + 真收发邮件组合，是最贴近「一个人 + 多个 agent」工作流的工具。它不像 Slack 那么重，也不像 Obsidian 那么散。

第三层：AI 团队建设者

如果你要给公司搭一支「AI Agent 同事」团队，cumora 的：

  • 统一身份（Computer 概念）
  • 真实邮件链路
  • 统一 cost ledger
  • 完整 benchmark 工具集
  • 跨平台壳（Web + iOS + Android + Electron）

—— 是少见的「能直接落地」的开源方案。不是 demo，不是白皮书，是一个真的能跑的产品。

第四层：AI 工程研究者

cumora 的 benchmarks/ 目录、docs/COORDINATION.md 的十一层防御、docs/SHIPPING.md 的「evidence-backed feature lifecycle」—— 这些都是公开的研究素材。如果你做 agent 协作研究，cumora 是一个开源的真实系统可以拿来切片。

5.2 局限在哪

老实说，我也得指出 cumora 的几个边界：

1. 还是 early stage

仓库 2026-08-17 才创建，三天时间 commit 滚了 30+、issue 开到 32—— 这既是优点（活跃），也是缺点（早期）。生产环境用要谨慎。我建议先在 BYOA + 本地 daemon 的路径上玩通，再考虑 Cloud 方案。

2. 强依赖 OpenAI Responses API

Cumora Cloud 的 managed loop 跑在 OpenAI Responses API 上，BYOA 虽然支持 Claude Code 和 Codex，但 triage 模型仍可能用 OpenAI 小模型（haiku /gpt-5.4-mini）。如果你想全栈自托管 + 全栈非 OpenAI，目前还要等。

3. 真收发邮件的运维成本

Cloudflare Email Routing + Resend + Cloudflare Worker 这一套链路需要你有一个域名、能配 Email Routing、能部署 Worker。个人开发者上手可以，但「我就要一个能开箱即用的 IM」的用户会觉得重。

4. 没有「非 English first」的本地化

README、文档、CLI 输出目前都是英文（除了 BYOA.md 里举的「千里之行始于足下」chain test 是中文 case study）。如果你的 agent 主要处理中文任务，工作流没障碍，但 UI 层面暂时没有中文界面。

5. Agent 互撞的「prompt 软约束」天花板

COORDINATION.md 自己承认了：

prompts are a soft mechanism with a ceiling

再完美的十一层防御，prompt 层仍然不是 100% 的。cumora 用 benchmark 测试 8/8 正确，但更复杂的场景（比如 12 个 agent 同时 debating）我没看到公开数据。

5.3 我的判断

如果要我给一个 TL;DR：

cumora 是 yetone 把「AI Agent 当同事」这件事严肃做了产品级落地的尝试。2,669 stars 是个开始，但它的设计深度（十一层防御、统一 Computer 抽象、cost ledger、benchmark 集）远超同期 90% 的「AI 协作工具」。

我会继续观察：

  1. v0.2 是否引入非 OpenAI provider 的 managed loop；
  2. iOS / Android 端的 Capacitor shell 稳定性；
  3. benchmarks/ 是否会公开更多真实多 agent 协作数据；
  4. 是否有第三方贡献者开始写 plugin（类似 Botkit / Zapier）。

末尾：项目链接

如果你已经玩上了 Claude Code 但总觉得「还差点什么」，先在 cumora.ai 注册看一眼 starter team，再决定要不要本地跑 BYOA。你大概率会被那个「6 个 agent 自己开会、自己认领 Kanban、自己发邮件」的 starter team 打动 —— 因为它让你第一次看到 AI Agent 不是你的工具，是你的同事。

一句话总结：Cumora 把 AI Agent 从「进程」提升到「同事」，yetone 用 11 层防御体系解决了多 agent 协作的撞车问题，是当下最值得认真看的 Agent 协作平台之一。