Cowork 把推理和虚拟机都搬到云端，彻底解决本地耗电和断连中断的问题

做本地 AI Agent 的人都知道一个朴素的真理：算力不在身边，体验就在云端。但“云端”这两个字太宽泛，具体到工程实现，是把整个大脑搬过去，还是只搬一半？Anthropic 的 Felix Rieseberg 最近拆解了 Claude Cowork 的架构迭代，这个变化看似只是部署位置的移动，实际上重新定义了本地 Agent 的运行逻辑。旧版 Cowork 虽然号称是“本地优先”，但本质上是在你的笔记本里养了一只隐形的大象；新版则直接把大象关进了云端的笼子，只留下一根细线连着你的设备。这种架构切换不仅解决了电池焦虑，还顺手修好了手机使用和本地文件映射的几个隐性痛点。

旧版架构的隐形成本：你在本地运行的是什么

理解新版的改进，得先看旧版是怎么跑的。Felix Rieseberg 明确指出，旧版 Cowork 采用的是“云脑 + 本地手脚”的模式。具体来说，模型推理（Model Inference）发生在云端，但执行工具调用（Tool Calls）的虚拟环境（VM）是被打包发送到用户电脑本地的。
这里有一个容易被忽略的技术细节：这个 VM 是 Anthropic 提供的，而不是你自己搭建的 Docker 容器。这意味着为了获得更强的能力、安全性和数据隔离，Cowork 需要在你的硬盘上开辟空间，在内存里常驻一个轻量级的 Linux 环境。
这种设计带来的直接后果有三点，都是实打实的物理开销：

• 磁盘占用：VM 镜像需要存储在本地文件系统，随着会话增多或缓存积累，这块空间不会自动消失。
• 电池消耗：即使模型在云端跑，本地 VM 也需要保持活跃以接收指令、执行文件读写和返回结果。后台进程的空转功耗比你想的要高，尤其是当 Agent 在进行复杂的多步任务时，CPU 的频繁唤醒会迅速耗尽 MacBook 的电量。
• 状态依赖：这是最致命的一点。当你合上笔记本盖子，本地 VM 就会挂起或停止。一旦工作流中断，Agent 就无法继续执行后续步骤。你失去了“随时可访问”的属性，Agent 变成了“仅在电脑开机时存在”的工具。

很多人喜欢旧版那种“数据只存在于你明确加入会话的文件”的简洁感，但对于一个需要持续工作的 Assistant 来说，这种架构限制了它的使用场景。你不能在地铁上用手机打开 Cowork 继续刚才未完成的代码重构，因为那台运行 VM 的电脑可能已经休眠了。

新版架构：全栈上云与沙箱隔离

新版的改动非常彻底：模型推理和 VM 都移到了云端。但这不仅仅是把文件传过去那么简单，核心变化在于状态隔离机制。
Felix 强调，新版 Cowork 中，每个会话（Session）现在拥有自己独立的沙箱（Sandbox），不同会话之间不共享状态。这种设计的精妙之处在于解耦了“计算环境”和“用户设备”。
当 Agent 需要读取你本地设备上的文件时，流程变成了这样：

1. 云端 VM 发起文件访问请求。
2. 桌面端应用（Desktop App）作为代理，负责在本地文件系统执行实际的读取操作。
3. 文件内容被传回云端 VM 供 Agent 处理。

这种“请求-响应”式的交互，比旧版那种“把整个环境搬过来”要轻量得多。桌面应用变成了一个轻薄的网关，只负责最基础的文件 I/O 权限验证和数据传输，不再需要维护一个完整的运行时环境。

架构切换带来的三个实际收益

这种从“本地 VM”到“云端沙箱”的转变，直接带来了三个对用户感知极强的改变。如果你正在评估是否切换到新版 Cowork，或者在思考自己开发的 Agent 架构，这三个点是关键的决策依据。

• 设备无关性：既然 VM 在云端，那么入口可以是任何能跑浏览器的设备。你可以在手机上启动 Cowork，云端沙箱依然在运行。这解决了 Felix 提到的“从手机使用 Cowork”的体验问题。手机不需要加载沉重的 VM 镜像，只需要维持一个 WebSocket 连接，功耗几乎可以忽略不计。
• 持久化运行：合上笔记本不再意味着工作中断。只要网络连接存在，云端沙箱里的 Agent 就可以继续运行长时间的任务（比如等待一个 API 响应、监控日志或进行批量数据处理）。这对于后台型任务是一个质的提升。
• 性能与续航平衡：本地不再承担 VM 的计算和 I/O 开销。对于使用 M 系列芯片的 Mac 用户来说，省电效果会非常明显。因为旧版 VM 即使在空闲时也占用了部分内存带宽和 CPU 周期，新版将这些负载完全卸载到了 Anthropic 的基础设施上。

潜在的权衡：延迟与网络依赖

当然，架构变更从来不是免费的午餐。把 VM 移到云端，必然引入网络延迟。
在旧版中，Agent 读取本地文件的延迟主要是本地磁盘 IO 的速度，通常在毫秒级。在新版中，文件读取需要经过：本地读取 -> 网络传输 -> 云端解析 -> 结果返回。对于小文件，这个延迟感知不强；但如果 Agent 需要处理大量大型文件或高频的文件写入，网络波动可能会影响响应速度。
此外，“独立沙箱”意味着状态重置的成本增加了。如果你习惯在一个长期运行的 Shell 环境中累积环境变量或临时文件，新版的隔离策略要求你更明确地管理上下文。每次开启新会话，都是一个干净的起点。这对保持输出的纯净度很有帮助，但也要求用户更清晰地规划工作流。

本地 Agent 的未来形态：混合式还是全云化？

Felix 的这个拆解其实揭示了一个趋势：本地 Agent 的最终形态可能不是“本地运行一切”，而是“本地感知，云端执行”。
目前的 AI 开发趋势有两个极端：一个是完全本地化的 Ollama 路线，追求绝对的隐私和零延迟；另一个是完全云化的 API 调用，追求最强的模型能力。Cowork 的新版走了一条中间道路：利用云端的强大算力进行推理和执行，利用本地的便捷性进行数据接入。
这种架构特别适合那些需要“通用能力”但又希望“零配置”的用户。你不需要关心 Docker 镜像、端口冲突或系统兼容性，Anthropic 在云端帮你搞定了所有脏活累活。你只需要关注你的数据（文件、文档）如何被 Agent 理解。

如何判断这种变化是否适合你

如果你属于以下两类用户，新版 Cowork 的提升是显著的：

1. 多设备切换者：经常在台式机、笔记本和手机之间切换工作流。旧版的状态绑定会让这种切换变得笨拙，新版的云端沙箱让你可以随时随地接续工作。
2. 续航敏感型用户：习惯带着笔记本出门，且经常在不插电的情况下使用 AI 工具。省下的电量可以直接转化为更多的专注时间。

但如果你是重度离线工作者，或者你的工作环境网络极不稳定，旧版的本地 VM 模式可能更可靠。至少，它不依赖外网就能完成基本的工具调用。不过，考虑到 Cowork 的核心价值在于利用 Claude 的强大推理能力，离线模式本就失去了“AI”的部分意义，所以这一点或许并不重要。

结语：简单化的背后是工程的复杂化

对用户来说，Cowork 的变化只是“不再吃电”和“可以用手机了”这么简单。但对开发者而言，这是从“同步阻塞式本地执行”向“异步事件驱动式云端沙箱”的重构。
Felix Rieseberg 提到这解决了他们听到的许多问题，这说明 Anthropic 并没有把 Cowork 仅仅当作一个聊天界面，而是在认真构建一个通用的代理基础设施。这种基础设施的演进方向很清晰：让计算无处不在，让接口无处不有。对于普通开发者来说，关注这种底层架构的变迁，比追逐最新的模型参数更有意义，因为它决定了你最终如何使用这些能力。