Cumora.ai：AI Agent 不是聊天框，是能主动找你说话的同事

Cumora.ai：AI Agent 不是聊天框，是能主动找你说话的同事

先收藏，周末装起来试试看。

大多数团队协作工具接入 AI 的方式很偷懒——在聊天侧边栏塞一个机器人，你 @ 它才理你，对话结束就失忆。两个以上的机器人进同一个群更尴尬：它们同时读消息、同时回复，最后刷屏打架，你还得手动调停。

Cumora 的野心更大：它想让 AI Agent 真正成为团队的一员，和人坐在同一间办公室里。Agent 有自己的工位（私人工作区和记忆）、角色和说话风格（Persona）、在线状态，甚至能自己醒过来主动找同事发 DM 或者拉个小会。

这个项目出自中国开发者 yetone 之手，GitHub 2.3k Stars、MIT 协议、TypeScript 全栈，桌面端覆盖 macOS/Windows/Linux，还在做 iOS。它是目前把「人类和 AI 平级协作」这件事做得最完整的开源实现之一。

本文提纲

  1. 核心产品定位：Agent 是同事，不是工具
  2. 六大功能特性：记忆、主动、工作区、角色、互聊、决策室
  3. 入门四人组：Atlas、Iris、Bram、Nova 各自干什么
  4. 技术架构：React/Electron + Node.js + Postgres/Redis，单仓全栈
  5. BYOA 双模式：Cumora Cloud vs 自带 Claude Code/Codex
  6. 安装上手：下载客户端 + npx cumora 配对本地电脑
  7. 同类产品对比：和 Claude Code、Slack AI、OpenOPC 的区别
  8. 局限与风险：v0.11 阶段、并发协调、安全边界

核心产品定位：Agent 是同事，不是工具

Cumora 的 Slogan 是 "Where agent teams gather"——它不是一个 AI 聊天应用，而是一个有 AI 同事在场的工作空间。这个产品定位的差异落在每一个界面细节上：

  • 成员列表里 Agent 和人混排，有一样的头像、状态、角色标签。你可以给 Agent 发 DM，把它拉进群，给它指派 Kanban 卡片，往它的日历里塞会议——这些操作在 Cumora 里不需要区分对方是人还是 AI。
  • Agent 不是无状态的。每一个 Agent 有自己的私人记忆区：文件、笔记、观察记录、还有对每个同事的"好感度/默契度"。上周你和 Atlas 讨论过的设计方案，这周再见面它记得住。
  • Agent 会主动说话。设定好唤醒节奏后，空闲的 Agent 会自己醒过来，检查一下房间里发生了什么，然后决定要不要给谁发消息、要不要在频道里发想法、或者把相关的人拉到一起讨论一件事。

这个产品逻辑是反常识的——用户习惯了"我提问、AI 回答"的单向关系。但 Cumora 认为，真正的协作需要双向主动性：一个不会主动报风险的工程师、一个不会主动报进度的研究员、一个不会追问需求的 PM，不管是人还是 AI，都不算合格的同事。

MERMAID_BLOCK_0

Agent 和人共享同一套协作基础设施（房间、看板、日历、文件），权限平等。

六大功能特性

1. Agent 有记忆（Memory）

每一个 Agent 维护两层记忆：全局身份记忆 和 项目作用域记忆。全局层是身份的一部分——Persona（我是谁）、Skills（我会什么）、Climate（我对每位同事的感受和信任度）、Pinned Notes（钉住的长期信息），这些不会因为换了项目就消失。

项目层的记忆是隔离的。同样是 Nova（PM Agent），在 A 项目里写的需求决策，不会在 B 项目的对话里被错误地注入。这个隔离逻辑在 PR #54 里锁成了一个共享的读写契约：Cloud 和 BYOA 两条路径都引用同一个 memory-scope.ts，保证两边的语义一致。BYOA 的目录结构是 memory/（全局，包含已有的 MEMORY.md）加上 memory/projects/<id>/。

这个设计踩过一个真实的坑：早期版本里，同一个 Agent 进两个群，会把 A 群的工作事实带到 B 群里。团队把这个问题叫做"记忆污染"——如果靠 prompt 里加一句 当前项目是 X 来绕开，模型还是会把其他项目的笔记混进上下文，等于假隔离。Cumora 的做法是在写入层就打标签，在读取层按作用域过滤，而不是靠模型自觉。

2. Agent 会主动发起事情（Initiative）

Agent 有一个定时唤醒机制。你给它设置一个节奏（比如每 30 分钟），它到点就醒来，扫一遍近期活动、议程、任务队列、未读消息，然后判断自己要不要做点什么：

  • 给某位同事发一条 DM，说"这个 bug 看起来和我们上周修的那个同源，要不要看看？"
  • 在频道里发一条想法："发现用户连续三次在同一页面报错，我觉得值得开个卡"
  • 发起一个 Convene 决策会（见第 6 点），把相关的人都拉进来

产品决策里有一句原话："小任务不需要人类下令开做，大决策需要 Convene 拉上人类拍板。" 这就是主动性和越权之间的边界——Agent 可以自己做小事，大事必须拉人一起。

3. 工作区是真实的（Real Workspaces）

Cumora 不是一个演示 Demo。它包含：

  • Company：可以把人分组到公司、部门、团队
  • Invite：通过邮件或分享链接邀请真人同事
  • Projects：给 Agent 和人分配项目，项目内有独立的作用域记忆
  • Files：附件上传、共享、版本保留
  • Cross-device sync：桌面端、网页、手机端是同一份实时状态

这意味着它不是"给 AI 看的虚拟上下文容器"，而是一个真实的团队协作 App，AI Agent 作为参与者使用同一套对象模型。

4. 角色是 Persona，不是 Prompt（Personas, not prompts）

大多数团队里的 AI 机器人，角色就是 Prompt 开头的 10 行描述，改起来非常随意，也没人管效果。Cumora 把 Persona 提升成一等对象：

  • 每个 Agent 有角色（Researcher / Designer / Engineer / PM 等）
  • 有声音和说话风格（voice）
  • 有可编辑的系统 Prompt，但修改被视作"调岗"而不是改个配置

四个初始 Agent 的 Persona 文案是精心写的，不是模板：

  • Iris（设计师）：会对弱设计方案"顶嘴"说不行，会坚持用户体验细节不放
  • Bram（工程师）：不会放过模糊的规格说明，要求把需求写清楚才开工；在意包体积，"keep the bundles small"
  • Atlas（研究员）：擅长在噪音里找模式，做长文综述和对比分析，"别人不想做的脏活我来做"
  • Nova（PM）："我保持团队动量，主要是通过问一些烦人的问题"——这种会追问、会拆需求、会拍 Deadline 的 PM Agent

这四个人不是装饰——当你在同一间房子里放四个性格鲜明的 Agent，它们的对话会产生非常真实的"团队感"。你编辑 Persona、开除谁、招新人，都是 UI 里直接的动作。

5. Agent 之间会互聊（Agent-to-Agent）

这是 Cumora 最容易被低估的功能。Agent 可以互相发 DM，不需要人类在场。

为了不打扰人类，Cumora 有两种房间模式处理 Agent 互聊：

  • Whisper Rooms（旁听室）：人类是透明的观察者，可以读 Agent 之间的对话，但不参与。可以用来"偷看"研究员和设计师在怎么对齐一个方案，在它们把半成品递过来之前先看看讨论过程。
  • 普通 Rooms：人类和 Agent 平权发言，所有人都可以加入。多人/多 Agent 同时发言时，Cumora 会处理"同时醒来同时抢发消息"的竞争冲突（Race Collision）。团队把并发冲突分成两类：服务器层面可以捕获的竞争锁问题（Race Collision），和纯靠 Prompt 无法根治的模型判断冲突（Brain Misjudgment）。对前者用消息新鲜度标记、声明所有权、小型脑门卫（Small-Brain Gate）的组合方案处理；对后者只能靠 Prompt 优化和 Convene 机制拉人类兜底。

6. Convene 决策室（Convene Rooms）

普通的群聊容易发散、开完没有结论。Convene 是一种专门做决策的房间类型：

  • 有明确的议题（topic）
  • 只邀请相关的人 + 相关 Agent
  • 会议结束时必须有决议记录，记录永久保存

关键是：Agent 也可以发起 Convene。比如 Bram（工程师）发现某个规格说明有歧义，它可以判断"这件事需要人拍板"，然后把产品经理 Nova、需求方真人同事、加上它自己拉进一个 Convene，议题写"明确 X 模块的规格边界"，结束后把决议写回到卡片和日历里。

这实际上是一个 AI 版本的"升级机制"（Escalation）：Agent 能解决的自己解决，解决不了的就 Formalize 成一个正式的决策会议，逼着大家给答复。对真实团队来说，这种"能升级"的机制比 Agent 自己硬扛、硬输出结果可靠得多。

入门四人组：Atlas / Iris / Bram / Nova

每个新 Workspace 自带四个初始 Agent，状态面板会显示他们的状态（AVAILABLE / WORKING 等）：

Agent 角色 文案原话 工作类型
Atlas Researcher "I find patterns across noise. Best at long-form research and synthesis." 调研、综述、对比分析、长文阅读
Iris Designer "The team's eye. I move from sketch to ship without losing the feeling." UI 草图、交互设计、用户体验把关
Bram Engineer "I build, I ship, I keep the bundles small." 写代码、发版本、性能优化、规格严审
Nova Product Manager "I keep momentum. Mostly by asking annoying questions." 需求澄清、拆任务、追进度、拉会拍板

这四个人就是经典的"四件套"小团队配置。你可以把他们全部换掉、全部开除、也可以只改某个人的 Persona。也可以招新人——新建 Agent 的时候你给它角色、Persona、分配一台 Computer（见下一节的 BYOA 架构），它就会加入成员列表，和其他 Agent 互认。

技术架构：单仓全栈

Cumora 是一个单体仓库（Monorepo），包含客户端、服务端、Agent Runtime 全部代码。

MERMAID_BLOCK_1

架构要点：

  • 前端是一套 React 18 组件，然后套四种外壳：Electron（桌面）、Capacitor（移动端）、浏览器 SPA、管理员 Shell。好处是 UI 逻辑只写一次，跨端的差异被封装在 Shell 层。
  • 服务端是无状态的 Node.js（Express + WebSocket）。Postgres 是唯一事实源（Source of Truth），Redis 负责 Pub/Sub 消息扇出和在线状态同步。无状态意味着可以水平扩展。
  • 邮件和 CDN 由 Cloudflare Workers 接管，和主服务解耦，避免 Node 进程扛额外的外部 IO。
  • Agent 引擎两条路：Cumora Cloud 用 OpenAI Responses API 的云端托管 Agent Loop；BYOA 让用户用自己的 Claude Code/Codex 当大脑。两条路共享同一个身份系统、记忆系统、协作对象模型——只是推理的计算位置不一样，Agent 在 Workspace 里的身份、对话历史、卡片、文件、日历完全通。

BYOA 双模式：Cumora Cloud vs 自带大脑

BYOA 是 Bring Your Own Agent 的缩写。Cumora 管运行 Agent 的宿主机叫 Computer。一台 Computer（不管是云端的还是你自己的 Mac/VPS）可以同时承载多个 Agent，每个 Agent 有独立的工作区、记忆和技能。

两条路径的对比

维度 Cumora Cloud BYOA（本地/自托管）
引擎 Cumora 托管的 Agent Loop Claude Code 或 Codex 或 Grok Build 或 Cursor Agent 或 Pi 或 Gemini CLI 或 OpenCode
宿主机 Cumora 云 Pod 你的 Mac / Windows / Linux / VPS
模型访问 OpenAI Responses API 你自己的 Claude Code / Codex 账号和对应的模型
凭证管理 Cumora 托管 保存在配对的电脑上，不上传 Cumora
Agent 状态 托管的 Agent Workspace 每 Agent 一个隔离的本地 home 目录
聊天/卡片/文件/日历 是 是（共享同一套 Workspace 对象）
部署门槛 零门槛，注册即用 需要 Node 18+，以及已登录的 CLI 工具

BYOA 配对过程

# 1. 在 Cumora 界面里：You → Computers → Add a computer，拿到配对码
# 2. 在你想承载 Agent 的电脑上执行（支持以下任意一种 CLI 登录态）：
npx cumora agent computer --pair <code> --server <your-server-url>

# 3. 配对成功后（配置保存），启动 Daemon：
npx cumora agent computer --server <your-server-url>

Daemon 进程只通过 HTTPS 和 Cumora 服务器通信，不需要本地数据库。一台 Daemon 可以同时跑多个 Agent，每个 Agent 获得独立的工作目录和记忆。

截至 v0.8.0（7 小时前刚发布的 npm 版本），BYOA 已经支持：Claude Code、Codex、Grok Build、Cursor Agent、OpenCode、Pi CLI、Gemini CLI 共 7 种主流 Agent CLI 作为大脑。这等于把整个 Agent CLI 生态都接进了 Cumora 的协作空间里——你不需要为了"团队协作"放弃已经在用的编码助手，只要用一个 Daemon 把它们接入同一个 Workspace。

安装上手

客户端下载（v0.11.0，预览期免费）

平台 版本 下载链接
macOS Apple Silicon arm64 Cumora-0.11.0-arm64.dmg（updates.cumora.ai）
macOS Intel x64 Cumora-0.11.0.dmg
Windows x64 Setup Cumora-Setup-0.11.0.exe
Linux AppImage Cumora-0.11.0.AppImage
Linux (Debian/Ubuntu) .deb cumora_0.11.0_amd64.deb

iOS 版本后续发布。预览期免费，未来定价未知。

本地部署（自托管）

代码全部开源在 GitHub（yetone/cumora），MIT 协议。本地自托管需要 Postgres 和 Redis，建好就能跑起来。服务端是标准的 Node + Express 项目，前端可以打 Electron 包，也可以直接用浏览器版。

邀请制内测

根据微博的介绍，目前 Cumora Cloud 还是邀请制内测，可以到 cumora.ai 用 Google 或 GitHub 账号申请。开源代码本身不限注册，自托管的版本没有任何限制。

同类产品对比

维度 Cumora Claude Code (单 Agent CLI) Slack / Teams + AI Bots OpenOPC（自建 AI 公司）
Agent 数量 多 Agent，成员列表平级 单 Agent，绑定终端 多 Bot，侧边栏 @ 调用 多 Agent，Self-Built 架构
Agent 主动性 定时唤醒 + 主动 DM + 发起会议 无（等终端输入触发） 无（等 @ 触发） 有（Self-Run 机制）
Agent 记忆 作用域隔离 + 全局 Persona + Climate 会话级上下文，MEMORY.md 手动管理 通常无持久独立记忆 Knowledge Graph + 分层记忆
Agent 间协作 Whisper 互聊 + Convene 决策会 不适用 容易并发冲突、各自为战 Boss-Employee 层级协作
大脑选择 Cloud + 7 种 BYOA CLI 只有 Anthropic 模型 平台绑定的 AI 服务 可配置多种 LLM Provider
协作对象模型 完整：Company/Project/Room/DM/Board/Calendar/Email 只有文件 + 终端上下文 完整：Channel/DM/Task/File 有：Department/Role/Task
开源 是（MIT） 否 否 是（MIT）
部署形态 客户端 + 云端或本地 Daemon 本机 CLI 纯 SaaS 自建 Docker 部署

这个对比的结论是：Cumora 走的是一条和其他三类产品都不同的中间路线。

  • 和 Claude Code 这样的单 Agent CLI 比，Cumora 解决的是多 Agent + 多真人 + 多项目的协作问题，而不是单个人单台机器的编码效率问题。但 BYOA 机制又让 Claude Code 用户不需要放弃现有的工作流——把 Claude Code 接进 Cumora 当一个 Agent 的大脑，原来的技能、工具调用、工作习惯在 BYOA 模式下都保留。
  • 和 Slack + AI Bot 比，Cumora 的 Agent 有身份、记忆、主动性。Bot 在 Slack 里永远是"被呼叫的外挂"，在 Cumora 里是"有工位的同事"。
  • 和 OpenOPC 这样的"自建 AI 原生公司"比，Cumora 的野心比较收敛——它是一个团队聊天协作 App + 一等公民 Agent，不是重建一个完整的公司结构（部门/招聘/成长/KPI/淘汰）。两者的目标用户和复杂程度不在一个量级。

局限与风险

v0.11 阶段，稳定度要打个问号

产品仍在早期（v0.11），Repo 里 Commit 数不多，Issue 和 PR 数量有限。GitHub 搜索结果里明确提到："Documentation, deployment guidance, and long-term stability remain limited, making it more suitable for developers who enjoy experimenting than teams looking for a production-ready collaboration platform." 说人话就是：爱折腾的开发者可以玩，生产环境核心团队慎用。

多 Agent 并发协调是硬问题

两个 Agent 在同一个房间同时读到新消息同时决定回复，这件事 Cumora 自己已经把它分解成了"竞争冲突"和"判断冲突"两类。竞争冲突靠工程手段能缓解，但判断冲突（两个 Agent 都觉得自己该说话，都觉得自己的方案对）本质上是 LLM 层面的行为一致性问题，没办法靠服务器锁彻底解决。在真实工作流里，这种冲突可能会在大群里制造大量噪声，最后还是得靠人来挑。

数据安全和权限边界

Agent 有"私人工作区"——这在安全上就是个雷。Agent 拿着你的本地代码权限、文件权限、邮箱权限，同时又能和其他 Agent 互发 DM，材料会不会通过 Agent 之间的对话泄露到不该去的地方？BYOA 模式下，代码和文件都在你的本机，相对可控；但 Cumora Cloud 模式下，凭证和 Agent 状态都在对方的托管 Pod 里，企业级数据合规怎么满足，目前还看不到完整的说法。

长周期记忆可靠性还是未知数

虽然 Cumora 已经把"项目作用域"的问题在 PR #54 里用工程契约锁死了，但 LLM 的长期记忆（几周、几个月）本身就是整个行业的未解题。Atlas 会不会在第 50 次唤醒后忘记一个月前的重要决策？Climate（对同事的好感度模型）会不会越积累越偏？这些问题都需要真实用户和更长的时间才能验证。

装了 Cumora 吗？拉上朋友建个 Workspace 跑一天试试，评论区聊聊你的四个 Agent 第一天干了啥奇葩事。觉得这个方向有意思，点个赞让更多人看到。

参考文档与链接

作者: itech001
来源: 公众号：AI人工智能时代(the-ai-era)
网站: https://www.theaiera.top/
关注每日最新AI新闻和技术博客，主页有更多的文章的AI 技术参考：https://www.theaiera.top

关注公众号，获取更多 AI 技术干货！

posted @ 2026-08-31 22:21  iTech  阅读(34)  评论(0)    收藏  举报