OpenClaw 这类 Agent 工具最近热度上升得很快，尤其是本地部署个人助理、接入 Teams 和 Obsidian 这些玩法，很多教程一上来就让你在主力电脑上直接开工。我看完项目 README 的第一反应，反而是先去找一台 Win11 虚拟机来承载它——原因很简单：OpenClaw 在本地会创建服务、监听端口、大量读写会话文件，还会频繁拉取依赖更新，稍不注意就能把工作电脑的环境搅得一团糟。
这篇文章想完整记录的就是这条路线：用 VMware 开一台 Win11 虚拟机，在虚拟机里完成 OpenClaw 的安装、配置、验证，甚至长期挂机。核心收益是“不污染主力工作电脑”，并且所有折腾都能通过快照一键回滚。适合想尝鲜 Agent 工具又不想牺牲工作环境稳定性的人，也适合公司安全策略比较严、不允许随便往办公电脑装软件的开发者。如果你只是想在系统里“跑起来看看”，这套方案能把风险完全锁在虚拟机内部；要是你打算长期让它做自动化，这套环境的日常维护成本也远低于直接在物理机上裸奔。
1. 为什么把 OpenClaw 放进虚拟机而不是直接装在物理机
1.1 你嘴上说的“跑一下”，实际会把系统翻个底朝天
我没有夸张。类似 OpenClaw 这样的 Agent 工具，在安装和运行阶段会做下面这些事情：
- 在用户目录下创建配置文件和多个会话目录，一段对话就是一份 JSONL 记录，来回聊几十轮就是几十上百个文件。
- 注册后台进程或定时任务，用来接收消息、处理回调。
- 监听本地端口。接入 Teams 这类外部通道时，通常要求本地服务能收到消息回调，端口一旦打开，就可能被安全软件盯上。
- 拉取依赖和模型接口。OpenAI 兼容接口、各类 SDK、本地模型，每次升级都可能重新下载几百 MB 甚至上 GB 的内容。
- 持续写日志。Windows 事件日志、WSL 日志、Docker 日志，排查问题时你会看到它频繁活动。
这些动作放在个人娱乐电脑上可能无所谓，但在主力工作电脑上就是“污染”。公司终端安全软件大概率会把未知服务的端口监听和定时行为标记成风险；系统启动速度和磁盘占用也会肉眼可见地变差；最麻烦的是卸载不干净，你测试完不想要了，删掉主目录未必能清掉所有线索。
我并不是否定 Agent 工具本身，只是它默认是给“可以随时折腾的机器”准备的，而不是给“唯一生产力工具”准备的。虚拟机的存在意义，就是把这两件事分开。
1.2 虚拟机隔离带来的三层保护
用 VMware 开一台 Win11 虚拟机来装 OpenClaw，等于做了三层隔离。
第一层是系统层隔离。虚拟机里有独立的注册表、服务列表、文件系统和用户配置。Agent 在虚拟机里随便折腾，宿主机的工作软件和系统配置毫发无损。
第二层是网络层隔离。默认 NAT 模式下，虚拟机访问外网走宿主机的地址转换，虚拟机里监听的端口不会直接暴露到宿主机局域网。对 Teams 回调、Webhook 这些场景来说，这个隔离级别够用，同时也不影响你验证联通性。
第三层是数据层隔离。OpenClaw 生成的会话数据、拉取的模型缓存、日志，全部留在虚拟磁盘里。就算 Agent 因为配置错误开始乱写文件，影响范围也仅限于虚拟磁盘。再加上快照能力，你完全可以在每次大动作之前存个档，出问题直接退回去。
1.3 这套方案适合谁，不适合谁
适合的人群其实很明确：
- 电脑有虚拟化条件，想体验 Agent 工作流，但对系统洁癖很强的人。
- 在企业电脑上受限，但手上有个人 Windows 环境，想做一个不溅到工作环境的实验场。
- 希望把风险控制在“删掉虚拟机”这个选项里的开发者。
不适合的人群也有一些。如果你追求最好的性能和最低延迟，虚拟机毕竟有虚拟化开销，内存和磁盘 I/O 都会打折扣；如果电脑物理内存只有 8GB 甚至更少，Win11 虚拟机加 Docker 再加 Agent 可能会比较吃紧，建议至少 8GB 起步，16GB 才会舒服。
虚拟化不是万能的，它牺牲一点性能，换来的是“随便折腾的自由”。这笔交易我觉得非常值。
2. 从 ISO 到可用的 Win11：VMware 搭建实录
2.1 需要准备的东西
我这次用的是宿主机上装 VMware Workstation 17 Pro，虚拟机里装 Windows 11 专业版。VMware 版本不要求太新，Workstation Player 免费版也能建虚拟机，但在快照和并发虚拟机上限制比较多，而快照对 OpenClaw 这种反复调试的场景太重要了，所以我建议有条件直接用 Pro 版，或者找一个能稳定支持快照的版本。
镜像方面，直接去微软官方渠道下载 Win11 ISO。别看那些第三方压缩包，谁也不知道里面被塞了什么。建议选专业版，因为安装流程里可以跳过强制联网，家庭版在虚拟机里有时会卡在联网登录这步，比较烦。微软官方页面会提供最新版本的 ISO 下载，下载时选择“Windows 11 多版本 ISO”即可。
硬件方面有两个前提：一是物理机的 CPU 要在 BIOS 或 UEFI 里开启 VT-x/AMD-V 虚拟化；二是物理内存建议 16GB 以上，磁盘剩余空间至少要留 100GB，因为 Win11 虚拟机加上 Docker 和 Agent 本身的数据，增长非常快。
2.2 创建虚拟机时的关键配置项，别偷懒
新建虚拟机时，有几个参数我建议不要用默认值。
客户机操作系统选 Windows x64，版本选 Windows 11。固件类型一定要选 UEFI，Win11 安装阶段会强制要求 UEFI 和安全启动。内存最低给 8GB，我给到 8GB 起步，有条件就 12GB。处理器至少 4 核，我一般给 6 核，如果宿主机核心数不多，4 核也够用。磁盘容量建议直接给到 90GB，不要按 Win11 的最低 64GB 来，因为后面 WSL 和 Docker 镜像会吃掉很大一块。
几乎所有人都容易漏掉的一步是“加密此虚拟机”。VMware Workstation 的 Trusted Platform Module 设备依赖虚拟机加密，不先勾选加密就看不到 TPM 选项。Win11 安装程序检测不到 TPM 的时候，会直接卡在“这台电脑无法运行 Windows 11”，这一步在创建阶段绕过远比安装到一半再来补救省事。
网络类型选 NAT 就行。桥接模式虽然更像真实环境，但会让虚拟机直接暴露在局域网里，没有必要。
创建完成后，挂载 ISO，启动虚拟机，正常进入 Win11 安装程序。因为我们在虚拟机上启用了 vTPM，TPM 检查会顺利通过，不会卡住。如果你用的是比较老的 VMware 版本，实在没有 vTPM 选项，安装界面才需要走一些绕过的办法。我建议还是优先升级 VMware 并开启 vTPM，维持“干净可复现”的路径，而不是靠各种注册表技巧去骗过安装程序。
2.3 Win11 安装后的系统瘦身与必备软件
装完系统之后，我还会做三件事。
第一，安装 VMware Tools。这一步直接决定鼠标能不能顺畅移出移入、剪贴板能不能共享、命令能不能方便地复制粘贴。没有 VMware Tools，后面操作会非常难受。
第二，关掉 Windows 自动更新。虚拟机里的系统更新往往是性能波动的最大来源，而且我们并不需要它自动改系统状态。设置里暂停更新，或者用组策略禁用自动更新，都能达到目的。
第三，把终端和常用工具准备好。后面会有大量命令需要在 PowerShell 和 WSL 里粘贴执行，Windows 11 自带的 Windows Terminal 就够用，不用额外装太多东西。
另外说一句，Win11 安装过程中如果卡在联网这一步，专业版会提供“我没有 Internet 连接”选项；如果你用的是家庭版，可以在进入联网页面前按 Shift+F10 调出命令行，输入OOBE\BYPASSNRO并重启，就能跳过联网要求。这个技巧在测试虚拟机里非常实用。
3. 在 Win11 虚拟机里准备 Linux 运行时：WSL2 与 Docker
3.1 为什么 OpenClaw 需要 Linux 运行时
OpenClaw 这类工具原生面向 Linux 环境。在 Win11 里要跑起来，通常是两条路：要么通过 WSL2 安装一个 Linux 发行版，直接在里面跑；要么通过 Docker Desktop，把 Agent 装进容器跑。WSL2 是底层，Docker Desktop 在 WSL2 之上提供容器管理。
我的选择是：Docker Desktop 加 WSL2 后端，同时装一个 Ubuntu 发行版用于命令行操作。原因有两点。
第一，Docker 方式隔离性更彻底，主机上的软件依赖不会和 Agent 的依赖混在一起。第二，Docker 的镜像、容器、数据卷语义非常清晰，启动、停止、删除都是一行命令的事，非常适合在虚拟机里反复验证。如果直接装 Ubuntu 来跑，当然可行，但手动管理 Node.js 环境、进程自启、日志轮转，维护成本会高不少。在虚拟机里，我优先追求可控和可回滚，Docker 的优势正好在这里。
3.2 安装 WSL2 与 Docker Desktop 的操作记录
在管理员 PowerShell 里执行：
wsl --install重启之后，系统会默认使用 WSL2 并装好 Ubuntu。为了确保版本一致，可以再执行一次：
wsl --set-default-version 2然后安装 Docker Desktop。安装时勾选“Use WSL 2 based engine”，它会自动创建docker-desktop和docker-desktop-data两个 WSL 发行版。安装完成后打开终端验证：
docker run --rm hello-world能弹出 “Hello from Docker” 就说明后端通了。
如果你不想用 Docker Desktop，只靠 WSL2 也能跑 OpenClaw，但那样需要手动安装所有依赖，还要自己做开机自启和日志管理。不是不行，是步骤多、出错概率高。
3.3 磁盘位置与性能踩过的坑
WSL2 默认把虚拟硬盘放在 C 盘用户目录下，Docker Desktop 的数据同样也在 C 盘。如果虚拟机系统盘只给了 80GB，用不了几天就会被镜像塞满。我的做法是给虚拟机加了一块单独的虚拟磁盘，标记为 D 盘，然后把 Docker 数据迁过去。
具体操作有两种路径：一种是在 Docker Desktop 的 “Resources > Disk image location” 里直接改路径；另一种是用wsl --manage docker-desktop-data --move D:\DockerData命令迁移。实测从 C 盘换到 D 盘后，IOPS 会受虚拟磁盘性能影响，但换回来的是系统盘不爆炸，完全值得。
还有一个性能相关的小细节：在虚拟机设置里手动固定 CPU 和内存，比“自动”模式稳定得多。VMware 的自动分配模式偶尔会在 Agent 加载模型时出现明显顿挫，手动固定为 8GB 内存、4 核之后，体验平稳很多。
4. OpenClaw 安装：从一键脚本到配置文件
4.1 先厘清项目身份
OpenClaw 是开源的 Agent 框架，可以简单理解为 Clawdbot/Moltbot 衍生出的一个活跃分支。定位是“你随时可以喊话的个人助理”，能通过聊天渠道下达任务、查资料、整理笔记，甚至维护 Obsidian 知识库。和 WorkBuddy 这类托管型助理相比，OpenClaw 最大的特点是自托管、开源，数据都在自己手里，你能随意改配置、接自己的模型、定制行为。也正因为如此，社区里才出现各种一键部署脚本，热度上升得很快。
如果你以后想把它长期挂机，也可以把这套环境里的关键配置迁移到云端的 Linux 服务器。但先用虚拟机跑通，比直接买一台云服务器来折腾要省钱得多。
4.2 一键部署的实际过程
官方提供的安装脚本结构大致是：
curl -fsSL https://clawdbot.com/install.sh | bash我个人的习惯是：不要看到管道符号就直接执行，先把脚本下载下来检查一遍，再决定跑不跑。不是不信任官方，而是安装脚本经常变化，先看内容能知道它将要写入哪些目录、编排什么容器。实测这类脚本主要做三件事：拉取需要的镜像、创建持久化数据卷、在 PATH 里放入 CLI 命令。
如果你是老手，也可以完全绕过脚本，直接手动拉镜像、建数据卷，把目录和端口映射写进 Docker Compose 文件。这个路线的控制力更强，但首次配置成本也更高。我给初学者的建议是先跑官方一键脚本，能跑通之后再考虑手动部署。
4.3 init 初始化与配置文件
安装完成后，第一次运行需要做初始化。通常会看到交互式命令：
openclaw init它会让你依次填机器人名称、Persona 描述、模型接口地址、API Key、启用的通道。这里最关键的就是模型接口：
- 如果你有 OpenAI 兼容的 API Key，直接把 Base URL 和 Key 填进去。
- 如果不想依赖外网，也可以用 Ollama 跑本地模型。OpenClaw 对本地接口的支持通常比较友好，但加载速度和你分给虚拟机的资源有直接关系。
初始化生成的配置文件一般在~/.clawdbot/config.yaml，关键字段大致是：
name: my-assistant provider: type: openai base_url: https://api.openai.com/v1 api_key: sk-xxxx channels: teams: enabled: true obsidian: vault_path: /home/user/obsidian_vault snapshot_dir: ~/.clawdbot/sessions配置文件改完之后，先在命令行直接开聊：
openclaw chat输入一句“你好”，观察 Agent 能否正常回话。这一步通了，再往 Teams 这类外接通道走。不要跳过这步直接上 Teams，通道问题叠加模型问题会让你根本分不清是谁的锅。
5. 我踩过的“session file locked”报错：一次完整排查
5.1 报错现场回顾
排查背景是这样的：我配置好 Teams 通道后重启了 Agent，然后在 Teams 里给机器人发了一条测试消息。Agent 没有回复，回到终端窗口看到一行提示：
agent failed before reply: session file locked (timeout 60000ms) openclaw直译过来就是：Agent 在真正回复之前失败了，会话文件被锁定，等待 60 秒超时。这里的timeout 60000ms说明它一直在等锁被释放，直到超时才放弃。
5.2 为什么会锁：会话文件的并发机制
OpenClaw 在保存聊天上下文时，每个会话对应一个文件。为了保证多个进程不会互相写坏数据，写入方需要先拿到文件锁。如果锁被另一个进程持有、残留的锁文件没有清理、或者文件系统本身不擅长处理锁操作，就会出现等锁超时。
排查时建议按下面这个顺序来：
- 检查是不是双开。用
docker ps看容器数量，用ps aux | grep openclaw看进程数量。如果已经有一个容器在跑，你又手动启动了 CLI，两个进程就会抢同一份会话锁。这是我认为最常见的根因。 - 检查运行目录。OpenClaw 的会话文件默认放在 Home 目录下，属于 Linux 原生文件系统区，文件锁没有额外开销问题。如果你通过配置把 workspace 指到了
/mnt/c或/mnt/d这类 WSL 挂载 Windows 盘目录，文件锁行为会变得非常不可靠。 - 检查残留锁文件。强行中断 Agent 或虚拟机直接重启，都可能留下过期的
.lock文件。
5.3 一步步修复
我的清理过程是这样的：
docker ps # 先看容器数量 docker stop openclaw # 停掉 Agent 容器 cd ~/.clawdbot/sessions ls -l *.lock # 查看锁文件 rm -f *.lock # 清理残留锁 docker start openclaw # 重新启动容器重启之后 Agent 就恢复了。注意不要在多个 Agent 实例同时访问同一个数据卷的情况下反复启动，那样只会重新制造锁竞争。
为了避免再次触发，我把配置里的 snapshot 目录明确指向~/.clawdbot/sessions，不让它落到 /mnt 下面。同时立了一条规矩：每次重启前先停 Agent，再关 VMware，避免强制杀死进程留下锁文件。
5.4 这个问题给我们的其他提示
从这个报错展开，我意识到会话文件管理是长期运行类 Agent 最容易被低估的部分。单文件、单线程、文本格式的会话存储，简单但脆弱。Agent 往往会在后台自动回复，你人不在旁边，锁一乱就可能错过重要消息。这也是为什么我坚持要用虚拟机快照，并且定期把~/.clawdbot/sessions里的会话日志复制到虚拟机外部的备份盘。
6. 接入 Microsoft Teams 与 Obsidian：从配置到可用
6.1 为什么第一个接 Teams
工作场景里，Teams 消息是很高频的入口。把 OpenClaw 接进 Teams，意味着你可以直接在聊天框里喊它“帮我整理会议记录”，它可以在后台处理后把结果发回频道。这是最贴近“私有助理”的体验，所以我把 Teams 作为第一个要打通的通道。
事先说清楚：Teams 通道不是改一个配置文件就能搞定的，它需要一个 Azure Bot 应用。整个链路大致是：在 Azure 侧注册 Bot -> 拿到 App ID 和 Client Secret -> 填写到 OpenClaw 配置中 -> 启动 Agent 去连 Teams。
6.2 Azure Bot 注册的步骤和坑
我这边测试时的操作路径是：
- Azure 门户里搜索 “Bot Service” 或 “Azure AI Bot Service”，新建一个 Bot 资源。
- 选择“单租户”或者当前默认形态，记下 Application ID。
- 生成 Client Secret，保存好，这个值后面不会再完整显示。
- 在 Bot 的配置面板里填 “Messaging endpoint”。这里需要用到虚拟机网络的端口映射。OpenClaw 如果跑在 Docker 容器里，一般需要把宿主机的某个端口映射给 Agent 的监听端口。
踩过的主要坑是：App ID 和 Client Secret 抄错、端口映射没有生效、重启 Agent 后通道没有重新初始化。这些问题排查起来都不难，但会让你误以为是 Agent 本身的问题。
6.3 在 OpenClaw 配置文件里开启 Teams
回到config.yaml，在 channels 段下增加：
channels: teams: enabled: true app_id: "你的Application ID" app_secret: "你的Client Secret" tenant_id: "你的Tenant ID"改完配置后重启 Agent，让通道初始化。然后在 Teams 里给 Bot 发一条私聊，或者 @ 它，看 Agent 是否回话。初次接入最常见的失败就两个方向：秘钥抄错，以及回调端口没通。
6.4 Obsidian 知识库接入与组合使用
OpenClaw 接 Obsidian 的逻辑并不复杂：你把知识库的 Vault 目录映射给 Agent 可访问的路径，它就能在这个目录里读取、检索、追加笔记。比较推荐的做法是把 Vault 放到虚拟机 D 盘，然后在配置里指向目录。配置项像我上面写的那样，指定一个vault_path。
之后你可以直接请求：“总结今天工作台里所有待办”。Agent 会扫描笔记并返回摘要。有两个问题需要提前注意：一是宿主机和虚拟机之间的笔记同步，可以用 OneDrive 或坚果云这类同步盘，但不要让 Agent 和同步盘反复写同一个文件，容易冲突；二是如果 Vault 特别大，笔记超过几千个 markdown 文件，建议让 Agent 只检索指定子目录，否则搜索响应会明显变慢。
7. 快照、维护与长期运行的经验
7.1 三个值得打快照的时间点
快照不是有事没事都存，而是在正确的节点存。我的习惯是打三个快照：
- Win11 安装完毕、VMware Tools 装好之后，打一个“干净系统”快照。这是所有后续操作的基础备份。
- WSL2 和 Docker Desktop 配置完毕，但还没拉取任何镜像的时候，打一个“运行时就绪”快照。后续安装出问题，回到这里能最快重新开始。
- OpenClaw 初始化成功、基础对话通过之后，打一个“最小可用”快照。这个状态一恢复，就已经是一个能聊天的代理。
之后的每一次大改动，比如升级版本、改通道配置、换模型接口，都先想一下要不要再存一个。有了快照，热升级失败也就是两条命令的事。
7.2 资源占用实测与调整建议
跑了一周之后，我观察到：Win11 虚拟机本身闲置时大约占 4GB 内存，Docker Desktop 加 WSL 约占 1.5GB，OpenClaw 容器和模型服务一起跑，高峰能到 6GB 以上。所以虚拟机内存至少 8GB，如果你想跑本地大模型，建议给到 12GB 或 16GB。
磁盘方面，一个干净的 Win11 占 30GB 左右，加上 Docker 镜像、OpenClaw 依赖和会话日志，一个月后虚拟机磁盘占用到 60GB 很正常。如果发现虚拟磁盘膨胀得厉害，可以在 Agent 停止的状态下做一次磁盘清理，或者配合 VMware 的 “Reclaim unused disk space” 操作回收空间。
7.3 我的日常启动与关闭流程
为了避免留下隐患，我现在的日常操作顺序是：
- 打开 VMware，启动 Win11 虚拟机。
- 等 Docker Desktop 自动启动后，手动启动 OpenClaw 容器。
- 处理完任务后，先停 OpenClaw，再正常关机。
- 定期把
~/.clawdbot/sessions里的会话日志复制到虚拟机外的备份盘。
这套流程听起来多，实际操作一分钟都用不到。主要目的就是避免之前说的 session file 锁定问题，也让虚拟磁盘尽量少出现异常状态。
最后再分享一个我自己用的很顺手的小技巧。如果你不希望每次启动虚拟机都看到 Docker Desktop 弹窗，可以在 Win11 任务计划程序里设定开机延迟启动 Docker Desktop；等 Docker 就绪后，再自动拉起 OpenClaw 容器。这是少数几个我测试下来既省时间又稳定的组合。这套虚拟机环境跑下来，最大的感受是：把 Agent 装进虚拟机，换来的不是“隔离”这个结果，而是“可以随便犯错”的自由。错了就删，删了再重建，反正有快照。试过一轮 Win11 虚拟机之后，以后想把它迁到 Linux 服务器长期挂机也毫无障碍，因为核心步骤除了操作系统环境准备，后面几乎一样。