“本地运行 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 也提供了完整的自建流程：
创建基础 Sandbox，手动安装 Node.js 22 和 OpenClaw
写入桥接脚本
修改 OpenClaw 配置文件，指向本地 Model Runner 的 API 地址
用
docker sandbox save保存为可复用镜像推送到 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，这体验丝滑得不像话！
