1. 从“养龙虾”说起：OpenClaw到底在解决什么问题
第一次看到“AI圈集体养龙虾”这个说法，我愣了几秒。后来把OpenClaw这个名字拆开看——Open（开放）+ Claw（钳子/爪子），再结合圈内人管它叫“龙虾”，才反应过来这是个社区梗。但梗归梗，这东西真正让我感兴趣的，是它试图解决一个存在了很久、却一直没被很好解决的问题：让AI智能体真正“住进”操作系统里，而不是飘在浏览器标签页上。
我们平时用的大多数AI工具，本质上都是“外挂”——你打开一个网页，输入问题，它给你答案，然后你手动把答案复制到需要的地方。整个过程里，AI和你的电脑操作系统是割裂的。你的文件系统、你的终端、你的进程管理、你的环境变量，AI一概碰不到。它就像一个隔着玻璃跟你说话的顾问，能出主意，但动不了手。
OpenClaw想做的事情，就是把这层玻璃拆掉。它给AI智能体提供了一个和操作系统对话的通道和桥梁——注意，这里的关键词是“通道”和“桥梁”，不是“替代”。它不打算重写一个操作系统，而是在现有系统（Linux、Windows、macOS）之上，架一层让AI能够理解并操作系统的中间层。你可以把它理解成一个“翻译官”：一边是自然语言指令，一边是系统调用、文件操作、进程管理这些底层动作。
这个定位为什么重要？因为AI智能体（AI Agent）这个概念喊了这么久，真正落地的场景大多还停留在“问答”和“内容生成”层面。能真正操作系统的智能体，意味着它可以帮你整理文件、批量重命名、监控系统资源、自动执行脚本、甚至在出现异常时自主排查。这才是“智能体”三个字里“体”字的含义——它得有个身体，得能动手。
适合谁来关注这个东西？三类人。第一类是AI应用开发者，尤其是做Agent方向的，OpenClaw提供了一套现成的系统交互层，省得你从零造轮子。第二类是运维和DevOps工程师，如果你每天被重复的系统操作烦得不行，这东西能帮你把很多琐事自动化。第三类是技术爱好者和学生，想理解AI怎么和操作系统底层打交道，OpenClaw是个很好的学习样本。当然，如果你只是想找个聊天机器人，那这东西可能不适合你——它更偏向“干活”而不是“聊天”。
我花了大概两周时间，在Linux和Windows两个环境下分别部署和试用了OpenClaw，踩了一些坑，也摸出了一些门道。下面把我理解的整体设计思路、核心细节、实操过程以及常见问题，按我自己的逻辑梳理一遍。
2. 整体设计思路拆解：为什么是“通道”而不是“重写”
2.1 核心定位：中间层思维
OpenClaw最核心的设计决策，是把自己定位成中间层，而不是操作系统本身。这个选择背后有很实际的考量。
重写一个操作系统意味着什么？意味着你要处理硬件驱动、内存管理、进程调度、文件系统、网络协议栈——这些东西任何一个拿出来都是几十人年的工作量。而且就算你做出来了，用户凭什么迁移？他们的软件生态、数据、使用习惯全在现有系统上。所以“AI操作系统”这个概念，听起来很酷，但落地路径极其漫长。
OpenClaw走的是另一条路：在现有操作系统之上，加一层AI可理解的抽象层。这层抽象层做三件事：
- 意图解析：把用户的自然语言指令（比如“帮我找出昨天修改过的所有Python文件”）翻译成结构化的操作意图。
- 系统调用映射：把操作意图映射到具体的系统API或命令（比如
find /path -name "*.py" -mtime -1）。 - 执行与反馈：执行操作，捕获结果，把结果转成自然语言反馈给用户或上层Agent。
这个设计的优势很明显：轻量、可移植、不破坏现有生态。你不需要换操作系统，只需要在现有系统上装一个OpenClaw，就能让AI智能体获得系统操作能力。而且因为它是中间层，理论上可以适配多种操作系统——Linux、Windows、macOS，甚至一些嵌入式系统。
但劣势也存在：中间层意味着多了一层抽象，性能和实时性会打折扣。对于需要微秒级响应的系统操作，这层抽象可能成为瓶颈。不过对于大多数日常操作和自动化任务来说，这个开销是可以接受的。
2.2 为什么选择开源
OpenClaw选择开源，这个决策我觉得非常关键。系统操作权限是一个非常敏感的东西——你让一个AI智能体去操作你的文件系统、执行命令，如果没有透明的代码审计，谁敢用？
开源解决了几个问题。第一是信任问题：代码公开，任何人都可以审查它到底做了什么，有没有后门，权限控制是否合理。第二是生态问题：开源意味着社区可以贡献适配层，比如针对不同Linux发行版的适配、针对不同Shell的兼容、针对特定场景的Skill扩展。第三是学习价值：对于想理解AI Agent如何与系统交互的开发者来说，OpenClaw的源码是一个很好的参考实现。
我在GitHub上翻过它的代码结构，整体组织比较清晰：核心层负责意图解析和调度，适配层负责不同操作系统的系统调用映射，Skill层是可扩展的功能模块。这种分层设计让它的扩展性很好——你可以只写一个Skill，就能让OpenClaw获得一项新能力。
2.3 与主流AI Agent架构的关系
现在主流的AI Agent架构，大致可以分为几类。一类是基于ReAct模式的（Reasoning + Acting），让模型在推理和行动之间循环，逐步完成任务。一类是基于规划-执行分离的，先让模型生成一个任务计划，然后由执行器逐步执行。还有一类是基于多智能体协作的，多个Agent分工合作完成复杂任务。
OpenClaw的定位比较特殊：它不直接是一个Agent框架，而更像是Agent的操作系统接口层。你可以把它和ReAct模式结合——模型推理出需要执行什么操作，OpenClaw负责实际执行；也可以和规划-执行架构结合——规划器生成操作序列，OpenClaw负责逐步执行并反馈结果。
这种“不绑定具体Agent架构”的设计，让OpenClaw的适用范围更广。你可以在它上面搭各种不同的Agent逻辑，而不用被某一种架构锁死。
2.4 安全边界的设计考量
让AI操作操作系统，安全是绕不开的问题。OpenClaw在这方面的设计思路，我总结为“默认保守，显式授权”。
默认情况下，OpenClaw的权限是受限的——它不能随意删除文件、不能修改系统关键配置、不能执行高危命令。需要这些权限时，必须显式配置或授权。这种设计避免了“AI一上来就把系统搞崩”的情况。
另外，OpenClaw对操作的审计做得比较到位。每个操作都有日志记录，包括操作意图、实际执行的命令、执行结果、时间戳。这对于排查问题和追溯责任很重要。我在测试时故意让它执行了一个危险操作（删除一个测试目录），它在执行前弹出了确认提示，并记录了完整的操作日志。这个体验让我比较放心。
3. 核心细节解析与实操要点
3.1 环境准备：Linux和Windows的差异
OpenClaw在Linux和Windows上的部署体验差异比较大，我分别说一下。
Linux环境下，部署相对顺畅。因为OpenClaw的很多系统操作是基于Shell命令的，Linux的Shell生态成熟，命令标准化程度高，适配起来比较自然。我用的环境是Ubuntu 22.04，Python 3.10，整体安装过程大概十分钟。
Windows环境下，情况复杂一些。Windows的命令行生态比较分裂——有传统的CMD、有PowerShell、还有WSL。OpenClaw在Windows上主要通过PowerShell和WSL来执行系统操作。如果你装了WSL，体验会接近Linux；如果只用原生PowerShell，某些Linux风格的命令需要转换，偶尔会出现兼容性问题。
提示：如果你主要在Windows上使用，建议先装好WSL2，并把默认发行版设为Ubuntu。这样OpenClaw的很多操作可以直接走Linux路径，兼容性更好。
3.2 安装配置的核心步骤
安装过程本身不复杂，但有几个关键点需要注意。
第一步是获取源码。从官方仓库克隆下来，注意选择稳定版本的分支，不要直接用main分支——main分支可能包含未测试的改动。
第二步是依赖安装。OpenClaw的核心依赖包括Python运行时、一些系统交互库、以及可选的LLM接口库。这里有个坑：不同版本的依赖库之间可能有冲突，建议用虚拟环境隔离。
python -m venv openclaw-env source openclaw-env/bin/activate # Linux/macOS # 或 openclaw-env\Scripts\activate # Windows pip install -r requirements.txt第三步是配置文件设置。OpenClaw的配置文件通常是一个YAML或JSON文件，里面需要配置几个关键项：LLM接口的地址和密钥、系统操作的权限级别、日志路径、以及可选的Skill列表。
llm: provider: "openai-compatible" base_url: "http://localhost:11434/v1" # 如果本地跑Ollama model: "qwen2.5:7b" api_key: "your-key-here" permissions: file_read: true file_write: false command_execute: true command_whitelist: - "ls" - "find" - "grep" - "cat" - "ps" - "top" logging: level: "info" path: "./logs/openclaw.log"这个配置里，permissions部分是最关键的。我建议初期把file_write设为false，command_execute设为true但配上白名单。这样OpenClaw只能执行你明确允许的命令，不会乱来。等熟悉了它的行为模式，再逐步放开权限。
第四步是LLM接口配置。OpenClaw本身不包含大模型，它需要连接一个LLM来做意图解析。你可以用云端API，也可以用本地部署的模型（比如通过Ollama跑Qwen或Llama）。本地模型的好处是数据不出本机，隐私性好；坏处是意图解析的准确率可能不如云端大模型。
我实测下来，7B级别的本地模型在简单指令上表现还行，但复杂指令（比如多条件组合的文件查找）容易理解偏差。如果你对准确率要求高，建议用更大的模型或者云端API。
3.3 Skill机制：扩展性的核心
OpenClaw的Skill机制是我觉得最有意思的部分。一个Skill本质上是一个功能模块，它定义了“这类操作怎么做”。比如有一个“文件管理”Skill，它知道怎么列出文件、怎么查找文件、怎么移动文件；有一个“进程管理”Skill，它知道怎么查看进程、怎么结束进程。
Skill的设计让OpenClaw的能力可以按需扩展。你不需要修改核心代码，只需要写一个新的Skill，注册进去，OpenClaw就获得了新能力。这对于特定场景的定制非常有用——比如你有一个内部系统，想通过OpenClaw来操作，写一个Skill就行。
我试着写了一个简单的Skill，功能是“查看当前系统的磁盘使用情况”。核心逻辑就是调用df -h命令，解析输出，返回结构化结果。代码量不大，但让我理解了Skill的工作机制：它本质上是一个“意图-命令”的映射器，加上结果解析逻辑。
注意：写Skill时要注意命令注入的风险。如果Skill接受用户输入并拼接到命令里，一定要做转义和校验，否则可能被恶意输入利用。
3.4 权限控制与审计日志
权限控制是OpenClaw安全性的基石。它的权限模型大致分为几个层级：
| 权限级别 | 可执行操作 | 适用场景 |
|---|---|---|
| 只读 | 查看文件、查看进程、查看系统信息 | 监控、查询类任务 |
| 受限写入 | 在指定目录内创建/修改文件 | 文件整理、日志写入 |
| 命令执行（白名单） | 执行白名单内的命令 | 自动化运维 |
| 完全控制 | 任意文件操作、任意命令执行 | 受信任的自动化环境 |
我建议大多数场景下，停留在“受限写入”或“命令执行（白名单）”级别。完全控制级别只在你完全信任Agent逻辑、且有完善的回滚机制时才使用。
审计日志方面，OpenClaw默认会记录每个操作的详细信息。日志格式大概是这样的：
[2026-01-15 14:32:11] INTENT: 查找昨天修改过的Python文件 [2026-01-15 14:32:11] COMMAND: find /home/user/projects -name "*.py" -mtime -1 [2026-01-15 14:32:12] RESULT: 找到3个文件: main.py, utils.py, test_api.py [2026-01-15 14:32:12] STATUS: SUCCESS这个日志对于排查问题非常有用。如果Agent执行了不符合预期的操作，你可以通过日志回溯，看到它到底理解成了什么意图、执行了什么命令。
3.5 与LLM的交互协议
OpenClaw和LLM之间的交互，采用的是“意图解析”模式。用户输入自然语言，OpenClaw把这句话连同当前系统上下文（比如当前目录、可用命令列表、权限范围）一起发给LLM，LLM返回一个结构化的操作意图。
这个交互协议的设计，直接影响了意图解析的准确率。我观察到几个关键点：
第一，上下文越丰富，解析越准确。如果你告诉LLM“当前目录是/home/user，可用命令有ls、find、grep”，它生成的命令会更贴合实际。如果什么都不给，它可能生成一个路径不对的命令。
第二，意图的粒度要适中。太粗的意图（比如“帮我整理一下电脑”）LLM很难处理；太细的意图（比如“把a.txt移动到b目录”）又失去了自然语言交互的意义。比较好的粒度是“中等复杂度”——比如“找出所有大于100MB的日志文件并列出它们的路径”。
第三，错误处理要明确。当LLM生成的命令执行失败时，OpenClaw需要把错误信息反馈给LLM，让它重新生成或调整。这个反馈循环的质量，决定了Agent的自主容错能力。
4. 实操过程与核心环节实现
4.1 从零搭建一个文件整理Agent
我拿一个实际场景来演示：自动整理下载目录。下载目录通常是重灾区，各种文件混在一起，手动整理很烦。我想让OpenClaw帮我做这件事。
第一步：定义任务边界。整理规则要明确：按文件类型分类（文档、图片、视频、压缩包、其他），每个类别一个子目录，超过30天未修改的文件移到“归档”目录。这些规则需要提前想清楚，因为LLM需要根据规则来生成操作序列。
第二步：配置权限。这个任务需要文件读取、文件移动、目录创建权限。我把file_write设为true，但限制在下载目录内。OpenClaw的配置支持路径级别的权限控制，这点很实用。
permissions: file_read: true file_write: true write_paths: - "/home/user/Downloads" command_execute: false # 这个任务不需要执行命令第三步：编写任务提示。我给OpenClaw的指令是这样的：
请整理/home/user/Downloads目录。规则如下：1. 按扩展名分类：文档（pdf, doc, docx, txt, md）、图片（jpg, png, gif, webp）、视频（mp4, mkv, avi）、压缩包（zip, tar, gz, 7z）、其他。2. 每个类别创建一个子目录，目录名分别为Documents、Images、Videos、Archives、Others。3. 超过30天未修改的文件，移动到Archive目录，保持原有的分类结构。4. 执行前先列出将要执行的操作，等我确认后再实际执行。
第四步：观察执行过程。OpenClaw首先扫描了下载目录，列出了文件清单和分类结果。然后生成了一个操作计划：创建5个分类目录，移动文件到对应目录，识别出12个超过30天的文件并计划移动到Archive。它把计划展示给我，我确认后，它开始执行。
执行过程中，我注意到一个细节：它在移动文件前，会先检查目标目录是否存在，不存在则创建。这个检查逻辑是必要的，否则移动会失败。另外，它在移动时保留了文件的修改时间戳，这个细节做得不错。
第五步：验证结果。执行完成后，我检查了下载目录，分类基本正确。有一个.tar.gz文件被分到了Archives，符合预期。有一个没有扩展名的文件被分到了Others，也合理。整体来说，这个Agent的表现达到了可用水平。
4.2 系统监控Agent的搭建与调优
第二个场景是系统资源监控。我想让OpenClaw定期检查CPU、内存、磁盘使用情况，超过阈值时提醒我。
这个任务的特点是周期性执行和条件触发。OpenClaw本身不直接提供定时任务功能，但可以结合系统的cron（Linux）或任务计划程序（Windows）来实现。
我的做法是写一个Shell脚本，脚本里调用OpenClaw的CLI接口，传入监控指令。然后用cron定时执行这个脚本。
#!/bin/bash # monitor.sh openclaw --task "检查系统资源：CPU使用率、内存使用率、磁盘使用率。如果CPU超过80%或内存超过90%或磁盘超过85%，输出警告信息并列出占用最高的5个进程。否则输出正常状态。"然后在crontab里配置每10分钟执行一次：
*/10 * * * * /home/user/scripts/monitor.sh >> /home/user/logs/monitor.log 2>&1这个方案跑了一周，整体稳定。但有一个问题：每次调用OpenClaw都要启动一次LLM推理，开销不小。如果监控频率高，资源消耗会比较明显。优化方案是让OpenClaw以服务模式常驻，通过API接收任务，而不是每次启动新进程。
4.3 用Ollama本地模型驱动OpenClaw
如果你不想依赖云端API，可以用Ollama在本地跑模型。我试过用Qwen2.5 7B和Llama 3.1 8B来驱动OpenClaw，说一下体验。
Qwen2.5 7B在中文指令理解上表现不错，对于“找出昨天修改过的文件”这类指令，意图解析准确率大概在85%左右。但在复杂指令上（比如多条件组合），偶尔会理解偏差。
Llama 3.1 8B的英文指令理解更好，中文稍弱。如果你主要用英文交互，这个模型更合适。
配置Ollama的方式很简单，在OpenClaw的配置文件里把base_url指向Ollama的地址即可：
llm: provider: "openai-compatible" base_url: "http://localhost:11434/v1" model: "qwen2.5:7b" api_key: "ollama" # Ollama不需要真实key，随便填提示：本地模型的推理速度取决于你的硬件。7B模型在16GB内存的机器上，单次推理大概2-5秒。如果你需要更快的响应，可以考虑量化版本（比如Q4量化），但准确率会略有下降。
4.4 关键参数的计算与选择
在配置OpenClaw时，有几个参数需要根据实际情况调整。
超时时间：LLM推理和命令执行都需要设置超时。LLM推理超时建议设为30-60秒（本地模型可能更久），命令执行超时根据命令类型设置——查询类命令10秒足够，批量文件操作可能需要几分钟。
并发数：如果你同时提交多个任务，OpenClaw需要控制并发。并发太高会导致资源竞争，太低则效率低下。我建议初期设为2-3，根据实际负载调整。
日志级别：调试阶段用debug，生产环境用info或warn。debug级别会记录每次LLM交互的完整请求和响应，信息量大但日志文件增长快。
重试次数：当LLM生成的命令执行失败时，OpenClaw可以自动重试。重试次数建议设为2-3次，太多会导致无限循环，太少则容错不足。
4.5 实操现场记录：一次完整的任务执行
我记录了一次完整的任务执行过程，展示OpenClaw从接收指令到完成任务的完整链路。
任务：找出当前目录下所有超过10MB的日志文件，按大小排序，输出前10个。
执行过程：
- 用户输入指令。
- OpenClaw收集上下文：当前目录
/var/log，可用命令find、du、sort、head，权限级别为只读。 - OpenClaw将指令和上下文发给LLM。
- LLM返回结构化意图：
{"action": "find_files", "criteria": {"type": "log", "size_min": "10M"}, "sort": "size_desc", "limit": 10}。 - OpenClaw将意图映射为命令：
find /var/log -name "*.log" -size +10M -exec du -h {} + | sort -rh | head -10。 - 执行命令，捕获输出。
- 将输出格式化为自然语言，返回给用户。
整个过程耗时约3秒（其中LLM推理占2秒，命令执行占1秒）。这个响应速度对于交互式使用是可以接受的。
5. 常见问题与排查技巧实录
5.1 意图解析偏差：LLM理解错了怎么办
这是最常见的问题。LLM把用户指令理解成了另一个意思，导致执行了错误的操作。
典型表现：你说“找出大文件”，它列出了所有文件；你说“清理临时文件”，它删除了不该删的东西。
排查思路：首先看日志里的INTENT记录，确认LLM把指令理解成了什么。如果意图明显偏差，说明LLM的解析出了问题。可能的原因包括：指令本身有歧义、上下文信息不足、模型能力不够。
解决方法：第一，把指令写得更明确，避免模糊词汇。第二，在配置里提供更丰富的上下文，比如当前目录的文件类型分布。第三，换用更大的模型或更擅长指令理解的模型。
我踩过的坑：有一次我说“把旧文件归档”，LLM把“旧”理解成了“超过1天”，结果把昨天刚下载的文件也归档了。后来我把指令改成“把超过30天未修改的文件归档”，问题解决。
5.2 权限拒绝：操作被拦截
OpenClaw的权限系统会拦截未授权的操作。如果你发现某个操作执行不了，先检查权限配置。
常见情况：
| 问题现象 | 可能原因 | 解决方法 |
|---|---|---|
| 文件写入失败 | file_write为false | 设为true，并配置write_paths |
| 命令执行被拒 | 命令不在白名单 | 添加到command_whitelist |
| 路径访问被拒 | 路径不在允许范围 | 添加到allowed_paths |
| 操作超时 | 超时时间太短 | 调整timeout参数 |
5.3 命令执行失败：环境差异导致
同一个命令，在你的终端里能跑，在OpenClaw里却失败。这通常是环境差异导致的。
典型原因：PATH环境变量不同、当前工作目录不同、Shell类型不同（bash vs sh vs PowerShell）、权限不同。
排查方法：在OpenClaw的日志里找到实际执行的命令，复制到终端里手动执行，看是否成功。如果手动执行成功但OpenClaw执行失败，说明是环境问题。
解决方法：在OpenClaw的配置里显式设置环境变量和工作目录。比如：
execution: work_dir: "/home/user" env: PATH: "/usr/local/bin:/usr/bin:/bin" LANG: "en_US.UTF-8"5.4 性能问题：响应太慢
OpenClaw的响应速度取决于LLM推理速度和命令执行速度。如果感觉太慢，可以从几个方面优化。
LLM推理优化：换用更小的模型、使用量化版本、开启推理缓存（相同指令不重复推理）。
命令执行优化：优化命令本身（比如用find的-maxdepth限制搜索深度）、减少不必要的命令调用。
架构优化：让OpenClaw以服务模式常驻，避免每次启动新进程的开销。
5.5 常见问题速查表
| 问题类别 | 具体现象 | 排查方向 | 解决手段 |
|---|---|---|---|
| 意图解析 | 执行了错误操作 | 查看INTENT日志 | 明确指令、增加上下文、换模型 |
| 权限控制 | 操作被拦截 | 检查权限配置 | 调整权限级别、添加白名单 |
| 命令执行 | 命令失败 | 手动执行对比 | 设置环境变量、工作目录 |
| 性能 | 响应慢 | 分析耗时分布 | 优化模型、命令、架构 |
| 日志 | 日志过大 | 检查日志级别 | 调整为info或warn |
| 兼容性 | Windows下异常 | 检查Shell类型 | 使用WSL或PowerShell |
5.6 独家避坑技巧
技巧一：先用只读模式跑一周。刚部署OpenClaw时，不要急着开放写入权限。先用只读模式跑一段时间，观察它的行为模式，确认意图解析准确率可以接受后，再逐步放开权限。
技巧二：给危险操作加二次确认。对于删除、覆盖、批量修改这类操作，在OpenClaw的配置里开启二次确认。这样即使LLM理解错了，你还有机会拦截。
技巧三：定期审查审计日志。审计日志不仅是排查问题的工具，也是发现异常行为的窗口。我每周会花十分钟扫一遍日志，看看有没有意料之外的操作。
技巧四：用版本控制保护重要目录。如果你让OpenClaw操作代码目录，建议先用Git把目录纳入版本控制。这样即使OpenClaw改错了文件，也能快速回滚。
技巧五：本地模型和云端模型混用。简单指令用本地模型（快、免费），复杂指令用云端模型（准、但花钱）。OpenClaw支持配置多个LLM后端，可以根据指令复杂度自动切换。
6. 扩展方向与个人体会
OpenClaw目前的能力边界还比较清晰——它主要处理文件操作、命令执行、系统信息查询这几类任务。但它的架构设计留出了足够的扩展空间。
一个有意思的扩展方向是与嵌入式系统结合。OpenClaw的中间层设计，理论上可以适配资源受限的环境。如果把LLM推理放在云端或边缘服务器，OpenClaw只负责本地的系统交互，那么在一些嵌入式Linux设备上也能跑起来。这对于物联网场景下的自动化运维很有价值。
另一个方向是多Agent协作。OpenClaw可以作为多个Agent的“系统操作层”，每个Agent负责不同的任务域，共享同一个OpenClaw实例来执行系统操作。这样既能复用系统交互能力，又能通过Agent分工来处理复杂任务。
还有一个方向是与CI/CD流水线集成。在持续集成环境里，OpenClaw可以承担一些智能化的运维任务，比如根据构建日志自动排查失败原因、根据资源使用情况动态调整构建参数。
我个人在实际操作中的体会是，OpenClaw这类工具的价值，不在于它现在能做什么，而在于它打开了一个方向：让AI从“对话”走向“操作”。过去我们习惯了AI只能动嘴，现在它开始动手了。虽然目前的手还比较笨，权限控制也比较保守，但这个方向一旦跑通，后续的想象空间很大。
最后分享一个小技巧：如果你在Windows上部署OpenClaw遇到路径问题，可以试试把所有路径都写成WSL风格的路径（比如/mnt/c/Users/...），然后在WSL里运行OpenClaw。这样能避开很多Windows路径转义的坑。我在Windows上折腾了两个小时没搞定的问题，换到WSL里十分钟就解决了。
