从 Muse 到 Manus，为什么 Agent 开始需要一台自己的电脑？

9 月 28 日，Manus 发布了 2.0。看完介绍，我没有太多眼前一亮的感觉。最近几个月，各种 Agent 产品接连出现，做网页、做视频、处理文件、自动执行任务，已经很难仅凭功能列表让我兴奋起来。不过，里面的 Cloud Computer，让我停下来多看了一会儿。

月初发布的 Meta Muse，也有一台属于用户的云端电脑。我自己使用 WorkBuddy 时，则看到另一种安排：Desktop 版本在本地工作，手机 App 使用云端沙箱。同样是接收指令、调用工具、交付结果，Agent 的工作环境并不相同。

最初我想得很简单：云电脑能力完整，沙箱轻便，区别大概在这里。查下去才发现，我把产品形态、隔离机制和运行寿命混在了一起。

Manus 的 Cloud Computer 早在今年 4 月就发布了。官方说明并列了三种环境：临时 Sandbox 处理脚本、分析和制作任务，Desktop 访问本机文件与应用，Cloud Computer 承载持续在线的程序和项目。到了 2.0，云电脑又与游戏服务器、自动化和专业创作联系起来。Manus Cloud Computer 说明、2.0 发布说明

同一个产品为什么需要三种环境？要回答它，得先看我们准备把什么样的工作交给 Agent。

一次任务结束后，哪些东西应该留下？

最先让我想到的是登录状态。假设我在手机上交代 Agent：去邮箱找客户发来的附件，整理进项目目录，明天收到补充材料后再更新。如果每次继续工作，都要我重新登录邮箱、输入验证码，这个助理就会不断把琐碎的步骤交还给我。它忙了半天，一个登录窗口又把我叫了回来。

登录态之外，下载的文件要还在，安装好的工具要还能用，编辑到一半的项目要能继续。遇到它处理不了的页面，我最好能进入同一个现场，完成必要操作，再把控制权交回去。

这里有四种需要分别设计的连续性：文件与环境、身份与授权、执行现场，以及任务进度。 磁盘文件还在，不代表后台进程还活着；浏览器重新打开了，也不代表 Agent 知道邮件已经处理到哪一封。

完整工作环境的价值，还在于把工具串起来。有合适 API 的服务，通过接口连接；没有合适接口的网站，可能需要浏览器。下载资料、运行脚本、修改文件、预览、上传，这些步骤要能接续，Agent 才不必每走一步都请用户搬一次文件。

这些需求并不意味着必须常驻一台虚拟机。Browserbase 的 Contexts 就支持跨浏览器会话保存 Cookie、认证信息和网站数据。浏览器会话换了，登录状态仍可接续；当然，网站依然可以使会话过期，或要求重新认证。Browserbase 文档

于是，问题从“要不要一台电脑”，变得更具体：长期接受个人委托的 Agent，需要保留哪些状态，由谁保存，又怎样接着工作？

云电脑 vs Sandbox：先比较运行方式

“云电脑”通常描述用户得到什么：一套可以使用的文件系统、工具、终端，可能还有浏览器和桌面。“沙箱”强调执行的边界：代码能够接触哪些资源，与其他用户、其他任务如何隔离。

虚拟机、microVM、容器属于实现机制；一次性、可休眠、一直在线，则是生命周期选择。一台支持浏览器、终端和持久磁盘的虚拟机，完全可以同时被产品称为云电脑，被基础设施称为沙箱。

具体到选型，可以比较“面向个人或项目的持久云电脑”与“按任务供给的 Sandbox”。这是两种运行方式，右栏并不代表所有沙箱。

长期环境减少重复配置，任务沙箱便于重建、并行和清理。个人 Agent 可以同时使用两者：主要工作区长期保留，批量研究或运行陌生代码时，再分配独立任务沙箱。

能力边界要看具体实现。 浏览器、图形桌面、软件安装、后台进程、网络与设备访问，都取决于镜像、运行时、权限策略和平台接口。“云电脑”不会自动获得全部能力，“沙箱”也未必缺少它们。

再往下一层：容器、VM 与 microVM 如何隔离

普通 Linux 容器里的程序，仍向宿主机的同一个内核发出系统调用。namespaces 隔开进程、网络、挂载点等资源的可见范围，cgroups 管理资源计量和配额，再结合 capabilities、seccomp 等机制限制权限与系统调用。容器因此可以拥有自己的工具和文件系统视图，但没有独立内核。Docker 安全机制说明

VM 则在虚拟硬件上运行 Guest 内核，由虚拟化层隔开 Guest 和宿主。microVM 保留这条边界，重点精简虚拟设备与启动路径。它仍是虚拟机，不是给普通容器换了一个名字。Firecracker 设计说明

Linux/KVM 路径示意，箭头表示依赖关系；实际平台可在 VM 内叠加容器。AI 辅助生成并按技术资料校对。

Docker 镜像本身也不能说明隔离强度。镜像是软件的打包方式，既可以用于普通容器，也可以成为虚拟机环境的用户态内容。而 VM 如果挂载了过多目录、拿到了过宽的服务授权，同样可能暴露用户数据。

三款产品的公开架构，把这些区别落到了实处。以下依据截至 2026 年 9 月 29 日的官方资料，不作产品性能排名。

Muse 为个人提供专属 VM，内部继续划分边界。编排模型与工具的 Harness，以及执行工具，位于 systemd-nspawn 容器中；凭证服务、权限判断和持久应用状态则在执行容器之外。Agent 有自己的工作环境，但不能读取里面所有东西。Muse 技术说明

ChatGPT Work Cloud 使用 VM 支撑的托管沙箱，可以复用环境，也可以替换环境并保留符合条件的状态。执行快照、项目文件、Library 和浏览器数据仍有各自的生命周期，“可以接续”不等于所有状态永久保留。Work Cloud 架构

Claude Cowork 的云端会话各自使用临时沙箱，沙箱随会话结束销毁，会话与文件保存在账户层。本地模式中，Agent 主循环运行在设备上，代码执行留在本地 Linux VM；云端会话也可以经在线的 Desktop 应用使用被授权的本机文件或浏览器。主循环、代码执行和工具访问，并不必然发生在同一个环境。Cowork 架构说明

给每个 Agent 一台电脑，会不会太贵？

我最初的另一个直觉是：虚拟机很重。这个印象主要来自 VMware——先启动完整系统，再等桌面和应用准备好。

microVM 降低了这部分开销。Firecracker 通过精简虚拟设备和启动路径，让独立系统环境变得更轻。

Firecracker 常被引用的两个数字是 125 ms 启动、5 MiB 内存开销。性能规范给出了明确口径：在指定宿主条件和精简系统配置下，从 InstanceStart 到 Linux 的 /sbin/init 开始运行，不超过 125 ms；5 MiB 是指定配置下虚拟机监控器（VMM）线程的额外内存，且会随负载变化。浏览器、桌面和应用占用的内存还要另算。Firecracker 性能规范

用户等的是“可以开始干活”。调度、镜像准备、磁盘与网络配置、工具启动、认证检查，都可能增加等待时间。125 ms 描述了其中一段，不能代表整个链路。

快照恢复则让环境不必每次从头准备：保存已经运行到某个时刻的状态，下次从那里继续。个人工作环境可以长期保留，计算资源则按需使用。 空闲时暂停，需要时再唤醒，是其中一种方式。

快照保存到哪一层，决定能恢复什么。只保存文件，应用仍需重新启动；包含内存与进程状态，才更接近恢复执行现场。挂载的数据卷、外部连接也未必处在同一个恢复边界里。选型时需要逐项核对，不能停在“支持快照”四个字上。Modal 对不同快照的说明

暂停期间，进程不会继续工作，定时和事件触发需要环境之外的机制。持续监听消息、维持长连接、向外提供服务的任务，可能仍适合常驻。存储、恢复读写和调度也都有成本，需要结合任务的活跃时长与接续要求来算。

兼容性同样不能省略。一套轻量 Linux 环境不会自动获得用户 Mac 或 Windows 上的全部应用与设备能力。启动速度、隔离强度和软件兼容性，仍要放在具体任务里权衡。

一台电脑，也可以有多个执行后端

文件留在同一个工作区，执行任务的环境还可以进一步拆开。

Cloudflare 在 8 月公布的 @cloudflare/computer 预览版，以 SQLite 支撑虚拟文件系统。适合的文件处理在轻量 isolate 中执行，需要 Linux 或原生程序时再使用容器，两种后端面向同一份工作区。这里的 isolate 提供隔离的 JavaScript 运行环境，不能当作完整 Linux 使用。Cloudflare 官方介绍

这个设计吸引我的地方，是工作区不必随着执行后端一起更换。Agent 面对熟悉的文件，平台则按工作内容选择资源。项目仍处于早期预览阶段，但已经给出了持久状态与弹性执行如何组合的具体例子。

参考 Cloudflare 官方架构图重绘：isolate 通过 binding 访问工作区，容器通过 FUSE 挂载并同步文件。

另一类研究在尝试把工作现场“分支”出去。TClone 把图形应用与桌面合成器放在同一个工作区容器中，让分支各自拥有窗口、光标、剪贴板和进程状态，通过写时复制共享未变化的数据。Agent 可以从已有现场开始隔离试错，再选择保留结果。这需要修改 Linux 内核和进程恢复工具，目前属于研究系统。TClone 论文

环境分支让试错更方便，也带来一个必须回答的问题：哪些变化可以带回，哪些动作一旦发生就收不回？

环境留下来了，麻烦也会留下来

长期工作区会积累工具、配置、文件与缓存。这些积累能省掉重复劳动，也会留下过期信息、互不兼容的依赖，以及误操作造成的损坏。保留环境之后，还得有人负责升级、清理和修复。

多个 Agent 之间的边界也要明确。Grok Bot 的官方文档说明，同一用户的多个 Bots 共享一台云电脑，文件、浏览器会话和应用登录可在 Bots 之间使用。这方便交接工作，也意味着不同 Bot 并不各自拥有独立的文件和账号隔离边界。Grok Bot 权限说明

登录状态的便利，也带来了长期授权的问题。我希望 Agent 不必天天向我要密码，但不希望它运行的任意脚本都能读到长期密钥。Muse 将凭证服务与执行容器分开，Cowork 将 Connector 授权 token 留在云沙箱之外，都说明身份接续可以与凭证访问限制同时实现。

即使读不到密钥，Agent 仍可能通过获准的接口做错事。隔离限定了它能接触的资源，却不能独自判断每次操作是否符合用户意图。

恢复也有类似的边界。假设 Agent 发出一封邮件后崩溃，平台把电脑恢复到发送前的快照。文件、内存或许回去了，收件人的邮箱不会跟着回去。Agent 如果只看恢复后的现场，很可能再发一次。

TClone 的论文也明确把邮件、支付等外部副作用排除在回滚能力之外。Firecracker 的快照规范则提醒，恢复后不能保证原有网络连接继续有效。TClone 的外部效果边界、Firecracker 快照规范

能恢复一台电脑，不等于能正确恢复一项委托。 平台还需保存动作记录，在结果不确定时核对外部系统，并为适用的步骤设计幂等机制，避免重复执行。快照之外，这些记录和规则才能帮助 Agent 判断下一步该做什么。

我期待怎样的个人 Agent

我的判断是：对于长期接受个人委托的 Agent，持久工作环境会越来越重要。它是否需要一台始终在线的 VM，则取决于任务的连续运行要求。

我倾向于让个人文件、偏好和授权持续保留，浏览器与工作现场按需接续；临时计算、陌生代码和并行试验使用独立环境；适合 API 的操作通过接口完成，需要本机软件或设备时连接本地。长期在线的服务，再保留常驻资源。

前面的产品和研究分别实现了其中一些能力，还不足以证明行业会收敛到同一种架构。

回到最初那个例子：晚上在手机上交代的工作，第二天应该能接着做。Agent 知道附件放在哪里、哪些内容已经处理、哪封邮件已经发出；遇到必须由我完成的步骤，能把现场交给我。至于它昨晚换过几次执行实例，我并不需要知道。

以后再看一款个人 Agent，我会多留意第一次演示之后的事情：我们留下的工作，它还能不能接住。