给安装步骤它需要的网络访问，然后在不可信代码运行之前把沙箱锁死，整个过程不需要重启。你的AI代理为了装一个依赖需要联网，为什么当它开始运行你从未写过的代码时，还保留着同样的访问权限？

假设你的安装步骤需要访问 pypi.org、files.pythonhosted.org 和一个 Git 托管平台。接下来模型生成的代码只需要访问一个内部 API，别的什么都不用。两个阶段运行在同一个沙箱里，受同一套防火墙规则约束，因为网络策略在两个阶段出现之前就已经定好了。

打开网易新闻 查看精彩图片

权限窗口比实际工作更宽

如果在安装之后策略保持不变，不可信阶段就会继承安装器的网络可达范围，并且一直保留到沙箱销毁。更宽泛的需求之所以胜出，仅仅是因为更窄的需求会破坏安装过程。

这就是把网络策略当作环境规格的一部分来处理的问题所在，和 CPU、内存、磁盘并列。对于执行过程中信任级别会变化的工作负载，权限应该跟随阶段走，而不是跟随沙箱走。

在环境创建时设置网络策略感觉很自然，这确实是我们通常思考容器和虚拟机的方式：给环境一组资源和权限，然后放着不动，直到它消失。

但代理工作负载不会停留在单一信任状态。在安装阶段，你运行的是自己明确选择的依赖和工具。几分钟后，同一个沙箱可能执行模型生成的代码或用户提交的代码。这些阶段可能需要非常不同的访问权限，但它们坐在同一道防火墙后面。

如果两个阶段共用一套策略，更宽的权限集合就会进入信任度更低的阶段。这不是因为沙箱本身需要这样，而是因为策略被绑定到了沙箱上，而不是绑定到沙箱内部正在发生的工作上。

几个明显的变通方案都不太理想

有几个显而易见的变通办法，没有哪个特别有吸引力：

  • 分离环境。可行，但你要在环境之间迁移状态，还要付两次安装成本。
  • 从沙箱内部强制执行策略。这把控制机制放进了你正试图限制的同一个环境里。
  • 在阶段之间重建沙箱。保住了安全边界，但丢掉了你刚刚构建好的状态。

我真正想要的更简单：保留沙箱，在阶段变化时更换它的出站策略，并且能清楚看到每个时间点生效的是哪套策略。出站策略定义了沙箱可以向哪里建立出站连接，这些规则不必在沙箱整个生命周期里保持不变。这要求强制执行机制位于工作负载之外，由编排运行的系统来控制转换。

这正是 Tensorlake 的 Sandboxes 派上用场的地方：出站策略可以在运行中的沙箱上通过一次更新调用直接替换。我在这里使用 Tensorlake，是因为它的行为在文档和 SDK 源码中足够明确，可以验证实际发生了什么，而不是靠猜测。