“

本地运行 OpenClaw？Docker 给出了目前最安全的方案。 不是因为外面太危险——而是因为你不知道 AI 代理在你的机器上悄悄干了什么。

---

OpenClaw 是今年最火的开源 AI 编码代理之一，上线一周就在 GitHub 斩获 15 万 Star，被称为"最疯狂的 AI 编程工具"。

它能在你的本地机器上跑起来，调用大模型帮你写代码、改 Bug、执行终端命令——一条指令，一支 AI 军队。

但问题也恰恰出在这里。

OpenClaw 是一个 AI 代理。

代理意味着它会自己做决策、自己执行操作。它有能力：

• 读写你机器上的任意文件

• 发起任意网络请求

• 接触你设置的 API 密钥（Anthropic、OpenAI……）

• 执行任意 Shell 命令

当你在本地跑 OpenClaw，你实际上是把一个有相当大权限的"AI 员工"放进了自己的机器里。它越聪明，你就越需要给它画一条边界。

这不是危言耸听，这是 AI 代理时代每个开发者都该想清楚的问题。

---

近日，Docker 官方发布了一篇技术博客，标题是：Run OpenClaw Securely in Docker Sandboxes 。

核心方案是两样新东西的组合：

• Docker Sandboxes：在隔离的微型虚拟机（microVM）里运行 AI 代理

• Docker Model Runner：在本地运行 LLM 推理引擎，不需要任何云 API

两者配合，可以让 OpenClaw 在一个完全受控的沙盒环境里运行，对外世界几乎透明，但对内部主机极度隔离。

Docker 官方给出的 Slogan 很简洁：**"用大约 2 个命令，保护你的 Agent 工作流"**。

---

Docker Sandboxes 是 Docker 生态里的一种新的运行原语（primitive）。

它不是普通的容器，而是运行在 微型虚拟机（microVM） 里的隔离环境。这个区别很重要：

对比	普通容器	Docker Sandboxes（microVM）
内核隔离	共享主机内核	独立内核
网络访问	默认可访问外部	代理层控制，可拒绝任意主机
文件访问	挂载目录可读写	只能访问分配的工作区
API 密钥	需要手动管理	Sandbox 代理自动注入，代理内不可见

微VM 级别的隔离意味着什么？

OpenClaw 在 Sandbox 里运行，它能碰到的，就只有你给它的那片空间。它想访问主机文件系统？不行。它想往某个它不该去的地方发请求？代理层直接拒掉。

最关键的一点：API 密钥由 Sandbox 代理自动注入，OpenClaw 本身永远拿不到密钥原文。即使它被某种方式劫持，也无法把你的密钥泄露出去。

---

Docker Model Runner 是 Docker Desktop 里内置的本地 LLM 推理引擎，绑定在主机的 localhost:12434。

你可以直接用 docker model pull 拉取模型，比如：

docker model pull ai/gpt-oss:20B-UD-Q4_K_XL

也支持 Qwen、Llama 等主流开源模型。

用 Docker Model Runner 跑 OpenClaw，意味着：

• 无 API 费用：模型跑在本地，按 Token 计费这件事彻底消失

• 完全私有：代码和 Prompt 从不离开你的机器

• 网络独立：不需要连接任何外部服务

当然，如果你需要更强的模型能力，也可以无缝切换到云端的 Anthropic 或 OpenAI——Sandbox 代理会自动注入密钥，你不需要改任何配置。

---

Docker 提供了一个预构建的镜像：olegselajev241/openclaw-dmr:latest，里面已经打包好了 Node.js 22、OpenClaw 和网络桥接脚本。

完整流程，真的很简单：

第一步：在 Docker Desktop 设置里启用 Docker Model Runner，然后拉取模型：

docker model pull ai/gpt-oss:20B-UD-Q4_K_XL

第二步：创建 Sandbox：

docker sandbox create --name openclaw -t olegselajev241/openclaw-dmr:latest shell .

第三步：配置网络代理（允许 Sandbox 访问主机上的 Model Runner）：

docker sandbox network proxy openclaw --allow-host localhost

第四步：运行：

docker sandbox run openclaw

进入 Sandbox 后，执行 ~/start-openclaw.sh 就可以了。

这个启动脚本会自动发现 Docker Model Runner 里可用的模型，列出来让你选。

---

这里有个稍微有趣的技术细节，值得说一下。

Docker Model Runner 跑在主机的 localhost:12434，但 Sandbox 内部的 localhost 指向的是 Sandbox 自己，不是主机。

OpenClaw 基于 Node.js，而 Node.js 并不遵循 HTTP_PROXY 环境变量（这是 Node.js 的一个老问题）。

所以 Docker 的方案里有一个约 20 行的桥接脚本，构造了这样一条通路：

OpenClaw
  ↓ 请求
本地桥接（127.0.0.1:54321）
  ↓ 转发
Sandbox 网络代理（host.docker.internal:3128）
  ↓ 路由
Docker Model Runner（主机 localhost:12434）

这个设计让网络控制权始终在代理层，OpenClaw 只能通过这条有限的通路与外部通信，不能自己乱发请求。

---

如果你不想用预构建镜像，或者想集成自己的工具链，Docker 也提供了完整的自建流程：

1. 创建基础 Sandbox，手动安装 Node.js 22 和 OpenClaw

2. 写入桥接脚本

3. 修改 OpenClaw 配置文件，指向本地 Model Runner 的 API 地址

4. 用 docker sandbox save 保存为可复用镜像

5. 推送到 Registry，团队成员一个命令拉起来

对于需要在团队里统一开发环境的场景，这个方案很实用：每个人的 Sandbox 镜像一致，密钥由各自的主机环境注入，互不干扰。

---

说到底，Docker 这次做的事情，不只是"给 OpenClaw 套个壳"。

它在尝试回答一个更根本的问题：当 AI 代理开始在本地机器上自主执行任务，我们该如何管理它的权限边界？

过去，这件事全靠开发者的自觉——你把 ANTHROPIC_API_KEY 写进 .env，你自己保证这个文件不会被代理泄露；你知道代理会读写哪些目录，你信任它不会越界。

Docker Sandboxes 提供的是一种结构性的约束：

• 文件访问被硬限制在工作区

• 网络请求经过代理层过滤

• API 密钥从不暴露给代理本身

这不是"信任 AI 代理"，而是"给 AI 代理设定可验证的边界"。

随着 AI 代理越来越多地进入本地开发流程，这个问题会越来越重要。Docker 这次的方案，至少是一个思路清晰、工程落地扎实的起点。

---

OpenClaw 很强，也确实有潜在的风险面——不是它"坏"，而是任何能自主执行操作的代理，都需要一个合理的权限边界。

---

参考资料：Run OpenClaw Securely in Docker Sandboxes | Docker Blog

热点推荐

• 杠上了！Vercel 盯着 Cloudflare 新框架找出 7 个漏洞、迁移指南

• NestJS v12 将迎来重大更新：全量 ESM、Vitest 上位、Zod 直连，老项目还能平滑升级？

• 多 Agent 全面并行干活！Claude Code 原生支持 Git Worktree，尤雨溪开了场「赛博斗蛐蛐」

• 再见 Electron！Electrobun 重磅发布！

• 2026 AI 编程将发生巨变！

• 终于等到！Draw.io 官方发布 MCP，这体验丝滑得不像话！