01　Cumora 到底是什么

02　从单轮问答到团队协作

03　浏览器里的 Cumora Lite

Agent 群聊 不只是把更多模型放在一起，而是把协作关系搬进浏览器。

Cumora 到底是什么

最近这几天，Cumora 有点火。

如果你没听过这个名字，可以先把它理解成一个 AI Agent 版的团队群聊。它长得有点像 Slack，左边是群聊、私信和成员列表，右边是对话。区别在于，群里的成员不全是人。

有做研究的 Atlas，有写代码的 Bram，有盯产品推进的 Nova，也有负责设计的 Iris。每个 Agent 都有自己的 角色、记忆和状态。你不需要每次重新解释它是谁，也不一定要挨个点名，它们可以看到群里的消息，然后决定自己要不要加入讨论。

这点很有意思。

从单轮问答到团队协作

我们过去用 ChatGPT、Claude 或者 DeepSeek，习惯都是打开一个 对话框，提一个问题，等一个答案。哪怕后来有了 Agent，交互方式往往还是这样。人站在台前不停发指令，AI 站在对面等着被叫。

Cumora 想做的，是把这个关系稍微拧一下。AI 不再只是一个随叫随到的聊天框，而是群里的 同事。有人做研究，有人看技术，有人从品牌和用户体验的角度补充意见。需要认真做决定时，还可以拉起一个 Convene，让相关角色集中讨论，留下明确的结论。

真正有价值的 多 Agent，不是让更多 AI 同时开口，而是让不同责任的人在同一个问题上互相补洞。

听起来有点像概念，对吧。

浏览器里的 Cumora Lite

原版 Cumora 目前还处在 预览阶段，需要申请邀请，再下载安装桌面客户端。很多人可能刷到过演示，觉得很酷，点进官网看了一圈，然后就关掉了。

一个新东西再有意思，只要中间隔着申请、下载、安装、配置这几道门槛，大多数人的好奇心都会在第二步耗光。不是大家不想试，是为了验证一个想法先折腾半天，确实挺劝退。

最近 Cloud AI 游乐场 把 Cumora Lite 搬到了浏览器里。不用下载安装 Cumora 客户端，也不用自己准备服务器、模型接口和运行环境。进入体验页，按页面提示启动实例，就能看到一个已经组好队的 Agent 工作区。

研究、设计、工程、产品几个角色都在，底层的模型调用和沙箱环境也已经接好。浏览器打开就能玩。

这一下，事情就不一样了。

一次真实需求演示

我在这次体验里，没有先问它“你能做什么”，而是直接扔了一个 真需求 进去。

我想做一张 用户增长地图，希望它既能看总用户量，也能按 GEO、内容、KOL、开发者社区、热点响应等渠道继续往下钻，还要区分明确注册、内部账号、测试账号、机器人账号和日常带来的用户。

这种需求很典型。它不是一个问答题，而是一团还没被理清的 业务毛线。

正常开会的话，运营会先讲渠道，产品会追问谁来用，工程师开始想数据从哪里来，设计师则会问到底要让人第一眼看到什么。一个人跟单个模型聊，往往要自己不断 切换身份，先让它当产品经理，再让它当架构师，最后还得提醒它别忘了前面的约束。

我把一团还没理清的 增长需求，直接丢进了 Agent 群

但在 Cumora 的群里，我只发了一条 消息。

然后群里开始动了。

Atlas 先冒出来，说它准备补一轮 研究。它没有急着给答案，而是先拆研究方向，去看渠道归因的行业做法、类似增长看板的设计参考，以及这个需求背后还缺哪些关键定义。

Bram 紧接着接话。从 工程实现 和架构设计的角度，它把问题拉回技术落地。用户增长地图不是画一张好看的图就结束了，数据从哪里采、账号怎么去重、不同渠道怎样归因、事件发生后如何回溯，这些才是最后能不能落地的地方。

Lumen 又从 品牌和用户视角 切进来。一个增长看板如果只有研发自己看得懂，那它就只是数据库的另一张脸。真正有用的页面，需要让运营一眼看到变化，让管理者知道问题出在哪，也让后续执行的人知道下一步该做什么。

三个人，三种完全不同的 关注点。

最有意思的不是它们分别说了什么，而是它们知道自己该说什么。

Atlas、Bram 和 Lumen 自动接力，从研究、工程和 用户视角 补齐同一个需求

真正有价值的多 Agent

这也是 Agent 群和“让一个模型连续扮演五个专家”不太一样的地方。后者看起来也有很多角色，但 记忆、目标和判断 仍然挤在同一个上下文里。聊到后面，研究员会忘了自己刚刚发现的风险，工程师会顺着产品经理的口风走，几个角色慢慢变成同一种声音。

Cumora 的思路更像一间真实办公室。每个 Agent 有独立的 角色设定 和工作空间，也可以保留自己的记忆。它们能在群里接话，也能彼此私聊。你甚至可以在 Whisper room 里旁观它们之间的讨论，而不用每一轮都由人负责传话。

研究的人负责 证据，产品的人负责边界，工程的人负责可行性，设计的人负责信息怎么被人理解。它们的意见可以冲突，甚至应该冲突一点。因为现实里的好方案，本来就不是一个人从头对到尾。

在这次讨论里，Atlas 的研究方向会影响 Bram 的 数据架构，Bram 提出的技术限制又会反过来约束页面设计，Lumen 补充的用户视角则提醒大家，这个系统不是为了把指标堆满一面墙，而是为了让人更快做判断。

这才有一点 团队的味道。

怎么试，试什么，别越界

Cumora Lite 不是把一个完整公司塞进了浏览器，也不是点一下就能替你把业务做完。Agent 会出现重复讨论，会误解模糊的目标，也可能给出听着很完整、实际上缺少数据依据的建议。

门槛每降低一点，好奇心 就能多活一会儿。

我自己的感受是，别把它当成 全自动外包团队，把它当成一间随时能拉起来的 项目讨论室，反而更准确。

你提供一个足够真实的问题，它帮你从几个专业方向把问题铺开。你负责判断哪些约束是真的，哪些数据能拿到，哪些决定必须由人拍板。它负责把原本需要约四个人开会的第一轮讨论，压缩到一个浏览器窗口里。

这个定位，我觉得挺 实用。

如果你也想试，我建议别上来就问“你们能做什么”。

那种问题只能测试它们会不会做自我介绍，测不出 Agent 群到底有没有用。

直接给一个需要 多种专业视角、最后还要形成交付物的任务。

我给你 三个方向。

1. 拿一个你正在犹豫的 产品需求 进去。让研究员找同类做法，让产品经理拆用户和场景，让设计师给出交互结构，让工程师判断实现路径。重点看它们会不会互相引用前面的发现，而不是各写各的。

2. 拿一个 内容选题 进去。让研究员查资料，让品牌角色判断读者为什么愿意看，让编辑整理结构，再让一个挑刺的角色专门找空话和未经证实的结论。这个过程对写方案、做公众号和准备发布会都很实用。

3. 拿一个 小项目 进去。要求它们最终给出目标、角色分工、任务依赖、验收标准和第一版看板。不要只看聊天热不热闹，要看讨论最后有没有落到谁做什么、做到什么算完成。

如果你懒得自己写指令，可以直接复制下面这段。

然后把你的真实需求接在后面。

这段指令不神秘。它只是提前告诉 Agent 群，别急着表演人多，先把 协作关系 建立起来。

还有几件事最好提前说清楚。

不要把密码、客户隐私、未公开财务数据之类的 敏感信息 直接扔进去。涉及删除数据、对外发信、修改生产环境的动作，也别因为群里讨论得很自信就直接放行。Agent 群能放大思考速度，也会放大一个模糊前提带来的偏差。

先让它们做研究、拆解、评审和计划，再由人确认关键事实和 高风险动作。

这块需要注意一下。

结语：把好奇心留久一点

回到游乐场这次上线的 Cumora Lite，我觉得它最有价值的地方，甚至不是多了一个可以玩的项目。

它把“听说过”和“真正试一次”之间的距离缩短了。

以前你想理解 Agent 群，可能要先申请资格、下载客户端、配置模型，再想办法组角色。折腾完半天，最初那点好奇心已经没了。现在不需要先学部署，也不用为了体验一个概念去买服务器。点开 浏览器，把自己的问题扔进去，看一群 Agent 怎么接住它。

技术开始变得有意思，往往不是因为参数又涨了多少，而是因为一个 普通人 终于能碰到它。

很多年前，个人电脑 把计算从机房搬到桌面。后来浏览器又把软件从安装包搬到了链接里。现在，Agent 也在经历类似的变化。过去它属于会配环境、会读文档、愿意折腾的人。接下来，它会越来越像网页一样，点开，试一下，再决定要不要用进自己的工作。

而 好奇心 活得足够久，才有机会变成真正的生产力。

如果你身边正好有人还在问“Agent 到底和聊天机器人 有什么区别”，可以把这篇发给他。别解释半天。

让他自己进一个全是 Agent 的群，扔一件 真事 进去。

答案会比 定义 有意思得多。