记录一次 Agent 实况级协作体验。
Google Docs 在 2010 年前后教会了所有人一件事：
多人可以同时在云端编辑同一份文档，改动即时可见，冲突自动解决。
这种体验后来成了协作类软件的默认设定，飞书、腾讯文档、Notion 都建立在这个前提之上。
但到了 Agent 时代，这个时刻至今还没有出现。
一个公司内的每一个部门里的每一个人，都需要单独开一个 Claude Code 或 Codex，Agent 之间无法「交互」。
没出现的原因，大致有 3 点。
【1】厂商之间有「生殖隔离」
每个人用的 Agent 来源不同，有人用 Claude Code，有人用 Codex，有人用Opencode，它们各自在自己的运行时环境里，没有一套通用方案能把它们真正放到一起。
【2】个人边界太强
现在的 Agent运行时环境都是围绕单个用户设计的，不管是本地电脑模式还是云端电脑模式，主语始终是「我」。
想和别人协作，物理设备本身就是一道越不过的墙。即使离开了自己的本地工具、配置、账号凭据，将 Agent 放到云端，依然会面临每个 Agent 沙箱的边界隔离问题。
【3】 Agent 底层协作困难
今天的 Agent 都和沙箱一对一绑定，每个 Agent 活在自己的「平行宇宙」里，它们之间缺少可实时同步上下文、共享资源、互相调用的通道，只能在事情完成后，通过网盘的上传下载、部署，或者在群里发送结果，来交换各自的产物。
实时协作需要的是一种新方案，能把这些 Agent 放进同一个「时空」。
所有原因叠加在一起，结果就是 Agent 越强，人在中间搬运上下文的工作量越大。复制粘贴、上传下载、总结背景、转发进度，这些「为了让工作能继续而做的工作」没有减少，反而随着 Agent 数量增加在变多。
虽然难点重重，但也有从产品创立之初就「全力押注」Agent 实况协作的团队，而这个团队在 8 月 24 日发布了正式产品 ——
Tutti · VM
在讲解这个产品之前，我们决定先把现在市面上的方案过一遍，才能回答：
【1】我们离「Agent 届的 Google Docs 时刻」到底还有多远？
【2】Tutti · VM 的产品逻辑是什么？产品价值到底在哪里？
Agent 经历了 4 次尝试
现有的探索大致有四条路线，代表性的形态分别是：Slack（群聊 Bot）、CrewAI（多 Agent 编排）、Devin/Replit Agent（云端数字员工），以及 Claude Code/Codex（Remote Control）。
每一类都解决了一部分问题，也各自离那个「Google Docs 时刻」差着一段距离。
【1】IM / 群聊类。
这类方法主要是把 Agent 拉进频道，让它被 @、任务执行完成后再回复消息、同步进度，Agent 之间传递的主要是消息和摘要，执行任务的实时过程依然跑在各自的本地电脑或者云端沙箱里，彼此无法看见。
如果拿 Google Docs 来类比，这相当于停留在「把文档截图发到群里」。
【2】本地多 Agent 编排类。
这类方法主要解决的是一个人管多个 Agent，可以同时开更多并行任务，效率确实提高了。但它面向的是个人，本身不涉及多人协作，就算勉强协作，也很难跨过物理机器的隔离。
【3】云端数字员工类。
这类方法是目前最常见的，例如 Devin、Replit Agent。
其主要是把 Agent 整个搬到云上，你在浏览器里就能让它干活，也方便把链接发给别人看。
快速分享产物的问题解决了，但因为 Agent 沙箱隔离的原因还是没有解决 Agent 之间的实时协作问题，而且需要你进入它的工具体系，自己本地的工具生态和文件都带不过去，要重新适应一套环境，并且再为它提供的 Agent 能力付一次费。
【4】Remote Control
Claude Code 今年 2 月上线的 Remote Control 和 Codex 的同类功能是这个方向最典型的例子，它们的工作流是让会话继续跑在你自己的电脑上，文件、凭据、本地配置都可以不动，而你可以从手机、平板或任意浏览器接着指挥。
但仔细看会发现这个工作流的本质是 Agent 在我的电脑上干活，我从别的设备盯着它。
没有其他协同者可以参与进来。
从这个角度来看，桌面 Agent 越普及，Claude Code、Codex、Cursor 人手一个，「Agent 实况干活」的缺口只会越来越大。
这4次尝试都具有一定真实价值，主要目的是让我们可以同时发起更多的并行任务，但这些并行任务必须是边界清晰的。
而在复杂的工作中，协作者之间的任务往往是相互依赖的，真正的并行协作还要求Agent 能有效分工、共享环境和状态、协调冲突并汇总结果。
这时候再回来看 Tutti · VM 。
它的产品逻辑是把大家连接起来，先尝试解决的是「我们的工作在哪相遇」。每个人的 Agent 放在各自电脑上跑，工作实况天然产生在同一个云端 Room 里。将大家连接起来后，就能发生很多有意思的事情，比如实时共享和实时协作。
共享和协作的中心，也变成了多个人和他们各自的 Agent。
换个说法，Remote Control 服务的仍然是你一个人和你的 Agent，只是让你离开座位也能接着用。Tutti · VM 服务的是一群人和他们各自的 Agent，整个团队和各自的 Agent 围坐在同一张会议桌前，所有人都能看到彼此在干什么。
Agent 留在本地，现场搬到云端
根据官方信息，Tutti · VM 把自己定义为行业「首个实况级」多人、多 Agent 实时协作空间，其把本地工具和云端工具的优点结合到了一起。
它的机制大致可以分为三点：
【1】每个人的 Agent（目前支持 Claude Code、Codex）继续跑在用户自己的电脑上，利用用户已有的订阅、配置和 skills。
【2】Agent 的指令经过多层虚拟化，由系统决定这条指令到底发往物理机、本地虚拟机还是云端，协作者在云端共享同一个运行时环境。
【3】云端 Room 成了所有人与 Agent 的「实况空间」
谁改了代码、Agent 在干什么、最新产物是什么，大家在同一个房间里彼此可见、随时复用。
概念讲到这里，产品逻辑算是基本理清了。
官网也给了一些和其他现有工具的能力对比：
下面，我们再来看看 Tutti · VM 实际上是如何使用的。
我们深度实测了几天，接下来分享我们的真实体验。
一个工程师，一个设计师，一个 Room
现在，我们来看这个场景：
我们有团队成员 Vibe Coding 了一个叫做 Crossing Writing 的网站，主要就是 AI 类目的专业信息做个有反向链接的知识库。 但 UI 设计略粗糙、代码架构、前端逻辑也略粗糙。 这次负责更新迭代的是两位同事，工程师用户 A 和设计师用户 B，他们共同进入 Tutti · VM 的同一个 Room。
先简单介绍下这两位同事：
用户 A：工程师，手里有一堆 Agent 产品订阅，Claude Code Max 账户、Codex Pro，主要工作是日常开发，做产品初版。
用户 B：UI 设计师，手里几乎没有 Agent 产品订阅，但是有设计 Taste，做设计把关。
接下来，我们按照他们的真实工作流讲解下 Tutti · VM 。
1.建立 Room，两人加入
首先，Tutti · VM 的官网网址是：
https://tutti.sh
下载之后，我们登录完账户，就可以直接进来主页面创建 Room 。
在这个 Room 内部，我们可以一键把邀请信息发送给对方。
用户 B 拿到邀请信息后就进入了 Room，可以直接看到 Agent 看板，上面会显示整个 Room 内所有正在执行、已经完成和失败的任务（包括用户 A 所执行过的任务）。
下面来看看具体的协作开发流程。
2. 创建项目
对于新的项目，可以直接启动，项目直接就会在 Tutti · VM 中创建，所有协同者立即共享。
如果是历史项目，可以直接在 Tutti · VM 中导入 Local Project。
或者也可以在终端中使用 Git 进行 Clone。
3. 工程师用 Tutti · VM 搭初版
用户 A 也就是工程师，他的工作流程一般是先用 Tutti · VM 搭建初版。在进入 Tutti · VM 后，就可以一键关联电脑本地的 Codex 和 Claude Code，等于说在 Tutti · VM 里的开发所用到的 Agent 都是本地 Agent：
工程师搭好项目后，设计师就可以直接进来使用这个项目，不用再自己折腾一遍环境。
同事 A 一般会把 Codex 和 Claude Code 搭配使用，比如用 Codex 做主力开发、搭建骨架，用 Claude Code 负责审查和规划。
用 Claude Code 完成规划和审查之后，可以直接在 Codex 的页面里使用「Big @」功能。它能引用其他 Agent 的会话、文件、任务、应用等上下文。
这样 Codex 就可以在对话框里直接引用 Claude Code 做审查和规划的那个会话。
比如用 GPT 5.6 Terra 模型，@ Claude Code 里的审查会话，让它复盘整个项目，找出 10 个在代码结构和交互上可以改善的点，整理成一份 Todo List。
Codex 就会基于 Claude Code 的上下文，按重要级别给出一整份 Todo List，覆盖补齐项目、工作台、路由框架骨架等内容。
有意思的是，在这个 Room 里，用户 B 可以通过 Agent 看板实时看到用户 A 整个项目的进展。
比如他可以站在设计师的视角查看这份 Todo List，直接在聊天对话框里发表意见，指出整个项目在设计上存在的逻辑问题。
工程师可以按照设计师的想法进一步修改。反过来，设计师在聊天框里也能用 Big @ 引用工程师的上下文，自己上手修改，这一步非常有意思。
跨人、跨 Agent 的 session 引用，改变的是提需求的方式。比如工程师的对话流里有非常多技术向的表达，像是整个 Crossing Writting 项目的交互为什么这么设计。
这些对于设计师来说原本可能是读不懂的，也复述不出来。现在他只要在自己的对话框里 @ 上工程师的这条 session，这些内容就作为上下文被完整带了过来，他只需要用设计语言描述自己想要的结果，具体怎么落地代码上由 Agent 结合已有上下文去判断。
某种程度上，引用会话本身就是一次「借能力」。设计师借的是工程师和他的 Agent 已经完成的技术判断，跳过了「先把需求翻译成工程师听得懂的话，再等工程师翻译给 Agent」这一层。
跨职能协作里最耗时的部分往往就在这两次翻译上。
使用过程中我还发现，做完一个项目之后，项目直接就可以在沙盒里运行，非常好用。
具体效果如下，我们做的这个 Crossing Writing 是一个非常大的知识库，里面加载了多个 Concept，每个概念都标注了对应的公众号或出处来源，并且采用多嵌入机制。
直接在沙盒中运行之后，它会通过一个 Localhost 地址打开。
这是因为 Room 里的协作者共享的是同一个运行时，Localhost 不再只属于开发者本机，谁在房间里谁就能直接访问。如果你在继续开发和调整，对方都可以实时看到最新版本，不需要重新部署、重新发送。
如果对方需要参与开发，加入 Room 就从看结果切换成了实时协作，也就是用户 A 和用户 B 现在的情况。
除了这种在 Room 里用 Localhost 共享路径之外，对于 Room 之外，不参与协作、只需要看结果的人，你可以在 Room 的文件夹里找到对应的 html 文件，点击分享拿到链接，把链接发出去就可以。
对方可能是你的老板，也可能是客户。他们不需要下载 Tutti · VM，不需要加入 Room，也不需要你先把项目部署到任何服务器上，在自己的浏览器里打开链接即可。
当设计师用户 B 也能看到 Agent 实况空间里发生的一切之后，他肯定会有更多需要用 Agent 执行的需求，比如改造整个项目的 UI