Agent 沙箱过去常被理解为一道安全边界：把模型生成的代码放到隔离环境里运行，限制文件、网络和凭证访问。但最近出现的一组产品与工程变化说明，隔离已经不够。长程 Agent 真正需要的，是一套能够保存状态、解释过程、处理中断并继续执行的运行时。
这不是给 Agent 再增加一个工具，而是在重新划分应用层和基础设施层的职责。任务在哪里运行、使用什么权限、进行到哪一步、为什么暂停、恢复后如何避免重复副作用，正在从零散的应用补丁变成统一的运行时能力。
隔离正在成为起点，而不是终点
AWS 展示了用 Lambda microVM 承载 Agent 不可信代码的方案，重点不只是“能运行 Python”，而是短生命周期环境、资源限制、最小权限和云端审计。Sanbox 则进一步把并行任务放进独立 microVM，将文件系统、工具调用、模型活动和对话历史绑定到同一个任务，并支持快照与续跑。
这两条路线共同指向一个变化：沙箱不再只是发生危险时缩小损失范围的容器，也开始承担任务状态管理。对于需要数十分钟甚至数小时的代码修改、数据处理和研究任务，进程中断并不罕见。不能恢复的隔离环境虽然安全，却会把网络抖动、人工审批和临时故障都变成昂贵的全量重跑。
“恢复”必须同时回答“恢复了什么”
可恢复性不是简单保存一个磁盘镜像。Suna 连续修复会话切换、沙箱启动和状态恢复问题，暴露出长任务产品的真实难点：后端可能正在排队、启动、等待审批或重连，前端如果只有“成功/失败”两种状态，用户就会误判任务丢失并重复提交。
与此同时，Bernstein 把带作用域的令牌、授权与撤销记录、逐次访问决策和运行审计组合成证据链。它提醒开发团队，恢复一个任务时，不应只恢复文件和对话，还要恢复当时有效的权限、预算、工具版本与审批上下文。否则，技术上能够续跑，治理上却无法证明这次执行仍然被授权。
计划层也开始接受约束
Skillscript 所代表的另一条路线，是用受限的声明式语言描述工具调用、并发、重试、错误分支和预算，再通过 schema 校验提前发现参数问题。它与 microVM 运行时并不冲突：前者约束“允许怎样执行”，后者负责“在哪里执行、如何隔离和恢复”。
这意味着可靠 Agent 的工程栈正在形成新的分层。模型负责理解目标和选择路径；受约束的计划表示负责控制流程与预算；运行时负责权限、状态、快照和审计；验证器再判断结果是否满足交付标准。仅靠一段更长的提示词，很难稳定承担这些职责。
对实际工作流意味着什么
对开发 Agent 的团队，最值得优先补齐的不是更多工具，而是统一的任务契约。每次运行至少应记录任务 ID、模型与工具版本、权限范围、网络策略、状态转换、成本、检查点、产物和验证结果。状态机也应明确区分 queued、starting、running、awaiting approval、recovering、failed 与 completed。
对使用者而言，评估一套 Agent 平台时也不能只看演示中的成功率。还要测试中途断网、进程退出、凭证撤销、人工暂停和恢复后重复写入等故障路径。能完成一次任务，只能证明能力；能在受控权限内中断、解释、恢复并避免重复副作用，才接近生产系统。
我的判断
Agent 基础设施的下一道门槛，不是把沙箱做得更像一台临时电脑，而是把它升级为可恢复、可审计的任务运行时。AWS、Sanbox、Suna、Bernstein 和 Skillscript 的成熟度并不相同，部分产品仍需独立验证安全性、启动开销和恢复一致性，但它们共同说明了竞争方向。
当 Agent 开始承担真实工作，模型能力决定它能否尝试，运行时则决定组织是否敢让它持续执行。未来更有价值的平台，不会只提供“启动 Agent”的按钮，而会提供一份可以检查、暂停、撤销、重放和追责的执行记录。
参考来源：AWS：使用 Lambda microVM 安全执行 Agent 代码、Sanbox、Suna Releases、Bernstein v3.3.0、Skillscript