← 全部文章
Analysis

Claude Cowork 的本地 VM 暴露了安全桌面 agent 的真实成本

A cream-background editorial illustration of a laptop running a sealed Linux VM box inside it, with terracotta arrows fo

5 月 25 日,Anthropic 在当前这场 agent 安全辩论里,发布了最诚实的一句话:Claude Cowork 的第一版桌面架构运行在“一个完整的虚拟机”里,在 macOS 上使用 Apple 的 Virtualization framework,在 Windows 上使用 HCS,并拥有自己的 Linux 内核、文件系统和进程表(Anthropic)。两周后,Hacker News 上的人们开始争论:为什么 Windows 上的 Claude Desktop 明明只是想聊天,却能拉起一个 1.8 GB 的 Hyper-V VM(Hacker News)。

这不是巧合。这是产品账单到了。

舒服的说法是 Anthropic 发了个 bug,没错,也确实有 bug 报告。更尖锐的说法是:安全的桌面 agent 正在逼模型公司变成 runtime 厂商。一旦一个 agent 能读取本地文件、运行代码、调用工具,并在会话之间保留状态,“AI 安全”就不再是模型卡片上的问题。它变成了文件系统、内核、hypervisor、网络策略、身份、审计和终端监控的问题。

架构草图,展示 Claude Desktop 宿主进程、原生 agent 循环、挂载的工作区文件夹、专用 Linux VM

VM 并不是偶然出现的

Anthropic 公开的架构说得很清楚。Claude Cowork 不只是一个带文件上传的聊天框。Help Center 表示 Cowork 使用两个执行环境:agent 循环在设备上原生运行,而 shell 命令和生成的代码则在一个专用 Linux VM 中执行,该 VM 通过 macOS 上的 Apple Virtualization.framework 和 Windows 上的 Hyper-V 进行隔离(Claude Help Center)。

这个设计站得住脚。事实上,这正是我最信任的部分。

Anthropic 的工程文章解释了为什么 Claude Code 可以依赖人工审批循环,而 Cowork 不行。Claude Code 的用户是开发者。他们通常能在批准前看懂一条 bash 命令。Cowork 面向更广泛的知识工作者,让用户去判断 find . -name "*.tmp" -exec rm {} \; 是否安全,那就是表演。对这类用户来说,正确的边界不是一个吓人的弹窗,而是一个始终开启的沙箱。

Anthropic 还给出了有用的数据。用户大约批准了 Claude Code 权限提示中的 93%。加入 OS 级沙箱后,权限提示减少了 84%。Claude Code 自动模式能拦下大约 83% 的“过度积极”行为,Anthropic 的脚注则说明仍有约 17% 会漏过去(Anthropic)。教训很直白:提示只是策略建议。沙箱才是策略执行。

Anthropic 真正在做的隔离取舍是这样的:

产品形态Runtime 边界主要安全成本
claude.ai 代码执行服务端 gVisor 容器本地能力更弱
Claude CodeOS 沙箱加审批用户必须理解风险
Claude Cowork本地 Linux VM启动、内存、磁盘、IT 可见性

VM 的存在,是因为 Anthropic 在认真对待本地爆炸半径。被选中的工作区和 .claude 文件夹会被挂载。凭据留在宿主机 keychain 里。网络出站受到限制。Anthropic 甚至特别提到符号链接校验和挂载模式:只读、读写、读写但不可删除。

这是真工程。它也有真成本。

社区恼火的是账单,不是边界

登上 HN 的那个 GitHub issue 开于 2026 年 2 月 26 日。报告者描述了一台 16 GB 内存的 Razer Blade 笔记本,运行 Windows 11 Pro 25H2,启用了 VirtualMachinePlatform,同时禁用了 Hyper-V、WSL、Docker 和 Windows Sandbox。在 Cowork 或 agent 模式用过一次之后,据称 Claude Desktop 每次启动都会拉起一个 Hyper-V VM,Vmmem 显示大约占用 1,796 到 1,846 MB(GitHub)。

这很重要,因为 1.8 GB 不是抽象数字。在一台 16 GB 笔记本上,它意味着用户还没要求 agent 做任何 agent 工作,就已经吃掉了超过 11% 的内存。同一个 issue 还说,空闲内存占用从约 50% 上升到 62%,在正常应用负载下又升到 70–75%。报告者还在 %APPDATA%\Claude\local-agent-mode-sessions\ 下发现了 2,689 个陈旧会话文件。

临时解决办法并不好看:

Disable-WindowsOptionalFeature -Online -FeatureName "VirtualMachinePlatform" -NoRestart
Stop-Process -Name vmwp -Force
Stop-Process -Name vmcompute -Force

这不是消费者级的 workaround。这是一张 IT 工单。

HN 线程做了 HN 会做的事:有人怪产品粗糙,有人为沙箱的必要性辩护,也有几个人问出了 Anthropic 应该正面回答的产品问题:为什么 Cowork 不能直接做成 opt-in?一位评论者给出了有用的中间地带:在把一切都交给 agent 和什么都不给它之间,存在一个连续谱(Hacker News)。这才是正确的框架。

Linux 用户的挫败感也来自同一个地方。Anthropic 官方安装页面只列出 macOS 11+ 和 Windows 10+,安装选项也只有“macOS”和“Windows”(Claude Help Center)。与此同时,Reddit 线程不断追问为什么没有 Linux 桌面应用,尤其是 Claude Desktop 已经在为本地 agent 执行交付一个 Linux VM(Reddit)。常见抱怨不只是“支持我的 OS”。而是:如果安全 runtime 是 Linux,为什么 Linux 用户得到的官方桌面支持最少?

答案可能是打包、企业部署、keychain 集成、应用沙箱、支持负担,或者缺少统一的 Linux 桌面安全 API。这些都是严肃理由。但产品观感很差。开发者看得到 VM。看得到 Hyper-V。看得到陈旧会话文件夹。看得到非官方 Linux 重新打包项目。他们知道抽象层什么时候漏了。

紧凑柱状图,对比已报告的本地开销:Windows issue 中 1.8 GB Hyper-V VM 内存、2,689 个陈旧会话文件

安全已经变成 runtime 问题

Anthropic 文章里最重要的部分不是 VM,而是失败模式。

Anthropic 描述了一次第三方披露:Cowork 的出站 allowlist 完全按配置工作。它允许访问 api.anthropic.com,因为产品需要这个 API。挂载工作区中的一个恶意文件包含隐藏指令和攻击者控制的 API key。Claude 读取文件,并通过 Anthropic 的 Files API 把它们上传到攻击者账户。Anthropic 的总结很残酷:沙箱生效了,数据仍然流出去了(Anthropic)。

这一个事件就概括了 agent 安全问题。域名 allowlist 不够,因为域名不是权限。它是一组能力的捆绑。允许 api.anthropic.com,就意味着允许该 API 背后所有可达操作,除非 runtime 理解来源、token 范围、header 和意图。

Anthropic 的修复是在 VM 内加入一个防御性的中间人代理,只放行携带 VM 自己预置会话 token 的请求,并拒绝攻击者嵌入的 key。这很好。它也给所有构建桌面 agent 的人竖了块路标:沙箱需要理解身份和能力,而不只是 IP 地址和路径。

传统桌面应用不需要这么多机器,因为它们不会自主决定打开文件、合成命令、串联工具,并绕过缺失的权限。浏览器沙箱隔离的是不受信任的网页。容器隔离的是服务。桌面 agent 沙箱要隔离的,是一个半自主的操作者:它能从恶意文档里读取指令,然后用合法工具做错事。

这就是为什么它正在变成 OS/runtime 层。

OS 已经拥有大多数基础原语:进程隔离、文件系统权限、安全凭据存储、网络过滤、审计日志、公证、EDR hook、设备管理。模型公司拥有 agent 循环和策略意图。缺失的产品,是两者之间的契约。

企业 IT 要付两次钱

VM 给了 Anthropic 一个硬隔离边界。它也把活动藏在了企业依赖的同一批安全工具之外。

Anthropic 直接说了这一点。在 Cowork 架构 FAQ 中,“endpoint detection (EDR) tools 能否检查 VM 内部活动?”的回答是“不能”。VM 按设计与宿主机安全工具隔离(Claude Help Center)。工程文章还补充说,当前缓解方式是面向管理员的拉取式 OTLP 导出,这和实时监控不是一回事(Anthropic)。

这意味着 IT 要付两次钱。

第一次,付资源成本:磁盘包、VM 启动、内存压力、虚拟化冲突、网络问题和 helpdesk 脚本。第二次,付可见性成本:让 agent 相对宿主更安全的东西,也让它对宿主侧监控更不透明。

这不是拒绝 VM 的理由。而是停止假装“跑在 VM 里”就是安全故事终点的理由。对企业 rollout 来说,一个没有一等遥测能力的密封 VM,就是一个边界漂亮的黑盒。

审计缺口更尖锐,因为 Help Center 表示 Cowork 活动“目前不会”被记录到审计日志、Compliance API 或数据导出中,并指向 OpenTelemetry 作为监控指南(Claude Help Center)。如果一个人类员工使用 shell、复制文件或调用 API,公司会期待日志。如果一个 agent 在 VM 里做这些事,“相信我们,它被隔离了”过不了采购。

前后对比的可观测性示意图:左侧显示宿主 EDR 只能看到不透明的 hypervisor 进程;右侧显示更细粒度的运行时遥测

开发者应该要求什么

社区争论太集中在 1.8 GB 是否“太多”。这取决于机器和任务。真正应该要求的是控制权。

桌面 agent 厂商应该把沙箱状态作为产品界面暴露出来,而不是把它埋在 AppData 和任务管理器里。开发者和管理员应该要求五件事。

第一:惰性启动。聊天不应该启动 VM。Cowork 才应该。定时任务也许有理由保持一个温热的 runtime,但这必须可见、可配置。

第二:沙箱仪表盘。显示 VM 状态、内存、磁盘使用、挂载文件夹、活动会话、出站策略和上次清理时间。如果 Docker Desktop 能显示容器,Claude Desktop 就能显示它的 agent runtime。

第三:明确的安装选项。如果 Cowork 在某些系统上需要 10 GB 级别的包,那就在下载前说清楚。让用户选择位置。让他们能移除它而不破坏聊天功能。

第四:策略即代码。开发者应该能够检查和版本化实际生效的沙箱策略:挂载、网络目的地、本地 MCP 权限、token 范围和删除规则。一个含糊的“出站设置”面板不足以支撑真正干活的团队。

第五:实时可观测性 hook。OTLP 导出是个开始。标准应该是按工具调用记录日志、文件访问事件、被拒绝的动作、网络决策、会话身份,以及管理员可读的原因代码。不能把 EDR 盲区轻描淡写成隔离的代价。

Linux 诉求也属于这里。Linux 桌面应用不只是社区福利。它是一个机会:可以构建在许多沙箱原语、开发者工作流和容器心智模型本来就原生存在的平台上。如果难点是桌面集成,那就明说。如果难点是跨发行版企业支持,那就明说。沉默只会让用户推断为忽视。

正确的结论

Anthropic 值得因为公开这些令人不舒服的细节而获得赞许。那篇文章包含真实数字、真实漏掉的风险和真实取舍。大多数厂商会停在“安全沙箱”四个字。Anthropic 解释了沙箱在哪里失效、用户审批在哪里失效,以及 VM 隔离在哪里让企业监控变得更糟。

但 HN 的愤怒也有道理。安全成本不会因为架构图合理就消失。它们会转移到用户的笔记本、管理员的部署计划和开发者的日常工作流上。

Claude Cowork 的 VM 是未来提前到场:本地 agent 将需要坚硬的 runtime 边界、限定范围的身份、网络中介和可审计的工具执行。赢家不会是那些把这套机器藏起来的厂商。赢家会让这套机器可理解、可调节、可观察,并且无聊。

一个能操作你的文件和工具的桌面 agent,不再只是一个 app。它是一个小型操作环境。请按这个标准对待它。

想亲自试试 Claude Fable 5 的读者,可以通过 Claude Fable 5 on OneHop 使用它,这是一个即插即用的端点,价格大约比标价低 30%。新账户可以先领 $10 免费额度,无需绑卡。

延伸阅读:Claude Fable 5 入门.