Sandbox 应该属于 Harness 还是 Runtime？
这个问题看起来像架构洁癖。
其实不是。
你把 Sandbox 放错位置，后面权限、审批、恢复、trace 都会跟着乱。
我的答案是：
Sandbox 的执行环境属于 Harness。
Sandbox 的策略决策属于 Runtime。
这两句话要同时成立。
先把三个词分开
Agent Runtime 负责一次 run 的执行治理：
上下文
模型调用
工具计划
权限审批
预算
trace
checkpoint
停止条件
Harness 负责把 Agent 放进一个可运行的外壳里：
工作目录
进程启动
文件挂载
网络配置
环境变量
容器 / VM / microVM
终端 IO
资源限制
Sandbox 是 Harness 提供的一类执行边界：
哪些文件能读写
能不能联网
能不能启动子进程
环境变量是否过滤
能不能访问宿主系统
运行结束后是否销毁
所以 Sandbox 不是一个纯业务模块。
它要落到操作系统、容器、网络、文件系统和进程隔离上。
但 Sandbox 也不是单纯基础设施。
因为'给这个 run 多大权限'，必须由 Runtime 根据任务、工具风险、用户审批和 policy 决定。
为什么说执行环境在 Harness
Runtime 不应该自己假装能隔离系统调用。
真正的隔离要靠底层：
macOS Seatbelt
Linux namespace / seccomp / bubblewrap
Windows restricted user / job object / firewall
container
microVM
remote sandbox
OpenAI 的 Codex 安全文档把 sandbox 和 approval 分开讲：sandbox 定义技术执行边界，比如能写哪里、是否能联网、哪些路径受保护；approval policy 决定什么时候要问用户。Anthropic 在 Claude Code sandbox 文章里也强调文件系统和网络隔离要一起做，否则只隔一边很容易被绕过。
这说明一件事：
Sandbox 的硬边界必须由运行环境提供。
靠 prompt 不行。
靠模型自觉不行。
靠工具函数里写几行 if 也不够。
工具函数可以做第一层防护，但它拦不住进程逃逸、依赖脚本、恶意测试、子进程读取环境变量。
所以 Harness 必须能创建和管理执行环境。
为什么说策略决策在 Runtime
但 Harness 不应该独自决定所有权限。
Harness 知道'我能提供哪些隔离级别'。
Runtime 知道'这次 run 需要哪些能力，以及哪些能力被允许'。
比如用户说：
帮我修复测试。
Runtime 会看到：
当前工具计划：read_file, write_file, npm test
风险：读、写、shell
用户策略：允许 workspace 内写入，禁止联网
预算：最多 8 step
checkpoint：写文件前必须保存 snapshot
然后 Runtime 请求 Harness：
启动 sandbox
挂载 workspace
允许 workspace 内读写
禁止网络
过滤敏感环境变量
允许 npm test
限制超时和输出
如果 Harness 自己决定'这个工具能不能跑'，它缺少上下文。
如果 Runtime 自己直接跑命令，不走 Harness，它缺少硬隔离。
两者都不完整。
Permission 不是 Sandbox
很多人会把 permission 和 sandbox 混在一起。
它们不是一回事。
Permission 回答：
这次工具调用是否允许？
是否需要用户批准？
批准范围是什么？
拒绝后能不能找替代方案？
Sandbox 回答：
就算允许执行，这个进程最多能碰到什么？
写入会落在哪里？
网络能访问哪些域名？
环境变量有哪些？
资源上限是多少？
Permission 是决策。
Sandbox 是边界。
一个写文件工具可能被 PermissionGate 批准，但仍然只能写 workspace 内。
一个 shell 命令可能被用户批准，但仍然不能访问网络。
一个 MCP 工具可能被允许调用，但仍然运行在隔离环境里。
不要让用户审批代替技术隔离。
人会疲劳。
Sandbox 不会因为点了太多确认而走神。
Sandbox 也不是单一开关
不要在配置里写：
{
"sandbox": true
}
然后就放心了。
Sandbox 至少有这些维度：
filesystem read
filesystem write
network egress
environment variables
process isolation
syscall boundary
resource limit
workspace mount mode
credential access
artifact export
lifetime
一个比较实用的策略对象可以是：
type SandboxProfile = {
id: string;
filesystem: {
read: string[];
write: string[];
readonlyMounts: string[];
};
network: {
mode: "deny" | "allowlist" | "open";
domains?: string[];
};
env: {
inherit: "none" | "safe" | "explicit";
allowlist: string[];
};
process: {
timeoutMs: number;
maxOutputChars: number;
killProcessTree: boolean;
};
lifetime: "per_tool_call" | "per_run" | "persistent_workspace";
};
这不是为了写得复杂。
是为了让团队能说清楚：这个 sandbox 到底隔离了什么。
三种常见层级
生产里可以分三档。
1. Workspace Sandbox
适合日常 coding agent。
只能读写当前项目
默认禁止网络
过滤环境变量
shell 走命令策略
写入走 checkpoint
优点是快，用户体验好。
缺点是隔离强度有限。恶意代码如果能逃出进程或利用系统漏洞，仍然有风险。
2. Container / VM Sandbox
适合运行测试、安装依赖、执行不太可信的代码。
独立文件系统
独立进程空间
可控网络
可销毁环境
依赖安装不污染宿主
Docker Sandboxes 这类方案把 coding agent 放进 microVM，让 agent 可以安装包、构建容器、改文件，同时不碰宿主系统。E2B 也把自己定位成给 AI agents 运行代码的安全云端 sandbox。
这类方案更适合非交互长任务和不可信代码执行。
3. Remote Ephemeral Sandbox
适合高风险任务。
每次任务创建新环境
只导入必要文件
不挂载用户主目录
不继承本机凭证
结束后导出 patch / artifact
环境销毁
代价是启动慢、同步复杂、调试体验差。
但对不可信输入、第三方代码、自动依赖安装，这个代价通常值得。
Harness 要提供能力目录
Runtime 不能凭空要求 sandbox。
Harness 应该暴露 capability：
type HarnessCapabilities = {
filesystemIsolation: "workspace" | "container" | "microvm";
networkControl: "none" | "deny" | "allowlist" | "full";
envFiltering: boolean;
resourceLimits: boolean;
snapshotExport: boolean;
perToolSandbox: boolean;
perRunSandbox: boolean;
};
Runtime 根据 capability 决定策略。
比如 Harness 不支持网络 allowlist，那 Runtime 只能选择 deny 或 ask。
Harness 不支持 env filtering，那 Runtime 不应该允许执行第三方脚本。
Harness 不支持 snapshot export，那 Runtime 要用自己的 file checkpoint 补上。
能力说不清，就不要假装安全。
Runtime 要把 Sandbox 写进 Trace
如果一次工具执行出了事，trace 里要能看到：
sandbox.profile = workspace-readwrite-network-deny
filesystem.write = ["workspace/**"]
network.mode = "deny"
env.inherit = "safe"
tool.name = "shell_readonly"
command = "npm test"
timeoutMs = 8000
approval.id = approval_42
checkpoint.id = checkpoint_7
否则排障时没人知道这次命令到底跑在什么边界里。
同一个 npm test：
在宿主机跑
在 workspace sandbox 跑
在 container 跑
在 remote microVM 跑
风险完全不同，结果也可能不同。
Trace 必须记录这个差异。
Checkpoint 和 Sandbox 要配合
Sandbox 可以隔离副作用，但不能替代 checkpoint。
比如工具在 sandbox 里改了文件。
你仍然要知道：
哪些文件变了
diff 是什么
是否要导出到真实 workspace
导出前用户是否批准
导出后如何 rollback
远程 sandbox 的一个好处是：可以先让 Agent 在隔离环境里大改，再把 patch 带回来给用户审。
但 patch 合并仍然是 Runtime 责任。
如果用户本地文件已经变了，Runtime 要做冲突检测。不能因为 sandbox 里跑通了，就直接覆盖用户当前工作区。
Computer Use 是另一类风险
还有一种更麻烦的能力：computer use。
它不是在文件工具或 shell 工具里执行，而是直接操作浏览器、桌面应用、网页 UI。
Anthropic 的帮助文档提醒，某些 computer use 场景没有 sandbox 隔在模型和屏幕之间。这个风险很真实：网页、图片、文档都可能包含恶意指令，Agent 又能点击、输入、下载、上传。
所以 computer use 最好运行在专门 VM 或隔离浏览器里。
Runtime 仍然要记录：
访问了哪个域名
看见了什么来源的内容
是否下载文件
是否上传文件
是否输入敏感信息
是否需要人工确认
Sandbox 不只属于代码执行。
只要 Agent 能影响外部世界，就需要边界。
我会怎么设计第一版
学习型项目可以这样做：
Runtime:
- Tool risk classification
- PermissionGate
- SandboxProfile selection
- Trace attributes
- Checkpoint before write
Harness:
- workspace path isolation
- shell command runner
- env filtering
- timeout / output limit
- optional container runner
Tool:
- 不直接决定全局权限
- 只声明 risk、resources、sideEffects
第一版不用一口气上 microVM。
但至少要做到：
workspace 外路径拒绝
symlink 写入拒绝
shell 默认只读
网络默认禁用
环境变量不全量继承
写文件前 checkpoint
权限和 sandbox profile 进入 trace
这已经比'让模型直接跑命令'强太多。
结论
Sandbox 应该属于 Harness 还是 Runtime？
执行环境属于 Harness。
策略决策属于 Runtime。
Permission 决定能不能做。
Sandbox 限制最多能做什么。
Trace 记录当时在哪个边界里做。
Checkpoint 保证做完还能恢复或回滚。
