深入解析DevBox：全代理沙箱架构如何自动生成PR

在AI代理架构设计中，“沙箱即工具”（sandbox-as-tool）与“全代理在沙箱中”（full-agent-in-sandbox）是两种常见模式。Reddit社区的一篇讨论帖中，开发者分享了他为DevBox项目选择后者的理由与实现细节。DevBox是一个基于Deep Agents构建的自主工程测试框架（harness），目标是将任务自动转化为草稿PR。本文将拆解其架构设计、关键权衡与可借鉴经验。

为什么选择全代理沙箱模式？

原作者在阅读了关于“沙箱即工具 vs 全代理在沙箱中”的对比分析后，决定采用全代理沙箱模式。在这种模式下，每个任务都运行在一个独立的沙箱内，代理拥有完整的操作环境，而非仅仅调用沙箱提供的工具接口。这种选择的核心动机是隔离性与状态管理的灵活性——代理可以在沙箱内自由执行命令、修改文件，而不会影响宿主机或其他任务。

DevBox的定位是一个“自主工程测试框架”，它接收任务描述，最终产出草稿PR。每个任务对应一个独立的沙箱实例，代理在沙箱内完成代码修改、测试和提交准备。这种设计使得任务之间天然隔离，避免了共享状态带来的竞态问题。

沙箱即工具（sandbox-as-tool）：该模式下，代理运行在受控的主环境中，沙箱只作为可调用的工具暴露有限接口（执行命令、读写文件等），每次调用返回结果。它的优点是启动快、资源复用高、代理编排逻辑集中；缺点是代理与沙箱之间存在接口边界，复杂操作需要多次往返，且多个子代理共享同一沙箱时状态互相可见，容易产生竞态与污染。与之相对，全代理在沙箱中把整个代理循环放进隔离环境，牺牲冷启动时间换取任务级隔离与更自然的文件/命令操作体验。

架构核心：凭证、状态与交接

凭证安全：铁代理交换真实密钥

沙箱内只存放虚拟密钥（dummy secrets）。当沙箱内的流量需要访问GitHub或LLM API时，会经过一个名为iron-proxy的代理层，由它将虚拟密钥替换为真实密钥。这样，即使沙箱被攻破，攻击者也无法直接获取真实凭证。这种“出站代理交换”模式在安全性与便利性之间取得了平衡。

出站代理交换（outbound proxy secret swapping）：这是一种凭证隔离模式，沙箱内应用只持有无权限的占位密钥，所有出站请求被强制路由到受控代理；代理根据目标域名与预设策略，在转发前把占位密钥替换为真实密钥，并对响应做必要过滤。与直接把真实密钥注入环境变量相比，它的优势是真实密钥从不进入沙箱文件系统或进程环境，泄露面大幅缩小；代价是需要保证沙箱流量无法绕过代理（如通过 DNS 或直连 IP），通常要配合网络策略与 egress 规则。

状态持久化：一次性沙箱与持久化磁盘

沙箱本身是一次性的（disposable），但磁盘不是。LangGraph的检查点（checkpoints）存储在按任务划分的持久卷上。如果Pod意外终止，新启动的沙箱会挂载同一个卷，并从最后一个检查点恢复执行。这种设计将计算实例的生命周期与状态存储解耦，既保证了隔离性，又避免了任务因实例故障而丢失进度。

交接机制：通过Pydantic结果传递

代理之间不直接传递文件，而是由测试框架为每个仓库启动一个worker。每个worker返回一个经过Pydantic验证的结果对象，框架验证后将其传递给下一个阶段。这种基于结构化数据的交接方式减少了隐式耦合，也便于框架对中间结果进行校验和记录。

LangGraph 检查点：LangGraph 是构建有状态、多步骤代理工作流的框架，其检查点机制会在每个节点执行后对图状态做一次快照并持久化。在 DevBox 中，检查点不是存在内存或临时目录，而是写入按任务划分的持久卷，因此 Pod 重建后只需从最新检查点加载状态即可继续执行，而不必从头重跑。理解这一点有助于判断恢复粒度：检查点通常以“步骤”为单位，恢复时可能重放最近一个未完成步骤，因此节点逻辑需保持幂等，避免重复副作用（如重复创建分支或重复提交评论）。

关键权衡：冷启动与新鲜代码

全代理沙箱模式的一个显著代价是每个任务都需要冷启动。每个任务获得一个全新的Pod，以及一个从仓库周期性快照恢复的卷。代理在规划之前会拉取所有仓库的最新代码，以确保不会基于过时代码工作。

恢复卷的过程较慢，原作者因此将沙箱创建超时从30秒提高到了5分钟。这是一个值得注意的工程取舍：为了状态一致性和隔离性，牺牲了启动速度。对于需要快速迭代的任务，这种延迟可能成为瓶颈；但对于需要可靠产出的自动化PR生成场景，确保代码新鲜度可能比启动速度更重要。

对“沙箱即工具+多子代理”模式的疑问

原作者在文末提出了一个开放问题：是否有人尝试过“沙箱即工具”模式并搭配3个以上子代理？在共享状态下这种模式是否依然可靠？这暗示了两种模式在不同规模下的表现可能存在差异。全代理沙箱模式通过任务级隔离简化了状态管理，而沙箱即工具模式在多子代理协作时可能面临更复杂的状态同步挑战。

DevBox的代码已在GitHub以MIT协议开源，感兴趣的开发者可以直接查看实现细节。对于正在设计代理架构的团队，这个案例提供了一个关于隔离粒度、状态持久化和凭证安全的实用参考。

实践启示

从DevBox的设计中可以提炼出几条可复用的经验：凭证通过出站代理交换而非直接注入，降低了泄露风险；一次性计算实例搭配持久化卷，兼顾了隔离与容错；代理间使用结构化结果对象交接，提升了可验证性；接受冷启动代价以换取代码新鲜度，是一种有意识的权衡。这些决策并非唯一正确答案，但为类似场景提供了可讨论的起点。