写这篇Windows沙箱故障复盘的时候，距离10月8号已经过去了一段时间。那天上午9点13分，我们内部用编码智能体批量生成的自动化任务突然开始大范围失败，监控告警像下雨一样往下掉。接下来的几个小时，所有人都围着“为什么沙箱一启动就退出”转，一开始怀疑是智能体生成的代码出了问题，后来把视角放大到沙箱自身，才找到真正的元凶。

这篇复盘没有虚的东西，全是从现场抓回来的现象、日志、配置和操作记录。核心词就三个：Windows沙箱、故障复盘、配置与资源边界。如果你也在用Windows沙箱跑自动化脚本，或者你跟编码智能体协作时碰到过“看起来什么都没错但就是跑不起来”的故障，这篇复盘应该对你有用。

1. 故障背景与整体复盘思路

1.1 这个沙箱环境平时是怎么用的

我们团队平时会用系统自带的Windows沙箱来跑临时代码和自动化脚本。为什么不用虚拟机？因为沙箱快：几秒钟就能拉起一个干净环境，用完关闭后所有数据直接丢弃，相当于一个一次性的测试台。我们的编码智能体负责批量生成回归测试脚本和数据处理任务，生成完以后由调度器把这些脚本送进沙箱执行，执行完成后把结果文件拷贝到共享位置，然后销毁沙箱。整个过程每天凌晨跑一轮，白天按需跑几轮，一直很稳定。

这种场景下，Windows沙箱的优势非常明显：不需要手工维护系统镜像，每次都是全新环境，宿主机上再乱也不会被被测代码污染；同时因为进程隔离，即使脚本写得再差也不会碰坏宿主机。我们只用.wsb配置文件来控制沙箱的网络、剪贴板、映射目录这些开关，这份配置被固定在一个模板文件里，调度器每次启动沙箱前都会重新生成一份。

1.2 为什么一次故障需要专门做复盘

故障本身只持续了两个多小时，任务量也不算特别大，但复盘的价值在于：这类环境和智能体协作的故障是第一次出现。过去我们把注意力都放在智能体生成的代码质量上，默认沙箱是绝对可靠的。结果这次恰恰是沙箱环境先出了问题。如果不在时间线、配置和日志上做一次重伤级的复盘，下次大概率会在同一个地方再摔一次。

复盘时我们主要做了四件事：第一，还原10月8号完整的时间线，把每个人看到的现象按时间对齐；第二，审核所有可能影响沙箱启动的环境配置，包括.wsb模板、宿主机磁盘、系统更新策略；第三，用沙箱的专门日志和系统事件日志做交叉比对；第四，构造最小复现用例，把故障原因用最稳定的方式再触发一次。这套方法论不只是针对Windows沙箱，遇到其他环境类故障也可以借用。

1.3 复盘结论一句话

先把结论放在这里：这次故障的根本原因，是编码智能体生成的脚本在沙箱临时目录里写出了超大量的中间文件，最终把沙箱的虚拟磁盘空间耗尽，沙箱触发了保护性退出。智能体本身没有理解错用户意图，它只是不知道这个一次性沙箱的存储边界有多薄。后面的所有内容，都是围绕这个结论展开的证据链。

2. 故障时间线与现象拆解

2.1 故障前的正常状态基线

为了说清楚异常，必须先说正常情况。我们调度器每天凌晨4点启动一批沙箱任务，每个任务会生成一个独立的.wsb文件，里面配置了映射目录和启动命令。沙箱启动后会自动执行一个PowerShell脚本，脚本会依次完成三件事：拉取最新测试数据、执行编码智能体生成的测试逻辑、把结果压缩后放到映射目录里。

正常时，一个任务的运行时间大概在15到30分钟，沙箱内部C盘临时目录使用量一般在2GB以内，宿主机C盘剩余空间保持在50GB以上。这些基线数据导致当天上午看到告警时，大家第一反应都不相信是磁盘问题，因为宿主机明明很空闲。事后回头看，问题恰恰就出在“宿主机空闲”和“沙箱虚拟磁盘满”之间没有划等号。

2.2 10月8号上午的时间线记录

以上时间线是我们几个人你一句我一嘴拼出来的。复盘的第一步永远都是把时间线拉齐，不然很容易各说各话，甚至会把相关负责人拉进“谁的锅”这种无意义讨论里。

2.3 故障现象的几个共同点

当天失败的12个任务现象不完全一样，但拆开看有明显的共性。

第一，沙箱进程都已经启动，不是启动即失败，而是运行几秒到十几秒后自动退出。第二，退出不是正常销毁，事件日志里没有“正常关闭”的记录。第三，所有失败任务都有一个共同点：生成的中间数据量比较大，要么是测试结果明细，要么是日志转储。第四，宿主机CPU、内存都正常，只有磁盘IO在任务失败前有一段长时间的高位运行。第五，失败后沙箱会立即回收，所以我们几乎拿不到现场，只能靠日志分析。

这五个共性把排查方向狠狠推向了“沙箱内部资源耗尽”而不是“代码逻辑报错”。事后看，如果我们当时能更早抓住“所有失败任务的中间数据都很大”这个特征，至少可以少走半小时弯路。

3. 根因定位：从“我以为”到“日志证据”

3.1 排查第一轮：先排掉最容易想到的诱因

任何故障复盘都会有绕弯路的部分，我们也不例外。第一轮排查时，值班同事先查了宿主机内存和CPU，因为Windows沙箱本质上是一个轻量虚拟机，内存不足会导致它直接崩溃。但看了任务管理器，内存只用了不到40%，CPU也稳定，于是把宿主机负载这条线排除了。

随后我们怀疑是杀毒软件冲突，因为沙箱创建虚拟磁盘时和某些安全软件容易起冲突。但临时关闭安全软件后问题依旧。我们也怀疑过是网络配置导致脚本卡死，后来发现失败任务根本没有进入网络请求阶段。排查到这里，剩下最可疑的就是磁盘和文件系统。

3.2 关键日志出现了

我让同事把所有沙箱相关的事件日志导出来，按“时间范围+关键字”过滤，很快看到一条记录，大意是“尝试扩展虚拟磁盘失败，沙箱将被终止”。这条日志出现的时间正好是每个失败任务退出前几秒。到这里，问题基本定性：不是代码跑挂了，是沙箱的虚拟磁盘无法继续扩容，Windows沙箱为了安全直接选择终止。

这里需要解释一下为什么宿主机还有几十GB空闲，沙箱却会磁盘扩展失败。Windows沙箱使用的是动态扩展的虚拟磁盘文件，文件本身会占用宿主机磁盘空间，但沙箱内部的C盘分区是有固定上限的。当沙箱内部的临时文件不断写入，虚拟磁盘文件增长到分区上限附近后，虽然宿主机还有空闲，但沙箱系统内已经没有多余可用空间，所以“扩展”这个动作就会失败。我们的问题发生在沙箱内部空间几乎写满的情况下，智能体生成的脚本还继续在临时目录里堆文件，最终触发了保护机制。

3.3 最小复现：把根因钉死

为了证明不是偶然，我们写了一个最小复现用例。用同款.wsb模板启动一个沙箱，通过映射目录放进去的脚本里，循环向沙箱的临时目录写入大文件，每100MB一个文件。运行大约两分钟后，沙箱自己退出，事件日志里出现了和当天早上完全相同的错误。这个测试我们在不同宿主机上重复了三次，结果一致。

最小复现还有一个附带收获：我们发现删掉脚本里写入临时目录的部分，或者把输出改到映射目录中，沙箱都不会退出。这等于反向验证了故障的核心诱因就是沙箱内临时目录写入量超过了上限。而编码智能体生成的脚本之所以会这样，是因为脚本里有一处“把结果明细逐行写入临时文件再压缩”的逻辑，它在宿主机上跑没有限制，但在沙箱内部遇到了环境边界。

3.4 影响范围梳理

这次故障影响到当天上午三个项目的12个自动化任务，导致回归测试结果缺失，有两个任务的调度被推迟到下午。因为沙箱设计就是一用完就销毁，数据没有残留，所以不需要清理脏数据。

影响最大的其实是信任感：团队里第一次出现“智能体、沙箱、调度器三方面都没写错，但任务就是失败”的案例。如果不复盘清楚，后续只要碰到沙箱相关问题就会互相猜疑。所以我在复盘会上明确说了一句：这次故障不是某个人的操作失误，也不是智能体“变笨”，而是环境边界没有在系统和提示词两个层面被显式表达出来。

4. 修复过程与落地措施

4.1 临时恢复：先把任务跑起来

当天上午修复分三步。第一步，检查宿主机上沙箱虚拟磁盘文件所在目录，把之前几次调试留下的旧VHDX和临时文件清理掉，释放了一部分空间。第二步，修改.wsb模板里的映射目录和启动命令，在脚本开头加了一段临时目录清理逻辑。第三步，把自动化任务重跑。这三步做完，11点20分左右所有任务恢复。

为了让临时方案更直观，我把当时的.wsb模板简化成下面这样：

<Configuration> <Networking>Enabled</Networking> <MappedFolders> <MappedFolder> <HostFolder>D:\tasks\project-a\source</HostFolder> <SandboxFolder>C:\work\source</SandboxFolder> <ReadOnly>true</ReadOnly> </MappedFolder> </MappedFolders> <LogonCommand> <Command>PowerShell -ExecutionPolicy Bypass -File C:\work\source\run_task.ps1</Command> </LogonCommand> </Configuration>

注意这里映射目录设置成了只读，源文件在沙箱内只能读不能改。输出结果通过另一个可写映射目录传回宿主机，避免把大文件堆在沙箱内部临时目录里。这个改动很小，但效果立刻出来，因为沙箱崩溃的根源就是临时目录写入不受控。

4.2 长期修复：模板和脚本一起加固

临时方案只能止血，我们在复盘后做了四件长期加固。

第一，把.wsb模板收进版本仓库，任何修改都必须带着变更说明提交，不能直接改生产模板。之前模板是一个共享目录里的文件，什么时候改过都查不到，这是这次事故的管理漏洞。

第二，在宿主机上增加一个预检脚本，每次启动沙箱前检查三件事：沙箱虚拟磁盘所在卷的剩余空间是否大于20GB、目标映射目录是否存在、同型号沙箱实例数量是否超过阈值。预检通过后才允许生成.wsb并启动，预检不通过直接给出原因。

下面是一个可用作参考的预检脚本片段：

param( [string]$SandboxRoot = "D:\Sandbox", [int]$MinFreeGB = 20 ) $drive = Get-PSDrive -Name (Split-Path -Qualifier $SandboxRoot).TrimEnd(':') $freeGB = [math]::Round($drive.Free / 1GB, 2) if ($freeGB -lt $MinFreeGB) { throw "沙箱目录所在卷剩余空间不足，当前 ${freeGB}GB，要求至少 ${MinFreeGB}GB" } $running = Get-Process -Name "WindowsSandbox" -ErrorAction SilentlyContinue if ($running.Count -gt 3) { throw "当前已有 $($running.Count) 个沙箱实例，超过并发上限" } Write-Host "预检通过，当前剩余空间 ${freeGB}GB"

这段脚本不需要很复杂，但能把最常见的两类问题拦在启动之前。

第三，在调度器里增加“沙箱启动健康检查”，即沙箱启动后先执行一个最小占用的探针命令，确认文件系统和几个关键路径都可写，再执行正式脚本。如果探针失败，直接标记任务失败，不进入正式执行阶段。

第四，把沙箱内的临时目录映射到宿主机上一块独立空间，并在执行结束后的销毁流程里自动清理。这样即使沙箱内部突然写满，也不会拖垮宿主机系统盘。

4.3 对编码智能体侧的改进

这次故障里，智能体不是背锅方，但它的使用方式需要改进。以前我们给智能体的提示词是“生成一个脚本，完成回归测试”，它不会知道沙箱有存储上限。现在我们会在提示词里明确告诉它：“脚本将运行在一次性Windows沙箱中，临时目录写入总量不超过1.5GB，所有结果必须显式输出到指定映射目录。”智能体收到这些约束后，生成的脚本会主动分批写文件、压缩中间结果，并且在临时文件达到阈值时提前退出。

这个改动说出来不复杂，但实际价值很大。编码智能体最缺的就是对运行环境边界的感知，而这些边界信息只能由我们作为使用方注入。这次故障教会我们：把环境约束写进提示词，比事后在日志里找原因要便宜得多。

5. 常见问题与排查技巧实录

5.1 Windows沙箱常见故障速查表

复盘结束后，我把之前遇到过的沙箱问题整理成了一张速查表，这里也分享给大家。

这些条目不一定覆盖所有情况，但都是实际踩过坑的。遇到新问题，第一原则是先把事件日志完整导出来，再对照关键字搜索，而不是靠猜。

5.2 复盘后最想分享的三条排查经验

第一条，Windows沙箱是“一次性环境”，任何运行痕迹都会在关闭后消失，所以必须靠日志和复现来还原现场。我们那次如果能早一点想到拉日志，至少能省半小时。

第二条，宿主机的空闲资源和沙箱内部的空闲资源是两个概念。看到宿主机磁盘还有几十GB，不要理所当然认为沙箱里也还有几十GB，分区上限、基础镜像占用、虚拟磁盘动态扩展这些因素都会让两边完全不一样。

第三条，和编码智能体协作时，要把运行环境当成一个需要显式说明的已知条件。智能体默认“它不知道沙箱的边界”，我们需要通过提示词和模板把这些边界传递给它。否则再聪明的生成器，也会在你给它限定的笼子里撞墙。

5.3 在这次事故里我们犯过的几个错

复盘不是找责任人，而是找错位。我们第一个错是启动沙箱的任务脚本里没有设置任何写入量上限，以为临时目录是无限的；第二个错是.wsb模板缺少版本记录，故障发生后连“这个模板是什么时候改成只读映射”都无法回答；第三个错是监控指标太单一，只关注任务失败率，没有关注虚拟磁盘文件的大小和沙箱内临时目录使用率，等于故障发生前完全没有前兆。

这几个错都在后续加固里补上了。如果你也在用类似的环境，建议直接对照着查一遍：临时目录有没有限制？配置文件有没有版本管理？监控里有没有磁盘增长曲线？这三个问题都回答完成，你的环境大概率比我们的出事前要稳。

我个人在这次复盘里最有体感的一件事是：故障复盘花了一个小时，真正产生价值的是把“我以为”全部打碎的过程。Windows沙箱是一个优秀的隔离工具，但它不会替你管理资源边界；编码智能体可以很高效地生成代码，但它无法看见运行环境的物理限制。在两者之间补上校验、清理和监控，才是做平台集成的人真正该干的事情。

如果你之后也遇到类似“沙箱一启动就退出”“任务莫名失败”的情况，先把事件日志拉出来，再检查临时目录写入量，大概率比在代码里反复找bug更有效。