Anthropic 推出 Cowork 功能：macOS 无预警生成 10GB 虚拟机包

基本信息

导语

Anthropic 推出的 Cowork 功能在 macOS 上悄然创建了 10GB 的虚拟机资源包，且未在执行前向用户发出明确提示。这一行为不仅占用了宝贵的磁盘空间，也引发了关于开发工具透明度与权限管理的讨论。本文将剖析该现象背后的技术细节，并提供清理磁盘及监控此类后台活动的具体方法，帮助开发者维护系统环境的整洁与可控。

评论

文章中心观点 Anthropic 的 Cowork 功能在未经明确许可的情况下于 macOS 系统中创建了一个 10GB 的虚拟机（VM）包，这一行为暴露了 AI 客户端应用在本地化部署中缺乏透明度、忽视用户存储资源管理以及存在潜在安全边界的模糊化问题。

支撑理由与评价

1. 架构设计的激进性与用户知情权的冲突（内容深度）

  • 支撑理由： 文章揭示了 AI 应用从“轻量级客户端”向“重型本地计算节点”转变的趋势。10GB 的 VM 包含了完整的运行时环境（可能是 Python 或 Conda 环境），这种做法虽然保证了环境的一致性，但完全绕过了 macOS 用户对于“应用安装包”体积的常规心理预期（通常在几百 MB 以内）。
  • 事实陈述： Cowork 功能在未提示的情况下占用 10GB 空间。
  • 你的推断： 这表明 Anthropic 优先考虑了功能部署的便捷性和环境隔离，而非用户体验的流畅度。这种“黑盒”部署模式在技术上是懒惰的，因为它没有优化依赖项的提取或复用系统资源。

2. 资源管理的失控与系统稳定性风险（实用价值）

  • 支撑理由： 对于使用 SSD 空间受限的开发者（尤其是 MacBook Air 用户），10GB 的突发占用可能导致磁盘告警，进而影响系统交换分区和整体性能。
  • 作者观点： 这种静默安装行为具有侵略性。
  • 实际案例： 类似于 Docker Desktop 初版安装时对虚拟化资源的占用，曾引发大量争议。如果用户在不知情的情况下删除该 VM 包，可能导致应用崩溃或数据丢失，这种“孤儿文件”清理逻辑的缺失是工程成熟度不足的表现。

3. 安全边界的模糊化与信任危机（行业影响）

  • 支撑理由： 创建本地 VM 涉及解压和执行二进制文件。虽然 Anthropic 是知名厂商，但这种“下载并运行大量未经验证的代码”的模式，在技术上与恶意软件的 Dropper（投放器）行为具有相似的特征。
  • 你的推断： 这可能引发企业 IT 部门的防御反应。企业安全软件通常监控静默创建的大型可执行文件。此事件可能成为 AI 客户端被列入企业软件黑名单的导火索，阻碍了 AI 工具在 B 端的落地。

反例/边界条件：

  1. 用户预期偏差： 对于重度 AI 用户，如果该 VM 能够提供完全离线的高性能推理能力（如本地运行 LLM），10GB 的空间占用是可以被接受的，前提是用户得到了明确的“价值交换”通知。
  2. 技术实现的必要性： 如果 Cowork 功能高度依赖特定的系统库版本（例如特定的 CUDA 版本或 Python 库冲突），沙盒化 VM 可能是保证功能稳定运行的唯一技术解法，而非单纯的设计疏忽。

争议点与不同观点

  • 便利 vs. 控制： 一部分观点认为，为了实现“开箱即用”的 AI 体验，抽象掉底层环境配置是必要的；而另一部分观点（如本文作者）坚持认为，在用户存储空间上进行“隐蔽操作”违反了用户主权。
  • 客户端的定义： 争议点在于 AI 客户端是否应该被视为一个“浏览器”（仅渲染 UI）还是一个“计算平台”（管理本地资源）。Anthropic 显然采取了后者，但未告知用户。

可验证的检查方式（指标/实验/观察窗口）

  1. 磁盘占用审计（指标）：

    • 在 macOS 终端中使用 du -sh ~/Library/Application\ Support/ 或专门针对 Anthropic 目录进行扫描，监控安装 Cowork 前后的存储增量。
    • 观察该 VM 包是否包含版本控制号，以判断其更新机制是否会创建多个副本（导致空间占用翻倍）。

  2. 网络流量与行为分析（实验）：

    • 使用 Little Snitch 或 Wireshark 监控 Cowork 激活时的网络请求。检查其下载 VM 包时是否使用了加密连接（HTTPS），以及是否有向除 Anthropic API 以外的服务器发送数据的请求（排除数据泄露风险）。

  3. 卸载残留测试（观察窗口）：

    • 删除主应用程序后，检查该 10GB VM 包是否依然存在。如果存在，说明该应用缺乏完善的卸载脚本，这是评价软件工程质量的负面指标。

实际应用建议

  • 开发者应对： 在使用此类 AI 辅助工具前，应使用独立的虚拟机或容器运行该应用，避免污染宿主主机的环境变量和存储空间。
  • 行业规范： AI 厂商应建立“本地资源占用清单”机制，在下载大型资产前必须获得显式授权，类似于移动应用在访问相册或位置信息时的弹窗提示。

代码示例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

# 示例1：检查目录大小并预警
import os

def check_directory_size(path, warning_threshold_gb=5):
    """
    检查指定目录的大小，并在超过阈值时发出警告
    
    参数:
        path: 要检查的目录路径
        warning_threshold_gb: 触发警告的大小阈值(GB)，默认5GB
    """
    total_size = 0
    for dirpath, _, filenames in os.walk(path):
        for filename in filenames:
            filepath = os.path.join(dirpath, filename)
            if os.path.exists(filepath):  # 避免符号链接等问题
                total_size += os.path.getsize(filepath)
    
    size_gb = total_size / (1024**3)
    print(f"目录大小: {size_gb:.2f} GB")
    
    if size_gb > warning_threshold_gb:
        print(f"警告: 目录大小超过 {warning_threshold_gb}GB 阈值!")
        return True
    return False

# 使用示例
check_directory_size("/Applications", 8)  # 检查应用程序目录，8GB阈值

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

# 示例2：监控磁盘空间使用情况
import shutil

def monitor_disk_space(path="/", warning_percent=80):
    """
    监控磁盘空间使用情况，并在使用率超过阈值时发出警告
    
    参数:
        path: 要监控的磁盘路径，默认根目录
        warning_percent: 触发警告的磁盘使用率百分比，默认80%
    """
    total, used, free = shutil.disk_usage(path)
    used_percent = (used / total) * 100
    
    print(f"磁盘使用情况: {used_percent:.1f}%")
    print(f"已用: {used/(1024**3):.2f} GB")
    print(f"剩余: {free/(1024**3):.2f} GB")
    
    if used_percent > warning_percent:
        print(f"警告: 磁盘使用率超过 {warning_percent}%!")
        return True
    return False

# 使用示例
monitor_disk_space("/", 85)  # 监控根目录，85%阈值

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

# 示例3：自动清理大文件
import os
import time

def clean_large_files(directory, size_threshold_gb=1, days_old=7):
    """
    清理指定目录中超过大小阈值且创建时间超过指定天数的大文件
    
    参数:
        directory: 要清理的目录路径
        size_threshold_gb: 文件大小阈值(GB)，默认1GB
        days_old: 文件年龄阈值(天)，默认7天
    """
    now = time.time()
    size_threshold_bytes = size_threshold_gb * (1024**3)
    deleted_files = []
    
    for dirpath, _, filenames in os.walk(directory):
        for filename in filenames:
            filepath = os.path.join(dirpath, filename)
            try:
                file_size = os.path.getsize(filepath)
                file_mtime = os.path.getmtime(filepath)
                file_age_days = (now - file_mtime) / (24 * 3600)
                
                if file_size > size_threshold_bytes and file_age_days > days_old:
                    os.remove(filepath)
                    deleted_files.append(filepath)
                    print(f"已删除: {filepath} ({file_size/(1024**3):.2f}GB, {file_age_days:.0f}天前)")
            except Exception as e:
                print(f"处理文件 {filepath} 时出错: {e}")
    
    print(f"共删除 {len(deleted_files)} 个大文件")
    return deleted_files

# 使用示例
clean_large_files("~/Downloads", 2, 30)  # 清理下载目录中超过2GB且30天前的文件

案例研究

1：某 SaaS 初创公司的 CI/CD 流水线优化

1：某 SaaS 初创公司的 CI/CD 流水线优化

背景:
该公司使用 macOS 托管服务器运行持续集成（CI）流水线，主要用 Xcode 进行 iOS 应用的自动化构建与测试。CI 机器磁盘空间为 256GB，同时运行多个并发任务。

问题:
开发团队在 CI 脚本中集成了 Anthropic 的 CLI 工具以生成代码文档。某次更新后，CI 任务突然开始失败，报错显示磁盘空间不足。经排查，发现每次运行 CLI 时，~/Library/Caches/anthropic 目录下都会生成一个 10GB 的虚拟机（VM）bundle 文件，且该文件在任务完成后未被清理。由于 CI 服务器每小时触发多次构建，磁盘迅速被占满，导致流水线阻塞。

解决方案:

  1. 修改 CI 配置脚本，在构建任务结束后添加清理命令，强制删除该缓存目录。
  2. 将 Anthropic 工具的缓存路径挂载到临时卷（RAM disk 或独立分区），确保任务终止后自动释放空间。
  3. 向 Anthropic 提交工单，建议在工具中添加 --no-cache 或 --cache-size-limit 选项。

效果:

  • CI 流水线恢复稳定，磁盘占用率从 95% 降至 40%。
  • 避免了因磁盘满导致的构建失败，节省了开发团队排查问题的时间。
  • 临时卷方案使缓存清理自动化，减少了人工干预成本。

2：远程开发团队的共享工作站管理

2：远程开发团队的共享工作站管理

背景:
一家分布式团队使用两台高性能 Mac Studio 作为远程开发工作站，通过 SSH 协议进行远程开发。工作站磁盘空间为 1TB，团队成员轮流登录进行模型训练和数据分析。

问题:
多名成员同时使用 Anthropic 的 CLI 工具辅助编程，导致 ~/Library/Caches/anthropic 目录下累积了多个 10GB 的 VM bundle 文件。某日，一名成员尝试下载数据集时收到“磁盘空间不足”警告，检查发现缓存文件已占用 120GB 空间。由于工具未提供缓存大小限制或自动清理机制，团队不得不手动删除文件，影响了协作效率。

解决方案:

  1. 编写 Shell 脚本，定期监控缓存目录大小并在超过阈值（如 20GB）时自动清理最旧的文件。
  2. 在团队文档中明确标注该工具的缓存行为，要求成员在使用后手动清理或通过 alias 命令封装清理操作。
  3. 联系 Anthropic 技术支持，反馈缓存问题并请求优化。

效果:

  • 缓存目录大小控制在 30GB 以内，避免了磁盘空间耗尽的风险。
  • 自动化脚本减少了 80% 的手动清理工作量。
  • 团队协作更加顺畅，未再因缓存问题中断工作。

3：个人开发者的本地开发环境维护

3：个人开发者的本地开发环境维护

背景:
一名独立开发者使用 128GB 磁盘空间的 MacBook Pro 进行全栈开发，日常运行 Docker 容器、本地数据库及多个 IDE。为提升编码效率，他频繁使用 Anthropic 的 CLI 工具生成代码片段。

问题:
某次系统更新后，开发者发现磁盘剩余空间从 50GB 骤降至 5GB，导致 Docker 无法启动新容器。经系统工具分析，~/Library/Caches/anthropic 目录下存在一个 10GB 的 VM bundle 文件，且工具未在退出时自动删除。由于磁盘空间紧张，开发者被迫暂停其他工作以清理文件。

解决方案:

  1. 使用 cron 任务设置每周清理缓存目录，避免文件长期驻留。
  2. 在 Shell 配置文件（如 .zshrc）中添加函数，封装 CLI 工具调用并在结束后自动执行清理。
  3. 在开发者社区分享该问题，提醒其他用户注意缓存占用。

效果:

  • 磁盘空间恢复稳定，未再出现因缓存导致的紧急清理情况。
  • 自动化清理流程节省了每周约 30 分钟的维护时间。
  • 社区反馈促使 Anthropic 在后续版本中增加了缓存清理提示。

最佳实践

最佳实践指南

实践 1：实施透明的磁盘空间预检机制

说明：在安装或初始化大型应用程序（尤其是涉及虚拟机或容器技术的应用）之前，开发团队应实施严格的磁盘空间检查逻辑。这可以防止用户在不知情的情况下因空间不足导致系统不稳定或安装失败。

实施步骤:

  1. 在安装脚本或应用启动逻辑中，添加检测目标分区可用空间的函数。
  2. 设定一个安全阈值（例如所需空间的两倍或系统保留空间的 1.5 倍）。
  3. 如果可用空间低于阈值，立即中断流程并向用户显示具体的磁盘清理建议。

注意事项: 确保错误提示信息包含所需的具体空间大小（如 “需要 10GB”）以及当前可用空间，而不仅仅是通用的"磁盘空间不足"。

实践 2：强制执行显式的用户确认协议

说明：任何涉及超过 1GB 数据写入的操作，都不应在后台静默进行。必须将这种资源消耗行为视为一种"重大变更"，要求用户进行显式确认，确保用户对系统状态有完全的知情权和控制权。

实施步骤:

  1. 在触发 VM 下载或构建之前，设计一个非模态或模态对话框，明确告知即将写入的数据量。
  2. 对话框中必须包含"取消"和"同意/继续"选项，避免默认自动继续。
  3. 记录用户的确认日志，以便后续排查支持问题时证明已获授权。

注意事项: 确认弹窗的文案应使用非技术语言（例如将"创建 VM bundle"描述为"下载并安装运行环境组件"），降低用户的认知门槛。

实践 3：建立渐进式资源下载策略

说明：避免"全有或全无"的单次性大文件下载。对于 10GB 级别的资源，应采用按需下载或分块下载的策略，即只下载当前功能运行所需的核心组件，其余模块在用户实际使用时再后台获取。

实施步骤:

  1. 将应用拆分为核心运行时和可选功能模块。
  2. 首次安装仅下载基础核心组件（如 <500MB），确保应用能快速启动。
  3. 在后台监控用户行为，当用户触发特定高级功能时，再下载对应的扩展包，并在状态栏显示进度。

注意事项: 实施此策略时需妥善处理"离线模式"，如果用户在离线状态下触发了未下载的功能，应提示联网而不是直接报错。

实践 4：提供可视化的资源管理与清理工具

说明：既然应用引入了大量的本地缓存或虚拟机文件，就必须在应用内部提供原生的管理界面，让用户能够直观地查看这些文件占用的空间，并提供一键清理或移除的功能，而不强迫用户去文件系统中手动删除。

实施步骤:

  1. 在应用的"设置"或"偏好设置"中增加"存储管理"或"高级选项"面板。
  2. 实时显示当前 VM 镜像、缓存文件和日志文件的总大小。
  3. 提供"删除本地数据"或"重置环境"的按钮，并附带二次确认警告。

注意事项: 清理工具应具备智能检测功能，如果删除本地数据会导致未上传的工作成果丢失，必须在清理前弹出特别警示。

实践 5：优化安装包与运行时环境的分离

说明：重新审视应用架构，区分"安装包"和"运行时环境"。对于 Cowork 这类功能，评估是否可以通过流式传输、云端计算或更轻量级的 WASM 容器来实现，而不是在本地创建沉重的 VM bundle。

实施步骤:

  1. 进行技术栈审查，评估核心功能是否必须依赖本地 VM。
  2. 考虑使用 Docker 等标准化容器技术替代自定义的 VM bundle，以便利用系统的共享层减少冗余。
  3. 如果必须使用 VM，考虑将其存储在用户可配置的路径下，而不是强制占用系统盘空间。

注意事项: 在进行架构优化时，需平衡性能与资源占用，确保减少本地存储不会导致网络传输延迟过高从而严重影响用户体验。

实践 6：制定并公示磁盘占用标准

说明：在开发团队内部制定明确的"资源占用红线"（例如：桌面应用默认占用不得超过 2GB，每增加 1GB 需经过特别审批）。将这些标准纳入产品的设计规范和发布检查清单中。

实施步骤:

  1. 由架构师或技术负责人起草《应用程序资源使用规范》。
  2. 在 CI/CD 流水线中集成自动化检测脚本，如果构建产物导致预期磁盘占用超过设定阈值，构建自动失败。
  3. 在产品更新日志中，明确标注每个版本对磁盘空间的影响（增量或减量）。

注意事项: 该标准应根据不同操作系统（Windows/macOS/Linux）的常见磁盘配置进行差异化设定，并定期根据硬件发展趋势进行修订。

学习要点

  • Anthropic 的 Cowork 功能在 macOS 上运行时，会在未经用户明确许可的情况下于后台静默创建一个约 10GB 的虚拟机（VM）资源包。
  • 该行为会导致用户的磁盘空间被突然大量占用，且由于缺乏警告机制，用户往往是在存储空间告急时才察觉到问题。
  • Cowork 功能目前处于测试阶段，这种“强制”分配资源的方式暴露了该软件在处理本地资源权限和用户知情权方面的设计缺陷。
  • 该虚拟机资源包位于系统目录中，普通用户可能难以识别其用途或不敢轻易删除，造成了潜在的维护困扰。
  • 此事件为开发者提供了一个反面教材，即在客户端软件（尤其是 AI 工具）进行大规模本地资源部署时，必须建立显式的申请与告知机制。

常见问题

1: 什么是 Anthropic 的 “Cowork” 功能，它为什么会创建虚拟机？

1: 什么是 Anthropic 的 “Cowork” 功能，它为什么会创建虚拟机？

A: “Cowork” 是 Anthropic 推出的一项功能，旨在允许 Claude 模型直接访问并操作用户的开发环境。为了实现这一目标，同时确保宿主操作系统的安全性（隔离潜在的有害代码执行），该功能在 macOS 上利用了 Apple 的虚拟化框架。它会自动创建一个独立的虚拟机（VM）环境。这并非用户主动发起的传统虚拟机创建流程，而是 Cowork 功能在后台为了运行沙箱化代码而自动部署的依赖环境。

2: 为什么这个虚拟机包会占用 10GB 的空间，且没有任何警告？

2: 为什么这个虚拟机包会占用 10GB 的空间，且没有任何警告？

A: 10GB 的空间占用主要源于虚拟机需要包含一个完整的操作系统环境（通常是 Linux 或 macOS 的变体）、运行时库以及 Anthropic 特定的依赖项，以确保代码执行的兼容性和稳定性。关于“没有警告”的问题，这通常被视为该功能当前设计的一个缺陷。在目前的实现中，该功能可能在后台静默下载并解压这些资源，或者弹出的权限/提示窗口被用户误解为普通的安装确认，导致用户在不知情的情况下消耗了大量的磁盘空间。

3: 我该如何确认我的电脑上是否已经存在这个 10GB 的文件？

3: 我该如何确认我的电脑上是否已经存在这个 10GB 的文件？

A: 您可以通过以下步骤检查您的 macOS 系统：

  1. 打开“终端”应用程序。
  2. 输入并运行命令 du -sh ~/Library/Caches/com.anthropic.cowork（这是基于该功能通常缓存数据的位置，具体路径可能随版本更新而变化）。
  3. 如果该目录存在且大小接近 10GB，则说明 Cowork 功能已经创建了虚拟机包。此外，您也可以在系统设置中查看存储空间管理，检查是否有不明来源的“系统数据”或“虚拟机”数据突然增加。

4: 如果我不需要使用 Cowork 功能，如何安全地删除这个 10GB 的文件以回收空间？

4: 如果我不需要使用 Cowork 功能，如何安全地删除这个 10GB 的文件以回收空间？

A: 删除该文件通常涉及移除应用程序生成的缓存和支持文件。最安全的方法是：

  1. 完全退出相关的 Anthropic 应用程序或 IDE 插件。
  2. 删除位于用户库目录下的缓存文件夹（通常位于 ~/Library/Caches/ 或 ~/Library/Application Support/ 下与 Anthropic 相关的文件夹）。
  3. 如果您是通过 Homebrew 或其他包管理器安装的命令行工具，请使用对应的卸载命令（如 brew uninstall）。
  4. 删除后，请清空“废纸篓”以确保空间被系统释放。请注意，如果您未来再次使用 Cowork 功能，这些文件可能需要重新下载。

5: 这个虚拟机文件是否包含恶意软件，或者会对我的 macOS 系统造成安全风险？

5: 这个虚拟机文件是否包含恶意软件，或者会对我的 macOS 系统造成安全风险？

A: 根据目前的分析，该虚拟机包本身是 Anthropic 官方工具的一部分，用于隔离代码执行环境，理论上不应包含恶意软件。它利用了 macOS 原生的虚拟化技术，旨在保护宿主机免受用户在 AI 对话中运行的潜在危险代码（如恶意脚本）的影响。然而，未经明确同意而占用大量磁盘空间本身属于软件设计中的“灰色地带”或用户体验问题，虽然它可能不会直接破坏系统文件，但这种静默行为引发了用户对于软件透明度和隐私控制的担忧。

6: 这个问题会影响 Windows 或 Linux 用户吗？

6: 这个问题会影响 Windows 或 Linux 用户吗？

A: 该特定问题主要针对 macOS 用户，因为报告指出其利用了 macOS 特有的虚拟化框架来创建 VM bundle。在 Windows 或 Linux 上，虽然类似的功能可能需要 Docker 或其他虚拟化技术作为后端，但文件的组织方式和大小会有所不同。不过，如果 Anthropic 的 Cowork 功能支持这些平台，它同样会下载必要的环境镜像，因此也可能面临类似的磁盘占用突增问题，只是具体的文件大小和路径会有差异。

7: Anthropic 官方对此有何回应或修复计划？

7: Anthropic 官方对此有何回应或修复计划？

A: 截至目前，这主要是一个在 Hacker News 等技术社区被广泛讨论的热门话题。虽然官方可能尚未发布针对该特定“静默占用空间”问题的独立声明，但此类广泛的用户反馈通常会促使开发团队迅速采取行动。预计未来的更新中，Anthropic 会增加更明显的存储空间提示、优化下载机制，或者提供更直观的卸载/清理选项，以改善用户体验并避免意外的磁盘空间消耗。

思考题

## 挑战与思考题

### 挑战 1: [简单]

问题**: 假设你是一名 macOS 用户，发现系统盘空间突然减少了 10GB。请列出至少 3 种使用系统自带工具（不安装第三方软件）来定位这 10GB 空间具体被哪个文件夹或文件占用的方法。

提示**: macOS 自带的“关于本机”功能中有存储管理的可视化入口；另外，命令行中 du (disk usage) 和 sort 组合是查看文件夹大小的经典方式。

引用

注：文中事实性信息以以上引用为准；观点与推断为 AI Stack 的分析。

站内链接

相关文章