OpenClaw本地部署教程：Windows+WSL2+Ollama搭建AI智能体

最近不少人在讨论 OpenClaw 这个项目，名字很有意思，“超级龙虾打工人”，说是能在本地把 AI 大模型调用、任务自动化、多平台消息处理这些事情全包圆。我花了两天时间在 Windows 上从零开始部署跑通，把整个过程中的坑和关键操作整理成这份教程，适合想在 Windows 上折腾本地 AI 智能体的朋友参考。

先说结论：OpenClaw 是一个基于消息驱动的 AI 智能体框架，你可以把它理解成一个“自带手脚”的 AI 打工人——它能接收来自 Telegram、飞书、Discord 等平台的消息，自动调用本地或云端的大模型进行思考，然后执行工具调用、写文件、跑脚本、查资料等任务，甚至能配合定时任务主动干活。本质上它把“大模型对话”和“自动化执行”缝在了一起，比单纯在终端里聊 ChatGPT 要实用得多。我选择在 Windows 上部署，主要是因为我日常主力机就是 Windows，不想为这一个工具专门切系统。

我这次部署使用的组合是：Windows 11 + WSL2 + Docker Desktop + Ollama（本地模型）+ OpenClaw 服务端，全程不需要魔法（强调：不涉及任何代理工具），依赖的组件都是官方渠道获取。

1. 部署前的认知：OpenClaw 是什么，以及为什么选 Windows + WSL2

1.1 OpenClaw 的核心能力拆解

OpenClaw 本质上是一个“消息进来 → 模型思考 → 工具执行 → 结果回传”的循环引擎。它的架构由几个关键模块组成：

• Channel（消息通道）：负责接入不同的聊天平台，常见的 channel 包括 telegram、discord、飞书、whatsapp-web 等。每条来自平台的消息都会被封装成统一的事件对象。
• Agent（智能体核心）：基于大模型（如千问、GPT、DeepSeek、Llama 等）进行意图识别和任务规划。它决定“这条消息该怎么回应”“要不要调用工具”。
• Tools（工具集）：OpenClaw 内置了大量工具，比如文件读写、网页请求、命令执行、定时任务、搜索等。你可以通过配置为 Agent 增加新的工具。
• Memory（记忆模块）：保存历史会话和关键信息，让 Agent 在一个会话中保持上下文连续性。
• Scheduler（调度器）：支持定时任务，比如每天早上自动汇总邮件、定时抓取网页内容等。

这五个模块加在一起，其实就是一个“能对话、能行动、能记住事”的本地 AI 打工人雏形。相比直接在终端里调用大模型 API，它的优势在于：有统一的消息接入层、有现成的工具链、有可扩展的机制。

我实际用下来的感受是：OpenClaw 真正解放的是“对接”这件事。不用自己写一堆胶水代码去打通 Telegram 机器人和大模型 API，也不用自己处理消息队列和会话存储，框架把大部分脏活累活都做了，剩下的就是配置和调参。

1.2 为什么在 Windows 上部署要优先考虑 WSL2

OpenClaw 的官方文档明确说明，它面向 Linux 和 macOS 环境做了主要适配，Windows 原生跑虽然有可能，但会遇到一堆文件路径、依赖编译、进程管理的问题。我没头铁直接硬上 Windows 原生，而是选择了 WSL2 作为运行时环境。

这里有个很多人容易混淆的点：WSL2 和虚拟机不是一回事。WSL2 其实是 Windows 内置的一个轻量级 Linux 内核虚拟机，它由 Windows 直接管理，启动速度极快，内存占用相对传统虚拟机要小得多，而且和 Windows 文件系统可以互相访问（通过 /mnt/c/ 挂载）。对于 OpenClaw 这种对 Linux 环境高度适配的应用，WSL2 既提供了兼容性，又保留了我们日常在 Windows 操作的习惯。

为什么不是直接用 Docker Desktop 跑容器？其实 Docker Desktop 在 Windows 上默认也是依赖 WSL2 后端的。如果你把 Docker Desktop 装好了，它的虚拟机本质上就是 WSL2 的一个发行版。所以无论你走“直接在 WSL2 里装环境”还是“用 Docker 容器跑”，底层都绕不开 WSL2。既然如此，我干脆直接以 WSL2 为底座，这样后续调试、看日志、改配置文件都更直观。

1.3 版本选择与组件清单

在动手之前，我先把这次需要安装的组件清单列清楚，这样后面每一步都不会慌：

这里有个取舍：如果你只是跑通最小功能，不装 Docker 也可以（直接在 WSL2 里 npm install 即可），但装了 Docker 之后，后续如果要跑一些依赖容器化的工具（比如单独的向量数据库、浏览器自动化服务），就方便多了。我建议两个都装，反正不冲突。

2. 环境准备：WSL2、Docker、Node.js、Ollama 安装全过程

2.1 WSL2 启用与 Ubuntu 安装

打开 PowerShell（管理员模式），先确认 Windows 版本支持 WSL2，然后执行：

wsl --install

这条命令会默认安装 WSL2 内核和 Ubuntu 发行版。如果你的系统是英文版，可能需要手动指定发行版：

wsl --install -d Ubuntu-22.04

安装完成后重启电脑。第一次启动 Ubuntu 会让你设置用户名和密码，这个密码是 Linux 子系统内的 sudo 密码，和 Windows 登录密码无关，建议设置一个单独的、好记的密码。

重启后进入 Ubuntu 终端，先更新软件源：

sudo apt update && sudo apt upgrade -y

然后确认 systemd 是否启用。OpenClaw 的定时任务依赖 systemd 或 cron，没有 systemd 会麻烦一些。在 WSL2 中检查：

ps -p 1 -o comm=

如果输出是systemd，恭喜，默认新版本 WSL 已经启用 systemd。如果输出是init，则需要手动启用 systemd：用记事本打开/etc/wsl.conf，添加以下内容：

[boot] systemd=true

然后在 Windows PowerShell 里执行wsl --shutdown，重新进入 Ubuntu。

2.2 Docker Desktop 与 WSL2 集成

Docker Desktop 在 Windows 上的安装很傻瓜化，一路下一步即可。关键在于安装完成后，需要进入 Docker Desktop 的 Settings → Resources → WSL Integration，确保你的 Ubuntu 发行版对应的开关是打开的。

为什么要强调这一步？因为如果你不开 WSL Integration，Docker 命令只能在 Windows 的 PowerShell 里用，在 Ubuntu 终端里敲docker ps会提示找不到命令。打开集成后，WSL2 内部直接就识别到了 docker 命令，不需要再单独在 Ubuntu 里装一遍 Docker CLI。

安装完成后验证：

docker --version docker compose version

如果都能正常输出版本号，说明环境就绪。

2.3 Node.js 安装：用 nvm 管理版本

OpenClaw 的服务端是基于 Node.js 的，对版本有要求。我建议不要直接用 apt 装 Node，因为 apt 源里的 Node 版本往往偏旧。用 nvm（Node Version Manager）安装和管理最稳妥。

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash

执行完成后重新加载 shell 配置：

export NVM_DIR="$HOME/.nvm" [ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"

然后安装 Node.js 20 LTS 版本：

nvm install 20 nvm use 20 node -v npm -v

这里有个小细节：npm 在某些网络环境下安装依赖会很慢，甚至直接报错。如果你遇到 npm 包下载超时的问题，可以临时切换镜像源：

npm config set registry https://registry.npmmirror.com

这是国内常用的 npm 镜像，装完后如果后续要发布包或者有安全顾虑，再改回官方源即可。

2.4 Ollama 安装与模型拉取

Ollama 是本地运行大模型的利器。它支持 Llama 3、Qwen（千问）、DeepSeek、Mistral 等众多开源模型，一条命令就能拉取并启动模型服务。

进入 Ubuntu 终端执行：

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

安装完成后先启动 Ollama 服务：

ollama serve

建议让它后台常驻。如果使用 systemd，可以：

sudo systemctl enable ollama sudo systemctl start ollama

模型选择上，我根据机器配置做了不同方案。如果你的显卡显存足够（至少 8GB），推荐用千问 7B 或 DeepSeek 7B 这类模型，效果和速度平衡较好。如果显存不够，就选 4B 甚至 1.5B 的小模型。

我机器是 3060 12GB 显存，拉取的是千问 7B 量化版：

ollama pull qwen2.5:7b

拉取完成后可以用一条简单的命令验证模型能否正常响应：

ollama run qwen2.5:7b "你好，请简单介绍一下你自己"

如果你用的是纯 CPU 推理（没有独立显卡），也不是不行，但速度会慢很多，建议选择 4B 以下的小模型，比如：

ollama pull qwen2.5:1.5b

值得一提的是，Ollama 启动后默认监听 11434 端口，OpenClaw 后面就是通过这个端口调用本地模型的。

2.5 关于“本地部署”和“远程模型 API”的选择逻辑

在配置 OpenClaw 的模型之前，你需要先明确一个问题：你是想完全本地推理，还是接云端 API？

完全的本地部署（Ollama 方案）优势是：数据不出本机、无额外 API 费用、断网也能用。代价是：模型能力受限于你的硬件，回答质量不如顶级商用 API，而且显存不够时速度慢到怀疑人生。

云端 API 方案（比如接 OpenAI、DeepSeek 开放平台）优势是：模型能力最强、速度稳定、无需本地算力。代价是：按 token 计费，长期高频使用有成本，且数据经过第三方服务。

我个人推荐混合方案：日常聊天和简单任务用本地小模型，复杂推理和重要任务用云端强模型。OpenClaw 恰好支持配置多个模型，并且可以根据条件切换。后面我会详细讲怎么配置。

3. OpenClaw 项目获取与初始化配置

3.1 获取 OpenClaw 源码与依赖安装

OpenClaw 的源码托管在 GitHub 上。进入 Ubuntu 终端，先创建一个工作目录：

mkdir -p ~/openclaw && cd ~/openclaw

然后克隆项目：

git clone https://github.com/openclaw/openclaw.git .

如果你在克隆时遇到网络问题，可以考虑使用 GitHub 加速代理，但这是可选的，不一定需要。克隆完成后，安装依赖：

npm install

这一步可能会耗时较长，取决于你的网络状况和机器性能。如果中间报错，多半是某些原生模块需要编译，这时需要确保系统里装了 build-essential：

sudo apt install build-essential python3 -y

装完后重新npm install一般就能通过。

3.2 配置文件的核心结构与逐项说明

OpenClaw 的配置采用 YAML 格式，默认配置文件是openclaw.config.yaml。首次运行时如果不存在，框架会生成一个默认配置。我的做法是先让服务跑起来一次，生成默认配置后再去改。

配置文件的顶层结构分成几个块：

app: name: OpenClaw description: "your personal AI assistant" dataDir: "./data" logLevel: info models: provider: ollama model: qwen2.5:7b apiUrl: http://localhost:11434/v1 channels: telegram: enabled: true botToken: "123456:ABC..." allowedUsers: - "your_telegram_user_id" channelType: telegram scheduler: enabled: true timezone: Asia/Shanghai memory: type: local storagePath: "./data/memory"

这里我重点说明几个关键配置：

• dataDir：OpenClaw 的数据存储目录，包括会话记录、记忆、日志等。建议保留默认的相对路径，这样整个项目目录可以整体迁移。
• models.provider：模型提供方，这里填ollama表示走本地 Ollama 服务。如果想用云端 API，可以改成openai、anthropic、deepseek等，并在apiKey字段填入对应密钥。
• models.apiUrl：Ollama 的 OpenAI 兼容接口地址。Ollama 在较新的版本里提供/v1路径，可以直接兼容 OpenAI SDK 的调用方式。
• channels.telegram.botToken：Telegram 机器人的 token，从 BotFather 获取。
• allowedUsers：白名单，只允许特定用户 ID 与机器人对话。这个非常重要，不配置的话你的机器人会对所有 Telegram 用户开放，任何人都能命令它执行工具，这就等于把你的电脑门钥匙交出去了。
• scheduler.timezone：定时任务的时区，国内用户一定要设为Asia/Shanghai，否则定时任务会在错误的时段触发。

3.3 Channel 选择：从 Telegram 到飞书

关于 channel 选择，官方支持多种类型。我最开始接触的是 Telegram channel，因为它的机器人 API 最成熟、文档最完善、调试也最简单。如果你是国内用户，连接 Telegram 服务本身可能不太方便，那么可以考虑飞书 channel——飞书在国内网络环境下可以直接访问，而且飞书开放平台创建应用机器人的流程非常成熟。

飞书 channel 核心配置如下：

channels: lark: enabled: true appId: "cli_xxxxx" appSecret: "xxxxx" eventEncryptKey: "" verificationToken: "" channelType: lark

其中appId和appSecret是在飞书开放平台创建企业自建应用后获取的。需要开通机器人能力，并配置事件订阅（接收消息事件），设置请求地址为 OpenClaw 服务暴露的公网地址。

这里有个实操点：飞书的事件订阅需要一个公网 HTTPS 地址，否则飞书平台无法把消息推送给你。这通常意味着你需要把本机的服务暴露到公网。这个环节涉及内网穿透、域名备案等额外工程，是很多新手容易被卡住的地方。如果只是本地自己玩，建议优先用 Telegram——Telegram 的 Bot API 是长轮询方式，不需要公网回调地址，服务启动后主动去 Telegram 服务器拉取消息，这样本地跑起来就能用，省去公网暴露的麻烦。

3.4 模型切换与配置多个模型

OpenClaw 支持配置多个模型，并根据不同场景自动路由。典型的场景是：默认用本地 Ollama 的千问模型响应日常对话，遇到复杂代码任务时切换到大模型的 API。

多模型配置示例：

models: providers: - name: local-qwen provider: ollama model: qwen2.5:7b apiUrl: http://localhost:11434/v1 weight: 80 - name: deepseek-api provider: deepseek model: deepseek-chat apiKey: "sk-xxxxx" weight: 20 defaultProvider: local-qwen

weight字段表示流量占比。这里不是“按概率随机抽”，而是 OpenClaw 在上下文复杂度达到某个阈值时，更倾向于调用weight更高的模型作为主模型。实际上 OpenClaw 还支持通过工具调用的方式动态切模型：你可以让 Agent 在认为任务复杂时，自己决定调用 API 模型以获取更高质量的回复。

我在实际使用中把默认模型设为本地千问 7B，把 deepseek 的 API 作为“备用大脑”。大部分日常问题本地模型就能胜任，只有遇到需要严谨推理或多步骤代码生成的任务时，我会在对话中明确指示它切换到 deepseek，效果比全部走 API 省钱得多。

4. 实操运行：启动服务、接入 Telegram、跑通第一个任务

4.1 创建 Telegram 机器人并获取 Token

如果你的选择是 Telegram 通道，那么需要用 BotFather 创建一个新的机器人。在 Telegram 里搜索 BotFather，发送/newbot，按提示填写机器人名字和用户名，成功后会得到类似下面的 token：

7234567890:AAHxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

这个 token 是机器人的唯一凭证，相当于密码。千万不要泄露到公开渠道，否则别人可以控制你的机器人。

然后需要拿到你的 Telegram 用户 ID。最简单的方式：在 Telegram 搜索@userinfobot，给它发任意消息，它会回复你的数字 ID。把这个 ID 填到配置文件的allowedUsers列表里。

4.2 修改配置文件并启动 OpenClaw

先复制一份默认配置：

cp openclaw.config.example.yaml openclaw.config.yaml

然后编辑配置文件，填入上面获取的 botToken 和 user ID。修改完成后，用以下命令启动服务：

npx openclaw start

如果一切正常，控制台会输出类似下面这样的日志：

[OpenClaw] Starting... [OpenClaw] Model initialized: qwen2.5:7b [OpenClaw] Telegram channel connected [OpenClaw] Agent is ready to serve

这时候你在 Telegram 里给机器人发一条 “/start” 或者随便发点什么，它应该会回复你一条欢迎消息，说明整个链路已经通了。

建议在使用前先在终端里确认 Ollama 服务和 OpenClaw 服务都在运行。Ollama 的日志可以用journalctl -u ollama -f查看（使用 systemd 时），OpenClaw 的日志则直接看前台输出。

4.3 跑通第一个实际任务：让 AI 写文件并执行脚本

光能对话只是第一步，OpenClaw 真正强大的是工具调用。我测试的第一个实际任务是让 AI 帮我写一个 Python 脚本，并执行它。

在 Telegram 里给机器人发消息：

请帮我写一个 Python 脚本，计算斐波那契数列前 50 项，打印结果并保存到文件 fib.txt 中。

正常情况下，OpenClaw 会经历以下过程：

1. Agent 收到消息，识别这是一个代码生成任务。
2. Agent 调用write_file工具，将 Python 代码写入当前工作目录。
3. Agent 调用execute_command工具，运行python3 fib.py。
4. Agent 读取输出结果，生成回复消息发回 Telegram。

整个过程你可以在 OpenClaw 的前台日志里看到每一轮工具调用的记录。如果某个环节失败，日志里会有具体的错误堆栈，方便定位。

这里有一个关键前提：OpenClaw 运行所在的终端工作目录必须是你有权限读写的目录。如果在/root下运行，工具默认就在/root下创建文件，权限没问题。如果是以普通用户运行，确认当前用户对项目目录有写权限。

4.4 定时任务的使用方法与配置

OpenClaw 的调度器允许你定义定时任务，格式类似 cron 表达式。比如每天早上 8 点让 AI 给你发送一条天气摘要（前提是你给它配置了天气查询工具）。

在配置文件的scheduler区块添加任务：

scheduler: enabled: true timezone: Asia/Shanghai tasks: - name: "morning-news" schedule: "0 8 * * *" action: "查询今天的天气，并整理成一条简短播报发送给我"

需要说明的是，定时任务的action是一段自然语言描述，OpenClaw 会按描述用大模型生成完整任务流程。这种设计在执行简单任务时很灵活，但复杂任务我建议写成一个固定 prompt，并在action里明确指定步骤，否则模型可能发挥不稳定。

定时任务调试时有个小技巧：先把schedule设成一分钟后的分钟级表达式，比如当前的 cron 表达式是*/1 * * * *（每分钟执行一次），验证任务能正确执行后再改成真正想要的周期。否则等定时任务触发可能要等一整天，调试效率太低。

5. 疑难杂症排查：我从失败到跑通的完整记录

5.1 WSL2 环境校验失败：openclaw could not safely verify the wsl2 environment

这个报错我安装完成后第一次启动就遇到了。OpenClaw 在启动时会检查 WSL2 环境的安全性，具体是看/proc/sys/kernel/randomize_va_space和其他内核参数是否符合预期。这个检查本意是防止在一个不可信的环境里运行，但在默认 WSL2 上会偶发失败。

解决方案分两步：先确认 WSL2 内核版本是最新的，在 PowerShell 里执行：

wsl --update

然后把 Ubuntu 里能升级的东西都升一遍：

sudo apt upgrade -y

如果问题依旧，检查你是否在 Windows 上装了第三方安全软件，有些安全软件会干扰 WSL2 的内核参数，导致 OpenClaw 检测异常。另外，把 OpenClaw 放到 WSL2 的 Linux 文件系统里，而不是放在/mnt/c/下。放在/mnt/c下不仅是性能差的问题，还可能因为 Windows NTFS 权限模型导致部分内核校验逻辑误判，我用的是~/openclaw路径后问题消失。

5.2 npm 识别失败：无法将“npm”项识别为 cmdlet

这个错误出现的原因很简单：在 Windows PowerShell 里直接敲 npm，但系统 PATH 里没有包含 npm 所在目录。解决方法是：要么在 PowerShell 里使用完整的 nvm 安装路径，要么干脆所有操作都进 WSL2 的 Ubuntu 终端里做。

我的习惯是：从 WSL2 的终端进入项目目录后，运行nvm use 20先激活 Node 环境，再跑 npm 命令。如果你重启 WSL 后发现node和npm都不见了，是因为 nvm 的环境变量没有自动加载。把下面这行加到~/.bashrc末尾：

export NVM_DIR="$HOME/.nvm" [ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"

改完执行source ~/.bashrc即可。

5.3 session file locked (timeout 60000ms)

这个报错出现在我同时开了多个 OpenClaw 进程时。OpenClaw 使用文件锁来防止多个实例同时写入同一个会话数据，当你意外启动了多个进程，或者上一个进程没有正常退出，就会出现会话文件被锁住的问题。

解决方法很简单：先杀掉所有 OpenClaw 进程，然后删除锁文件。

pkill -f openclaw rm -rf ~/openclaw/data/sessions/*.lock

再启动服务即可。如果频繁出现这个错误，检查你是不是在 Windows 和 WSL2 两边都启动过 OpenClaw，两边同时访问同一个数据目录会导致文件锁冲突。

5.4 工具调用报错：cannot read properties of undefined (reading 'prepare')

这个错误出现在我用非官方模型时，模型返回的 tool call 格式不规范，导致 OpenClaw 在解析工具调用时崩溃。OpenClaw 对模型的 function calling 能力有要求，不是所有模型都能稳定输出符合 OpenAI 格式的 tool_calls。

解决思路有两个方向：

一个是换模型。如果你的本地模型（尤其是小参数模型）不支持 function calling，或者输出格式经常错误，建议切换到支持 function calling 的模型。千问 7B 和 DeepSeek 系列对工具调用的支持相对稳定。

另一个是关闭该模型的工具调用能力，让它退化成一个纯对话模型。在配置里加上：

tools: enabled: false

这样能暂时绕过问题，但代价是 OpenClaw 的“打工人”属性就少了很大一部分。我更推荐的做法是：给特定模型关闭工具调用，给支持好的模型开启工具调用，两者交错使用。

5.5 其他高频问题的速查表

6. 进阶玩法与选型建议：让“超级龙虾”真正会干活

6.1 多模型路由的实用配置

如果你既想用本地模型省钱省事，又想保留调用最强 API 的能力，可以配置一个规则：当检测到消息中包含“写代码”“分析数据”“深度思考”等关键词时，自动切换到大模型；否则走本地模型。OpenClaw 在较新版本中支持关键词路由，可以把这部分业务的 prompt 预设在models.routing中。

我比较常用的路由配置是将本地模型作为默认，把更高阶的云端模型设置为premium，在消息里使用#deepseek前缀即可指定使用云端模型。这样既控制了成本，也保证了复杂任务的质量。

6.2 通过工具扩展 OpenClaw 的能力边界

OpenClaw 的工具集是可以自定义扩展的。官方定义了一套工具接口，你可以在tools/目录下新增一个 JavaScript 文件，继承基础工具类，实现execute方法，然后在配置文件的tools.custom注册即可。

我一个常用的自定义工具是“内网检测”：当我问“今天服务器负载怎么样”时，Agent 会调用一个脚本执行uptime和df -h，把结果整理成文字回复。这个工具代码量不大，但能解决实际问题，比手动 SSH 上去敲命令舒服得多。

延伸场景也很多：定时抓取某个网页内容、自动把收到的消息写入数据库、与日历工具联动管理待办事项等。工具的扩展逻辑都不复杂，关键是理解input和output的数据结构约定。

6.3 从单机到随时可用的建议

如果你希望让 OpenClaw 在 Windows 开机后自动运行，可以用 Windows 任务计划程序创建一个任务，启动 WSL 并执行启动命令。核心思路是在 PowerShell 里先启动 WSL，然后在 WSL 中执行 OpenClaw 的启动命令。这个方案比 WSL 内配置 systemd 服务要简单一点，而且 Windows 任务计划程序的界面操作直观。

在这种配置下，你的 OpenClaw 就真正变成了一个后台打工仔：开机自动起，Telegram 发消息就能指挥它干活，定时任务也会自动执行。整个过程不需要打开终端窗口，Windows 右下角关掉终端完全不影响。

7. 我踩过的坑和最后的几点体会

部署 OpenClaw 这件事，从结果看是一套命令加配置的问题，但过程中真正的难点是你对“AI 智能体”的运行机制理解了多少。它和普通的 Web 服务部署最大的区别在于：输出是不可预测的。同一个 prompt，今天可能完美调用工具，明天可能因为模型更新就出现格式错误。所以部署完成只是开始，持续调试才是常态。

第一个体会：别一上来就追求全功能。先把 Telegram 消息收发跑通，再开工具调用，最后加定时任务。每加一个功能，就测试一个功能，出了问题能迅速定位是哪个模块的事。我一开始贪多求全，一次性把飞书、Telegram、定时任务全开了，结果半夜日志刷屏，排查了好久才发现是定时任务调用一个不存在的工具导致的。

第二个体会：日志是你的第一生产力。OpenClaw 的 debug 日志非常详细，几乎每个工具调用的输入输出都会打印。遇到问题先用日志说话，不要瞎猜。我把日志级别设置为info，日常使用足够，调试时再切到debug，这样避免日志刷太多影响排查。

第三个体会：本地模型的选择要量力而行。如果你的机器只有 8GB 内存且无独显，别硬上 7B 模型，1.5B 模型虽然“笨”一些，但好歹能用。我试过在一台 16GB 内存无独显的笔记本上跑 7B 模型，一条消息的响应时间按分钟算，完全没有实际使用价值。后来换了 3B 模型，速度勉强能接受。

最后想说的是，OpenClaw 这类本地部署 AI 智能体的价值，不在于它有多聪明，而在于它把“对话式 AI”和“本机自动化”打通了。你可以把它当作一个能听懂人话的本地命令行工具，也可以把它当作一个自动执行任务的管家。对我来说，它最有用的场景是：躺在沙发上用手机给机器人发一条消息，让它去电脑上跑个脚本、查份资料、回封邮件，然后把结果汇报给我。这种“手机指挥电脑干活”的体验，确实有一种养了一个数字打工人的感觉。