企业官网建设流程全解析

拿到一个新的 AI 助手项目，第一件事永远是纠结它该住哪。OpenClaw 这种个人 AI 助手框架，官方定位就是“可以在任何地方运行”，但这句“任何地方”恰恰是最没用的信息。我自己最开始直接扔在自己的主力笔记本上，跑了两个礼拜，后来因为一次出差断电，助手当场失联，才认真把“本机 vs 云部署”这件事捋了一遍。

这篇东西不会跟你讲“各有优劣、视情况而定”这种废话。我会直接拆清楚：什么场景下本机部署是正确选择，什么场景下你必须上云，以及两条路各自完整的实操方案、关键参数和后期维护手段。同时我也会分享自己在迁移过程中踩过的坑和总结的排查经验。如果你正准备给 OpenClaw 找地方住，这篇文章应该能帮你少走不少弯路。

1. 先搞清楚核心问题：你打算让它干嘛

在纠结装在哪之前，先回答一个问题：你部署 OpenClaw，是打算让它偶尔响应你的指令，还是希望它像一个真正的“助手”一样随时在线？

这个问题的答案，直接决定了后面所有技术选型的方向。

1.1 自用、调试、开发为主：本机是首选

OpenClaw 本质上是一个基于 Node.js 运行的个人 AI 助手框架，它能接入多种聊天平台，具备多角色人设、记忆、定时任务等能力。如果你主要的使用场景是：

• 本地写代码时让它帮忙总结文档、生成脚本、做点自动化的事情；
• 频繁修改角色配置、测试新的行为逻辑；
• 不需要长时间挂机，只在你想用的时候打开它。

这种情况下，本机部署是效率最高的方案。理由很简单：没有额外的网络跳跃，没有服务器权限管理，改完配置立刻重启就能看到效果。开发调试阶段，把整个项目放在本地是最舒服的。

1.2 常驻、聚合、对外服务：云部署是刚需

但如果你打算让 OpenClaw 接入某个聊天群组，或者作为团队的自动化入口，又或者希望它“每天凌晨定时执行一次信息汇总”，情况就完全不一样了。这些场景有一个共同前提——它得一直活着。

本机部署最大的致命伤就是“它依赖于你本机的电力与网络”。一旦你合上笔记本、家里停电、出门连不上网，助手便直接消失。我之前就是没想清楚这一点，以为“谁会在半夜用助手啊”，结果偏偏有一次人在外面，需要在群组里调取一份资料，助手却跟着家里的路由器一起罢工了。

所以，我建议你在动手部署之前，先做个最简单的判断：

1.3 一个实用的自测清单

我在做决定前，给自己列了 5 个问题，你也可以照着过一遍：

1. 如果这台机器断电 2 小时，会造成什么后果？
2. 除了我自己，还有没有别人需要使用这个助手？
3. 我的数据里是否包含非常敏感的个人信息？
4. 我是否有云厂商的服务器资源可以复用？
5. 我是否愿意花时间维护一台 Linux 服务器的运行环境？

把答案写下来，再去翻第 2 节和第 3 节的详细方案，基本不会选错。

2. 本机部署：把 AI 助手放在自己眼皮底下

本机部署的好处是直观、零成本、试错成本低。但“简单”不代表“随便装一下就能跑”，它其实有一些值得注意的细节。

2.1 环境准备：版本和依赖要一次到位

OpenClaw 的底层是 Node.js，所以第一步是确认本机的 Node 版本。官方文档一般会注明“建议使用 Node.js 20 及以上版本”，低于这个版本时，某些依赖可能安装失败或运行时报错。

node -v npm -v

如果版本过低，我建议直接使用版本管理工具来安装多版本 Node，而不是去动系统自带的版本。这样做的好处是不会影响你本机其他项目的依赖环境，也方便后续升级或切换。

接着需要准备 Git：

git --version

没有的话就装一下。后面的安装动作都是从代码仓库拉取源码，所以 Git 是必选项。

2.2 安装与初始化：完整跑通前的三个要点

项目本身的安装流程不复杂，按顺序执行即可：

git clone <项目仓库地址> cd openclaw npm install cp .env.example .env

这里有几个关键点，很多人第一次装的时候容易卡住：

依赖安装速度慢。npm 默认源有时候确实不给力。我一般会临时切换镜像源，或者直接设置全局源地址，能明显提升安装速度。不展开讲具体地址，你在搜索引擎里找“npm 镜像源”就很清楚了。

配置文件里的模型接口地址与密钥。OpenClaw 本身不生产内容，它需要对接大模型服务商的接口。配置文件中的 API 地址、Key、模型名都要提前确认好。如果本机有代理类工具，还容易出现“本机能访问但如果换台机器就失灵”的陷阱，这点后面会详细说。

首次启动之后先看日志。启动命令一般是：

npm run start

看到“started successfully”或类似输出再放心，不要只看终端没报错就以为万事大吉。有时候端口冲突会被 Node 吞掉，表现为反复重启，不观察日志很难发现。

2.3 让它在后台安静地跑：三种守护方案

如果决定在本机常驻，第一步就是要让 OpenClaw 脱离终端窗口。否则你一关终端，进程就跟着没了。以常见的 Linux/macOS 环境为例，我按推荐程度排列三个方案：

方案一：pm2

npm install -g pm2 pm2 start src/index.js --name openclaw pm2 save pm2 startup

pm2 的好处是自带日志管理、内存监控、自动重启。即使进程崩溃，它也会在几秒内重新拉起来。缺点是对新手来说多了一个工具需要了解。

方案二：systemd

如果你不想引入额外依赖，使用 Linux 自带的服务管理工具是最稳的。写一个服务配置文件，指向 OpenClaw 的启动命令，然后通过 systemctl 管理它的启停。这样开机自启、崩溃自愈都由系统接管，可靠度高很多。

方案三：screen / nohup（不推荐长期使用）

nohup node src/index.js > openclaw.log 2>&1 &

这个方案适合快速测试，但不适合长期跑。因为一旦进程崩溃，没有机制把它拉起来。而且日志文件如果长期不切割，很容易涨到几个 GB。

2.4 本机部署的真实短板，以及如何补救

本机部署最大的问题不是性能，而是“不确定性”。我总结下来主要是这三类：

• 断电和断网。这是硬伤，没有任何本机层面的技术方案能解决。
• 休眠与后台限制。笔记本合盖后默认会休眠，进程直接冻结。你需要去系统设置里调整“合盖不休眠”或“外接电源时保持唤醒”。
• 网络环境变化。本机切换 WiFi、移动热点时，公网 IP 变化可能导致平台回调失效。尤其是接入聊天平台时，很多平台要求配置回调地址，如果你用的是动态公网 IP，地址一换，整个链路就断了。

针对网络变化的问题，一个常见的补救方案是配置内网穿透工具，但这类工具通常也依赖一台额外的公网服务器，既然都要用到公网服务器了，那还不如直接考虑云部署。

所以我的建议是：如果你想长期稳定运行，就别费劲在本机上折腾这些补丁方案了，直接上云更省心。

3. 云部署：让 AI 助手 7x24 在线

云部署本质上就是租一台永远开着的电脑，然后把 OpenClaw 放在上面跑。这听起来比本地部署复杂，但实际走一遍你会发现，核心操作就那么几步。

3.1 云主机选型：别买贵，也别抠门

OpenClaw 本身的资源占用不算高。它是 Node.js 程序，主要内存消耗在加载模型上下文和维持连接上。我实际测试下来，常驻内存大约在 300-500 MB 之间，有消息进来时会短暂上涨。

所以，从成本角度考虑，一台入门级的云主机（比如 2 核 2G 内存）就足够跑了。选型时需要额外关注四个点：

不要一上来就买高配。我见过有人用 8 核 16G 的机器跑一个文本助手，纯属浪费。真到资源不够的那天，云厂商一般都支持在线升配，到时再升级也不迟。

3.2 基于 Docker 的一键部署方式

如果项目提供了官方镜像，那 Docker 就是最舒服的部署方式。它的好处是把 Node 版本、依赖安装、环境变量全部封装进镜像里，不会因为系统环境差异导致跑不起来。

在服务器上依次执行：

# 安装 Docker（看官方文档即可） curl -fsSL https://get.docker.com | sh # 创建项目数据目录 mkdir -p ~/openclaw/data # 拉到镜像并启动（示意，具体镜像名和参数以你自己的项目文档为准） docker run -d \ --name openclaw \ --restart unless-stopped \ -e TZ=Asia/Shanghai \ -v ~/openclaw/data:/app/data \ -p 3000:3000 \ openclaw/openclaw:latest

注意几个关键点：

• -v挂载的数据目录非常重要。容器本身是临时性的，镜像升级或容器重建后，只有挂载出来的数据卷会保留。OpenClaw 的记忆、配置、历史对话都放在数据目录里，千万不能省这行。
• -p 3000:3000是端口映射。把容器的端口暴露到宿主机，方便后续通过 API 或管理界面访问。
• --restart unless-stopped是 Docker 的自动重启策略。机器重启后容器会自动拉起，进程崩溃也会自动重启。

如果是第一次跑，我建议先用前台模式跑一次，确认日志无误后再改成后台模式：

docker logs openclaw

看到正常的启动日志后，再docker restart openclaw重新启动一下，确保重启后状态良好。

3.3 不使用 Docker 时，用 systemd 接管进程

如果你不想用 Docker（比如想把依赖直接装进系统），那也一样需要处理“开机自启”和“进程守护”这两件事。我以 node 直接启动为例，写一个 systemd 服务配置：

[Unit] Description=OpenClaw AI Assistant Service After=network.target [Service] User=root WorkingDirectory=/opt/openclaw ExecStart=/usr/bin/node /opt/openclaw/src/index.js Restart=always RestartSec=5 Environment=NODE_ENV=production [Install] WantedBy=multi-user.target

保存为/etc/systemd/system/openclaw.service，然后执行：

systemctl daemon-reload systemctl enable openclaw systemctl start openclaw

以后管理就是systemctl restart openclaw、systemctl status openclaw。这套方案和 pm2 是等价替换，我更喜欢 systemd，因为它不依赖任何第三方工具，而且所有日志统一走 journalctl，排查起来更方便。

3.4 云部署的反直觉问题：时区、日志和平台回调

云部署之后，你以为万事大吉了，但实际上有一批“只有云上才会遇到”的问题。

时区问题。很多云主机默认时区是 UTC，导致定时任务执行时间和你的预期差 8 小时。排查半天发现是时区问题，相信你一定会觉得非常无语。设置时区：

timedatectl set-timezone Asia/Shanghai

日志清理。Docker 容器默认的日志驱动可能会让日志文件无限增长。长期运行后，磁盘空间会被日志占满，OpenClaw 就会开始异常。建议给 Docker 加日志轮转，具体做法是在/etc/docker/daemon.json里限制日志文件大小，这个配置很多教程都会提到。

平台回调地址。接入聊天平台时，平台需要向你的服务发送消息事件。这个回调地址必须是公网可访问的。云服务器有固定公网 IP，这点天生占优势。但别忘了在云厂商的防火墙控制台里放行对应端口，否则端口映射做得再好，外部请求也进不来。

很多人第一次上云时都会把“服务器本地防火墙”和“云厂商安全组”搞混，其实两者都要检查。云上网络不通时，第一件事永远是看安全组规则，而不是在系统内部反复排查。

4. 本机 vs 云：指标级对比与决策方法

到了这一步，两种部署方式的利弊已经很明显了。但为了让你能做一个定量决策，我整理了实际使用过程中的维度对比，并给出一套可以“打勾”的选择方法。

4.1 核心指标对比

4.2 一套可执行的打分决策法

设定 5 个维度，每个维度按重要程度给权重（加起来等于 100%），然后对两种方案分别打分（1-5 分），最后加总得分高的胜出。

举个我的实际例子：

加权结果：

• 本机 = 0.4×2 + 0.2×4 + 0.15×5 + 0.1×4 + 0.15×5 = 3.3
• 云 = 0.4×5 + 0.2×3 + 0.15×3 + 0.1×3 + 0.15×3 = 3.8

结果一目了然。你也可以用这个办法算算自己的场景。

4.3 混合方案：本地开发版 + 云端生产版

最后一种玩法，是我目前采用的方式：本地和云端同时各跑一套。

本地这套用来开发调试。改配置、试新功能、验证 prompt，全部在本地完成，改完确认没问题，再同步到云端。云端那套保持稳定版本，面向日常使用和长期任务。

这样做有一个额外的好处：你始终有一套完整可用的数据备份。就算某天云端数据丢了，本地还有一份完整的配置和历史记录可以快速恢复。代价是你要习惯“两处改配置，一处做同步”的流程，本质上是用一点维护成本换高容错率。

5. 常见问题与排查经验实录

无论选哪种部署方式，运行过程中都会遇到一些共性问题。这里把我遇到过的几个典型问题整理成一份速查手册，按频率从高到低排列。

5.1 内存占用持续走高，进程被杀

最主要的表现是：OpenClaw 运行几天后越来越慢，最后进程直接消失。排查方法分两步：

1. 用htop或docker stats看内存占用走势。
2. 如果内存在持续增长，通常是历史会话数据的累积问题。

解决思路是定期重启进程（每周一次足够），或者把定时任务配置为每天清空一次临时会话缓存。不要等到内存爆了再去处理，那时候连接已经断了，问题往往会复杂得多。

5.2 平台回调失败，消息发不进来

消息平台在群聊中调用你的服务时，如果请求超时，最常见的原因是回连接不通。按这条链路排查：

# 在服务器上测试本机端口监听是否正常 curl http://127.0.0.1:3000/health # 从外部测试公网端口是否通（在另一台机器上执行） curl http://<你的公网IP>:3000/health

第一步不通，查应用是否在跑；第二步不通，通通指向防火墙和安全组。

5.3 数据迁移：从本机搬到云端

换机器最怕的是丢记忆。OpenClaw 的记忆和配置都存在数据目录里，迁移的本质就是拷贝目录。

本机执行：

tar -czf openclaw-backup.tar.gz ~/.openclaw

云服务器执行：

tar -xzf openclaw-backup.tar.gz -C ~/

解压完成后，重启 OpenClaw 服务，它就能像以前一样“认识你”。我建议把这种备份养成习惯，每次做重要配置变更前先压缩一次，成本几乎为零，关键时刻却能救命。

5.4 日志爆炸：磁盘被写满

云上跑 Docker 时最容易出现的磁盘问题。定期执行df -h检查空间，如果发现/var/lib/docker占用很快变大，大概率是容器日志没有轮转。

除了通过修改 Docker 守护进程配置来解决，也可以在系统层面加一个定时任务，定期清理废弃镜像和日志文件。这个方式粗暴但管用。

5.5 使用小技巧：把配置文件纳入版本管理

最后分享一个我用了很久的实用习惯：把 OpenClaw 的配置文件（不包括密钥和历史会话数据）放入一个 Git 仓库里。每次修改任何参数，提交一次变更记录。

这样做的好处非常多。改坏了可以随时回滚；换机器时，拉一下仓库就恢复了所有配置；别人问你“当时这个参数是怎么调的”，翻一下提交记录就能找到答案。投入不到 5 分钟，换来的是长期可追溯的配置历史。

我自己现在本地和云端各跑一套 OpenClaw，本地负责折腾，云端负责稳定。这个格局形成之后，我几乎不再操心“它今天在不在线”这种事了。如果你正在犹豫装在哪，不妨按照第 1 节的清单先过一遍，再结合第 4 节的打分方法算一算，基本就能做出决定了。