企业官网建设流程全解析

1. 先搞清楚龙虾是啥，再决定你该本地部署还是云端部署

1.1 "Openclaw"这个丑萌名字，其实是个AI智能体底座

我第一次听到"龙虾"这个外号，是在一个技术群里，有人问"你们的龙虾部署到哪了"，我第一反应以为是外卖。后来才知道，大家说的是Openclaw——一个开源的AI智能体（Agent）编排平台。名字本身挺形象：claw是爪子，open是开放，翻译过来就是"张开爪子干活的开放框架"，叫着叫着就被国内社区叫成了龙虾。

我可以用一句话说清它的价值：大模型是大脑，Openclaw就是连接大脑和手脚的神经系统。你让它读文档、写周报、调接口、回消息、跟Obsidian同步笔记、在Microsoft Teams里干活，它都能把任务拆成多步骤流程，自己调用工具、自己决定下一步，最后把结果交付给你。比起直接在聊天窗口问大模型，它的核心优势在于"自动化执行"——不是给你建议，而是替你完成。

因为项目是开源的，社区也活跃，配置门槛并不算高。就算没写过代码，只要按步骤走完环境准备和部署流程，也能把一台普通电脑变成"7x24小时的AI助理"。所以今天这篇就完全围绕Openclaw展开，覆盖本地部署和火山Arkcloud云端部署两条完整路线，适合刚从"聊天式AI"过渡到"真干活Agent"的入门者，也适合已经装过但反复踩坑的老手。

1.2 本地部署和云端部署，怎么选才是对的？

在动手之前，先解决路线问题。你是打算把Openclaw跑在自己的电脑上，还是放到火山Arkcloud这类云服务器上？这两条路我都走过，体会非常明显。

本地部署的优势很实在：

• 数据和对话记录全留在本机，隐私可控；
• 不依赖公网带宽，内网调用响应快；
• 可以接Ollama这类本地模型，跑小任务不花一分钱。

本地部署的代价也不少：

• 电脑必须常开，否则定时任务全废；
• Windows环境坑多，WSL2、Node版本、路径分隔符都可能出问题；
• 人在外面时，想远程访问还得额外做内网穿透或端口映射，麻烦。

云端部署（以火山Arkcloud为例）恰好弥补了这些短板：

• 7x24小时在线，适合挂定时任务、团队共享；
• 纯Linux环境干净，部署路径反而比Windows顺利；
• 有公网IP，随时随地能连。

代价也明确：要花钱，虽然不少云厂商对新用户有试用活动；以及数据在别人机房，密钥和权限得自己管理好。

我的建议是：如果只是个人试验、处理隐私文档、人基本就在电脑前，先走本地；如果你要让Agent在凌晨定时跑任务、要给团队用、经常不在电脑边，直接上云端。两条路线在后面的章节里都会完整走一遍，先攻本地，毕竟它是门槛最低、也最容易跑通的第一站。

2. 本地部署前的环境体检：不把地基打牢，后面全是坑

2.1 那个经典报错：WSL2环境无法安全验证

先聊一个我在无数求助帖里见过的报错，原话大致是：

Openclaw无法安全验证WSL2环境。请在PowerShell中运行wsl --status。

可以说，这是一个几乎每个Windows用户在本地部署Openclaw时都会撞上的第一道坎。它厉害在哪？安装过程明明很顺利，命令却直接拒绝启动。原因一点也不玄学：Openclaw在执行代码、操作文件系统这类系统级任务时，要借助WSL2作为沙箱环境，用它隔离Agent对Windows本体的影响。如果WSL2没装好、版本不对，或者默认版本还是1，启动检查就会直接亮红灯。

标准排查路径是这样的。先打开管理员权限的PowerShell：

wsl --status

如果提示WSL未安装，执行：

wsl --install

装完重启电脑，系统会自动拉取一个Ubuntu发行版。然后确认版本：

wsl -l -v

看到两个发行版，VERSION列是2，就对了。如果发现是1，执行：

wsl --set-version Ubuntu 2 wsl --set-default-version 2

注意，Ubuntu要替换成你系统里实际的发行版名称。我实测下来，好多人报错不是因为没装WSL，而是系统里同时存在WSL1和WSL2的残留状态，默认版本一直指到1。这时候上面两条命令一起跑，再重新执行wsl --status确认"默认版本：2"，才算真正过关。

还有一个小概率问题：WSL2本质是一个轻量虚拟机，如果BIOS里关了虚拟化功能，它也会处于各种奇怪状态。这个属于硬件层面，排查顺序放在前面步骤之后即可，不用一开始就进BIOS鼓捣。

2.2 Node.js版本别贪新，用nvm管理最省心

Openclaw基于Node.js生态，热搜里也有"node.js官网下载openclaw"，说明很多人是从官网下载Node再装Openclaw的。但我强烈建议不要在官网下载一个固定版本装死，而是用nvm（Node Version Manager）来管理。原因有两个：

第一，Openclaw社区迭代极快，不同版本对Node版本的要求可能不同，固定装一个版本，后面升级容易卡壳。第二，nvm可以在不同项目之间切换Node版本，这里做实验、那里跑生产，互不干扰。

WSL或Linux环境里装nvm：

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash source ~/.bashrc nvm install 20 nvm use 20

如果你的网络访问GitHub不稳定，装失败也没关系，去nvm的GitHub仓库页面手动下载release包，解压后配置PATH同样能生效。装完执行node -v，看到v20.x.x就说明环境就位。

然后顺手把npm镜像源换成国内镜像，不然装依赖的时候你会怀疑人生：

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

这一步在国内环境几乎必做。我见过有人在默认源下安装Openclaw的依赖，一晚上都没装完，换完镜像三分钟搞定。

2.3 大模型从哪来：本地模型、云API还是综合接口

Openclaw本身不带大模型，它只是调度中枢，你得给它接一个"大脑"。这里有三条路线，按成本从低到高排列：

第一条是Ollama本地模型。装好Ollama，拉一个参数量适中的模型，比较典型的是qwen2.5:3b或qwen2.5:7b。零API费用、隐私最好，效果取决于你的内存和显卡。有8G以上显存跑7B很舒服；老笔记本跑3B也能应付文本任务。热搜里的"qwen2.5-3b 关联到openclaw"说的就是这条路线。

第二条是国内云API，比如DeepSeek、豆包这类。价格便宜、效果强，需要申请API Key并充一点额度。DeepSeek的API在很多任务上速度和质量都很能打，个人使用几十块能用很久。热搜词里"deepseek本地部署"也很火，那是另一个方向，本文第4节会讲DeepSeek云端API怎么接到Openclaw上。

第三条是大厂综合API，比如OpenAI兼容接口、火山引擎的大模型服务。生态好、能力强，但价格更高，对多数任务来说属于"杀鸡用牛刀"。

选型判断很简单：新手先用Ollama+3B模型把流程跑通，成本为零，理解完机制之后再按需升级。别一上来就买一堆API额度，先把Agent能跑这件事验证了再说。

3. 本地一键部署实操：从下载到跑通全流程

3.1 安装Openclaw的两种路径：官方脚本与源码

环境准备好之后，安装Openclaw就容易了。社区里最常见的是"本地一键部署"的方式，官方提供安装脚本，下载后自动拉取运行时依赖并生成配置文件。大体流程是：确认Node和WSL2就绪，然后去官方GitHub Releases页面下载对应平台的安装包；或者直接用包管理器做全局安装。以npm为例：

npm install -g openclaw

装完会有命令行工具，再执行初始化命令开始配置。另一种方式是从源码安装，适合想二次开发、看内部实现的人：

git clone https://github.com/openclaw/openclaw.git cd openclaw npm install npm run build

我的建议非常明确：新手先走官方脚本或全局npm包，别碰源码。原因很简单，源码安装等于自找麻烦，要处理构建工具链，Windows和WSL混着用时还可能遇到编译报错，排查成本成倍增加。先让项目跑起来，之后想做插件、写技能时再回头研究源码不迟。

3.2 首次启动：配置文件是重头戏

安装结束后，第一次运行会进入引导流程。前期需要准备的东西有这么几件：

• 存放配置的目录，我一般放在~/.openclaw/下面；
• 模型服务地址，如果走Ollama，填http://localhost:11434；
• 模型名称，比如qwen2.5:3b；
• 如果走云API，还需要API Key。

这里有个非常容易踩的细节：配置里"模型服务地址"和"模型名称"是分开的两个字段。很多人只改了模型名称，服务地址还是默认的OpenAI地址，结果Openclaw怎么都不工作。后面排错章节我会专门讲这个。

如果引导流程没法完全满足你的需求，也可以直接手改配置文件。核心配置一般长这样：

provider: ollama baseUrl: http://localhost:11434 model: qwen2.5:3b apiKey: "" skillsDir: ~/.openclaw/skills

3.3 用一个最简单任务验证整条链路

配置写完之后，启动Openclaw服务端进程，然后下达第一个Agent任务。我推荐的任务是：

请读取当前目录下的README.md，提取三个要点，写入summary.txt。

为什么第一单用这个？因为它把Openclaw的调度、模型的理解能力、文件读写工具全串起来了，又不涉及执行系统命令，权限上最安全。第一次试验别让它删文件、别让它跑脚本，先验证基本链路。

实测中跑不通的原因，七成在模型连接。判断方法很直接：先用curl直接调模型接口。比如测Ollama：

curl http://localhost:11434/api/tags

能看到模型列表，说明Ollama正常。再测生成接口，能返回文本，再回头检查Openclaw配置。这个排查顺序能帮你省掉大量瞎猜的时间。链路通了，你才算是真正把Openclaw在本地部署起来了。

4. 接上你的专属模型：从Qwen到DeepSeek的接入实战

4.1 本地模型方案：Ollama + Qwen2.5

把本地模型接到Openclaw，是性价比最高的一种玩法。模型层和Openclaw配置层分开操作。

模型层先装Ollama：

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

拉取模型：

ollama pull qwen2.5:3b

启动服务，默认监听11434端口：

ollama serve

然后回到Openclaw配置，把provider设为ollama，基础地址填http://localhost:11434，模型名填qwen2.5:3b。

这里要重点提醒一个网络问题：如果Openclaw跑在WSL里，Ollama跑在Windows原生环境，它们之间的地址就不是localhost了。WSL的Linux环境访问Windows宿主机，需要填Windows那台机器的局域网IP，或者把Ollama的监听地址改到0.0.0.0。最省心的做法是让Ollama和Openclaw都跑在WSL里，网络问题直接消失。

我自己的习惯是跑在WSL里后，用一行命令确认IP：

hostname -I | awk '{print $1}'

然后在Openclaw配置里就填这个WSL的IP加端口。多花三十秒，少踩一个深夜排错的大坑。

4.2 云端API模型：DeepSeek接入细节

本地3B模型跑跑简单任务还行，遇到复杂推理经常"力不从心"。这时候接DeepSeek这类云API会舒服很多。

接入流程：

1. 去DeepSeek开放平台注册账号，创建API Key，充值最小额度；
2. 在Openclaw配置里，provider设为deepseek；
3. 填上apiKey；
4. 模型名一般填deepseek-chat或deepseek-reasoner。

DeepSeek的API走OpenAI兼容协议，所以如果你的Openclaw版本里没有deepseek这个provider选项，可以用OpenAI provider，然后手动把baseURL改成DeepSeek的接口地址。两种方式效果等同，看版本支持情况选择。

一条安全建议：API Key属于敏感信息，别直接写进团队共享的配置文件。至少要用单独的环境变量文件，比如在~/.openclaw/.env里写：

DEEPSEEK_API_KEY=sk-xxxx

然后在主配置里引用环境变量。这个习惯帮我避免过一次灾难：有一回我把key明文写进配置，整个目录又提交到了Git仓库，虽然仓库是私有的，但同事clone之后key就等于半公开了，最后只能全部轮换重来。教训很实在。

4.3 多模型配置：主备切换与成本控制

Openclaw支持配置多个模型，这算得上是我最喜欢的功能之一。因为本地模型偶尔会抽风——显存被占、进程挂掉；云API偶尔也会超时或限流。配置一个备用模型能有效防止任务中断。

我的主力配置长这样：

• 主模型：本地Ollama + qwen2.5:7b，零成本，响应快，处理日常任务；
• 备模型：DeepSeek API，处理复杂推理，主模型连续失败时兜底。

配置里设置好优先级或权重字段。但你不用一开始就搞自动切换，建议先手动切几天，摸清楚哪些任务小模型能handle、哪些必须上大模型，再考虑自动降级。自动降级听起来高级，实际上如果你的任务对输出格式要求严格，不同模型切换可能带来格式不一致的问题，反而让下游工具挂掉。循序渐进最稳。

5. 火山Arkcloud云端部署：把龙虾放到云上跑

5.1 云服务器怎么选：配置、镜像、安全组

本地部署跑通之后，云端其实就是换一台永远开机的电脑。我选火山Arkcloud来演示，是因为它对新用户友好、国内访问速度快、Linux实例镜像很干净。

配置选择方面，我的建议是：

• 入门体验：2核4G + Ubuntu 22.04，足够跑Openclaw并接云API模型，但别指望它能跑本地重模型；
• 进阶配置：4核8G，勉强能在云端CPU上跑7B级模型，但推理速度很慢，不怎么实用；
• 磁盘：至少40G，模型文件、容器镜像、日志都会慢慢吃掉空间。

购买时有两个容易忽略的选项，必须重视起来。

第一个是登录方式。一定选SSH密钥对，别用密码。密码登录不仅自己记着累，还会被全网扫描爆破。密钥对一次配好，一劳永逸。

第二个是安全组。刚开机的云服务器默认只开放22端口，这没错。但如果你之后要用浏览器访问Openclaw的Web界面，就得在安全组里手动加一条规则放行对应端口。这个几乎人人都会踩，我第6节还会再提。

5.2 云端部署全流程：从SSH到systemd守护

连接服务器：

ssh root@你的公网IP

接下来都是Linux常规操作：

apt update && apt install -y curl git curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash source ~/.bashrc nvm install 20 nvm use 20 npm config set registry https://registry.npmmirror.com npm install -g openclaw

到这里，云端的安装跟本地Ubuntu几乎没差别。之后就是初始化配置，填模型provider和API Key。

如果你坚持在云端接本地模型，装Ollama也行：

curl -fsSL https://ollama.com/install.sh | sh ollama pull qwen2.5:3b

但我必须说句实话：云服务器CPU推理真的很慢。2核4G的机器跑3B生成长文本，等几分钟很常见。所以云端部署时，我更推荐接云API模型，把云服务器当成一个纯粹的调度中枢，响应速度快，成本也可控。

Openclaw跑起来后，最关键的一步是用systemd把它做成守护进程。不然SSH一断开，进程就跟着没了。这也是"上云部署"和"在云上跑一下"的区别所在。

新建服务文件/etc/systemd/system/openclaw.service：

[Unit] Description=Openclaw Agent Service After=network-online.target [Service] Type=simple User=root WorkingDirectory=/root ExecStart=/usr/bin/openclaw start Restart=always RestartSec=10 Environment=NODE_ENV=production [Install] WantedBy=multi-user.target

ExecStart路径务必用which openclaw确认一下，不同安装方式路径不一样。然后执行：

systemctl daemon-reload systemctl enable openclaw systemctl start openclaw systemctl status openclaw

看到active (running)，说明守护成功。以后开机自动启动、崩溃自动重启，你的龙虾就在云端安家了。

5.3 数据持久化：云端跑，别把会话弄丢

云端部署和本地最大的差别，是本地电脑是你的，数据丢了还能找回来，云服务器如果不做持久化，重置镜像后配置和会话全部归零。

我的三个习惯：

第一，把配置目录和数据目录挂到独立云盘。购买火山Arkcloud时可以加一块数据盘，挂载到/data，然后在Openclaw配置里把数据路径指向/data/openclaw。这样即使系统盘出问题，数据盘还在。

第二，定期备份技能目录和配置。技能是你沉淀下来的资产，可以打包上传到对象存储或私有Git仓库。我的备份脚本很简单，每天凌晨打包一次数据目录，保留最近7天。

第三，升级前先备份。这个放到第7节详谈，但原则现在就可以定：任何大版本升级前，没有备份就不要动。

这些工作看着枯燥，等你要回滚一次配置或者换一台服务器时，你会感谢当时的自己。尤其技能目录里积累的那些工具函数，丢了重写一遍真的肉疼。

6. 远程接入与工具链扩展：让龙虾不止会聊天

6.1 SSH端口转发与HTTPS反代：云端的访问姿势

云端Openclaw跑起来之后，怎么访问它？

开发阶段最轻量的是SSH端口转发。把本地电脑的某个端口转发到云服务器的Openclaw端口：

ssh -L 3000:localhost:3000 root@你的公网IP

然后本地浏览器打开http://localhost:3000，就能看到Web界面。好处是数据全程走SSH加密，不需要额外暴露端口；坏处是隧道断了就得重连。

正式使用的话，建议用Caddy做反向代理加HTTPS。Caddy配置极简，自动申请证书，几分钟搞定。Caddyfile里写：

你的域名 { reverse_proxy localhost:3000 }

然后在云服务器安全组只放行80和443，3000端口继续保持仅内网访问。既安全又体面，手机、电脑、任何浏览器都能直接访问。

这里再次强调安全组：很多人在这一步卡住，服务明明在跑，Web界面就是打不开。先看systemd状态，再在服务器上用ss -tlnp | grep 3000确认端口监听，最后看安全组。按这个顺序排查，定位问题只要两分钟。

6.2 接入Microsoft Teams与Obsidian：让Agent进入日常工作流

Openclaw比较吸引人的一个点，是能把你的Agent接入现有工具。热搜词"openclaw 如何接入microsoft teams"和"openclaw obsidian"对应的就是这类需求。

接入Teams的典型方式：在Microsoft 365后台注册一个应用，拿到应用ID和客户端密钥，然后在Openclaw里创建一个"技能"，让Agent监听Teams频道里的特定指令。比如同事在频道里@openclaw 整理本周客户反馈，Agent跑完之后把结果发回频道。团队协作时大家不用打开Openclaw界面，直接在Teams里指挥Agent，体验很顺。

Obsidian接入则更偏个人知识库场景。可以写一个技能，让Agent读取Obsidian库里的Markdown笔记，根据新资料更新笔记、整理标签、生成每日总结。这个方案适合做"知识库管家"：Agent不再是一个聊天气泡，而是能真正操作你笔记系统的助手。

接入第三方平台的技术要点其实只有两个：一是授权（OAuth或机器人Token），二是Webhook或WebSocket事件监听。Openclaw把这两块都抽象成了模块，你只需要在配置里填对信息。但千万注意：Token绝对不要写进公共代码或公开仓库，这是安全底线。

6.3 技能目录：把重复任务沉淀成Openclaw技能

Openclaw的"技能"概念很像编程里的函数封装。第一次让Agent完成任务，可能只是对话式的一次性行为；但如果把这个任务的执行流程写成技能，之后就能反复调用。

我写过最有价值的一个技能叫"周报整理"：读取多个来源的笔记，按项目归类，生成周报Markdown，推送到指定目录。第一次编写花了一小时，之后每周重复利用，省下来的时间早就回本了。

技能目录在配置里指定，一般是一个文件夹，里面是描述文件加可执行脚本。Openclaw会在合适的时机自动选择调用这些技能。对新手来说，这个概念可能有点抽象，但你可以从最简单的"读取文件并总结"开始，用到顺手了再逐渐加工具。记住一个原则：凡是你在对话里让它干过两次以上的事，都值得沉淀成技能。

7. 部署完之后的维护清单与踩坑实录

7.1 升级与备份的节奏

Openclaw迭代快，功能更新频繁，但配置格式也可能变动。我的升级节奏很固定：

先备份配置和数据目录，再执行升级，升级后立刻跑一个验证任务，确认核心流程没被破坏，然后摘要把这次升级记录到自己的跟进清单里。

全局npm包的升级命令很简单：

npm update -g openclaw

源码安装的话，去仓库拉最新代码重新build。无论哪种方式，升级前花两分钟看一眼官方更新日志，确认有没有破坏性变更。省这一眼，可能换来一整晚的排错。

7.2 常见故障速查表

我整理一份实际部署中遇到过的故障表，按频率排序：

这张表其实是从几十次深夜排错里提炼出来的。每次出问题，先默念"状态、日志、配置、网络"，按顺序查，基本都能定位。

7.3 我个人踩过且值得分享的三个坑

第一个坑：在Windows下直接跑Openclaw，不用WSL。我当初觉得装好了就没事，结果Agent操作文件时一直报路径解析错误，因为它把Windows路径当成Linux路径了。最后把所有东西迁进WSL里，世界安静了。所以热搜里那个"Openclaw无法安全验证WSL2环境"的报错，真不是开发者在小题大做，它是在保护你。

第二个坑：把API Key写进配置文件，然后整个目录又进了Git仓库。虽然仓库私有，但团队里有人clone后，key就等于半公开了，最后全部轮换。现在我所有密钥一律走环境变量，配置文件里只留引用名。

第三个坑：云端安全组忘记放行端口。部署完systemd，Web界面怎么都打不开，远程排查了半小时，最后发现就是安全组没开。这个错误低级到不值得犯第二次，所以我把排查顺序写死在脑子里：先看服务状态，再看端口监听，最后看安全组。

7.4 给后来者的几句实在话

最后不打算做总结，只想补几句真话。Openclaw这类AI Agent框架，真正值钱的从来不是安装过程，而是你如何设计它要执行的任务、如何选型模型、如何把重复劳动沉淀成技能。工具迭代再快，方法论是通用的——先小步验证，再逐步放大，出了问题按顺序排查，永远比满屏猜测有效。

这篇指南从WSL2环境讲到了火山Arkcloud云端守护进程，从Ollama本地模型讲到了DeepSeek云API，基本覆盖了从零到能用的全过程。希望你装上龙虾之后，少走几次弯路，至少不用再围在WSL2那个报错前面挠头了。