两个人类，三个 Agent，一个没有冲突的下午
多人同时编辑一份文档、改动实时可见、冲突自动解决——这是 Google Docs 十几年前就解决的问题，飞书、腾讯文档、Notion 都建立在这个前提上。但 Agent 协作至今没有等到这一刻。一个团队里，每个人开着自己的 Claude Code 或 Codex，Agent 之间互相看不见，人还是那个在中间搬运上下文的苦力。
三个卡点
厂商之间没有通用协议，Claude Code、Codex、Opencode 各自活在自己的运行时里，谁也打不通谁。
现在的 Agent 运行时是围绕单个用户设计的，主语永远是"我"，想协作，物理设备本身就是一道墙。就算把 Agent 搬上云，沙箱与沙箱之间照样互相隔离。
最根本的是 Agent 底层缺一条能实时同步上下文、共享资源、互相调用的通道。今天交换产物的方式，还是网盘上传下载、部署链接、群里甩结果——都是事后补丁。
Agent 越强，人在中间搬运上下文的活反而越多。复制粘贴、总结背景、转发进度，这些"为了让工作能继续而做的工作"不会随 Agent 数量增加而减少，只会更多。
已有的四条路走不通
市面上的方案我过了一遍，各有各的短板：
IM/群聊类把 Agent 拉进频道，被 @、执行完再回复，传递的只是消息和摘要，执行过程互相看不见——相当于把文档截图发到群里，而不是协同编辑。
本地多 Agent 编排解决的是一个人管多个 Agent 的效率问题，本质还是个人工具，跨不过物理机的隔离。
云端数字员工（Devin、Replit Agent 一类）把 Agent 整体搬上云，分享产物方便了，但要放弃自己本地的工具生态，重新适应一套环境，还要为它的 Agent 能力再付一次钱，Agent 之间照样互不相通。
Remote Control（Claude Code 今年 2 月上线的功能、Codex 的同类功能）本质是"Agent 在我的电脑上干活，我从别的设备盯着"，没有第二个协作者能真正参与进来。桌面 Agent 越普及，这个缺口越明显。
这四条路都在解决"一个人发起更多并行任务"，前提是任务边界清晰。真实协作里任务往往相互依赖，需要 Agent 能分工、共享状态、协调冲突、汇总结果——这是四条路都没碰的问题。
Tutti·VM 换了个角度：身份留在本地，现场搬上云
8 月 24 日发布的 Tutti·VM，不问"怎么把 Agent 搬到云上"，先问"我们的工作在哪相遇"。
每个人的 Agent 继续跑在自己电脑上，用自己已有的订阅、配置、skills；但工作实况——谁改了什么代码、Agent 在干什么、最新产物是什么——发生在同一个云端 Room 里，所有人彼此可见。
这跟 Remote Control 的区别是本质性的：Remote Control 服务的是"你一个人和你的 Agent"，只是让你换个设备接着用；Tutti·VM 服务的是"一群人和他们各自的 Agent"，团队围坐在同一张桌前。
一个工程师、一个设计师、三个 Agent 的实测
工程师用户 A 手里有 Claude Code Max、Codex Pro 一堆订阅，设计师用户 B 几乎没有订阅但有设计判断力，两人进同一个 Room。
工程师先搭骨架：用 Codex 做主力开发，Claude Code 做审查规划，再用 Codex 的「Big @」功能直接引用 Claude Code 那个审查会话的上下文，让它复盘出一份 Todo List。
设计师全程能在 Agent 看板上看到工程师的进展，直接在对话框里对这份 Todo List 提设计意见；反过来也能用 Big @ 引用工程师的会话，自己上手改。这一步是关键——设计师不需要先把需求"翻译"成工程师能懂的话再等工程师转述给 Agent，跨会话引用本身就是一次"借能力"，省掉了跨职能协作里最耗时的两次翻译。
项目跑起来后通过 Localhost 直接打开，因为 Room 里共享的是同一个运行时，谁在房间里谁就能直接访问最新版本，不需要重新部署。Room 外只想看结果的人（比如老板、客户），点开分享出来的 html 链接就行，不用装 Tutti·VM、不用进 Room。
设计师手里没有 Agent 订阅时，可以直接"借用"工程师共享出来的 Agent，围着同一个 Localhost 页面做前端设计——借的只是能力授权，账号不转移，工程师随时能收回。
最有意思的是"并行时刻"：三位同事在同一个 Room 里各自调度 Agent 同时改同一套代码——一个人补图标、一个人调标题样式、第三个人接入时间轴，全程没有代码冲突。这打破了此前"一个人做完另一个人才敢接着做"的串行习惯。
这次协作下来，最直观的感受是一批动作彻底消失了：不用重复搭开发环境，不用来回处理 Git 冲突，不用在群里报进度，不用为传一份改动导出上传下载，也不用在终端、文档、设计工具、聊天软件之间来回切换。
技术上怎么做到的
产品用起来简单，背后是把「身份」「执行」「共享」三件事拆开分别处理。
身份留在本地：Claude Code、Codex 依然是本地工具，登录态、订阅、API key、SSH key、公司 SSO、内网服务这些敏感资产不出电脑，模型厂商的风控和企业安全策略照常生效，“借用别人的 Agent"因此能安全成立。
执行放在本地虚拟化层：Agent 的运行时被放进一个受管的 Linux 环境，系统根据正确性、性能、沙箱成本判断每条指令该去物理机、虚拟机还是云端，Agent 和用户都感知不到差别。
共享才真正上云：上云的只是工作实况这一层——文件改动、任务进度、生成的产物。据官方说法，因为只有协作相关的指令上云，沙箱成本只有普通云端方案的 20% 到 25%。
冲突解决的方式也值得记一下：Google Docs、Figma 的冲突处理在应用层，因为文档操作有限、可以穷举；但 Agent 的命令和文件操作五花八门，没法在应用层逐一适配。Tutti·VM 把协同下沉到文件系统层，自研了一套文件级实时协同引擎，这样上面跑的是 Claude Code、Codex 还是 VS Code 都不需要改代码就具备协作能力。
如果所有 Agent 都能进同一个房间
往远看，这条路线如果走通，会带来几个变化。
Agent 从个人助手变成组织成员：项目的文件、任务、决策过程会沉淀在持续存在的 Room 里，人可以离开、Agent 可以退出，项目不会跟着某一个人的离场而消失，组织由此具备"长期 Memory”。
Agent 之间会形成"默契"：谁负责什么、决策习惯是什么，不需要每次都重新说明，新人入职第一天他的 Agent 就能继承整个组织的上下文。
Agent 之间会自然形成自主分工：当每个 Agent 都能看到全局，它们自己就能判断哪些任务能并行、哪些要排队等待，不再需要一个中央编排器在上面指挥。
这几件事能成立，前提都只有一条——所有 Agent 待在同一个空间里，看着同一份实况，共享同一个运行时。Tutti·VM 目前还在内测阶段，这个方向是否真能走到"Agent 届的 Google Docs 时刻"，还要看更多团队实际用起来之后的反馈。