Agent 运行时新范式：沙箱如何重塑执行环境

Personal Agent 正在获得属于自己的「计算机」，能够全天候为用户提供服务。但这是否意味着每个 Agent 都必须独占一台 7×24 小时运行的云主机？答案是否定的。更务实的方案是为 Agent 提供按需创建的沙箱——任务启动时即时创建，完成后暂停或销毁，避免资源闲置浪费。沙箱的价值远不止于成本节省。想象一下，如果 Agent 运行在公用机器上，自主执行命令、修改文件，很可能产生相互干扰甚至越权访问。沙箱通过会话级隔离机制，让 Agent 能够在安全边界内更自主地完成任务。这正是本文要探讨的核心议题：沙箱正在成为 Agent Runtime 的核心执行环境。

沙箱的本质与安全边界

沙箱并非新技术，本质上是一个受控的运行环境，通过隔离机制限制程序对宿主机文件、网络和其他资源的访问。例如，直接在本地运行 AI 生成的脚本，可能误删文件或读取敏感数据；而放进沙箱后，可以通过策略限制这些危险行为。这种隔离性对 Agent 尤为重要。我们很难提前枚举 Agent 完成任务所需的所有操作，也不可能每一步都让用户审批确认。因此，让沙箱为 Agent 划定安全边界是必要的——在边界内，Agent 可以自主行动；越界行为则被自动阻断。正是这种「放手不放任」的特性，使沙箱成为 Agent 执行环境的理想选择。

Docker 的局限与 Agent 的特殊性

既然沙箱是隔离的执行环境，已经使用多年的 Docker 难道不能满足需求吗？实际上，很多沙箱底层仍采用容器技术。但问题不在于 Docker 本身，而在于传统应用的运行方式未必适合 Agent。传统 Web 应用以服务为单位部署，长期运行的容器持续处理请求，业务状态存储在数据库中。这种模式成熟稳定，因为应用逻辑固定、请求相对独立。但 Agent 不同，它的执行以任务为中心，会自主执行 Shell 命令、安装依赖、创建文件，甚至启动其他进程。这些操作持续改变执行环境，而变化不会随请求结束自动消失。虽然可以用 Kubernetes Job 为每个任务启动独立容器、完成后销毁，但这已表明我们开始围绕任务而非服务来管理执行环境——这正是沙箱的核心思路。

沙箱在 Agent 系统中的四种形态

根据 Agent 与执行环境的关系，沙箱在 Agent 系统中主要有四种使用形态。第一种是本地沙箱，让 Agent 在受控范围内自主执行命令，典型如 Claude Code，通过操作系统隔离限制文件系统和网络访问，Anthropic 实践数据显示引入沙箱后权限确认次数减少 84%。第二种是 Agent in Sandbox，将 Agent 及其执行环境整体放入沙箱，适合需要完整工作空间的长程任务。第三种是 Sandbox as Tool，把沙箱作为独立工具供 Agent 按需调用，如阿里云 AgentBay 的 Browser Use 为 Agent 提供云端浏览器环境。第四种是 Harness 加 Session 加 Sandbox 的三元架构，将决策层、执行层、历史记录层完全解耦，各组件可独立管理生命周期，Harness 可重启、Session 持续保存历史、Sandbox 按需创建回收。

从容器中心到沙箱中心的范式转移

从本地沙箱到 Agent in Sandbox，再到 Sandbox as Tool，直至 Harness 与 Sandbox 的解耦，我们看到一个明确趋势：沙箱正从附加的安全措施演变为 Agent 运行环境的核心。过去部署应用首先想到构建镜像、启动容器，让服务持续处理请求。但 Agent 不只是运行预先编写的程序，它会自主执行命令、修改文件、安装依赖，甚至改变执行环境本身。因此，Agent 需要的不只是运行程序的容器，而是一个独立、受控、能够按需创建和回收的执行环境。沙箱底层可以继续使用容器技术，也可以采用 microVM 等更强隔离机制，但站在 Agent Runtime 视角，真正变化的是基础设施的核心抽象：从以容器为中心运行应用，转向以沙箱为中心为 Agent 提供安全、独立、可自主操作的执行空间。

沙箱已从一项附加的安全措施，逐渐成为 Agent 运行环境的核心组件。它为 Agent 提供隔离边界、安全保障和自主执行的空间，同时实现资源的高效利用。随着 Agent 应用的持续深化，沙箱的重要性将进一步凸显，成为 Agent Runtime 的基础设施底座。