两个人类，三个 Agent，一个没有冲突的下午- Tutti · VM开始内测

记录一次 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 设计。

按原来的工作流，设计师用户 B 手里没有 Claude Code 或 Codex 的订阅，自己调不动任何 Agent，只能在群聊对话框给工程师提意见，让工程师去改善交互、排查内在逻辑问题。

但这样就有了断点和摩擦，因为设计师还是要依赖工程师来继续执行。

所以此时就用到了 Tutti · VM 的另一个功能 —— 设计师可以直接向工程师借用他的 Agent。

4. 借用 Agent

在 Tutti · VM 里借用 Agent 非常方便，在左下角点击「共享你的 Agent」就可以。

可以看到，设计师用户 B 已经能使用用户 A 共享的 Codex 或 Claude Code 了。

因为整个项目都运行在 Tutti · VM 的 共享工作区里，设计师用户 B 又获得了 Agent、拥有整个 Room 里所有的上下文，他可以按自己的想法自由修改样式、做前端 UI 设计。

Tutti · VM 里还有一个应用中心，集成了产品原型设计等功能，同样可以调用底层 Agent。

现在，设计师可以用共享的 Agent，围绕共享的 Localhost 页面，在 Tutti · VM 的产品原型设计应用里，做设计稿了：

5.并行时刻

回顾整个流程，工程师用户 A 做主力开发，完成了项目的骨架和初版。过程中设计师实时关注工作实况空间，提出设计和开发意见，工程师再据此优化。初版完成后转交给设计师，由他借用工程师的 Agent 做前端整体设计。

我们注意，上面的整个工作流程还是串行的，为了避免代码发生冲突，所以很多时候大家的工作习惯还是等一个人做完了事情，另一个人才敢接着做。比如通常是设计师先vibe coding完静态页面，提交到git，工程师再把静态页面从git上拉下来，在上面补充代码逻辑。

但其实 Tutti · VM 在「实况空间 Room」里完全支持多人协同，就像在google docs或者figma里协同一样。两个人可以对着同一个页面和项目，分别调度各自的 Agent 同时跑迭代，Tutti · VM 会帮助多个 Agent 自动避免和解决冲突情况。

为了更直观地展现 Tutti · VM 的「并行时刻」及其流畅度，我们通过一段 3 人在同一个 Room 中协作的实测视频来进行拆解。

视频前半段，同事 A 与同事 B 共享同一个 Localhost 预览，各自调度 Agent 执行不同的前端任务：A 负责为任务列表补充图标，B 同步调整顶部标题样式。在两人操作期间，第三位同事进入 Room，直接为列表左侧接入时间轴。至此，三人基于同一套代码结构，完成了无冲突的多 Agent 并行迭代：

整体协作非常顺畅，多人在同一空间内调度各自的 Agent 并行迭代，没有出现代码冲突或任务重叠的摩擦。

这样的 Agent 实况空间带来几个好处。首先就是效率提升了，两人的 Agent 执行环境是共享的，所以他们能同时使用 Agent完成同一个项目，实现跨职能协同。也不用担心潜在的代码或者操作冲突等。

而且协作过程中各自 Agent 的上下文和产物也都是实时共享的，每个 Agent 都能及时知道其他 Agent 正在做什么，最后做出的项目也会更完整。

回到我们这次的项目，最终落地的效果是这样的：

现在这个知识库已经加上了图片懒加载和事件防抖，很多重复的卡片重构成了可复用的组件，整个 UI 设计也重新改了一遍。

回顾这几天的协作，最直观的感受是有一批动作全程没有再出现。不需要每个人重复搭一遍开发环境；也不需要频繁地操作 Git 和解决冲突；没有人在群里同步一遍「我现在做到哪了」；也没有人为了传一份改动去导出、上传、再下载；也不需要在终端、文档、设计工具和聊天软件之间来回切换。

所有事情都发生在同一个环境里。看板上显示着彼此的 Agent 正在执行什么任务、产出了什么，每个人都是用的同一份代码，想接着对方的进度往下做，用 Big @ 引用他的会话或文件就可以。前面提到的那些「为了让工作能继续而做的工作」，在这个 Room 里被消化掉了。

整个工作流没有出现明确的断点，上手也很快，快到让我一度以为 Tutti · VM 的产品逻辑并不复杂。但支撑这种「产品简单」的背后技术方案，实际上极其复杂。

它到底是怎么做到「本地云端结合」的？

回过头看 Tutti · VM 这条技术路线，核心动作是把「身份」「执行」「共享」三件事拆开，各自放到合适的位置。

首先，Agent 的「身份」留在了本地。

你的 Claude Code、Codex 依然作为本地工具跑在你的物理机上。登录态、订阅、API key、SSH key、公司 SSO、IP 白名单、内网服务，这些敏感资产都不出你的电脑，云端拿不到。

对企业用户来说这一点很关键，因为 Agent 的请求仍然从你的真实设备和网络发出，模型厂商的风控、企业的安全策略都照常有效。

「借用别人的 Agent」也因此能安全成立，借出来的只是能力授权，不涉及账号转移，授权方随时可以收回。

其次，Agent 任务的执行在本地虚拟化层。

通过多层虚拟化，Claude Code、Codex 的运行时环境被放进一个受管的 Linux 环境里。系统会接管 Agent 的进程调用和文件读写，从正确性、性能、沙箱成本几个维度做判断，决定每条指令最终去往物理机、虚拟机还是云端。

Agent 自己感知不到差别，用户也不需要改变任何使用习惯。

最后，Agent 之间的共享和协作都在云端 Room。 真正进入云端的只有工作实况这一层，Agent 正在改什么文件、任务执行到哪一步、生成了什么产物。这些内容在 Room 里实时共享，Room 里的人和 Agent 基于它产生连接和并行协作。

按官方的说法，因为只有和协作相关的指令上云，沙箱成本只有普通云端方案的 20% 到 25%。

这里还有一个值得单独说的技术细节：

实时协同的冲突是怎么解决的？

Google Docs 和figma等产品的冲突处理在应用层，因为文档的操作是有限的，插入、删除、格式修改，可以穷举。但 Agent 不一样，它的命令和文件操作五花八门，没有办法在应用层逐一适配。

Tutti · VM 的做法是把实时协同下沉到文件系统层，据官方信息，其自研了一套文件级实时协同引擎。所以，协同发生在文件系统这一层之后，上面跑的是什么工具就无所谓了，Claude Code、Codex、VS Code 基本不需要改代码，就具备了协作能力。

团队自己的形容是：

「让三十年来的工具生态一夜之间全部学会了协作。」

这个形容或许稍显激进，但产品逻辑是有一定支撑的。

如果所有 Agent 都在同一个房间里，会发生什么？

如果所有人的 Agent 都突破了本地物理机的限制，在同一个 Room 里共享运行时，往后看会有几点价值，这很有想象力。

首先，Agent 会从个人助手，进化到组织成员

今天的 Agent 大多只属于一个人：它的上下文、工具、产物和工作过程，都留在个人电脑与一次次会话里。人离开、会话结束，项目容易失去记忆。人离职，组织可能永久失去在个人电脑上的上下文。

Tutti · VM让人继续使用自己的电脑和 Agent，不改变工作习惯喜好的同时，把项目的文件、任务、运行状态、决策与工作过程沉淀在持续存在的 Room 中。成员和 Agent 可以自由加入、离开、切换项目；项目本身不会随着任何一个人的退出而停止或消失。

Agent 不再只是替某个人完成一次任务，而是以项目为单位参与协作，成为组织可共享、可交接、可积累的能力。

组织也将具备「长期 Memory」，当一个项目做完，Agent 可能会退出，但 Room 还是存在的。下一个项目、下一个季度，新的 Agent 进来后，面对的是带着完整历史的组织记忆，而非一个空白的新会话。

其次，Agent 之间会产生「默契」。

这点很有意思，人和人长期协作会形成默契，谁负责什么、决策习惯是什么、现在手上在做什么，不用每次都说。

Room 里的 Agent 也可以知道其他 Agent 是谁、归属谁、什么职能、正在做什么。这样，新人入职，他的 Agent 第一天就继承了整个组织的上下文。

最后，Agent 之间将会自然形成自主分工。

当每个 Agent 都看得到全局，它们可以自己判断哪些任务能并行、哪些要等待、怎么避开冲突，不需要一个中央编排器在上面指挥。

这几件事的共同前提只有一条：

所有 Agent 在同一个空间里，观看同一份实况，共享同一个运行时。

Tutti · VM 目前还在内测， 十字路口拿到了一批「内测邀请码」，公开如下：

- ACVXM4

- LRBR4N

- 4CGJN5

- 4LXEGT

- S4F7QR

- PHKOJW

- PQNX3O

- HLQ4GQ

- O3Y34H

欢迎大家围观它所带来的「想象力」。

文章来自于微信公众号 “十字路口Crossing”，作者 “十字路口Crossing”