企业官网建设流程全解析

1. 先说清楚：OpenClaw大龙虾到底是什么，为什么必须丢到云服务器上

OpenClaw这个项目，社区里都喜欢叫它"大龙虾"。名字的来由其实挺直观——OpenClaw的logo和命名本身就带着点龙虾钳子的味道，更重要的是它干的事也像龙虾：张牙舞爪，什么都能夹一夹。它不是一个大模型本身，而是架在大模型之上的一层"个人AI助手网关"：接收你从聊天平台发来的消息，调模型思考，再把思考结果落地成实际动作，比如查天气、读写文件、执行脚本、抓网页内容、管理定时任务，最后把回答推回给你。

说白了，它解决的是"大模型只会聊天"的痛点。默认情况下你找模型聊天就是一个对话框，它帮不了你干任何事。但OpenClaw给模型装上了"手"，你可以通过它把自己那台云端服务器，变成一个有AI大脑的私人助理。

那为什么非得部署到云服务器上，而不是跑在自己电脑里？这条我太有发言权了，本地跑和云上跑的体验差距不是一点半点。本地部署有几个硬伤：

• 电脑不是一直开机的。合盖、休眠、断电，任何一件事发生，你的AI助手就失联了。
• 飞书机器人需要一个公网能访问的回调地址。本地想实现就得折腾内网穿透，或者去路由器做端口映射，配置麻烦，稳定性还看运气。
• 安全和功耗都不划算。为一个常驻服务让电脑24小时不关，既不省电，也把家庭网络暴露面拉大了。

云端部署的好处正好对应这三条：服务器7x24在线，天然有公网IP，安全组和防火墙规则自己可控。尤其当你准备用飞书作为聊天入口时，云上部署几乎是唯一舒坦的方案。

这篇教程的定位是"保姆级"，每一步都给你开路：从买服务器、装基础环境、下载OpenClaw、填模型配置，到创建飞书应用、配置机器人权限、填回调地址、联调发消息，全程用命令和表格说清楚。适合那些有基本命令行经验、想给自己搭一个7x24小时AI助手，但对整套链路还不熟的朋友。如果你还没买服务器，照着第2节选就行。

2. 部署前的物料清单：服务器、API Key和必须先想清楚的三层关系

2.1 服务器怎么选：配置、系统和地区

先说结论：2核4G内存的云服务器完全够用，系统选Ubuntu 22.04 LTS或24.04 LTS，系统盘40GB，带宽按量计费或者5Mbps起步都可以。

为什么这个配置就够？OpenClaw作为一个常驻服务，跑起来之后占用的内存通常在几百MB到1GB之间，主要开销在运行时和缓存。2核4G可以保证它和系统其他进程互不挤占。真正吃资源的是它调用的模型API——那些计算全部发生在模型服务商的服务器上，跟你这台小机器没关系。所以别听人忽悠买8核16G，纯属浪费钱。

地区怎么选？两个原则：一是离你近，延迟低一点是一点；二是价格合适，不同地域差价挺大的。默认系统选Ubuntu，原因无他——社区文档、教程里的命令基本都是Ubuntu/Debian系的，你用CentOS的话，会在装包阶段就遇到一堆奇奇怪怪的坑，完全没必要给自己加难度。

2.2 大模型API Key：先把"大脑"准备好

OpenClaw本身不带模型，它需要你提供一个大模型API的Key作为"大脑"。你需要去模型服务商的开放平台注册账号、创建一个API Key，并确认账户里有可用的余额或配额。

这一步有两个特别容易踩的细节。第一，API Key创建之后通常只显示一次，一定要复制保存好，丢了只能重新建。第二，注意记下这个API的Base URL和模型标识（model name），后面配置的时候要填。很多人第一次启动失败，就是因为把API地址填成了网页版对话地址，类型完全对不上。

API Key属于敏感信息，建议放到环境变量里，或者用你习惯的密钥管理方式，不要直接写死在会提交到公开仓库的配置文件中。这个习惯越早养成越好，后面出一期泄漏事故你就知道有多痛了。

2.3 理清三层关系：模型层、服务层、消息层

动手之前，先花两分钟理解OpenClaw在你整个系统里的位置。这点想清楚，后面出问题排查时会快很多。

整个链路分三层。最底层是模型层，也就是大模型API，它负责"思考"；中间是服务层，就是OpenClaw本体，它负责"调度"——接收消息、构造对话上下文、调用工具、决定下一步；最上层是消息层，也就是飞书机器人，它负责"传话"——把你发的消息递给OpenClaw，再把回复发回来。

这三层的接口非常清晰：飞书和OpenClaw之间通过Webhook回调通信，OpenClaw和模型之间通过HTTP API通信。任何一个环节报错，先判断卡在哪一层。比如飞书里机器人不回复，可能是回调没打通（消息层的错），也可能是模型API报错（模型层的错），排查方向完全不同。这个框架记在心里，后面看日志时就不会慌。

3. 云服务器基础环境：从登录到Docker就绪

3.1 登录服务器：密钥登录更省心

服务器买好后，控制台会给你公网IP和登录方式。强烈建议你创建密钥对而不是用密码登录，既省去每次输密码的麻烦，安全度也高一个档次。如果你已经在用密码，可以后续在服务器上生成密钥对、把公钥加进authorized_keys，再把密码登录关掉。

Windows用户用终端里的ssh命令，macOS和Linux用户直接终端执行。登录命令长这样：

ssh -i ~/.ssh/your_key.pem root@你的公网IP

第一次登录会提示确认指纹，输入yes回车即可。登录成功后会看到系统提示符，说明你已经进入服务器。

3.2 系统初始化：更新、装常用工具

新服务器到手，先做一轮系统更新。这属于我每次部署前的固定动作，防止后面装包时因为软件源索引过期而报错：

sudo apt update && sudo apt upgrade -y

然后装上后面会用到的工具：curl用来测试接口、git用来拉代码（如果你走源码安装方式）、vim或者nano用来编辑配置。顺手把时区改成你的所在地时区，免得日志时间看着别扭：

sudo apt install -y curl git vim sudo timedatectl set-timezone Asia/Shanghai

注意，timedatectl在较新的Ubuntu版本才默认可用，如果你系统提示找不到，先sudo apt install systemd。这些小问题的处理思路就是：缺什么装什么，别慌。

3.3 安装Docker：推荐的运行方式

OpenClaw支持几种运行方式，但如果你不想折腾环境依赖，我建议直接用Docker。Docker最大的价值是"环境隔离"：它把OpenClaw以及它需要的运行时版本、系统依赖全部打包在一个容器里，你本地只需要一个Docker引擎，就能保证跑起来的环境和官方测试的一致，不会出现"我明明按照教程做了，但就是报错"的玄学问题。

安装Docker官方提供的自动化脚本最省事：

curl -fsSL https://get.docker.com | sudo sh

装完验证一下：

sudo docker version

如果提示权限不足，可以把当前用户加入docker组并重新登录会话，这样后面就不用每次敲sudo了：

sudo usermod -aG docker $USER

然后执行sudo systemctl enable --now docker，把Docker设为开机自启。到这里，服务器的基础环境就准备好了，整个过程不超过十分钟。

4. 安装OpenClaw本体：拉取项目、填配置、首次启动

4.1 规划目录并拉取项目

我习惯把OpenClaw放到/opt/openclaw下，跟系统其他目录隔开，升级和备份都清晰。以使用Docker Compose方式为例，先建目录：

sudo mkdir -p /opt/openclaw cd /opt/openclaw

然后把项目文件和示例配置拉下来。如果你是直接下载发布包，解压到当前目录即可。这里有个很多人会忽略的关键动作：先看一眼项目的README或者示例配置文件，确认当前版本的配置字段格式。不同版本之间字段名确实有变化，别拿老版本的配置硬套新程序，启动时会报"未知配置项"，到时候你又得回来查，浪费十分钟。

4.2 配置文件逐项解读

这一步是整个部署的核心。打开配置文件（可能是config.yaml、.env或者docker-compose.yml，取决于你的安装方式），里面核心要填的内容分三组。

第一组是模型配置，对应前面说的模型层：

model: api_key: "sk-你的API Key" base_url: "https://api.你的模型服务商.com/v1" model_name: "你的模型标识"

api_key就是你在模型服务商控制台创建的那个Key；base_url是API的根地址，注意别漏掉末尾的/v1，很多模型接口的路径规范长这样，漏了会直接404；model_name填你在控制台看到的模型标识，照着控制台抄就行。

第二组是飞书适配器的配置，对应消息层。常用字段大概长这样：

feishu: app_id: "cli_xxxxxxxxxxxx" app_secret: "你的应用密钥" verification_token: "事件订阅里的校验令牌" encrypt_key: "加密密钥，可为空" port: 8080

app_id和app_secret在飞书开放平台的应用凭证页面里能找到；verification_token和encrypt_key要到事件订阅那里配置完后才能拿到。所以严格来说，配置文件你得填两次：第一次先填一半，把服务跑起来，然后去飞书那边创建应用、拿到完整参数，再回来补全重启。这很正常，不用觉得自己哪里搞错了。

第三组是通用项，比如服务的监听端口、日志级别、是否开启某个工具插件等。建议一开始全部保持默认，先让链路通起来再慢慢调，一上来就想把所有插件开满，只会让排查变难。

4.3 首次启动与自检

配置填好后，用Docker Compose启动：

sudo docker compose up -d

首次启动会拉镜像，耐心等一会儿。启动后先看日志：

sudo docker compose logs -f

看到类似"服务已启动，监听8080端口"的输出，说明OpenClaw本体没问题。这时候可以先在本机测试一下健康接口：

curl http://localhost:8080/health

返回正常状态说明服务在跑。到这里，服务器这半边就绪了，剩下的事情全部在飞书开放平台那边。

注意：这一步也是在提醒你，飞书的回调验证必须等到OpenClaw跑起来之后再做。服务没启动，飞书发来的验证请求根本没人接，后台会一直报验证失败，而你可能还以为是地址填错了。

5. 飞书应用创建与权限配置：全教程最容易翻车的一环

5.1 在飞书开放平台创建应用

打开飞书开放平台，登录后进入开发者后台，点击创建企业自建应用。这一步有个前置条件要注意：如果你登录的是个人飞书账号，部分企业级权限会受限。最稳妥的做法是用你所在团队或企业的飞书账号来创建，或者先创建一个简单的团队再操作。

应用创建时填个名字，比如"我的大龙虾助手"，图标随便选一个。创建完成后进入应用详情页，左侧菜单找到"添加应用能力"，把机器人能力开启。这一步不做的话，后面所有跟消息相关的配置都白搭——没有机器人就没有对话入口，你连跟它说话的对象都没有。

5.2 权限Scope：少一个都收不到消息

飞书的安全模型比较严格，机器人能干什么完全由权限Scope控制。你需要到"权限管理"页面，手动搜索并开通以下几项核心权限：

具体权限标识以开放平台后台显示的为准，不同时间可能有调整。开通后记得逐条确认，别漏。漏开通权限的典型表现是：机器人能通过挑战验证，但死活收不到你发的消息。这是新手最常见的翻车点，没有之一。

5.3 事件订阅：把回调地址填进去

在左侧菜单找到"事件与回调"或"事件订阅"，添加事件，搜索"接收消息"（不同版本叫法略有差异），添加。然后在"请求地址"里填你的回调地址，格式是：

http://你的公网IP:8080/feishu/callback

路径的后缀要以你实际配置为准，常见的有/feishu或/webhook，去项目文档里确认一下。填完之后点保存，飞书会向这个地址发一个验证请求——这就是为什么我反复强调必须先跑起OpenClaw再配置飞书：服务没起来，验证请求根本没人接，永远配不上。

5.4 密钥记录：Verification Token和Encrypt Key

保存事件订阅后，页面上会出现Verification Token，部分版本还可以设置Encrypt Key。把这两个值复制下来，回到服务器的配置文件里，补全飞书配置那几行，然后重启OpenClaw：

sudo docker compose restart

这里有个小建议：Encrypt Key是可选的安全增强项，刚开始快速跑通可以先不填。因为一旦开启加密，飞书推送过来的事件payload是密文，OpenClaw这边如果解密实现有问题，排查起来极其痛苦。先把Verification Token填对，能收到明文消息就够了。等链路稳定了，再考虑把加密加上，这是典型的"先跑通再加固"思路。

6. 云端与飞书的握手：挑战验证、消息联调与报错排查

6.1 先过URL验证这一关

当你在飞书后台保存请求地址时，飞书会POST一个challenge挑战参数到你的回调地址，要求原样返回。这个逻辑OpenClaw内置了，你不需要自己写代码，但你需要确认两件事：一是云服务器安全组的入站规则确实放行了8080端口，二是服务器自己的防火墙（如果启用了ufw）也放行了。

安全组是最最容易被忽略的一步。很多云厂商默认的安全组只放行22端口，你不放行8080，飞书的请求根本进不来，后台会一直报"请求地址验证失败"。处理方式：到云控制台，找到这台服务器实例，编辑安全组，添加入站规则，端口写8080，来源设为0.0.0.0/0。飞书的服务器IP段不固定，用白名单不现实，所以只能全放，但后面可以用Verification Token做应用层校验来兜底。

6.2 在飞书里找到机器人并私聊

保存成功后，回到飞书客户端，在搜索框里输入你刚才创建的应用名字，找到机器人，点开私聊，发一句"你好"。正常情况下几秒内会收到回复。

如果你的机器人没有出现在搜索结果里，大概率是应用版本没有发布。飞书的企业自建应用改了配置后需要发布新版本，到应用详情的"版本管理与发布"里创建版本并发布，机器人才会在组织内生效。这个问题我遇到过一次，当时还以为是应用被禁用了，查了半天才发现是忘了发布，尴尬。

6.3 常见报错排查表

联调阶段最常见的几个问题，我整理成一张表，建议截图保存：

6.4 日志是调试的上帝视角

任何一步出问题，第一反应都应该是看日志，而不是乱改配置。OpenClaw的日志会告诉你：是否收到了飞书请求、是否成功调用了模型API、报错的具体HTTP状态码是什么。几个常用命令记一下：

sudo docker compose logs -f sudo docker compose logs --tail=200

日志怎么看？先定位有没有收到来自飞书的请求。如果没有，问题在消息层——安全组、地址、事件订阅；如果收到了但下面跟着模型API的报错，问题在模型层——Key、Base URL、余额。用第2节说的三层架构来判断，基本十秒能定位。养成这个习惯之后，你部署任何类似的机器人项目都会顺利很多。

7. 跑通之后的收尾经验：守护进程、安全习惯和下一步玩法

7.1 让服务真正7x24起来

Docker容器默认跟随Docker引擎，而Docker引擎我们已经设了开机自启，所以重启服务器后服务会自动恢复，这比裸装进程省心得多。如果想进一步保证"挂了自动拉起"，可以在docker compose文件里给服务加restart: unless-stopped，这样即使容器因为异常退出，Docker也会自动重启它。

我实际用下来的感受是，加了这一行之后，几乎不需要手动去管服务了，除非是配置变更需要重启。这对"放在那就当个助理用"的诉求来说非常重要——你总不想大半夜想用助手，结果发现服务昨天就挂了。

7.2 三个安全习惯值得养成

第一，API Key永远不要出现在公开的代码仓库、博客截图或者聊天记录里。一旦泄露，立刻去模型服务商后台作废并重建，不要心存侥幸。第二，服务器上不要开放多余的端口，用不到的一律不监听，安全组最小化授权。OpenClaw只需要8080这一个入口就够了，其他端口全部关掉。第三，定期看一眼日志和磁盘占用，不需要保留的旧日志清理掉，避免磁盘撑满导致服务异常。这些事平时五分钟能搞定，真出事时能救你一命。

7.3 稳定之后，你可以接着玩什么

这条链路跑通之后，OpenClaw的价值才刚刚开始。你可以继续加定时任务，让AI每天早上把当天的待办、天气、监控数据整理好发到飞书群里；可以把常用工具插件配起来，比如网页抓取、文件处理这类能力，让它帮你做信息筛选；也可以在同一个OpenClaw实例上对接多个飞书机器人或者多个群，按场景分配不同的系统提示词。

我个人在跑通后的最大体会是，部署本身只占整个使用旅程的三分之一，剩下三分之二都在"调教"——调整系统提示词让回复更贴合自己的需求，开关工具插件控制它能做什么不能做什么。慢慢你会发现，这只大龙虾真的会越来越像一个得力的助手，而不是一个单纯的聊天窗口。

最后再分享一个我自己的小习惯：跑通之后，第一时间把服务器的登录方式、OpenClaw的配置路径、飞书后台的几个关键页面都记到一个私密笔记里。等过两个月要改配置时，你会感谢当时的自己。这篇先到这，后面如果大家有兴趣，我再写一篇关于工具插件配置和提示词调教的经验分享，把那些坑也一并讲清楚。