如果你同时在用 Claude Code 和 Codex，你一定经历过这个场景：Claude 改完了一版前端，你想让 Codex 接着优化。你得把 Claude 改了哪些文件、讨论了什么、preview 长什么样，手动总结一遍，粘贴给 Codex。
如果你还在和朋友一起做项目，你们俩各自跑着 Agent，那就更痛苦了。互相发文件、贴进度、复述 Agent 刚做了什么，人成了 Agent 之间的「渡轮」。
Tutti · VM 要解决的就是这个问题：让多个人、多个 Agent 在同一个空间里实时协作，不需要手动传递上下文。
核心机制：共享工作实况
Tutti · VM 的做法不是让 Agent 之间互相发消息，而是把所有 Agent 的「工作实况」放到同一个云端 Room 里。
工作实况按三个维度呈现：
- 正在聊的：Agent 正在和谁讨论什么、历史对话记录。所有交互上下文，包括指令、回复、追问和澄清，Room 里的每个人和每个 Agent 都能看到。
- 正在做的：Agent 此刻正在发生的一切工作过程。正在改哪些文件、改了什么、任务跑到哪一步、有没有出错、preview 现在长什么样。这些状态实时更新，Room 里的人和其他 Agent 看到的永远是最新进展。
- 做好的了：Agent 已经完成的产出物：代码、图片、文档、设计稿等。这些成果物以最终态留在 Room 里，成为后续工作的上下文。
因为 Agent 指令是通过房间发出的，所以这些工作实况天然就在 Room 里，每个人和每个 Agent 都能看到。
这意味着 Agent 不再需要「做完 → 总结 → 传递 → 重新理解」这个循环。它们直接基于同一个工作实况协作，实时感知其他 Agent 在做什么，自动判断哪些任务可以并行、哪些需要等待。
你一个人用多个 Agent
在同一个 Room 里同时开 Claude Code 和 Codex。Claude 做完（或正在做）一版方案时，你切换到 Codex 的对话框，输入 @，选择 Claude 的那段对话。Codex 直接拿到 Claude 的对话历史、文件改动、preview 状态，接着干。
具体例子：你让 Claude Code 写前端组件，同时让 Codex 写后端 API。两个 Agent 在同一个 Room 里并行工作。Claude 写完组件后，Codex 通过共享的工作实况知道前端接口长什么样，直接对接，不需要你手动告诉 Codex「Claude 的接口是这样的」。
多人带着各自的 Agent 一起协作
你创建一个 Room，邀请朋友进来。他带着自己的 Agent 加入，你们各自的 Agent 都在同一个空间里运行。
你们彼此都能看到对方在做什么。打开 Agent Board 看板，每个人的 Agent 的对话内容、执行过程、产出物一目了然，按「进行中 / 已完成 / 失败 / 停止」分类。看到某个任务你想接手，用「卡片转发」把它转给自己的 Agent，或者在对话框里 @ 那段对话让它继续。
对 Agent 来说，过去 Agent A 做完任务需要总结结果传递给人，人再传递给 Agent B，上下文细节容易丢失，Agent B 需要重新理解项目。现在 Agent A 和 B 直接基于同一个工作实况协作，自动判断该并行还是等待、如何避免冲突。
具体例子：你和朋友一起做全栈项目。你的 Claude Code 负责前端，他的 Codex 负责后端。你们各自在自己的电脑上操作，但两个 Agent 的工作实况在同一个 Room 里。你的 Claude 写完了登录页组件，朋友的 Codex 立刻能看到组件的接口定义，对接后端认证逻辑，不需要你们互相发消息说「我的接口是这样的」。
同时改同一个东西：其他产品做不到的事
这是 Tutti · VM 最独特的协作能力，也是让我们最兴奋的功能。
场景：你和朋友同时写同一个前端页面。你改 Header 组件，他改 Footer 组件，你们都在同一个文件里工作。
过去这几乎不可能做到。不管是用 Git 分支合并，还是用云端 devbox，多人同时改同一个文件最大的痛点就是冲突：你改了第 30 行，他也改了第 30 行，合并的时候必须手动解决冲突。如果两个人同时改的频率很高，冲突会密集到让协作变得不可行。
在 Tutti · VM 里，这件事被解决了。
我们用了复杂的协同编辑技术，类似 Google Docs 的实时协同编辑，但作用对象不是文档，而是 Agent 的工作环境。具体来说：
- 实时感知：你的 Agent 改了哪一行，朋友的 Agent 瞬间就知道。不是「改完了再传递」，是实时的、毫秒级的感知。
- 自动冲突回避：当两个 Agent 同时尝试改同一个区域时，系统会自动协调，类似 Google Docs 里两个人光标不会打架。
- 实时预览：你们可以同时看到 preview 的变化。你改了 Header，preview 上 Header 立刻变了；他改了 Footer，Footer 也立刻变了。你们各自看到对方的修改实时出现，不需要等对方「提交」。
为什么其他产品做不到？
- 云端 devbox（如 Gitpod、Codespaces）：它们解决的是「每人一个云端环境」的问题，不解决「多人同时改同一个文件」的问题。多人协作靠 Git 分支和 merge，冲突依然存在。
- 纯本地 Agent（如 Cursor、Windsurf）：它们是单机工具，根本没有多 Agent 共享环境的机制。
- Agent 编排平台（如 Devin、Factory）：它们是「给你一个 Agent」的模式，不支持你带自己的 Agent 进来，更不支持多 Agent 同时改同一个东西。
- API 模式的 Agent 平台：Agent 之间靠 API 传消息，不共享运行时环境，无法做到实时感知和冲突回避。
Tutti · VM 能做到，是因为架构上就把「工作实况」放在了共享的云端 Room 里，所有 Agent 基于同一个实时状态工作。这不是后期加的功能，是底层架构的自然结果。
这不只是「省去了合并冲突」那么简单。它改变了协作的粒度：从「你做完一版，我做一版」变成「我们同时在做」。从串行到并行，从交接到共创。
协作和连接是底层原语
在 Tutti · VM 里，协作和连接不是某个功能加了协作能力，而是最底层的原语。这意味着：
- Room 里的所有东西天然支持多人同时操作。
- 应用中心的每个应用也天然具有协作能力，多人可以同时在同一个应用里工作。
- 每个 Agent 天然能感知 Room 里的其他 Agent。
这不是给某个应用特殊加的能力，而是底层架构自然涌现的。
为什么这和「接力式的消息传递」不一样
传统的 Agent 协作方式是「通信」：Agent A 做完，总结结果，发给 Agent B，Agent B 重新理解再开始。上下文在传递中必然损耗。Agent A 做的某些决策细节、调试过程中的发现、中间产出的半成品，这些在总结时往往被丢掉。
Tutti · VM 的方式是「共享」：所有 Agent 共享同一个工作实况，谁要什么信息，第一时间拿到完整无损的版本。就像你和同事在游戏里联机，你不需要每隔十分钟停下来跟他说「我刚才做了什么」，他抬头看一眼你就知道了。
协作是实时的、连续的、不需要翻译的。这就是 Tutti · VM 对「多 Agent 协作」的回答。
