第 23 章：扩展工程地图——平台、任务系统与维护状态

不必把所有项目当成直接竞争者

前面的四项工程帮助我们理解沙箱平台与本地限制器。接下来补充 Daytona、E2B、Modal Sandboxes 和 Judge0，分别观察工作环境接口、SDK 契约、托管资源，以及提交式代码执行。它们可以相互借鉴，但不能只凭都能运行 Python，就认定功能与责任完全一样。[15]～[18]

学习时继续沿用“收入总额 250”任务。真正要比较的是：输入怎样进入、执行发生在哪里、结果怎样验证、状态怎样保存、任务结束后谁负责清理。登录方式、安装命令和最新套餐请查当时文档，本书不固定易变的费用信息。

本次获取的 daytonaio/daytona README 开头明确声明：自 2026 年 6 月起，核心开发转移到私有代码库，该公开仓库不再接收更新、修复或发布。[15] 因此本书把它当作历史公开实现与产品接口的学习材料，不把它描述成仍持续维护的开源核心。

这纠正了前面讨论中的笼统推荐。公开仓库仍能帮助理解工作空间、文件操作、命令执行、快照和访问入口如何被组织成产品，但旧源码与当前托管产品可能已经不同。接口文档可以继续变化，公开仓库却停止更新，二者不能互相代替。

给小白的阅读任务：找出创建环境、文件读写和停止环境的接口；然后确认你读的是历史源码还是当前产品文档。最后在笔记中写上维护状态、版本、许可证位置与查阅日期。能运行一次并不代表今后还能获得相同维护支持。

E2B 的公开 README 展示了普通命令执行、Code Interpreter 和 Desktop 等不同入口，并把自托管说明指向其他运行时资料。[16] 因此“读过 E2B 仓库首页”不能等同于审阅了完整基础设施。

普通命令接口提供一个进程的 stdout、stderr 与退出结果；代码解释器还可能维护代码上下文、返回图表或富结果；桌面接口处理屏幕、鼠标与键盘。选择哪一层接口，决定控制器应该检查什么。计算 CSV 时不需要桌面能力，就没有必要为了方便开放整套交互桌面。

SDK 还是理解兼容层的参照：把实际使用的方法、版本、超时、异常和销毁方式列出来，再去检查 SPACE 或 CubeSandbox 对这些行为的覆盖。不要仅以成功 import 或一次 echo 认定迁移完成。

Modal 官方指南把 Sandbox 描述为运行不可信用户或 Agent 代码的容器环境，并给出创建、exec、读取输出和 terminate 的流程。[17] 还可以配置镜像与卷等资源。这里参考的是托管服务接口文档，本书没有把它当作可审阅的完整服务端源码。

它适合研究两件事：应用如何临时创建环境，以及环境寿命如何与其中的单次命令分开。一个环境可以运行多条命令；其中一条命令超时，不应被想当然地理解成所有关联资源都消失。

练习：用文字列出临时文件、持久卷、运行实例和应用配置四类对象，逐个查它们的生命周期。假设报告已经写进持久卷，terminate 实例以后报告是否保留？答案要从该存储对象的契约中找，不能仅从 terminate 这个动词推导。

Judge0 是在线代码执行系统，README 介绍多语言编译运行、标准输入、执行结果以及时间与内存限制等能力。[18] 它很适合帮助你理解：智能体出现以前，服务端运行陌生代码就已经需要调度、预算和错误处理。

与长期工作空间相比，一次代码提交通常更容易表达为“源代码、语言、输入、限制 → 编译或执行 → 结果”。这类接口适合练习和判题。多轮修改仓库、保持后台 Web 服务或保存终端状态，则需要再检查它是否提供相应语义，不能直接照搬。

把销售分析映射进去：提供固定代码与演示数据，拿到执行结果后校验 250。要区分编译错误、运行错误、超时、输出不符合预期。HTTP 请求成功仅表示接口调用得到响应，不等于代码完成了正确任务。