OpenClaw 里该选 SSH/OpenShell Sandbox还是 Docker Container一篇讲透隔离、状态与运维代价在 OpenClaw 这类 Agent 运行框架里“执行环境”不是实现细节而是系统设计的一部分。你让 Agent 去读代码、改文件、跑命令、访问网络、调试服务时背后必须回答一个问题它到底运行在什么边界里工程上常见的两条路线是OpenShell / SSH sandboxAgent 通过 shell 会话进入一个已有主机环境直接在该环境中执行命令。Docker containerAgent 被约束在一个容器镜像与容器实例内文件系统、进程视图和网络策略通常都更可控。这两种方式都能“跑起来”但它们在隔离、状态、可复现性、调试方式和运维成本上差异极大。对有经验的 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镜像即契约迁移成本低九、一个实用决策框架不要问“哪个更先进”请按下面四个问题决策任务是面向“现场状态”还是“标准化流程”前者选 SSH后者选 Docker。你更怕环境漂移还是更怕接入摩擦怕漂移选 Docker怕摩擦选 SSH。安全边界要靠人工纪律还是靠默认机制如果希望平台层面强约束Docker 更合适。任务生命周期是长期驻留还是短期可销毁长期积累上下文偏 SSH短期任务、做完即回收偏 Docker。十、结论它们是互补关系不是替代关系在 OpenClaw 里SSH/OpenShell sandbox 与 Docker container 对应的是两种不同的工程哲学。SSH/OpenShell贴近真实机器、低延迟、上下文完整适合运维现场、重交互、强依赖既有环境的任务。Docker边界清晰、环境可复制、易治理适合标准化执行、多租户平台和需要一致性的自动化任务。如果你在搭建 Agent 基础设施我的建议很直接把 SSH 看成“接入真实世界”的工具把 Docker 看成“收敛执行边界”的工具。前者解决贴近现场的问题后者解决规模化与可控性的问题。成熟的 OpenClaw 部署往往不是二选一而是根据任务类型把两者编排在不同层级上诊断走 SSH批处理走 Docker敏感任务再叠加更严格的网络与权限策略。真正好的架构不是统一答案而是让每类任务都在合适的边界里运行。