OpenClaw 里该选 SSH/OpenShell Sandbox，还是 Docker Container？一篇讲透隔离、状态与运维代价

在 OpenClaw 这类 Agent 运行框架里，“执行环境”不是实现细节，而是系统设计的一部分。你让 Agent 去读代码、改文件、跑命令、访问网络、调试服务时，背后必须回答一个问题：它到底运行在什么边界里？

工程上常见的两条路线是：

1. OpenShell / SSH sandbox：Agent 通过 shell 会话进入一个已有主机环境，直接在该环境中执行命令。
2. Docker container：Agent 被约束在一个容器镜像与容器实例内，文件系统、进程视图和网络策略通常都更可控。

这两种方式都能“跑起来”，但它们在隔离、状态、可复现性、调试方式和运维成本上差异极大。对有经验的 DevOps、Infra、AI Agent 实践者来说，真正重要的不是“哪个更先进”，而是：你的任务模型到底需要哪种边界。

一、架构差异：它们不是同一层抽象

SSH/OpenShell sandbox 的本质，是把 Agent 接到一个现成操作系统会话上。这个会话可能是本机 shell，也可能是远程 Linux 主机上的用户空间。Agent 看到的是一套已经存在的环境：已有目录、已有工具链、已有用户权限、已有进程状态。

Docker 则不同。它不是“远程 shell”，而是基于镜像定义运行时边界。Agent 进入的是一个按镜像构建出的用户态环境，依赖、目录布局、基础工具版本通常由镜像固定，生命周期也更接近“实例”。

所以二者的核心区别不是“一个能连远程、一个不能”，而是：

• SSH/OpenShell 偏向接入既有环境
• Docker 偏向声明和复制环境

如果你的任务依赖“接近真实机器的当前状态”，SSH 更自然；如果你的任务依赖“稳定可重建的执行基线”，Docker 更适合。

二、隔离模型：用户边界 vs 内核共享下的容器边界

从隔离强度看，SSH/OpenShell 通常依赖的是：

• Unix 用户权限
• sudo/非 sudo 权限模型
• 主机本身的文件权限与系统策略
• 可选的 chroot、受限 shell、跳板机等附加机制

这意味着它的默认隔离往往是“同一台机器上的多用户协作式隔离”。如果 Agent 能访问某个目录、进程或网络接口，通常是因为宿主机本来就允许该用户这么做。

Docker 的隔离则建立在 Linux namespace、cgroup、capabilities、seccomp 等机制之上。虽然容器不是虚拟机，仍与宿主机共享内核，但它在工程实践中能更明确地限制：

• 可见进程范围
• 文件系统根视图
• CPU / memory 配额
• 默认网络栈与端口暴露
• 可授予或移除的 Linux capability

因此，若你关注的是“把 Agent 的可见面和可操作面缩小到最小”，Docker 通常比普通 SSH shell 更容易制度化。

三、工作区语义：目录是“现场”，还是“挂载物”？

很多团队低估了 workspace 语义的差异。

在 SSH/OpenShell 模式下，workspace 往往就是主机上的真实目录。Agent 在 /srv/project 或某个用户 home 下工作，看到的是项目当前现场：git 状态、缓存目录、未提交文件、后台服务、临时产物都是真实存在的。优点是上下文完整，尤其适合运维排障、线上同构环境排查、在已有 monorepo 上直接迭代。

Docker 下的 workspace 通常是容器内目录，但它有两种常见来源：

• 镜像内 baked-in 文件
• 从宿主机 bind mount / volume 挂载进来

这会带来一个关键差异：容器内路径是运行时视图，不一定等于宿主机原生语义。比如文件属主、换行、软链接、inotify、构建缓存、UID/GID 映射，都可能与宿主机直接 shell 工作不同。
换句话说，SSH 模式更像“在现场施工”，Docker 更像“带着工具车进入受控工位施工”。

四、状态持久化：天然持久 vs 显式持久

SSH/OpenShell 的状态天然持久。你安装一个包、改一个配置、生成一个缓存，除非显式回滚，否则它就留在那台机器上。这对于长期演进式任务非常方便：Agent 可以复用历史上下文，二次进入时几乎无缝续跑。

但它的问题也很明显：环境漂移。今天能跑，不代表明天还能复现；这台机器能跑，不代表另一台也行。

Docker 的默认哲学相反：容器实例应当是可销毁的，持久化需要显式设计，比如 volume、bind mount、对象存储、外部数据库。好处是环境更可描述、可重建、可迁移；代价是你必须提前想清楚什么该保留、什么应该丢弃。

对 Agent 来说，这决定了一个现实问题：
如果任务需要“逐步积累上下文”，SSH 很顺手；如果任务需要“每次都从干净起点执行”，Docker 更稳。

五、网络与安全边界：谁来定义出口与暴露面？

SSH/OpenShell 模式里，Agent 的网络能力通常继承宿主机：能访问哪些内网、DNS 怎么配、代理怎么走、是否能触达生产数据库，往往是主机既有属性。它的优势是接入真实企业网络方便；它的风险也是一旦权限给宽，Agent 的可达面就会随之变宽。

Docker 在这方面更适合做最小化网络面：

• 可使用独立 bridge / overlay 网络
• 可限制容器间连通性
• 可只暴露必要端口
• 可配合 egress 策略、只读根文件系统、非 root 用户运行

当然，容器并不会自动安全。--privileged、宿主机目录大范围挂载、挂 Docker socket，本质上都在削弱隔离。但在同样认真配置的前提下，Docker 通常更容易把“权限最小化”做成可复制的默认值。

六、性能与时延：不是“容器一定更慢”，而是冷启动与依赖命中不同

很多人直觉上认为 SSH 更快、Docker 更重。这个判断只对一半。

SSH/OpenShell 的优势是几乎没有冷启动成本：会话建立后即可执行，宿主机已有工具链和缓存时，命令响应会非常直接。对于频繁的小步交互、排障、脚本试跑，这种低摩擦很有价值。

Docker 的运行时开销通常并不大，真正的成本主要来自：

• 拉镜像与分发镜像
• 首次启动容器
• 容器内依赖预热
• 挂载卷与缓存命中策略

如果镜像治理做得好、缓存稳定、容器长驻，Docker 的交互性能完全可以接近原生 shell；但若每次任务都重新拉镜像、重新初始化依赖，那延迟会明显上升。

因此，短平快、强交互任务偏向 SSH；批量化、可复制、需要一致性的任务更适合 Docker。

七、可观测性与调试：SSH 更直觉，Docker 更标准化

SSH/OpenShell 的调试体验往往最好：ps、top、lsof、strace、系统日志、真实目录结构都近在眼前。对 SRE 或资深运维来说，这是“信息密度最高”的环境。

Docker 的优势则是可观测接口更标准：

• 容器日志统一收集
• 镜像版本可追踪
• 资源限制可量化
• 生命周期事件可编排
• 更容易和 CI/CD、审计、镜像扫描结合

简单说，SSH 更像专家手工台，Docker 更像流水线夹具。前者利于临场判断，后者利于规模化治理。

八、真实场景怎么选？

场景	更推荐	原因
线上故障排查、临机诊断	SSH/OpenShell	需要直接观察主机真实状态、现有进程和现场文件
在固定开发机上迭代脚本/工具	SSH/OpenShell	复用已有依赖、缓存和用户上下文，反馈最快
CI 任务、批量代码生成、自动化回归	Docker	环境一致、易复现、便于并发与回收
多租户 Agent 平台	Docker	更容易做资源隔离、权限收敛和审计
需要访问企业内网且依赖已有堡垒机策略	SSH/OpenShell	接入现有网络与权限体系更自然
需要可移植、可快照、可标准化交付	Docker	镜像即契约，迁移成本低

九、一个实用决策框架

不要问“哪个更先进”，请按下面四个问题决策：

1. 任务是面向“现场状态”还是“标准化流程”？
   前者选 SSH，后者选 Docker。

2. 你更怕环境漂移，还是更怕接入摩擦？
   怕漂移选 Docker，怕摩擦选 SSH。

3. 安全边界要靠人工纪律，还是靠默认机制？
   如果希望平台层面强约束，Docker 更合适。

4. 任务生命周期是长期驻留还是短期可销毁？
   长期积累上下文偏 SSH；短期任务、做完即回收偏 Docker。

十、结论：它们是互补关系，不是替代关系

在 OpenClaw 里，SSH/OpenShell sandbox 与 Docker container 对应的是两种不同的工程哲学。

• SSH/OpenShell：贴近真实机器、低延迟、上下文完整，适合运维现场、重交互、强依赖既有环境的任务。
• Docker：边界清晰、环境可复制、易治理，适合标准化执行、多租户平台和需要一致性的自动化任务。

如果你在搭建 Agent 基础设施，我的建议很直接：
把 SSH 看成“接入真实世界”的工具，把 Docker 看成“收敛执行边界”的工具。
前者解决贴近现场的问题，后者解决规模化与可控性的问题。成熟的 OpenClaw 部署，往往不是二选一，而是根据任务类型把两者编排在不同层级上：诊断走 SSH，批处理走 Docker，敏感任务再叠加更严格的网络与权限策略。

真正好的架构，不是统一答案，而是让每类任务都在合适的边界里运行。