《Agent Runtime 工程化》Sandbox 应该属于 Harness 还是 Runtime？

它们不是一回事。

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 保证做完还能恢复或回滚。

推荐阅读

• Agent Runtime 和 Workflow Engine 有什么区别？
• 我对生产级 Agent Runtime 的 10 条工程判断
• Production Agent Checklist v1.0 发布