Deep Agents沙箱架构：sandbox-as-tool还是全代理入沙箱？

在LangGraph上构建研究综合型代理时，Deep Agents的沙箱文档摆出了两条路：sandbox-as-tool（代理在沙箱外，按需调用沙箱执行特定操作）和full-agent-in-sandbox（整个协调器-工作者树都跑在沙箱内）。Reddit上一位开发者正为此纠结，他的问题也戳中了不少多代理系统搭建者的痛点——尤其是当多个子代理需要共享工作状态时，边界到底划在哪里。

两种模式的核心权衡

原文把两者的利弊说得挺直白。sandbox-as-tool的吸引力在于更低的分步开销：不需要每次调用都启动虚拟机，调试链路更短，代理状态天然和LangGraph的图状态待在一起。但代价是每次调用都是一次边界往返；如果一个子代理要连续跑好几段代码才能完成一个子任务，这笔往返成本会被反复支付。

full-agent-in-sandbox则更适合协调器-工作者结构：子代理各自拥有工作文件系统，代理平面本身不需要被信任。麻烦在于冷启动更重，而且要把子代理的进度从沙箱里捞出来、送进LangSmith做可观测，得额外接管道。这位开发者目前的倾向是sandbox-as-tool，理由是他的场景里每个子代理的工具操作都短，状态主要落在代理自己的文件和待办列表里。

LangGraph 是 LangChain 团队推出的用于构建有状态多代理应用的编排框架，其核心抽象是“图”（Graph）：节点表示代理或工具调用步骤，边定义控制流，而图状态（State）贯穿整个执行过程，可在节点间传递和修改。正是这种显式的状态管理机制，使得“沙箱外代理 + 按需调用沙箱”成为自然选择——代理的推理状态与图状态保持同构，沙箱只是被当作一个工具节点接入。理解这一点，才能看清 sandbox-as-tool 模式下“代理状态天然和 LangGraph 的图状态待在一起”的真正含义：状态不需要跨边界同步，因为代理平面本身从未离开图。

LangSmith 是配套的可观测性平台，用于追踪代理的调用链、工具执行耗时与中间输出。当代理运行在 sandbox 外部时，工具调用边界清晰，LangSmith 可以自动捕获每次沙箱往返的耗时与参数；而当整个代理树跑在沙箱内部时，这些内部事件对 LangSmith 不可见，必须手动埋点或搭建日志管道把数据引出沙箱，这正是 full-agent-in-sandbox 模式“额外接管道”的由来。

后端选项与API契合度

文档列出的后端包括Modal、Daytona、Deno和Node VFS。发帖人额外提到了GMI AgentBox，看中的是它的create/upload/exec/result/delete这套API——五步接口几乎就是为sandbox-as-tool模式量身定做的，上传、执行、取结果、销毁，每个动作对应一次工具调用，语义干净。

这种API设计上的契合度值得注意：它降低了把沙箱包装成单一工具的心智负担，也让每次工具调用的生命周期边界变得明确。对研究综合型代理来说，频繁的代码执行往往是小颗粒度的，接口越接近“一次性操作”模型，sandbox-as-tool的往返成本就越容易被接受。

Modal、Daytona、Deno 和 Node VFS 代表了沙箱后端的几种不同形态。Modal 和 Daytona 提供的是完整的远程容器/虚拟机执行环境，具备文件系统、网络隔离和进程管理，适合执行任意代码；Deno 沙箱则偏向轻量级 JavaScript/TypeScript 运行时隔离，权限模型更细但生态受限；Node VFS 是虚拟文件系统抽象，并非真正的执行沙箱，更多用于在代理进程内模拟文件操作。这些后端在冷启动延迟、持久化能力和 API 粒度上差异显著，直接决定了 sandbox-as-tool 模式下每次工具调用的实际往返成本。发帖人青睐 GMI AgentBox，本质上是在寻找一种 API 语义与“一次性工具调用”模型对齐的后端，从而避免为状态管理额外编写适配层。

真正棘手的问题：子代理共享状态

帖子的核心疑问不在模式选择本身，而在沙箱按工具调用生命周期管理时，子代理状态怎么办。如果子代理A写了一个文件，子代理B在下一步要读它，只有两条路：要么在整个子代理运行期间保持沙箱温热——但这已经近似于full-in-sandbox了；要么在每次调用之间把状态物化回代理文件系统。

这个矛盾很有代表性。sandbox-as-tool的卖点是轻量和边界清晰，可一旦多子代理需要共享工作产物，状态同步的复杂度就会反噬。发帖人自己也意识到，“保持沙箱温热”和“全入沙箱”在工程上差别不大，只是名义上的模式不同。

沙箱温热（warm sandbox） 指的是在两次工具调用之间不销毁沙箱实例、保持其运行状态的做法。与冷启动相比，温热沙箱省去了启动虚拟机、重新挂载文件系统的开销，但代价是资源持续占用和生命周期管理复杂化。在多子代理场景下，“保持沙箱温热”实际上模糊了 sandbox-as-tool 与 full-agent-in-sandbox 的界线：前者原本假设每次调用独立、用完即毁，而温热策略让沙箱变成了一个有状态的长期存在，代理需要显式管理其存活周期，这与把整个代理树放进沙箱在工程复杂度上已非常接近。发帖人的直觉——“保持沙箱温热和全入沙箱在工程上差别不大”——正源于此。

决策框架：从状态共享密度出发

从这段讨论可以提炼出一个实用的判断轴：子代理之间的状态共享密度。如果子任务之间几乎不交换文件、每次工具操作独立且短小，sandbox-as-tool的往返成本可控，调试和可观测性也更省事。如果协调器-工作者结构里子代理需要持续读写同一份工作目录，那把整个代理树放进沙箱、接受冷启动和额外埋点成本，往往是更诚实的选择。

发帖人最后向社区提问：多子代理共享工作状态的场景下，大家是收敛到full-in-sandbox，还是坚持sandbox-as-tool、把状态通过代理文件路由？这个问题目前没有标准答案，但它把Deep Agents沙箱设计的真实分界线画了出来——不是性能数字，而是状态该住在哪一侧。

原文来自Reddit社区讨论，其中关于GMI AgentBox的观察为发帖人单方经验，尚未见其他来源交叉验证。