市面上的 AI Agent 协作产品，大部分选择了同一条路：把你的 Agent 搬到云端。给你一台云端机器，Agent 在上面跑，所有状态天然在云端，共享看起来很简单。
Tutti · VM 没走这条路。这篇文章完整解释为什么，以及我们用了什么替代方案。
云端 Agent 的三个问题
把 Claude Code、Codex 这类 Agent 搬上云，听起来合理，但一落地就会撞上三堵墙。
第一堵墙：身份
Claude Code、Codex 这类 Agent，不是一个无状态的程序。它身上挂着一整套你的身份：
- 账号登录态：你的 Claude 订阅、OpenAI 订阅，是绑定在你账号上的。
- 订阅额度：你每月付的 $20 / $200，对应的调用额度跟着你的账号走。
- 私有仓库的 access token：Agent 要替你读写 GitHub 仓库，需要你的 Git 凭据。
- 公司 SSO：如果 Agent 要访问企业内部系统，SSO token 是必须的。
- SSH key：Agent 要 SSH 到服务器，用的是你的密钥。
- API key 和 MCP 配置：你给 Agent 配的各种 tool 和 MCP server，连接信息都在本地。
你要让它在云端机器上跑，就得把这些东西全部搬上去。有几种方式：
- 手动复制：你自己把 API key、token 粘贴到云端环境里。安全风险极高，而且 token 过期了得重新弄。
- 在云端重新登录：在云端机器上重新走一遍 OAuth 流程。但很多企业 SSO 不允许在非受信设备上登录。
- 平台帮你注入：你把凭据交给平台，平台替你注入到云端环境。这意味着平台持有了你的凭据。
不管哪种方式，结果都是：云端成为了你身份的实际持有者。你的订阅额度在云端被消耗，你的凭据在云端被存储，你的 access token 在云端被使用。你失去了对身份的直接控制。
第二堵墙：锁定
为了绕过身份问题，很多云端方案选择自建 Agent 体系。你不带自己的 Claude Code 进来了，用平台的 Agent，走 API 模式，平台给你配好了一切：模型、工具、额度。
但这里有一个被忽视的成本：你已经在自己常用的 Agent 上投入了大量时间和钱。
你已经有 Claude Code 的 Pro 订阅，已经为 Codex 付了费。你花了几个小时配好了 MCP server，连上了你的数据库、你的 Jira、你的 Slack。你写了自定义 skill，教 Agent 理解你的代码库规范。你调好了 system prompt，让 Agent 按你的习惯写代码。
这些是你的个人能力资产，它们绑在你本地的 Agent 上。
如果为了协作就把这些全扔掉，用平台的 Agent 从零开始配；或者更糟，为了拿回等价的能力再额外付费给平台，这笔账怎么算都不划算。
这就是 BYOS（Bring Your Own Subscriptions）的核心逻辑：你应该带着自己的订阅进来，不该为协作换工具。
第三堵墙：网络身份
Agent 从你的电脑发出请求时，走的是你的网络出口，这个出口携带着你的网络身份：
- 公司 IP 白名单：很多企业的内部服务只允许公司 IP 访问。Agent 从你的电脑发请求，天然符合白名单。
- 企业 SSO 的 IP 绑定：部分企业 SSO 系统会校验请求来源 IP，非公司网络的请求会被拒绝。
- 内网服务：Agent 可能需要访问只在内网可达的服务（数据库、CI/CD、内部 API）。这些服务对公网不可见，只有你的电脑能访问。
- 模型商的风控：模型提供商（如 Anthropic、OpenAI）会根据 IP 做风控。你的账号绑定了常用的 IP 段，突然从云厂商机房发请求，可能触发风控甚至封号。
一旦 Agent 搬到云端，请求从云厂商机房发出，这些东西全部可能失效。你的 Agent 突然连不上公司内网了，突然触发风控了，突然 SSO 不认了。这些问题在开发时不易发现，在生产中才暴露。
三个问题的叠加效应
这三个问题不是独立的，它们会叠加。身份搬上云 → 平台要求你用它的 Agent → 你的网络身份失效 → 平台的 Agent 也连不上你的内网 → 协作体验严重降级。
这个叠加效应让我们确信：把 Agent 整体搬上云，不应该是一条该走的路。
Tutti · VM 的三层架构
三个问题叠加在一起，我们做了一个架构决定：把「身份」「执行」「共享」三件事物理分离，各自放在最合理的位置。
身份留在你的电脑上
登录态、凭据、API key、SSH key、Git 凭据，这些敏感的东西不出你的电脑，云端永远拿不到。
这意味着：
- 你的订阅额度始终在你的账号下消耗，不经过任何第三方。
- 你的凭据不会出现在任何云端服务器上。
- 你可以随时查看、修改、撤销你的凭据，不需要通知任何人。
- 即使 Tutti · VM 的云端服务被攻破，攻击者也拿不到你的身份信息。
执行在本地虚拟机里
Tutti · VM 用多层 VM 技术，在你的机器上跑一个受管的 Linux 环境。Claude Code、Codex 就在这里面运行。
关键细节：
- 继续用你自己的订阅：Agent 认你本地的登录态，不经过云端中转。
- 继续用你自己的 MCP 配置：你配好的 MCP server 连接、tool 定义，原封不动地在 VM 里生效。
- 继续用你自己的 tools 和 skills：你写的自定义 skill、调好的 system prompt，都在。
- 用的是你本机的算力：不需要为云端计算资源付费。
- 用的是你本机的网络：Agent 发出的请求走你自己的网络出口，公司 IP 白名单、SSO、内网服务全部正常工作。
多层 VM 技术保证了执行环境的安全隔离。Agent 在 VM 里运行，不会影响你的宿主系统，但又能访问你授权给它的资源。
共享在云端
只有一个东西会进入云端：Agent 的「工作实况」。
工作实况按三个维度呈现：
- 正在聊的：你与 Agent 的对话内容，包括正在讨论什么、历史对话记录。所有交互上下文，从你给 Agent 的指令、Agent 的回复，到中间的追问和澄清，都在这里。
- 正在做的：Agent 此刻正在发生的一切工作过程。正在改哪些文件、改了什么、任务跑到哪一步、有没有出错，如果 Agent 在改前端，preview 现在长什么样。这些状态实时更新，Room 里的人和其他 Agent 看到的永远是最新进展。
- 做好的了：Agent 已经完成的产出物，包括代码文件、图片、文档、设计稿等。这些成果物以最终态留在 Room 里，成为后续工作的上下文。
这些状态天然就在云端 Room 里，Room 里的人和 Agent 都能看到。
注意区分：云端拿到的是协作空间的「执行权」（工作实况的读写权），不是你的「身份」。这就像你把房间的钥匙给了别人，但没有把身份证也给他。他可以进房间工作，但不能冒充你去做其他事。
因为这种分离，你可以随时断开、随时收回。你的 Agent 账号体系始终在自己手里。
BYOS：不只是「自带订阅」
BYOS（Bring Your Own Subscriptions）是上面这套架构的直接产物。因为身份在本地、执行在本地 VM，所以你带进来的不只是「订阅额度」，而是你完整的 Agent 工作环境：
- 你的 Claude Code Pro 订阅
- 你的 Codex 订阅
- 你配好的 MCP server（数据库连接、Jira 集成、Slack 通知等）
- 你写的 自定义 skills
- 你调好的 system prompt 和 tool 配置
- 你的 Git 凭据和 SSH key
这些全部跟着你，不需要重新配置，不需要额外付费。
BYOS 还支撑了一个 Tutti · VM 独有的功能：Agent 借用。因为每个人的 Agent 身份都在本地，所以 Room 里的人可以授权别人临时使用自己的 Agent。比如你的 Codex 触发了小时限制，你可以借用朋友的。这不是账号转移，是能力委托，授权者随时能收回。
比直接上云难得多，但值得
这套架构比云端托管方案难建得多。主要的工程挑战：
多层 VM 的复杂度。在用户机器上跑一个受管的 Linux 环境，需要同时兼顾性能、安全隔离和跨平台兼容（Mac OS / Linux / Windows）。每个操作系统的虚拟化方案不同，需要分别适配。
工作实况的一致性。多个 Agent 同时往同一个 Room 的工作实况里写数据，怎么保证一致性？怎么处理并发写入冲突？网络断连后怎么恢复？这些都是经典的分布式系统问题。
跨 Agent 的冲突处理。两个 Agent 同时改同一个文件，会怎样？我们用复杂的协同编辑技术来回避和解决冲突，类似 Google Docs 的实时协同编辑，但作用对象不是文档，而是 Agent 的工作环境。
每一个都很难。但到今天，我依然觉得坚持是正确的。因为这条路线可以让大家不必在「协作」和「自由」之间做取舍：
- 不换 Agent，自带订阅（BYOS）。
- 不暴露身份，凭据留在本地。
- 不破坏网络身份，Agent 用你自己的网络。
- 随时断开，云端只有你的工作实况，没有你的控制权。
- 可以借用别人的 Agent，别人也可以借用你的，是能力委托而非账号转移。
Tutti · VM 不替你换工具，只是帮你拆掉你们 Agent 之间那堵墙。
