面向过程的运行时：沙箱、快照与状态恢复

长时程任务不能把状态留在内存里：轻量沙箱隔离、秒级快照 Checkpoint 与事件驱动的按需唤醒。

很多初期搭建的智能体，底层的运行方式非常脆弱：在服务器上启动一个常驻进程，智能体生成的所有中间文件和状态，全部堆放在宿主机的同一个目录或当前进程的内存中。

这种模式在本地演示时看似正常，但是一旦进入生产环境，就会迅速暴露出三处严重的工程缺陷：

第一是资源浪费与并发瓶颈。如果一个任务需要等待人工审批，或者需要等待外部耗时较长的自动化测试，常驻进程就只能在服务器上空转等待。当并发任务量增加时，服务器的计算资源和网络连接很快就会被消耗殆尽。

第二是长流程缺乏故障恢复能力。一旦宿主机发生重启或网络闪断，原本已经执行了半小时的任务就会被迫中断。由于中间过程没有持久化记录，系统只能从头重新执行，不仅浪费了大量的时间，此前消耗的模型调用成本也无法追回。

第三是环境污染与安全风险。多个任务共享宿主机的文件系统，如果某个智能体误删除了公共依赖或者下载了异常脚本，就会直接导致同一台机器上的其他任务全部崩溃。

要解决这些问题，必须把运行时的底层抽象从「脆弱的常驻进程」升级为「面向过程的弹性沙箱」。

核心设计准则：计算临时，状态持久

面向过程运行时的第一原则，是将计算资源与业务状态彻底拆开：

计算资源是临时的（Ephemeral）。 智能体需要执行命令行、分析代码或处理数据时，系统才动态分配一个轻量沙箱。一旦当前操作执行完毕，或者任务进入等待阶段，计算资源就可以随时暂停甚至销毁。

业务状态是持久的（Durable）。 任务进行到了哪一步、修改了哪些文件、产生了哪些依赖，这些数据必须被独立保存在持久化存储中，绝不能依赖某台具体机器的内存。

轻量沙箱隔离与出网控制

为了实现安全隔离，执行环境通常基于轻量虚拟化技术构建 firecracker-microvm。

每个任务启动时，系统为其挂载只读的基础系统镜像，以及一块专属于当前任务的可写数据层。智能体在沙箱内可以自由创建和修改文件，但是它看到的只是一个被严格限制的虚拟空间，无法触碰宿主机的文件，更无法窥探相邻沙箱的数据。

同时，沙箱必须施加严格的网络出口白名单管理。默认状态下，沙箱处于完全断网或仅允许访问指定内部依赖镜像源的状态。如果任务确实需要访问外部互联网（例如抓取公开技术文档），请求必须经由代理网关进行域名审查，防止模型受到诱导将企业机密数据外发。

秒级快照（Checkpoint）与安全回滚

在动辄持续数十分钟的长时程任务中，秒级快照机制是保证交付成功率的核心资产 cursor-cloud-sandboxes。

系统会在三个关键节点自动创建增量快照：

1. 阶段里程碑达成时：例如环境初始化完成、核心代码文件编写完毕、单元测试全部通过之后；
2. 高危动作执行前：即将执行数据库写入、修改系统配置等不可逆操作之前；
3. 模型探索产生重大分歧前：当智能体准备在多种技术方案中尝试其中一种时。

快照不仅包含文件系统的改动记录，还完整封装了当前的步骤计数、会话记忆摘要与环境配置。这套机制的用户态实现（在 Linux 上冻结与恢复进程）已有成熟开源方案可供参照 criu-checkpoint。

如果智能体在后续步骤中陷入死循环、或者尝试的方案被证实完全行不通，系统不需要让任务重头开始。调度器可以直接命令沙箱丢弃最近的错误改动，一键回滚到上一个健康快照。模型拿到干净的环境状态与上一轮失败的具体原因说明，就能迅速换一条合理的路线继续推进。

按需休眠与事件驱动唤醒

当智能体触达人工审批节点，或者需要等待外部第三方系统的耗时响应时，系统不会允许沙箱继续空转消耗资源。

此时，运行时会将沙箱状态完整固化到对象存储中，随后将微虚拟机挂起休眠 fly-machines。底层的 CPU 和内存被立即释放，用于调度其他活跃任务。

当管理员在飞书或网页端点击了通过按钮，或者外部系统的构建完成通知以 Webhook 形式送达时，事件网关根据任务标识找到对应的休眠记录。调度器在几百毫秒之内拉起新的纯净沙箱，解压恢复之前的快照状态，让任务仿佛从未中断过一样继续执行。

终态归档与环境销毁

当任务最终判定通过全部验收并交付时，系统将最终生成的交付文件（例如打包产物、补丁文件或数据报告）转存入企业的正式存储系统中，并生成一份不可篡改的交付记录。

与此同时，任务此前使用的临时沙箱被彻底删除，临时目录被彻底清空。没有存留的残留进程，也没有积累的技术垃圾。这种从创建、隔离、快照、休眠到销毁的完整闭环，让长时程智能体真正具备了企业级生产系统所需的稳定性和成本可控性。