为什么 Agent 一旦能写代码就必须跑在沙盒里

当大模型停留在「问答」形态时把它部署成聊天服务几乎零风险——即使模型胡说八道，影响范围也局限在一个文本框里。但因为 function call、tool use 等能力标准化后Agent 的能力边界已经从「回答问题」演化为「写代码、跑测试、改生产数据库」。再看这代表着，Agent 现在拥有的是对内核态输入命令、数据库 DDL/DML 的权限。而不是仅仅复述文档，

OWASP Top LLM 应用漏洞榜单显示，「Improper Output Handling 」与「Excessive Agency 」始终排前列。官方修复建议首要是将 Agent 放在隔离环境中运行——沙盒是工程实践清单上的第一道防线，而非附加层。

下面用对比矩阵拆解四类隔离机制在工程上的真实取舍：

隔离机制	启动时延	内存使用	逃逸风险	运维成本
裸机 / 共享宿主0
	逃逸 = 全局沦陷最低。无隔离可言
	Docker / containerd	100ms~1s	几 MB ~几十 MB	中等逃逸面宽，需要 K8s 编排
如果 Agent 要执行任意 shell + 下载 npm 包 + 跑测试 + 可能触网下载依赖，微 VM 是更稳妥的选择；gVisor 适合“需要容器密度，又担心容器逃逸”的折中场景。LangSmith Sandboxes 默认采用 microVM 路线，因为它在“不可信模型输出”与“毫秒级响应”之间找到平衡。

从使用者痛点来看，担心凭据泄露导致生产数据库被篡改？微 VM 能让每个实例拥有独立内核，降低横向移动风险。

Sandbox 生命周期示例代码

from langsmith_sandboxes import Sandbox,SecretVault
def run_user_code_in_sandbox:
# 启动 microVM
sb = Sandbox.create(
template="python--slim",network_egress={"mode": "allowlist","allow": },cpu=...,mem_gb=...,ttl_seconds=...
)
从try来看。# 从 SecretVault 获取一次性凭据
cred = SecretVault.mint(
scope=f"sandbox:{sb.id}",permissions=,expires_at=sb.expires_at,)
sb.inject_env
# 在沙盒里执行使用者代码
result = sb.exec
return {"stdout": result.stdout,"sandbox_id": sb.id}
finally:
sb.destroy
SecretVault.revoke

痛点这方面，凭据必须绑定到沙盒生命周期，否则凭据会残留导致后续攻击。

把『隔离计算机』作为 Agent 的一等公民：LangSmith Sandboxes 产品哲学

从痛点来看，团队常因缺乏统一网站而出现“绕过沙盒”的隐蔽通道——只有将沙盒提高为程序主轴才能消除这些盲区。

AWS Lambda 在 2024 年从 EC2 容器架构切换到 Fireer microVM 后其函数冷启动尾部延迟显著调整，同时支持单台物理机并发数百个隔离运行时这是 microVM 在 serverless 场景中的主要优势。

"\t" "

# 维度	# Sandbox as runtime 插件 # Sandbox as API 公民	# 功能差异 \t	# 运维差异 \t	# 成本差异 \t	# 监控差异 \t \t \t \t \t \t \t \r> \r> \r> \r> \r> \r> \r> \r> \r> \r> \r> \r>" "\t"
"运维心智"
"sandbox 为加速器，可绕开 sandbox 时按实际 usage 按需计费；若强制 per-session 必选，则纳入 harness 基础订阅监控""	"trace span 自动注入 vs dev 自接""	"失败后无降级方法 vs 降级方法需手动配置""	"凭据由 harness 注入 vs agent 自行注入""	"env 永存 vs 随 exec 换 token""	"dev 环境跳过 vs prod 才启用同一行为一致性""

把 sandbox 做成 harness 一等公民。需要权衡三件事：

• - 冷启动成本：Fireer 启动约125 ms，可通过预热池子缓解；但开启太多预热池会占用物理资源。
• - 可观测性面扩大：所有 sandbox 调用都变成 trace span。存储开销上升，但提供完整回放链路，减少后期排查时间。
• - 开发者体验下降：本地直连测试被迫走 sandbox 方法。需要适配 SDK 与工具链，但长期看能降低安全事故概率。
• 如果你的团队想立即上线而不想承担额外监控与预热负载，那么保持 sandbox 为插件仍是可行方案；若追求安全第一，可将其提高为必选 API 公民。
• 务必避免“默认允许所有工具”或“无审计日志”。否则即使开启了 sandbox，也无法阻止 prompt injection 导致的数据泄露或破坏操作。
.

Snapshot → Fork → Scale 三件套：从 base image 到 N 个并行沙盒

Snapshot → Fork → Scale 的工程语义

从痛点来看。传统 “拉镜像+安装依赖+拉数据+执行” 步骤慢且易出错，一次快照+分叉就可以多实例并行，大幅降低评测门槛和资源浪费。

Snapshot — 把干净基底一次性做完

• MVP 成本只付一次在 snapshot 阶段完成镜像拉取、Python 环境准备和依赖安装，接下来作为一个不可变基础文件程序上传至对象存储或分布式块设备.
• = 对每一次 fork 都能保证一样的依赖版本与环境一致性.
• = 快照大小受限于镜像大小，一般几百 MB，为高效评测提供可复制基底.
• = 对外部依赖网络访问的限制可以通过 snapshot 阶段完成，不再需要每次 fork 时重新请求.
.

Fork — 分叉产生 N 个互不干扰实例

• Cow 技术让每个 fork 只复制脏页，这样就能实现毫秒级启动速度.
• N 个 fork 并行执行时共享同一份 base image，只需按需创建小量临时层即可.
• = 所以无论任务数量多达千级，都不会重复拉镜像导致 I/O 瓶颈.
.

Scale — 按需求分配到不同运行时

• K8s 节点适合长生命周期任务，需要稳定磁盘与 VPC 内网通信，例如持续集成流水线或生产 AI 服务.
• AWS Lambda 更适合短周期事件驱动任务，如 GitHub Actions 或即时推理调用.
• Lambda 或 Modal 提供毫秒级冷启动且无需持久磁盘。更适合轻量 CI 或实验型工作流..

两种模式的取舍矩阵

维度	每个任务独立启动	基于 Snapshot Fork
启动时延 秒 随依赖 & 数据下载影响 毫秒 基于预热快照的 CoW 派生 秒 接近常数摊销 数秒-数十秒 接近常数摊销
磁盘 IO 总量 100× 完整镜像 IO 易触发瓶颈 1× 完整镜像 IO + N× 差分层 IO 缓存命中率任务间几乎无共享
网络出口压力 每实例独立拉包 放大公网流量 一次拉取,N 次复用 显著降低 egress 成本
资源隔离性 独立实例无需额外配置 微 VM/容器命名空间 cgroup 配置
适用场景 | 单任务 | 批量评测 | CI/Eval | 长期服务 |------|--------|--------|-------- | 独立启动 | 快速但成本高 | 高 CPU & 网络开销 | 大规模部署难 | Snapshot Fork | 高密度 & 成本低 | 大规模评测 & CI 流水线 | | | | /

/ / / /

​

。

---