技术 · 熟练
agent 的沙箱，能不能睡一觉再醒来？
按隔离强度选沙箱是错的，要按「它活多久」选
给 agent 配沙箱时，大多数人只问一个问题：隔离够不够强。但同一个 agent 在一小时里做的事，决定了另一个更要紧的问题 —— 它需要活多久。一次性任务里，容器跑完即销毁最省；而一个「每天被叫醒几次、每次几十秒」的 agent，如果每次都要重新装依赖、重新拉仓库、重新登录，那么你付的钱大部分花在「重新准备环境」上，而不是花在干活上。这一页给的是按生命周期选型的判据：能睡能醒的持久沙箱打底（空闲时休眠、文件与状态留着），需要 Docker / 数据库 / 模拟器的工作负载退到完整虚拟机，再把生命周期 API、备份与花销上限当成选型的必选项，而不是加分项。
方法 · 一图看懂
1
先算一个问题：这个 agent 一天被叫醒几次 — 突发型（偶尔被叫一次）与常驻型（持续被唤醒）的账完全不同；常驻型的成本大头在「重新准备环境」，不在算力本身
2
默认选「能睡能醒」的沙箱，而不是一次一建 — 空闲时休眠但保留文件与状态，下次唤醒直接接着用；这一步省下的不是算力，是每次重启都要重做的那一整套准备动作
3
隔离强度按工作负载分档，不分档就会两头痛 — 普通脚本类负载用轻量沙箱足够；需要 Docker、Kubernetes、数据库或模拟器的，退到完整虚拟机，而不是硬撑轻量方案
4
生命周期、备份、花销上限要进选型清单 — 能不能主动启停、状态能不能快照与回滚、单次与单日花销有没有上限，这三样决定这套环境能不能长期无人看管地跑
5
把「谁在用哪个沙箱」记在账上 — 多租户场景下，每个 agent 各自的沙箱要有归属，否则排查问题与清理残留都无从下手
原理 · 为什么有效
沙箱的选型被两股力量同时拉扯：隔离强度决定了最坏情况下能损失多少，生命周期决定了日常运行要付多少重复成本。只优化前者，会得到一个安全但昂贵的环境（每次从零开始）；只优化后者，会得到一个便宜但危险的共享环境。真正的做法是把两者拆成两个独立轴：先按「活多久」定形态，再按「谁碰谁」定隔离档位。这也解释了为什么「空闲时休眠、状态留着」这一点值得单独拎出来 —— 它把「一次一建」的固定成本摊薄了，而隔离强度可以另配，两者互不牺牲。
适用场景
适合要长期跑、且会被反复唤醒的 agent：按需响应的工作助手、多租户的自动化服务、需要保留登录态 / 缓存 / 中间产物的编码 agent。不适合一次性批处理任务 —— 那种场景跑完即销毁本来就是最优解，改成持久化只会多一份要维护的状态。
自测 · 5 问
你的 agent 是「一天被叫醒几次」还是「跑一次就结束」？两类选法完全不同
每次唤醒是不是都要重新装依赖、重新拉代码、重新登录？如果是，成本已经落在错的地方
需要 Docker / 数据库 / 模拟器的负载，是不是硬塞进了轻量沙箱？
有没有主动启停与状态快照？出事时能不能回到上一个干净状态？
单次与单日的花销有没有上限？无人看管的环境必须自己会刹车
怎么上手 · 验证步骤
三步落地：① 把现有 agent 按「唤醒频率」分两类（一次性 / 反复唤醒），只对后者改造成持久沙箱；② 给每个 agent 划定自己的环境边界（文件、登录态、缓存各自独立），并把「需要完整虚拟机」的工作负载单独列出；③ 补三件运维件 —— 生命周期接口（启停）、状态快照与回滚、单日花销上限与告警。做完这三步再谈节省，否则你只是在把一个更贵的东西换成另一个更贵的东西。
拿最近一周的实际运行记录验一遍：把「真正在干活的时间」与「准备环境的时间」分别加起来，看比例。准备时间占比高于三成，说明这套沙箱选型正在为生命周期买单；再用一次「断点续跑」测试收尾 —— 主动停掉一个正在工作的 agent，再唤醒它，看它是接着上次的状态干，还是从零开始。后者说明它其实并不持久。