企业官网建设流程全解析

上篇我们把 WSL2 和 Ubuntu 从零折腾到能跑起来，说实话那只是万里长征第一步。部署 OpenClaw 真正见功夫的地方，是今天要讲的这两件事：核心配置和模型对接。OpenClaw 这个开源个人 AI 助理框架，环境装好只是给了它一副躯壳，配置文件才是它的神经系统，而模型对接则是让它开口说话的大脑。

如果你已经按照上一篇把 WSL2 和 Ubuntu 准备就绪，这一篇就直接照着抄作业。如果你正好卡在配置半天不生效、模型怎么都连不上的阶段，那更要往下看。我这篇记录的坑和排查思路，主体上比官方文档实在得多。

我自己在 WSL2 + Ubuntu 24.04 上跑 OpenClaw 已经小半年了，从最早只会让它讲两句废话，到现在接上本地模型、Teams 和 Obsidian 知识库，中间踩过的坑两只手数不过来。这篇下篇，我打算按“环境复查 → 核心配置 → 模型对接 → 问题排查 → 扩展玩法”的逻辑来写，核心目标只有一个：让你的 OpenClaw 真正跑起来、说得上话。

1. 项目概述与整体思路

1.1 OpenClaw 到底是个什么项目

OpenClaw 是一套开源的个人 AI 助理框架，前身是 Clawdbot / Moltbot 那一系的项目。你可以把它理解成一个“AI 大脑的操作系统”：它本身不产生智能，而是把大模型的对话能力、工具调用能力和你本地环境的各种资源组合起来，让 AI 真正能帮你干活。和纯聊天机器人不一样，OpenClaw 支持配置多个“适配器”和“扩展”，比如让它读写本地文件、调用命令行、访问笔记库、接入办公软件，这些都是通过配置文件来管理的。

打个不那么严谨的比方：大模型就像刚招进来的高材生，脑子里有货但不懂你公司的规矩；OpenClaw 是带他的老员工，负责告诉他“文档放哪、找谁签字、活儿怎么干”；配置文件就是那本员工手册，你和 AI 之间的所有协作规则都在里面写着。

1.2 为什么部署在 WSL2 + Ubuntu 上

很多人问过我，Windows 上直接跑不行吗？能跑，但很难受。OpenClaw 这类项目对 Linux 的生态依赖很深，文件权限、shell 调用、进程管理、Docker 联动，这些在纯 Windows 环境下总会冒出一堆奇怪的问题。WSL2 的妙处在于：它既是真正的 Linux 内核，又能和 Windows 文件系统互相访问，等于同时拿到了 Linux 的稳定和 Windows 的便利。

我之所以把模型对接放在下篇的 C 位，是因为 OpenClaw 的“核心配置”本质上就是在回答三个问题：用谁的大脑（模型）、以什么身份工作（Agent 身份）、能做哪些事（扩展与权限）。这三个问题不解决，环境装得再漂亮也是空壳。所以这篇你不需要再折腾安装包，而是跟着我把配置文件和模型通道逐一理顺。

1.3 适合谁参考这篇内容

这篇内容适合两类人。第一类是已经在（上）篇把环境装好、正要进入配置阶段的新手，你可以直接照着下文操作，我尽量把每一步的前因后果说清楚，免得你配置完了不知道自己在配什么。第二类是已经能跑起来但总觉得不对劲的老手——比如改了配置不生效、换模型老报错、想接本地模型不知道怎么下手，那你重点看第 3 节和第 5 节，大概率能找到对应解法。

2. 进入核心配置前的环境复查

2.1 确认 WSL2 版本与 Ubuntu 状态

正式开始配 OpenClaw 之前，我强烈建议你先花两分钟在 PowerShell 里跑一条命令，确认自己的 WSL 环境没有埋雷。打开 PowerShell，输入：

wsl --status

这条命令会告诉你当前默认的 WSL 版本。注意看输出里有没有“默认版本：2”字样，如果显示的是 1，那你后续跑 OpenClaw 大概率会遇到各种 IO 和网络兼容问题。用下面这条命令可以列出所有发行版和各自对应的版本：

wsl -l -v

正常情况下，Ubuntu 那一行应该是“2”。如果显示“1”，执行转换命令：

wsl --set-version Ubuntu 2

转换过程会花几分钟，期间别关终端。这一步属于“查漏补缺”，但非常重要——OpenClaw 对文件系统事件监听的依赖比较深，WSL1 和 WSL2 的行为差异很容易导致配置文件修改后无法热加载，到时候你会以为是自己配错了，实际上是你跑在旧内核上。

2.2 顺手处理三个 Ubuntu 高频小问题

很多人在配 OpenClaw 之前，会被 Ubuntu 底层的小毛病卡住，我这里把出现频率最高的三个一并说掉。

第一个是“Ubuntu 忘记登录密码”。WSL 里的 Ubuntu 默认进入时不需要密码，但如果之前手动设置了 root 密码又忘了，可以在 PowerShell 里执行wsl -u root直接以 root 身份进系统，然后运行passwd 你的用户名重置。这个问题在社区里问的人特别多，实际上根本不用重装系统。

第二个是“Ubuntu 中文输入法怎么设置”。如果你只在终端里操作 OpenClaw，完全不需要中文输入法。但如果打算用 VS Code 连进 WSL 写配置、或者用图形界面查看日志，可以考虑装搜狗输入法或 fcitx5。这一步不会影响 OpenClaw 本身，属于纯个人体验优化，我建议新手先跳过，等核心配置跑通后再回来折腾。

第三个是 apt 源的问题。国内服务器访问 Ubuntu 默认源经常超时，建议先把源换成国内镜像。Ubuntu 24.04 的源配置在/etc/apt/sources.list.d/ubuntu.sources，操作前先备份，然后替换成你所在网络环境下访问速度较快的镜像源，执行sudo apt update验证。这一步不做，后面安装 Node.js 依赖或者 Python 包时会让你怀疑人生。

2.3 WSL2 里显卡驱动到底怎么算生效

热词里有好几个关于“WSL2 英伟达驱动”“WSL2 安装 CUDA”的问题，我在这里把逻辑一次说透。WSL2 里的显卡驱动不是装在 Ubuntu 里的，而是装在 Windows 侧。你只需要在 Windows 上安装 NVIDIA 官方驱动（版本号 471.11 以上），WSL2 里就能直接调用 GPU 跑 CUDA 程序。很多人的误区是跑到 Ubuntu 里执行sudo apt install nvidia-driver-xxx，结果装了半天不生效，还把系统搞乱。

验证驱动是否生效，在 Ubuntu 终端里直接运行：

nvidia-smi

如果能看到显卡型号和驱动版本，说明 GPU 已经可以被 WSL2 使用了。如果提示找不到命令，不用急着装，先确认 Windows 侧驱动是否已经装好，再考虑在 WSL 里装 CUDA Toolkit。OpenClaw 对接本地模型时，GPU 能不能用直接决定推理速度，这一步复查一下后面不闹心。

3. 核心配置深度拆解

3.1 配置文件在哪里、什么时候生成

OpenClaw 的配置文件不是安装时自动生成的，而是首次启动后才生成的。很多新手找半天找不到配置文件，就是因为还没启动过。安装完成后，第一次在终端里执行启动命令，让它跑一下，它会在用户主目录下生成配置目录。

不同版本存放的位置略有差异，但大体都在~/.openclaw/或~/.config/openclaw/下。如果用 find 命令全局搜一下更直接：

find ~ -name "*claw*" -type f 2>/dev/null

看到输出里有claw.json、.env之类的文件，基本就找到了。我建议熟读配置文件之后再正式使用，否则默认配置只会给你一个能说话的空壳。

3.2 核心配置项逐字拆解

打开配置文件后，你会发现它其实是一个 JSON 或 JSONC 格式的结构。核心配置项主要分四块：身份、模型、记忆、扩展。身份配置决定 OpenClaw 怎么称呼你和怎么自称：

{ "identity": { "human": "你的名字", "agent": "Claw" } }

这里的human是你自己的称呼，agent是 AI 的名字。后续所有对话里，AI 会依据这两个字段区分彼此。不要小看这个配置，它影响着 AI 的上下文记忆格式——它需要知道哪句话是“主人”说的，哪句话是它自己回复的。

模型配置是重头戏，基础结构如下：

{ "model": { "provider": "anthropic", "name": "claude-sonnet-4-20250514", "apiKeyEnvVar": "ANTHROPIC_API_KEY" } }

provider决定走哪条 API 通道，name决定具体用哪个模型实例，apiKeyEnvVar则是告诉 OpenClaw 去读哪个环境变量来获取密钥。这里有个细节值得注意：官方推荐用环境变量名而不是直接把密钥写进配置文件，是有安全考虑的。配置文件可能会被同步到网盘或提交到 Git 仓库，密钥一旦泄露就是灾难。

记忆配置决定了 AI 能否跨对话记住你的偏好：

{ "memory": { "enabled": true, "storageDir": "./memory" } }

如果关闭记忆，每次对话都是“初见”；开启后，AI 会把重要信息写入本地存储文件，下次对话自动加载。我个人建议开启，但要以周为单位清理存储目录，否则文件会越来越大，加载速度越来越慢。

扩展与权限配置长这样：

{ "extensions": ["filesystem", "shell", "mcp"], "permissions": { "shell": ["ls", "cat", "grep"] } }

这里的逻辑是：你可以给 AI 开放本地文件读取和 shell 命令执行权限，但一定要限制命令白名单。我在初期犯过一个错，给 AI 开了全部 shell 权限，它执行删除命令时我吓得一身冷汗。开源项目再靠谱，权限控制也得攥在自己手里，这是原则问题。

3.3 API 密钥的安全加载方式

密钥管理这块我要单独拎出来强调，因为它太容易被忽略。配置文件里尽量不要写明文密钥，推荐做法是把密钥放在.env文件里，然后在配置文件里指定读取的环境变量名。

在~/.openclaw/目录下创建.env文件：

touch ~/.openclaw/.env chmod 600 ~/.openclaw/.env

chmod 600确保只有当前用户能读写，这一步很多人会漏掉。然后用文本编辑器写入：

ANTHROPIC_API_KEY=sk-ant-xxxxxx

OpenClaw 启动时会自动加载这个文件。如果你是手动export环境变量的流派，也可以把密钥写进.bashrc，但.env文件的方式更干净、更便于后期维护，换机器部署时只需要迁移一个文件。

3.4 配置生效与验证方法

改完配置后，最重要的一步是验证是否生效。我见过太多人改完配置就跑回来问“怎么还是老样子”，十有八九是没重启服务。OpenClaw 的配置文件多半是在启动时读取的，改完必须完全停掉进程再重启：

pkill -f openclaw openclaw start

启动后观察日志，如果看到加载配置文件的路径和模型初始化成功的提示，说明本次配置已经生效。我习惯在每次修改配置后用一行命令确认当前加载的模型：

openclaw status

如果输出里显示了模型名称和 provider 信息，那就是配好了。这一步养成习惯，能省掉大量无头排查的时间。

4. 模型对接实战

4.1 官方推荐路线：对接 Anthropic Claude

OpenClaw 对 Anthropic Claude 的支持最完善，因为项目本身就有很深的 Claude 基因。去 Anthropic 控制台申请 API Key，创建密钥后把它填进.env文件的ANTHROPIC_API_KEY字段，然后确认配置文件里模型参数指向一个有效型号：

{ "model": { "provider": "anthropic", "name": "claude-sonnet-4-20250514", "apiKeyEnvVar": "ANTHROPIC_API_KEY" } }

这里提醒一句：API Key 申请后要立即复制保存，控制台不会二次展示完整密钥。我曾经就因为没保存直接关掉页面，白白重新生成了一次。配置完成后，先跑一句最简单的测试：

openclaw run "你好，请介绍一下你自己"

如果正常返回一段自我介绍，说明 Claude 通道已经打通。接下来就可以进入参数调优环节了。

4.2 国产模型方案：对接阿里云百炼 Qwen 系列

国内开发者对接 Claude 会遇到网络延迟和访问稳定性的问题，所以备选方案是阿里云百炼平台的千问系列。OpenClaw 支持 OpenAI 兼容协议，而百炼平台恰好提供 OpenAI 兼容的接口，所以对接方式非常接近。

先去阿里云百炼控制台开通模型服务，申请 DashScope API Key。然后在 OpenClaw 配置里新增一个 provider 指向百炼端点：

{ "model": { "provider": "openai", "name": "qwen-plus", "baseURL": "https://dashscope.aliyuncs.com/compatible-mode/v1", "apiKeyEnvVar": "DASHSCOPE_API_KEY" } }

这里baseURL是关键参数，它告诉 OpenClaw “去哪个地址请求模型服务”。很多人的配置死活不生效，就是因为没填这个字段，默认走了 OpenAI 官方地址。填好后再把DASHSCOPE_API_KEY写进.env，重启验证即可。

Qwen 系列对中文的理解能力和工具调用能力都不错，日常对话和轻量任务完全够用。如果你是首次配置 OpenClaw，用 Qwen 当入门模型其实比 Claude 更省心，因为访问稳定、报错少，可以先跑通整个链路再切换更强的模型。

4.3 本地模型方案：Ollama + qwen2.5-3b

热词里有一条“qwen2.5-3b 关联到 openclaw”，这正好是本地模型对接的典型案例。本地模型的优势是数据不出门、无 API 费用、响应不受网络影响。我的建议是：先装 Ollama，再在 Ollama 里拉取 qwen2.5:3b。

安装 Ollama 很简单：

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

拉取模型：

ollama pull qwen2.5:3b

然后在 OpenClaw 配置文件里指到本地 Ollama 服务：

{ "model": { "provider": "ollama", "name": "qwen2.5:3b" } }

Ollama 默认监听http://localhost:11434，OpenClaw 会自动探测到这个端口，一般不需要额外配置 baseURL。启动后测试一句中文对话，如果响应速度在可接受的范围内，说明本地链路已经通了。3B 模型的智能水平肯定不如云端大模型，但胜在干净利落——我通常用它做配置验证和日常测试，不浪费云端配额，等要处理复杂任务时再切到云端模型。

4.4 模型参数与 Agent 行为调优

模型对接成功只是开始，真正影响体验的是参数调优。OpenClaw 配置里常见的几个参数值得逐一说明：

这里我最想强调的是 temperature 和工具调用的关系。如果允许 OpenClaw 执行 shell 命令，而 temperature 太高，模型可能在解析命令时“创意发挥”——比如把rm -rf的参数搞错位置，后果不堪设想。我个人的经验是：agent 场景把 temperature 压到 0.2 以下，宁可回答枯燥一点，也不能让它自由发挥。

4.5 对接成功的验证方法

每次改完模型配置，都要验证三件事：模型能通、配置正确、Agent 能干活。我的验证流程是：

第一，执行openclaw status，确认当前加载的模型和 provider 正确。第二，执行一句普通对话，确认模型能正常返回。第三，执行一句涉及工具调用的指令，比如“帮我列出当前目录下的所有文件”，观察 AI 是否真的调用了 shell 并返回结果。

第三步尤为重要，因为它验证的不只是模型连通性，而是整个 Agent 链路。如果模型返回了纯文本“当前目录的文件有 abc.txt”而不是真正去执行命令，说明工具调用没生效，需要检查权限配置和模型是否支持 function calling。

5. 常见问题与排查实录

5.1 “无法安全验证”报错怎么处理

热词里有一条“openclaw 无法安全验证”，这是模型对接阶段最容易遇到的报错，现象是启动后请求 API 时提示证书验证失败。根据我的排查经验，这个错误有三大诱因。

第一是系统时间不对。WSL2 如果长时间休眠再唤醒，系统时间可能漂移，导致 HTTPS 证书校验失败。在 Ubuntu 里执行：

sudo ntpdate ntp.aliyun.com

强制同步时间后再试。第二是 API 端点地址填错或代理冲突，导致请求被指向了错误的服务器。检查baseURL是否拼写正确，以及是否有残留的 HTTP_PROXY 环境变量在干扰。第三是根证书过期，可以更新系统证书：

sudo update-ca-certificates --fresh

这个报错我当年卡了整整一下午，最后发现就是 WSL2 休眠后的时间漂移问题。所以排查顺序建议是：先看时间，再看地址，最后动证书。

5.2 WSL 安装错误 0x80070424

热词里那条“分发名称: 'ubuntu' 错误代码: 0x80070424”也是高频问题。这是 Windows 侧的 WSL 组件没有正确安装或版本过旧导致的。修复方法分三步：

首先，在 PowerShell（管理员模式）里启用两个 Windows 功能：

dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart

然后重启电脑，这一步不能省。重启后在 PowerShell 里执行：

wsl --update

把 WSL 内核更新到最新版，最后再执行wsl --set-default-version 2。这条组合命令能解决绝大多数 0x80070424 问题，本质就是 Windows 的虚拟机平台没开全。顺带提一句，如果安装的是精简版 Windows 系统，可能需要先补系统组件，否则即使命令执行成功，WSL 也可能起不来。

5.3 显卡驱动“卸载不掉”“不生效”的真相

热词里关于显卡驱动的提问特别多，比如“ubuntu 显卡驱动卸载不掉”“WSL2 英伟达驱动生效吗”。这两类问题放在一起看特别有意思——前者是在 Ubuntu 里装错了驱动，后者是搞不清 WSL2 的驱动机制。

我前面已经强调过，WSL2 里不要安装 NVIDIA 驱动，它用的是 Windows 侧驱动。但如果你已经在 Ubuntu 里装了错误的驱动导致系统异常，卸载方法如下：

sudo apt purge nvidia-* sudo apt autoremove

卸载后重启，WSL 会恢复到默认的显示驱动。然后在 Windows 侧确保 NVIDIA 驱动是最新版，再回到 WSL 里执行nvidia-smi验证。这个“先卸载、后验证”的流程，能解决 90% 的显卡相关困惑。装 CUDA Toolkit 则建议通过官方 runfile 或 conda 安装，不要用 apt 装，否则极其容易把系统依赖搞乱。

5.4 环境变量配置错误导致命令找不到

热词里有“ubuntu 环境变量配置错误”，如果是在改.bashrc或profile时把 PATH 弄坏了，会导致所有命令都提示“command not found”。我在部署 OpenClaw 时也犯过这个错——手滑把export PATH=/usr/bin后面的原有路径覆盖了。

修复方法是：由于当前 shell 的命令基本不可用，需要用绝对路径调用系统命令：

/usr/bin/env PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin bash

这条命令会用一份干净的 PATH 重新打开 bash，然后再把.bashrc里的错误配置改正。如果你连export都用不了，可以考虑直接用 Windows 侧的 PowerShell 执行wsl -u root进入 root 环境修复文件。这个问题的教训就是：改环境变量之前，先备份原文件，改完先开新终端测试，再关旧终端。

5.5 常见问题速查表

这张表是我实际使用中积累出来的，每一条都对应我或身边朋友踩过的真实坑。配置 OpenClaw 不复杂，复杂的是在出错时能快速定位问题层级——先操作系统，再评估网络，然后才动配置。

5.6 两个独家避坑技巧

最后送两个自己摸索出来的私货技巧。第一个：OpenClaw 的日志文件是最好的老师。遇到任何诡异问题，先翻日志，别急着改配置。日志路径通常在~/.openclaw/logs/下，用tail -f实时观察，能直接看到模型请求发出去了没、响应返回了什么、在哪一步报错。很多时候你觉得自己配置写错了，其实是网络超时或 API 端限流，日志里写得一清二楚。

第二个：配置模型时一步到位是大忌。我见过太多人一上来就同时配 Claude + Qwen + 本地模型，结果报错时根本没法判断是哪个链路出了问题。正确的姿势是“单模型起步”：先把一个模型跑到稳定，再加第二个，逐个验证。多模型切换应该是稳了之后的便利，而不是起步阶段的负担。

6. 扩展场景与应用建议

6.1 接入 Microsoft Teams：让助理进入办公群

OpenClaw 对接 Teams 后，可以直接在聊天群里呼叫 AI，让它查资料、整理会议纪要，甚至执行授权范围内的小任务。原理是通过 Teams 的机器人应用接口，在 Azure 门户创建一个 Bot 服务，拿到 App ID 和 Client Secret，然后在 OpenClaw 的适配器配置里填进去。配置成功后，AI 会以机器人身份出现在指定的团队频道里。

我建议把邮件热词里的“openclaw 如何接入 microsoft teams”记下来，这个需求确实高频。需要注意的是：Teams 机器人需要公网可达的端点来接收消息，本地开发时可以用临时隧道解决，生产环境建议部署到云服务器。

6.2 接入 Obsidian：用本地知识库喂给 AI

如果你在用 Obsidian 管理笔记，可以把 OpenClaw 指向你的笔记库，让它基于你的笔记内容回答问题。原理是配置 filesystem 扩展，把笔记目录挂载为 AI 的文件空间。我自己的用法是：把项目复盘、技术备忘、读书笔记都放在 Obsidian 里，然后让 OpenClaw 根据这些内容做周报汇总，或者回答“我之前是怎么解决那个网络问题的”。

这个功能极其强大，但也最需要谨慎。笔记库往往包含个人信息和敏感内容，给 AI 开放读取权限意味着这些内容会经过模型处理。用本地模型承接这部分任务是最佳实践——数据不出门，又能享受知识库的便利。

6.3 部署到云服务器：从本地玩具到常驻服务

本地跑 OpenClaw 只是玩具阶段，真要让它全天候可用，建议部署到云服务器。如果你没有现成的服务器，可以用阿里云的免费试用套餐，一个轻量应用服务器足够跑 OpenClaw 和本地小模型。部署的核心要点有三个：用 systemd 把 OpenClaw 注册为开机自启服务；用 Nginx 反向代理把 Web 端口暴露出去；用安全组限制访问来源 IP。

这套组合下来，你的个人 AI 助理就真正“在线”了，随时随地能通过网页或 API 调用。很多人把 OpenClaw 当命令行玩具用，其实它的设计初衷是常驻的 AI 协作者，部署到服务器后体验会完全不同。

6.4 后续还可以怎么玩

OpenClaw 的生态里还有不少值得折腾的方向。一是通过 MCP（Model Context Protocol）接入更多外部工具，比如让 AI 直接查询数据库、调内部 API；二是编写自定义技能，把重复性工作封装成 AI 可以直接调用的指令；三是结合定时任务让 AI 每天早上自动汇总新闻发到你的邮箱。

我自己的下一步计划是把 OpenClaw 和家里的智能家居网关打通，让 AI 能根据我的日程自动调节灯光和空调——这类想象的空间很大，但基础还是先把配置和模型链路打扎实。

6.5 个人体会与建议

在 WSL2 里跑 OpenClaw 这半年，我最大的体会是：配置别追求一步到位，先把最简单的对话跑通，再逐步加扩展。很多人在第一天就急着接 Teams、挂知识库、上多个模型，结果出了问题根本不知道从哪排查。我更推荐的路径是：先用云端模型跑通对话，再加本地模型，然后逐步接入工具和外部服务，每一步都验证稳定了再走下一步。

另外一个小技巧是：每次改配置前，先复制一份配置文件备份。别觉得麻烦，OpenClaw 的配置文件改错了不会自动回滚，手动备份能让你在折腾时始终有退路。用我自己的话说，部署 OpenClaw 就像装修房子——硬装（环境）要扎实，布线（配置）要清晰，家电（模型）要试过再买。这篇的配置和对接方法，就是帮你把最核心的“布线”和“家电调试”做完，剩下的软装，就看你自己的想象力了。