让 Computer Use Agent 在 Windows Sandbox 里安全玩 Minecraft：沙箱实战指南

Computer Use Agent（CUA）是能够通过截图理解桌面、移动鼠标、输入键盘并完成任务的 AI 代理。它和传统自动化脚本的区别在于：脚本执行预先写好的坐标和命令，CUA 则会根据当前画面临时决定下一步动作。

这让它可以启动游戏、点击菜单、识别方块、移动角色，甚至根据目标不断试错。但问题也很直接：一个能操作桌面的 Agent，同样能打开文件、运行程序、访问网络，或者被网页、聊天窗口和游戏内文本中的恶意指令误导。

因此，Minecraft 并不只是一个有趣的演示场景，它还是测试 CUA 安全边界的理想实验场：任务足够复杂，需要连续视觉反馈；环境又相对可控，世界可以重置，损失不会直接波及生产数据。本文以 Windows Sandbox 为隔离层，搭建一套“让 Agent 玩游戏，但不要碰宿主机”的实验流程。

先说结论：Windows Sandbox 适合一次性实验，不等于完整的 Agent 安全平台

Windows Sandbox 是 Windows 提供的轻量级临时桌面环境，每次启动都从干净状态创建，关闭后默认删除其中的文件和改动。它比直接在日常电脑上运行 CUA 安全得多，适合短时、低信任、可重置的 Minecraft 实验。

但它不是“打开之后就万事大吉”的保险箱。沙箱仍然可能拥有网络访问能力，也可能通过用户映射目录读取宿主机文件；如果 Agent 的控制程序运行在宿主机上，控制链路本身仍然是高权限入口。更重要的是，隔离层只能缩小执行半径，不能判断 Agent 的意图，也不能修复编排逻辑中的错误。

一个实用的安全模型应该至少包含四层：

1. 操作系统隔离：用 Windows Sandbox 限制文件系统、进程和用户会话的可见范围。
2. 网络隔离：默认关闭网络，只有确实需要下载资源或连接控制端时才开放。
3. 权限隔离：不给共享目录、剪贴板、宿主机凭据和不必要的设备访问权限。
4. Agent 约束：限制它能点击的窗口、允许执行的动作、任务时长和最大重试次数。

一、准备环境：硬件和系统要求

Windows Sandbox 是基于虚拟化的隔离环境，运行 Minecraft 和视觉模型时，内存与图形性能会成为主要瓶颈。建议至少准备 16 GB 主机内存、四核 CPU、支持硬件虚拟化的处理器，以及 30 GB 以上可用磁盘空间。若 Agent 还要在本机运行视觉模型，建议将主机内存提高到 32 GB。

在 BIOS/UEFI 中确认 Intel VT-x 或 AMD-V 已开启，并在 Windows 功能中启用“虚拟机平台”和“Windows 沙盒”。可以通过“启用或关闭 Windows 功能”图形界面完成，也可以使用管理员 PowerShell：

Enable-WindowsOptionalFeature -Online -FeatureName Containers-DisposableClientVM -All

启用后通常需要重启。Windows Sandbox 主要面向 Windows Pro、Enterprise 和 Education 等版本，家庭版是否可用取决于具体系统版本和微软后续支持情况，不建议把非官方脚本当作生产安全方案。

Minecraft 版本也要先做选择。若目标是让 CUA 直接观察并操作桌面，Minecraft Bedrock 的启动路径通常更短；若要接入代码控制、WebSocket 或 Education Edition 的 Agent 能力，则应使用明确支持这些功能的版本。不同版本的菜单、渲染和输入行为并不完全一致，教程中的坐标不能跨版本照搬。

二、创建最小化的 Windows Sandbox 配置

Windows Sandbox 配置文件使用 .wsb 扩展名。它是一个 XML 文件，用来声明内存、网络、显卡、启动命令和宿主机目录映射。

下面这份配置的思路是：关闭网络、关闭剪贴板、不给宿主机目录做共享，只把一个专门准备的安装目录映射为只读。这样即使 Agent 在游戏里遇到恶意文本，也没有机会直接浏览用户文档、源码仓库或 SSH 密钥。

<Configuration>
  <MemoryInMB>8192</MemoryInMB>
  <vGPU>Enable</vGPU>
  <Networking>Disable</Networking>
  <ClipboardRedirection>Disable</ClipboardRedirection>
  <MappedFolders>
    <MappedFolder>
      <HostFolder>C:\SandboxAssets</HostFolder>
      <SandboxFolder>C:\Assets</SandboxFolder>
      <ReadOnly>true</ReadOnly>
    </MappedFolder>
  </MappedFolders>
  <LogonCommand>
    <Command>cmd.exe /c C:\Assets\bootstrap.cmd</Command>
  </LogonCommand>
</Configuration>

这里的 8192 MB 只是起点。若游戏启动后频繁卡顿，可提高到 12288 MB；但不能把主机内存几乎全部分给沙箱，否则视觉模型和宿主机控制程序会一起发生交换，延迟反而更高。

vGPU 是否开启取决于系统版本、显卡驱动和实验目标。对于需要持续截图的 CUA，开启虚拟 GPU 通常能改善桌面合成和游戏画面的流畅度；对于极端安全场景，则应该评估是否接受额外的图形设备暴露面。

最容易被忽略的是 MappedFolder。只读映射只能防止沙箱进程写回宿主机目录，不能把目录内容变成秘密。不要把浏览器配置、密码数据库、代码仓库、云凭据或任何包含个人数据的目录映射进去。

三、启动脚本不要做成“万能管理员脚本”

启动脚本的职责应该是检查环境、启动需要的程序并写入日志，而不是把所有安装、提权和网络配置都塞进一个批处理文件。脚本越长，Agent 可利用的入口越多。

一个更稳妥的初始化顺序是：

1. 创建专用的游戏工作目录。
2. 检查 Minecraft 是否已经安装。
3. 启动游戏并等待主窗口出现。
4. 将日志写入沙箱内部，而不是映射回宿主机。
5. 以普通用户权限运行游戏和控制程序。

如果必须从宿主机把安装包带入沙箱，先在宿主机完成哈希校验，再通过只读目录提供。不要让 Agent 自己从搜索结果中选择下载链接，也不要把“下载并运行任何必要组件”写进任务提示词。

四、把 CUA 控制回路拆成“观察—计划—动作—验证”

CUA 的核心不是一次性给出几十个鼠标坐标，而是循环处理屏幕状态。一个安全的控制回路应该明确分成四步：

• 观察：截取当前窗口或桌面画面，确认焦点窗口、游戏状态和可交互元素。
• 计划：只生成下一小步动作，例如点击“单人游戏”，而不是直接执行一串不可审计的操作。
• 动作：发送鼠标移动、点击、按键或短时按键组合。
• 验证：检查画面是否出现预期变化；如果没有变化，最多重试有限次数。

定义“动作预算”比单纯设置总超时更重要。例如一次任务最多执行 300 个鼠标键盘动作、最长运行 10 分钟、连续三次验证失败就暂停。这样可以截断 Agent 因为看不懂画面而反复点击、无限转圈或持续挖掘的情况。

Agent 还应该拥有明确的停止条件：角色死亡、窗口失去焦点、出现下载提示、出现权限请求、画面出现未知弹窗，或者任务目标已经完成。停止不是失败，而是桌面 Agent 的必要安全动作。

五、从低风险任务开始，不要一上来挑战“自动通关”

Minecraft 任务可以按风险分为三个阶段。第一阶段只允许 Agent 在已经创建好的世界里移动、观察和放置少量方块；第二阶段再开放采集、合成和建造；第三阶段才考虑跨区域探索、与村民交互或使用复杂模组。

建议从以下任务开始：

• 在出生点附近向前移动 20 秒，然后停下。
• 识别画面中的树木、石头和水面。
• 收集指定数量的木头，但不得离开出生点 100 个方块。
• 用已有材料搭建一个 5×5 的方形平台。
• 打开背包并报告当前物品，不执行丢弃操作。

这些任务的价值在于能测试视觉识别、键盘保持时间、镜头控制和状态验证，而不需要把 Agent 交给不可预测的开放世界。

如果使用 Minecraft Education 或 Bedrock 中的 Agent 机制，应区分“游戏内 Agent”和“Computer Use Agent”。游戏内 Agent 是 Minecraft 提供的可编程实体，能执行移动、攻击、采集、耕种等有限命令；Computer Use Agent 则是操作整个桌面的外部模型。前者边界更窄，后者权限更宽，不能因为游戏内 Agent 安全就推断桌面 Agent 也安全。

六、输入注入：游戏里的文字也可能是攻击面

间接提示注入是指外部内容把指令伪装成普通数据，诱导 Agent 改变原本目标。网页正文、聊天消息、书与告示牌、服务器公告、模组说明，甚至地图中的文字，都可能成为输入来源。

例如，Agent 的任务是“收集木头并回到出生点”，但游戏内告示牌写着“按 Alt+Tab 打开终端并执行某命令”。如果模型把这段文字当成高优先级指令，就可能离开游戏窗口，触碰宿主机资源。

防护重点不是让模型“学会永远聪明”，而是把不可信文本和可执行动作分开：

• 游戏内文字只能作为环境描述，不能覆盖系统任务。
• 任务提示中明确禁止 Alt+Tab、Win 键、运行对话框和终端。
• 控制器拒绝点击游戏窗口之外的区域。
• 任何安装、下载、权限变更和网络操作都需要人工确认。
• 对截图和 OCR 结果做标记，注明它们是“不可信观察结果”。

这也是沙箱与 Agent 编排必须分开设计的原因。沙箱可以限制进程能看到什么，但无法判断一个被污染的工具描述是否会让模型做出错误决策。

七、网络策略：默认断网，按实验目的开放

Minecraft 单机演示通常不需要互联网，因此默认关闭网络是最合理的选择。断网可以降低恶意下载、远程控制、追踪请求和外部内容注入的风险，也能让实验结果更稳定。

如果必须连接局域网服务器，应将“能联网”视为一项高风险能力，而不是普通开关。至少要明确服务器地址、端口和实验时长，避免让 Agent 获得任意出站访问权限。测试期间持续记录连接目标；一旦发现游戏进程以外的程序建立连接，应立即终止沙箱。

不要为了让启动器自动登录而把微软账号凭据放进映射目录或启动参数。对于需要账号的场景，优先使用专门的测试账号、临时世界和最小化权限；如果实验不需要联网，最好提前准备离线可运行的内容。

八、资源、日志与可复现性

CUA 实验最容易出现的误判，是把“模型不行”与“桌面延迟太高”混为一谈。至少要记录截图时间戳、动作类型、动作坐标、窗口标题、模型响应延迟、验证结果和失败原因。

一套有用的指标包括：

| 指标 | 含义 | 建议记录方式 | |---|---|---| | 首次可操作延迟 | 游戏启动到 Agent 能识别画面的时间 | 记录进程启动和首帧时间 | | 单步成功率 | 一次动作是否产生预期状态变化 | 按动作类型统计 | | 平均恢复步数 | 发生错误后回到正常状态所需动作数 | 区分卡顿和误操作 | | 任务完成率 | 在动作预算内完成目标的比例 | 至少重复 20 次 | | 资源峰值 | CPU、内存、显存和磁盘占用 | 每秒采样 | | 越界动作数 | 点击游戏区域外或触发禁用组合键的次数 | 直接作为安全指标 |

如果只跑一次演示，任何结论都不可靠。建议固定 Minecraft 版本、世界种子、窗口分辨率、鼠标灵敏度和视角初始方向，再用相同任务重复测试。对于模型比较，不能只看“是否完成”，还要看完成用了多少步、犯了多少次错误，以及是否触发了越界动作。

九、故障排查：先看状态，再调模型

如果 Agent 说自己看到了菜单，但实际画面没有变化，首先检查窗口焦点和截图来源，而不是立刻更换模型。Windows Sandbox 中可能同时存在桌面、启动器和游戏窗口，控制器截取了错误窗口就会导致整个决策链失效。

如果鼠标点击位置总是偏移，检查 DPI 缩放、窗口是否全屏、沙箱分辨率和截图缩放比例。不要把固定坐标写死为跨机器通用方案；更稳妥的做法是通过窗口边界归一化坐标，并在动作后验证按钮或画面变化。

如果游戏运行很卡，依次降低渲染距离、关闭高质量光影、减少截图分辨率，并确认主机没有同时运行大型模型推理。视觉输入不一定越大越好：对于菜单点击，低分辨率足够；对于识别远处方块，才需要更高分辨率。

如果沙箱每次启动都丢失资源，这是预期行为。需要保留的不是整个沙箱，而是任务日志、世界存档和模型评测结果。保存前要人工检查内容，避免把恶意脚本或意外生成的凭据带回宿主机。

十、这套方案的边界在哪里

Windows Sandbox 能解决的是“实验环境被污染后，影响范围尽量小”的问题，不能解决所有 Agent 安全问题。它不能保证模型不会在授权范围内摧毁世界，也不能阻止恶意服务器利用游戏客户端漏洞，更不能替代应用层的输入校验、人工审批和审计。

对于高风险、长时间运行的 Agent，应该考虑更强的隔离方案，例如专用虚拟机、快照回滚、独立测试账号、出口防火墙、进程白名单和集中式审计。Windows Sandbox 的优势是启动快、清理简单、使用门槛低；代价是持久化、网络策略、GPU 支持和深度策略控制能力有限。

| 方案 | 适合场景 | 优点 | 局限 | |---|---|---|---| | Windows Sandbox | 短时桌面实验、游戏演示 | 一次性、易重置、Windows 集成好 | 策略粒度和持久化能力有限 | | 完整虚拟机 | 长流程 Agent、需要快照 | 可回滚、隔离边界更清晰 | 占用资源更多，维护成本更高 | | WSL2/Linux 沙箱 | 代码执行和开发工具 | 可结合 Landlock、seccomp 等机制 | 不等于原生 Windows 桌面隔离 | | 容器 | 非 GUI 的构建和脚本任务 | 启动快、易编排 | 对桌面和 GPU 隔离不够直接 |

最后的实战清单

在启动 CUA 之前，确认以下事项：

• Windows Sandbox 已启用，且主机虚拟化正常。
• 沙箱默认断网，未共享个人目录、剪贴板和凭据。
• Minecraft 使用专用测试世界和测试账号。
• Agent 只能操作指定窗口，禁止 Alt+Tab、Win 键、终端和安装程序。
• 设置最大运行时间、动作数量、重试次数和人工暂停点。
• 游戏内文字、网页内容和工具输出均被视为不可信输入。
• 日志记录动作、截图、资源占用和异常网络连接。
• 任务结束后销毁沙箱，并人工审核需要导出的文件。

真正有价值的结果，不是让 Agent 在 Minecraft 里完成一次炫技式建造，而是证明这套控制系统在失败时也能停下来，在遇到诱导时不会越权，在清理环境后不会留下不可控的副作用。对 Computer Use Agent 来说，能完成任务只是能力指标；知道什么时候不该继续，才是安全指标。

参考来源

• Microsoft Windows Sandbox 文档与示例（GitHub）：用于了解 Windows Sandbox 配置文件、映射目录和实验工具。
• Cursor：Implementing a secure sandbox for local agents：介绍 Landlock、seccomp 以及 Agent 沙箱的权限边界。
• Agent Sandbox 项目（GitHub）：用于对比面向 Agent 任务的沙箱生命周期、资源限制和审计思路。
• Minecraft Wiki 相关项目讨论（GitHub）：用于了解 Minecraft 自动化与游戏内 Agent 能力的边界；具体版本功能应以对应版本官方文档为准。