产品发版前，测试同事发来了两组测试结果。团队原本有一段 PowerShell 脚本负责汇总数据，你让 Agent 给脚本加上 JSON 输出，准备接入自动化发布流程。

脚本改好了，接下来还得验证一遍：

用这次的测试数据，在 Windows 上跑一次，把报告给我。

问题来了：Agent 运行在 Linux 上，而这段脚本需要在 Windows 发布环境中执行。要完成验证，通常还得准备一台 Windows 机器，把脚本和测试数据传过去运行，再将报告取回来。

现在，七牛云沙箱正式支持 Windows 11。目前，我们已在扬州和达拉斯区域提供公开的 Windows 11 基础模板。开发者可以通过 SDK 按需创建独立的 Windows 实例，上传文件、执行命令，再将结果返回给调用程序。将这项能力封装成工具后，Agent 也能在需要时调用 Windows 环境。

01 每次任务，都应该有自己的 Windows 环境

在 Windows 上验证程序和脚本，不只是检查代码逻辑，还要考虑实际运行环境。

比如，系统 PATH 中优先匹配到的是哪个程序、带空格的文件路径能否正确处理、命令执行失败时返回什么退出码，都可能影响最终结果。这些问题需要在目标 Windows 环境中检查。

就算有现成的 Windows 测试机，多个任务共用一台机器也可能带来新的问题。有人升级了工具，或者上一次执行留下了旧文件，都可能影响后续的测试结果。

七牛云 Windows 沙箱将可复用的环境配置保存在模板中。每次执行任务，都可以从指定模板创建一个独立实例，拥有自己的文件和进程空间。即使两个任务都生成名为 report.json 的文件，只要运行在不同实例中，就不会相互覆盖。

任务完成后，先取回需要保留的结果，再释放实例。原有的任务调度、报告归档和通知流程都可以继续使用，只需要在需要 Windows 环境的环节调用沙箱。

02 在 Windows 沙箱里跑一次 PowerShell

回到开头的发版任务。要让 Agent 完成验证，可以先将 Windows 沙箱的调用过程封装成工具。下面就以这次 PowerShell 汇总为例，看看工具内部如何通过 SDK 执行任务。

假设这次有两组测试，单元测试全部通过，集成测试有⼀项失败。传⼊的 CSV 只有三⾏：

suite,passed,failed
unit,12,0
integration,7,1

两组测试结果整理在 checks.csv 中，汇总脚本为 summarize.ps1。配置好七牛云 API Key 和区域地址后，就可以通过 SDK 创建 Windows 实例，上传文件并执行脚本。

核心调用代码如下：

const sandbox = await Sandbox.create('windows11', {
  requestTimeoutMs: 120_000
})

try {
  const dir = String.raw`C:\Windows\Temp`

  await sandbox.files.write(`${dir}\\checks.csv`, csv)
  await sandbox.files.write(`${dir}\\summarize.ps1`, script)

  await sandbox.commands.run(
    'powershell.exe -NoProfile -NonInteractive -ExecutionPolicy Bypass -File .\\summarize.ps1',
    { cwd: dir }
  )

  const report = JSON.parse(
    await sandbox.files.read(`${dir}\\report.json`)
  )

  console.log(report)
} finally {
  await sandbox.kill()
}

注：以上为核心调用片段，省略了 SDK 初始化过程，csv 和 script 需提前准备。示例中的 windows11 为模板短名称，在自己的账号下调用时，请根据开发者指南填写对应的完整模板别名。

代码将测试数据和 PowerShell 脚本写入沙箱，再调用 powershell.exe 执行。脚本通过 Import-Csv 读取测试数据，汇总后在同一目录生成 report.json，供调用程序读取。

我们分别在扬州和达拉斯区域执行了这一任务。两次运行均正常完成，调用程序在释放沙箱前成功读取报告，得到的结果一致。

图：扬州、达拉斯两区域的 Windows 沙箱执行结果

报告显示，19 项测试通过，1 项集成测试失败。这意味着 PowerShell 脚本已经正常完成汇总，输出与原始数据一致；但测试本身还有一项未通过。后续发布流程可以根据报告决定是否暂停发版、排查失败用例。

03 把 Windows 接入 Agent 和 CI 工作流

除了前面的脚本汇总，Windows 沙箱还可以用于更复杂的程序验证，并接入现有的 Agent 和持续集成流程。

让 Agent 验证 Windows 程序

例如，发版前需要验证一个 Windows 命令行工具，但系统 PATH 中存在两个同名程序。怎样确认实际运行的就是准备发布的版本？

可以先定位程序的实际路径，读取版本信息和 SHA-256 文件摘要，与构建记录核对，再用已知输入运行程序，检查退出码及输出文件。

如果团队已经有相应的验收脚本，就可以按照前面的方式，将脚本和沙箱调用过程封装成工具，供 Agent 使用。当 Agent 发起验证任务时，工具会将待验证的程序、测试文件和验收脚本交给 Windows 沙箱执行，再把检查结果返回给 Agent。

这样，Agent 就可以根据结果判断程序是否正常运行，以及哪些问题还需要处理。需要修改后再次验证时，也可以从相同模板创建新实例，避免上一次执行留下的文件影响结果。

在 CI 流程中运行 Windows 作业

Windows 沙箱同样可以用于持续集成。

七牛云 CI Runner 已提供 Windows 11 预览规格，可为 GitHub Actions 作业提供临时 Windows 环境。Runner 在 Windows 环境中检出代码，在可写工作区运行 CMD 或 PowerShell 命令，并在作业结束后清理环境。

与前面的 PowerShell 示例不同，CI 作业还需要 Git、Runner 等工具，因此使用预装相关依赖的专用模板。如果团队需要固定工具版本或安装其他依赖，在开通 Windows 模板构建权限后，还可以从已有模板派生自己的环境，减少重复配置。

04 用自己的 Windows 脚本试一次

如果你手头已经有需要在 Windows 上运行的 PowerShell 脚本，可以直接用它试一次。通过七牛云 API Key 配置 SDK，选择对应区域和 Windows 11 模板，按照示例完成第一次调用。