VMware虚拟机部署OpenClaw：Ubuntu下AI代理与多模型接入指南

折腾OpenClaw这个开源AI代理，是我最近做得最上头的一件事。先说结论：在Ubuntu虚拟机里部署OpenClaw，难度真不大，真正让人崩溃的是访问链路和模型配置这一串连环坑。宿主机死活连不上虚拟机里的服务、模型API各种报错、权限文件不认账，每一个都能卡你半天。这篇文章把我从零到一完整走过的路都记下来了，包括VMware里装Ubuntu、OpenClaw本体部署、本地浏览器访问配置、Claude/千问/DeepSeek/本地模型的多后端接入方案，以及我在NVIDIA NIM上的一次失败尝试。如果你也想在Windows宿主机上跑一个私有AI助手，并且希望它既能连云端模型、又能在没有公网API的时候切到本地模型，这篇文章应该能帮你省下至少一个周末。

1. 环境准备：虚拟机与Ubuntu安装

1.1 为什么我用虚拟机而不是直接装在物理机上

OpenClaw这类AI Agent工具，核心能力是让模型能主动操作电脑：写文件、跑命令、调用工具、自动化处理任务。这种“能动手”的特性本身就意味着它需要较高的执行权限，而这种权限在物理机上直接放开是有风险的。

举个例子，我最初在Windows宿主机上试过直接跑OpenClaw，结果它执行一条清理临时文件的命令时，差点把我一个重要目录里的缓存文件全删了。从那以后我就养成了习惯：所有带自动执行能力的Agent，一律丢到虚拟机里隔离运行。

虚拟机带来的几个直接好处：

• 快照回滚。装坏了、配置乱了，一条命令回到初始状态，比手工排查快得多。
• 环境隔离。虚拟机内部随便折腾，删库跑路也不影响宿主机。
• 环境一致性。Ubuntu比Windows更适合跑这类服务，依赖问题少，systemd管理服务也方便。
• 资源可控。给虚拟机分配多少CPU内存自己说了算，不会因为某个服务失控拖垮整台主力机。

如果你只是想在Windows上简单体验一下OpenClaw，PowerShell安装也支持，但我实测下来，Windows端的路径权限和防火墙弹窗比Linux麻烦不少，而且OpenClaw的很多工具调用在Linux环境下跑得更顺畅。所以我的建议很明确：用虚拟机跑Ubuntu，再在上面部署OpenClaw，是这个项目最省心的组合。

1.2 VMware Workstation Pro + Ubuntu 24.04 LTS配置建议

宿主机是Windows的话，虚拟机方案首推VMware Workstation Pro。现在VMware Workstation Pro对个人用户已经免费了，直接去官网注册一个个人账号就能拿到正版许可，没必要再用什么精简版、绿色版。

Ubuntu版本我强烈建议选24.04 LTS，别追新。网上搜“Ubuntu 26.04”之类的热词，多半是版本号写错了，目前真正的LTS主线还是24.04和22.04。做服务器用途，稳定压倒一切，LTS版本有长期安全更新，社区资料也最多，踩了坑搜得到答案。

我的虚拟机资源配置如下，目前跑OpenClaw加Ollama本地模型刚好够用：

安装Ubuntu时有一点要注意：在VMware创建虚拟机向导里，镜像文件选好24.04的ISO后，客户机操作系统类型要手动选“Ubuntu 64位”，别让它自动识别成别的版本。分配磁盘时选“将虚拟磁盘存储为单个文件”，性能稍微好一点，迁移也方便。

1.3 装系统阶段最容易让人摔跤的三个地方

第一阶段有三个高频报错，我在不同机器上都遇见过，这里一起说了。

第一个是“客户机操作系统已禁用CPU”。打开虚拟机电源直接弹这个，大概率是没开启CPU虚拟化。解决方法是：先关掉虚拟机，右键虚拟机设置，在“处理器”选项卡里勾选“虚拟化引擎”下方的“虚拟化Intel VT-x/AMD-V”，然后重启虚拟机。如果依然报错，那就要去宿主机BIOS里确认Intel VT-x或AMD-V功能是否处于开启状态，这两个开关是嵌套虚拟化的前提。

第二个是“VMware Workstation无法连接到虚拟机。请确保您有权运行该程序、访问该程序使用”。这个报错常见于VMware版本升级之后，或者虚拟机的vmx文件被移动过位置。处理步骤是：以管理员身份重新运行VMware Workstation，然后在“编辑-首选项-工作区”里把默认虚拟机目录重置到正确位置，再打开虚拟机。如果还不行，把VMware的授权服务重启一下，Windows服务管理器里找“VMware Authorization Service”，右键重启。

第三个是“虚拟机安装Linux蓝屏”。Linux系统本身很少蓝屏，出现这个多半是VMware的3D加速图形驱动和Ubuntu默认桌面环境冲突。我的一台AMD显卡机器上开3D加速装Ubuntu 24.04，装到一半就花屏重启。解决办法很简单：虚拟机设置里把“加速3D图形”取消勾选，用默认显示模式重新安装，装完再开图形加速，问题就不会复现了。

系统装好之后，先把软件源换成国内镜像，不然apt下载能慢到怀疑人生。然后顺手把open-vm-tools装上，用于剪贴板共享和窗口自适应：

bash复制sudo apt update && sudo apt upgrade -y
sudo apt install -y open-vm-tools open-vm-tools-desktop

如果你习惯用搜狗输入法，去官网下deb包安装时大概率会遇到依赖缺失，一条sudo apt -f install就能修好，这个也是老传统了。另外Ubuntu默认不设置root密码，要切换到超级管理员执行sudo -i或者sudo su即可，不需要单独设密码，网上那些讲“Ubuntu 26.04切换超级管理员”的内容，核心也就是这两条命令。

2. OpenClaw主体部署

2.1 先搞清楚OpenClaw到底是什么

OpenClaw是一款开源的、能主动干活的AI代理框架。和你平时用的聊天机器人不一样，它不仅仅是“回答问题”，而是能基于任务目标自己调用工具、读写文件、执行命令、编排工作流。你可以把它理解成一个会干活的下属，你给它布置任务，它自己拆解、自己动手、最后给你交付结果。

它和Claude Desktop有一些理念上的相似之处，都是把模型能力和本机工具能力打通，但OpenClaw是纯命令行加Web UI的形态，跑在服务器或者虚拟机上更合适。它天然支持各种模型后端：Anthropic的Claude、OpenAI兼容接口的各家模型，以及本地推理服务都能接入。这个“模型后端可插拔”的架构是它最值钱的地方——意味着你不必绑死在一家模型厂商身上。

我在虚拟机上部署它，核心诉求是：让这个Agent能在Ubuntu环境里自由操作文件系统、跑脚本、做自动化任务，同时通过浏览器从宿主机访问它的Web面板，随时查看任务状态和结果。

2.2 Ubuntu下安装与初始化

OpenClaw的安装流程比较简单。官方推荐的是命令行一键安装，在Ubuntu终端里执行文档给出的安装脚本，它会自动下载二进制文件并写入~/.openclaw目录。整个安装过程主要做三件事：

• 下载OpenClaw主程序，放到~/.openclaw/bin目录
• 创建默认配置文件~/.openclaw/config.yml
• 初始化本地数据目录，存放运行状态和日志

安装完成后，命令行会提示你运行初始化命令。首次初始化会要求你填写模型供应商信息，这一步可以选Claude，也可以直接跳过，后面再通过改配置接入别的模型。我建议先跳过，因为后续我们要接的后端不止一个，等会儿统一写在配置文件里更清爽。

安装后的目录结构大概是这样的：

text复制~/.openclaw/
├── bin/                  # 主程序
├── config.yml            # 配置文件
├── exec-approvals.json   # 命令执行批准记录
├── sessions/             # 会话数据
├── logs/                 # 运行日志
└── skills/               # 技能插件目录

这里要提醒一个很多人忽略的点：如果当前用户不是root，安装完成后未必能直接让OpenClaw读取配置目录。我一开始用普通用户安装、用sudo启动服务，结果服务读取的配置目录是/root/.openclaw，和我普通用户下的配置完全是两套，折腾了半天才发现。解决办法是明确指定用户，安装、配置、启动全流程都用同一个用户身份来做，不要混用root和普通用户。

2.3 权限批准机制：exec-approvals.json的坑

OpenClaw为了让模型安全地执行系统命令，内置了一套命令执行审批机制。关键词是“exec-approvals”：当Agent要执行一条命令时，它会先查这个批准记录文件，如果命令不在白名单里，就需要人手工确认；确认之后会写入exec-approvals.json，下次同类命令就不再询问。

这套机制本身设计得很合理，但版本升级时很容易踩坑。我遇到过一条非常典型的报错：

text复制legacy exec approvals exist at /root/.openclaw/exec-approvals.json. run `ope...

大意是说检测到了旧版本生成的批准文件，新版OpenClaw不认这个格式，让你手动跑一个命令去迁移。我当时不知道该怎么处理，直接把这个文件删了，结果之前所有确认过的命令权限全部失效，Agent每执行一条命令都卡在审批环节，体验非常糟心。

正确做法是：先备份旧文件，再运行提示里的迁移命令，让新版工具自己把旧格式转换成新格式。如果忘记了那条迁移命令叫什么，也可以把旧文件挪走，让服务重新生成空白的批准文件，再把之前确认过的命令重新批一遍。虽然麻烦点，但总比删库跑路强。

这个文件在日常使用中还会越来越庞杂，建议每隔一段时间进去清理一下，把大量重复的、不常见的命令条目清掉，保持审批列表干净。

2.4 用systemd把OpenClaw变成常驻服务

OpenClaw是长期运行的守护进程，不可能一直开着终端窗口。在Ubuntu下最标准的做法是注册成systemd服务，让它开机自启、崩溃自动重启、日志统一管理。

我在/etc/systemd/system/openclaw.service里写了一个服务单元：

ini复制[Unit]
Description=OpenClaw AI Agent
After=network.target

[Service]
User=你的用户名
WorkingDirectory=/home/你的用户名
ExecStart=/home/你的用户名/.openclaw/bin/openclaw serve
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

注意ExecStart的路径要写成你实际安装目录下的openclaw serve子命令，具体子命令名称以你当前版本的帮助输出为准。写完之后执行：

bash复制sudo systemctl daemon-reload
sudo systemctl enable --now openclaw
sudo systemctl status openclaw

看到active (running)就说明服务起来了。后续看日志我用journalctl -u openclaw -f，比去翻文件方便十倍。

注册成服务后还有个好处：如果服务启动失败，systemd会按RestartSec设定的间隔反复拉起，不会因为一次偶然的网络抖动就把整个Agent搞挂。这个就比裸终端跑稳太多了。

3. 本地访问打通

3.1 NAT还是桥接：先决定网络策略

虚拟机装好、OpenClaw也跑起来了，接下来就是“本地访问”这个关卡。这部分的本质是：宿主机上打开浏览器，能不能访问到虚拟机里OpenClaw的Web UI。

VMware虚拟机的网络模式我建议直接用NAT，别一上来就折腾桥接。NAT模式下虚拟机共享宿主机IP出口，对内对外都不暴露独立IP，安全性更好，而且通过端口转发就能实现宿主机访问虚拟机服务，链路最短。

桥接模式虽然能让虚拟机像一台独立机器一样出现在局域网里，但你需要额外处理路由器设置、宿主机防火墙、局域网安全一堆问题。除非你是要在真实服务器上跑OpenClaw，否则开发调试阶段NAT完全够用，后面需要桥接再切换也不迟。

3.2 端口转发配置实操

NAT模式下的端口转发，是在VMware的虚拟网络编辑器里配置的。具体操作如下：

打开VMware Workstation，菜单栏“编辑-虚拟网络编辑器”，窗口里选中VMnet8（NAT模式的虚拟网卡），点“NAT设置”，在弹出的对话框底部找到端口转发列表，点“添加”按钮。

这里要填三个东西：

• 宿主机端口：宿主机的Windows上监听哪个端口，比如3456
• 虚拟机IP地址：在Ubuntu里用ip addr查，通常类似192.168.100.128
• 虚拟机端口：OpenClaw Web UI监听的端口，我这里统一按8000来写

保存之后，从宿主机浏览器访问http://localhost:3456，如果一切顺利，就能看到OpenClaw的Web界面了。

这一步最常见的坑是：转发配好了，宿主机还是打不开页面。多半是虚拟机里的OpenClaw服务只监听了127.0.0.1，没有监听对外网卡。检查方法是在虚拟机里执行：

bash复制ss -tlnp | grep 8000

如果看到监听地址是127.0.0.1:8000，那外部转发永远进不来。这时候去配置文件里把服务监听地址改成0.0.0.0，重启服务再验证：

yaml复制server:
  host: 0.0.0.0
  port: 8000

改完之后再执行ss -tlnp，监听地址变成0.0.0.0:8000才算生效。这个细节卡了我快半小时，后来想想其实原理很简单：端口转发只负责把宿主机流量导到虚拟机网卡，如果虚拟机里的服务自己把自己关在回环接口上，那谁也进不去。

3.3 防火墙和监听地址，缺一不可

除了监听地址，虚拟机的防火墙也可能把宿主机来的流量拦在外面。Ubuntu桌面版默认不开ufw，但如果你手痒开过，记得放行端口：

bash复制sudo ufw allow 8000/tcp
sudo ufw reload

我自己还试过一种更容易忽略的场景：OpenClaw服务放在虚拟机里跑，但Web面板长时间不操作会断开连接。这是因为服务端的WebSocket保活机制超时时间设得短。这不算bug，但日常使用体验很割裂。如果遇到频繁断线，去配置文件里把连接超时时间调大，或者在浏览器侧用自动化刷新脚本兜底，都可以。我目前的做法是直接把超时时间从默认值调到了一小时，足够覆盖我日常的使用频繁度。

4. 模型配置一站式实操

4.1 先理解OpenClaw的模型对接逻辑

OpenClaw本身不包含模型，它只是一个API客户端。模型配置的本质，就是告诉它三件事：模型供应商是谁、API地址在哪、用哪个模型名。

现代模型服务的接口已经高度标准化了。Anthropic有自己的一套消息协议，而其他绝大多数服务——千问的DashScope、DeepSeek、Ollama、NVIDIA NIM、LM Studio——都实现了OpenAI兼容的/v1/chat/completions接口。所以在OpenClaw的配置文件里，你只需要指定provider、api_key、base_url、model四个字段，就能把模型后端换来换去。

理解了这个逻辑，后面所有配置就都顺理成章了。

4.2 配置Claude官方API

OpenClaw对Claude的支持是最原生、最完整的，因为它核心的工具调用能力就是围绕Anthropic的接口设计的。用官方API配置最省心。

在~/.openclaw/config.yml里写入：

yaml复制model:
  provider: anthropic
  model: claude-sonnet-4-xxxxx  # 以你账号实际可用的型号为准
  api_key: sk-ant-xxxxxxxxxxxx

API Key在Anthropic控制台生成，环境变量方式export ANTHROPIC_API_KEY=sk-ant-xxx也同样生效。

用Claude官方API的好处是工具调用稳定，复杂任务不出幺蛾子。坏处也很直白：国内网络环境访问它的API经常超时或者返回不稳定，尤其是长任务执行到一半突然断掉，真的很抓狂。如果你只依赖Claude官方API，整套系统的可用性就全押在通路上，一旦不通，Agent就直接躺平。这也是我后来坚持要配多套模型后端的原因——鸡蛋不能放在一个篮子里。

4.3 CC Switch与千问等第三方模型接入

这里要先把一个概念理清楚：CC Switch是给宿主机上Claude Desktop用的开源工具，它的作用是可视化地把Claude Desktop的模型连接切换到第三方供应商，比如千问、DeepSeek。你要在Claude Desktop里体验千问模型，就给Claude Desktop配CCSwitch；你要让虚拟机里的OpenClaw用千问模型，直接改OpenClaw自己的配置文件更直接，不需要经过CC Switch。

千问（通义千问）目前提供了OpenAI兼容的调用端点，OpenClaw配置如下：

yaml复制model:
  provider: openai
  base_url: "https://dashscope.aliyuncs.com/compatible-mode/v1"
  api_key: sk-你的千问APIKey
  model: qwen-plus

model字段可以选qwen-max、qwen-plus、qwen-turbo，具体以你在阿里云百炼控制台开通的模型为准。这套配置和OpenAI官方API的格式几乎一样，只是把base_url换成了千问的兼容端点。DeepSeek同理，把base_url换成https://api.deepseek.com/v1，模型名写deepseek-chat就能用。

我把这三家的模型都实测过一轮，直接说结论：

日常主力我用千问，成本可控、调用稳定；需要复杂工具编排的深度任务切回Claude；简单文本处理用DeepSeek。这个组合在成本、稳定性、能力三者之间是比较均衡的。

4.4 Ollama部署本地DeepSeek-R1 7B

本地模型的价值在于：不依赖任何云端API，断网也能用，数据不出虚拟机，隐私友好。在虚拟机上跑本地模型，我选的是Ollama加DeepSeek-R1 7B的组合。

先安装Ollama，官方脚本一条命令：

bash复制curl -fsSL https://ollama.com/install.sh | sh

然后拉取模型：

bash复制ollama pull deepseek-r1:7b

7B模型文件大概4.7GB，取决于网络情况可能要等一阵。拉完之后Ollama会在后台自动监听127.0.0.1:11434，OpenClaw侧配置指向这个地址就行：

yaml复制model:
  provider: openai
  base_url: "http://127.0.0.1:11434/v1"
  api_key: ollama  # 本地服务不校验，填任意非空值即可
  model: deepseek-r1:7b

有两个坑必须提醒。

第一，本地模型跑在CPU上，速度慢得惊人。4核CPU跑DeepSeek-R1 7B，一个复杂问题从开始思考到输出完整回答，可能要好几分钟。如果你只有4核8GB的虚拟机配置，建议把任务拆小，或者忍受它的慢节奏。想要流畅跑7B模型，物理机的16GB内存起步，虚拟机内分配的内存也别低于8GB。

第二，模型名必须带版本标签。很多人配完报model not found，就是把deepseek-r1:7b写成了deepseek-r1。这个坑我踩得刻骨铭心，因为Ollama的模型名机制要求完整标签才能匹配到本地已有模型，少写一个冒号后半段就找不到了。

4.5 NVIDIA NIM接入尝试与放弃

搜索热词里有人问“openclaw配置nvidia nim”，这个我也专门试过。NVIDIA NIM是NVIDIA出的推理微服务方案，把Llama、Qwen这类开源模型封装成OpenAI兼容API，用Docker一键起服务，理论上和OpenClaw对接也很容易，只需要把base_url指向NIM服务地址。

我当时的计划是用NIM在虚拟机上跑一个小模型作为备用后端。但实际操作中遇到了一个硬伤：NIM的推理容器依赖NVIDIA GPU，虚拟机上如果没有做GPU直通（GPU Passthrough），容器根本起不来。我的主力机器是NVIDIA显卡，但VMware下的GPU直通配置繁琐，笔记本平台还经常不支持，折腾了一晚上没搞定，最后放弃了NIM，改用了Ollama。

如果你的服务器是纯Linux物理机加NVIDIA GPU，NIM是值得考虑的方案，它有官方优化，推理性能比Ollama在CPU上跑强太多；但如果你的环境是虚拟机，我的建议是趁早放弃NIM，老老实实用Ollama或者LM Studio这类CPU也能扛的本地推理方案。

5. 常见报错速查表

这几天的踩坑过程，我把遇到的所有问题整理成了三张速查表，按层级分类，方便你按图索骥。

5.1 VMware与Ubuntu层

5.2 OpenClaw运行层

5.3 模型连接层

这套排查思路其实不止适用于OpenClaw，任何接本地模型的应用逻辑都相通：先确认服务端在跑、再确认端口通、最后确认模型名和接口格式一致。按这个顺序排查，90%的“请确认模型配置”都能解决。

最后再分享一个小经验：虚拟机里跑OpenClaw这套组合，最稳的状态是把所有配置固化下来，然后做一个干净的虚拟机快照。快照里预置好已经批准的权限列表、配好的多套模型后端、Ollama加上DeepSeek-R1本地模型。这样哪天配置弄乱了，直接回滚快照，几分钟就恢复到一个可用的状态，不用再从头踩一遍这些坑。我的这个快照现在就是我的AI Agent开发基准盘，省下的时间远超当初做配置的那一下午。