3 篇博文 含有标签「sandboxing」

如果你在任何真实规模下运行编程智能体 (coding agents)，你就拥有一支临时虚拟机舰队。你可能并没有主动申请这样做。但在你决定（且正确地决定）不信任的、由模型生成的代码绝不应该在应用程序的信任边界内执行的那一刻，这一切就发生了。每个任务都有自己的沙箱，每个沙箱都是一个微型虚拟机 (microVM) 或硬化容器。突然间，那个自以为在构建“智能体产品”的平台团队，实际上正在运营一些看起来非常像微型 AWS Lambda 的东西：池预热 (pool warming)、快照流水线、装箱调度器 (bin-packing schedulers)，以及一个针对无人认领环境的清理进程 (reaper process)。

陷阱在于假设你的容器编排直觉可以无缝迁移。有些确实可以。但 Kubernetes 是为了调度长周期的、同质化的服务而设计的，而智能体沙箱恰恰相反：生命周期短、极度异构，且创建速度之快让部署滚动更新 (rollout) 看起来像是在悠闲散步。那些挣扎的团队往往将沙箱基础设施仅仅视为“步骤更多的容器”。有趣的工程挑战——以及几乎所有的成本——都集中在四个问题上：冷启动、文件系统状态、装箱密度和弃置。

你的技术栈通常有三个环境。开发环境（Dev）是可抛弃的，预发环境（Staging）是类生产环境，而生产环境（Prod）是神圣不可侵犯的。二十年的工程文化——CI 门禁、金丝雀发布、蓝绿部署——全都建立在这种分层之上。但当你给智能体（Agent）一个调用 Salesforce、QuickBooks 或 Gmail 的工具时，这种分层就悄然消失了。对于客户的组织来说，并没有“预发环境下的 Salesforce”。也没有发票账本的影子副本。一旦工具调用跨越网络边界进入第三方 SaaS，环境就只剩下一个，那就是生产环境。

这是智能体工程（Agent Engineering）中最少被讨论的鸿沟。我们已经擅长对智能体的“计算”进行沙箱化处理——容器、出口白名单、资源配额。我们在评估智能体的“推理”方面也做得还行——离线评估、LLM 作为评委、轨迹评分。但智能体对“外部世界”的操作仍然是在包含真实客户数据的生产系统上运行的，因为对于大多数 SaaS 界面来说，除此之外别无他法。团队只能通过仅有的两种方式悄悄解决这个问题：要么在生产环境中测试，要么根本不测试。

大多数发布具备代码执行能力的 LLM 智能体（Agent）的团队都犯了同样的错误：他们将沙箱化视为一种二元属性。要么完全跳过隔离（“我们信任我们的用户”），要么部署 Docker 容器并认为问题已解决。这两种立场在进入生产环境后都经不起考验。

现实情况是，沙箱化存在于一个包含五个不同级别的光谱上，每一级都提供不同的隔离保证、性能配置和运营成本。所选隔离级别与实际风险概况之间的不匹配是大多数智能体安全事件的根本原因 —— 而不是根本没有沙箱。