企业官网建设流程全解析

OpenClaw 这名字最近在技术群里的讨论度实在太高，中文社区直接给它起了个外号叫“龙虾”。我第一次看到“你的龙虾跑起来没有？”这句话时愣了半天，后来才反应过来是在问 OpenClaw 部署了没。作为一个常年蹲在命令行里折腾各种 Agent 框架的人，我最近一个月把 OpenClaw 从本地测试一路跑到了云服务器，中间还顺手接上了 Microsoft Teams，踩过的坑能写满一页纸。所以这篇我不打算复述官方文档，就写写我自己心里那份“OpenClaw 六要六不要”。

所谓六要六不要，是我总结的一套部署与使用底线：六要，是每次安装和接入前必须做对的事；六不要，是那些看着不重要、实际上非常危险的坏习惯。下面我一条条展开说，每条都会带上踩坑现场和可以照抄的操作。如果你是第一次接触 OpenClaw，看完至少能避开 80% 的入门翻车点。

1. OpenClaw“龙虾”到底是什么，适合哪类人部署

1.1 它不只是一个聊天机器人，而是一个“长了手”的大模型

OpenClaw 的定位是通用型个人 AI 智能体。普通聊天工具只能让模型给你回一段文字，OpenClaw 则是把模型的输出意图解析成具体动作：写入本地文件、调用外部接口、执行命令行工具、收发 IM 消息，甚至整理 Obsidian 笔记库。你可以把它理解成“给大模型装上了一双手”，它不仅能说，还能做。

它的工作流大致是这样：你在终端里启动 Agent，它维护一个长期会话上下文，你交代任务后，Agent 调背后的模型做推理和任务拆解，然后通过内置工具逐步执行。整个过程会在会话文件里留下记录，方便你回溯。这种设计对喜欢凡事看日志的技术人来说非常舒服，一切都有迹可循。

1.2 适合谁用，先掂量一下

我个人觉得 OpenClaw 更适合这几类人：第一，已经玩过命令行、看得懂 systemd 或 pm2 的技术爱好者；第二，手里有云服务器，想跑一个 7x24 在线的消息助手；第三，对数据边界比较敏感，希望 AI 框架掌握在自己手里的人。

如果你只是想要一个开箱即用的聊天窗口，那 OpenClaw 对你来说有点重。它的价值不在“对话”，而在“自动化”。你愿意花一点时间配置环境、设定权限，它才能变成真正靠谱的数字助理；不愿意折腾，劝你直接用手里的现成 AI 产品。

2. 六要：OpenClaw 部署前必须做对的六件事

2.1 要：先定边界，再定部署位置

很多人一上来就急着安装，结果装了几天就劝退，原因是没搞明白自己到底要在哪台设备上跑 OpenClaw。这个项目的玩法非常灵活：放在个人电脑上，它可以是本地自动化管家，帮你整理文件、跑脚本、汇总信息；放到云服务器上，它更适合做临时会话平台对接，比如挂到 Microsoft Teams 群里当自动回复机器人。两种玩法的部署姿态完全不同。

我的建议是第一次先在本地测试环境跑通，不要直接上云服务器。本地折腾坏了，也就是重装的事；云服务器上如果权限没设好，一个失误可能影响整台机器的服务。等你把配置、Skill、会话存储都摸熟了，再迁到云端长期运行，这样最稳。

2.2 要：把运行环境盘干净

OpenClaw 官方建议的运行时环境以 Node.js 生态为主，我实测用过 Node 18 和 Node 20，稳定性都不错。但有个前提：系统里尽量不要有其他旧版本 Node 干扰，否则依赖安装阶段很容易出现各种奇怪报错。

我习惯的做法是先更新系统包索引，再装基础工具，然后用 nvm 这类版本管理工具安装指定 Node 版本。命令行大致如下：

sudo apt update && sudo apt install -y curl git curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash # 重新加载终端后安装 Node 20 nvm install 20 nvm use 20

这里不要偷懒跳过版本确认，装完之后用node -v和npm -v检查一下。依赖环境脏导致的安装失败，是 OpenClaw 入门第一个隐形大坑。

2.3 要：用“系统用户 + 独立工作目录”做隔离

OpenClaw 最大的能力是文件操作，也因此最需要权限隔离。官方默认你是在自己的用户目录下跑，但如果你有服务器，我非常建议单独创建一个系统用户，比如openclaw，然后把它的活动范围限制在一个专用工作目录里。

创建用户和目录的命令不复杂：

sudo useradd -m -s /bin/bash openclaw sudo mkdir -p /home/openclaw/openclaw-workspace sudo chown openclaw:openclaw /home/openclaw/openclaw-workspace

之后切换到该用户再启动 OpenClaw。这样即使某个任务被恶意提示词诱导，Agent 的读写范围也基本被压缩在特定目录，而不至于把整个/home翻个底朝天。看到这里你可能会觉得多此一举，但我后面会讲一个真实教训，它就是没做隔离才出的问题。

2.4 要：密钥走环境变量，配置走模板

很多项目都会提供一个.env.example模板，OpenClaw 也不例外。我强烈建议把所有 API 密钥、Token 都放进.env文件里，而不要直接改到核心配置文件中。原因很简单：核心配置文件以后每次升级都可能被覆盖，一旦你把真实密钥写进去，升级时很容易丢失或泄露。

操作上，先复制模板再编辑：

cp .env.example .env vim .env

启动前可以用set -a; source .env; set +a把环境变量加载进当前进程。如果使用 systemd 管理，还可以在 service 文件里写EnvironmentFile=指向这个.env，这样密钥就和代码完全分开了。这里的核心思想是：敏感信息永远不要进版本库，也不要进代码文件。

2.5 要：用进程守护让 Agent 长期在线

在我见过的新手操作里，最常见的翻车方式是直接在终端里node xx.js跑起来就以为完事了。一旦你关掉终端或者 SSH 断开，Agent 进程也跟着结束。这不是“崩溃”，而是没人做守护。

正确做法是用 systemd 托管。下面是一份可用的 service 模板：

[Unit] Description=OpenClaw Agent After=network.target [Service] User=openclaw WorkingDirectory=/home/openclaw/openclaw EnvironmentFile=/home/openclaw/openclaw/.env ExecStart=/usr/bin/node /home/openclaw/openclaw/dist/index.js Restart=always RestartSec=10 [Install] WantedBy=multi-user.target

注意ExecStart的具体启动入口要以你实际安装的版本为准。配置好后，systemctl enable --now openclaw开机自启，journalctl -u openclaw -f看日志。用守护进程的好处是：它崩了会自动拉起来，日常维护省心太多。

2.6 要：接入 IM 平台前先做最小化测试

OpenClaw 支持接 Slack、Teams、Discord 这类 IM 平台，这也是很多人决定折腾它的直接理由。但我想提醒一句：不要直接把 Bot 拉进所有工作群开跑。第一次接入时，只建一个测试频道，给它最有限的权限，先确认消息收发链路是通的。

以 Microsoft Teams 为例，你需要先在 Teams 开发平台创建一个 Bot 应用，拿到 App ID、Client Secret、Bot Token 等参数，再填到 OpenClaw 的配置里。第一次测试时，让 Bot 只在某个测试群响应，别让它监听所有频道。你也不想看到它把群里每条闲聊都当作任务开始分析吧？最小化测试既保护别人，也保护你自己排查问题时的心情。

3. 六不要：OpenClaw 使用中一定要避开的六个坑

3.1 不要：用 root 账号直接跑

用 root 跑 OpenClaw 是我见过最危险的操作。root 意味着 Agent 可以无差别读写系统上任何一个文件，一旦某个 Skill 里藏着危险命令，或者模型被诱导去执行删除操作，后果是灾难性的。我的一个真实经历：有一次我在 root 下跑了个文件整理任务，Agent 在清理缓存时把大量用户目录文件当成了目标，等我发现时，整个服务器用户目录已经被搅得一团糟。

正确的做法就是前面说的，建一个独立用户，给它最小权限。别嫌麻烦，权限隔离是最后一次防线，平时可能用不上，一旦用上就能救你一命。

3.2 不要：多个实例同时抢同一个配置目录

这个话题和最近社区热门的报错直接相关：agent failed before reply: session file locked (timeout 60000ms)。这个报错我第一眼看到时也很懵，后来排查清楚发现，OpenClaw 启动后会在配置目录里给当前会话文件加一把锁，用来保证同一个 Agent 实例不会同时被多个进程写入。如果你在终端手动启动了一次，又用 systemd 启动了第二次，两个进程就会抢占同一份会话文件，后者默认等 60 秒拿不到锁，直接报错退出。

排查起来很简单，先看进程：

pgrep -fl openclaw

如果发现多个 node 进程都在指向同一个项目目录，清理掉多余的，只保留一个守护进程。还有一种情况：旧进程被 kill 后锁文件没释放，这种情况下进入配置目录删除.lock结尾的文件再启动即可。这个坑我印象太深，因为当时是我在 systemd 服务运行的同时，手贱在终端里又跑了一遍。

3.3 不要：拿着默认配置直接上公网服务器

OpenClaw 的默认配置更多是为“本机自用”准备的，如果你的服务器有公网 IP，直接把项目监听端口暴露出去，很容易被扫描工具盯上。这类开源 Agent 项目热度高，很多扫描器每天都会批量探测常见端口。一旦被人摸到入口，轻则被刷请求，重则被利用来执行操作。

上公网前我建议至少做三件事：第一，监听地址尽量改成 127.0.0.1，或用防火墙只允许自己 IP 访问；第二，给 Agent 加上访问认证层，比如 Nginx 前置 basic auth 或接入身份验证；第三，调低模型和 Agent 的自动化权限，不要让它一上来就执行高风险操作。默认配置是“方便你本地跑通”，不是“方便公网裸奔”。

3.4 不要：给 Agent 无差别执行 Shell 的全权

很多 Skill 在执行任务时确实需要调用 shell 命令，但给到“无差别全权”和给到“白名单命令”是完全不同的概念。无差别执行意味着一个被污染的提示词可以让 Agent 在服务器上执行任意命令，这相当于你给自己的系统安了一个随时可能失控的远程执行器。

我的习惯是：先在 Skill 里严格声明可用命令列表，凡是涉及删除、覆盖文件的操作，必须显式确认之后才执行。更稳妥的方案是让 Agent 第一步只生成计划，把命令展示出来，等你确认后再真正执行。你想想，一个能帮你干活的助手，和一把乱挥的刀，差别就在于你有没有给它安排刀鞘。

3.5 不要：把密钥和 session 备份到同一个仓库

OpenClaw 的会话目录里保存了 Agent 与模型的对话记录，这些记录里很可能包含你在对话中提到的各种敏感信息。如果你用 Git 管理配置目录，或者定期往网盘备份，请务必把.env、session目录、锁文件全部忽略掉。

.gitignore至少这么写：

.env session/ *.lock

备份这件事，丢了能重建的代码可以复制，但密钥和会话记录一旦泄露，就不是重装能解决的问题。我见过有朋友把整个配置目录直接推到公开仓库，密钥、Token、会话文件全在，那种翻车场面真的没法收拾。

3.6 不要：来者不拒地装 Skill

Skill 是 OpenClaw 生态里最吸引人的部分，本质上是给 Agent 追加能力和行为定义的脚本集合。但 Skill 的质量参差不齐，社区里有些 Skill 出自很负责任的开发者，源码干净、文档清晰；也有一些来路不明的 Skill，里面藏着奇怪的网络请求或高危命令。

我装任何 Skill 之前一定会先做两件事：第一，把 Skill 目录里的代码打开看一遍，关注有没有curl、rm、eval这类敏感指令；第二，只从可信渠道获取，优先选择 star 多、更新频繁的仓库。装 Skill 就像给手机装 App，你不能因为图标好看就闭眼装，总得看一眼它要了什么权限。

4. Ubuntu 下 OpenClaw 从零部署到 systemd 守护的实测过程

4.1 部署前的准备清单

在正式开始前，我建议把清单过一遍：一台 Ubuntu 22.04 或更新版本的服务器，一个非 root 的部署账号，Node.js 20，Git。如果你用的是云厂商提供的免费试用机，一般都会预装好 Ubuntu，先执行sudo apt update把基础环境刷新一遍。

另外确定一个专用工作目录，比如/home/openclaw/openclaw，后面项目代码和配置都放这里。目录权限一定要确认，部署账号需要完整读写权，其他人不应该有访问权。

4.2 克隆项目、安装依赖、初始化配置

切换到专用账号后，克隆官方仓库代码到工作目录：

sudo -u openclaw -H bash -l cd /home/openclaw git clone 官方仓库地址 openclaw cd openclaw npm install

依赖安装时间因网络状况而异，耐心等它跑完，不要中途 Ctrl+C。安装完成后，复制环境变量模板并编辑：

cp .env.example .env vim .env

在这个文件里填好你的模型接入信息和 API 密钥。这里是关键一步：密钥只存在这个.env里，不要写进任何代码文件。填完之后，先用node或项目入口启动一次，确认能正常加载模型并完成一次最简单的任务测试。

4.3 写入 systemd 服务，实现守护运行

测试通过后，正式注册 systemd 服务。我用的 service 示例在前面已经给出，放在/etc/systemd/system/openclaw.service。复制后需要执行：

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

执行到status时如果显示 active，说明守护进程已经跑起来了。以后所有日志都能通过journalctl -u openclaw -f看到，不用再把输出打到后台文件里。到这一步，你的“龙虾”已经算正式入住，接下来才是接平台、配 Skill 的事情。

5. OpenClaw 常见报错与排查技巧实录

5.1 session file locked 的完整排查思路

这个报错是目前社区里出现频率最高的一个，我再展开讲一下。报错里那句timeout 60000ms的意思是：当前进程等了 60 秒都没能获得会话文件的锁，直接放弃。通常有三个原因：

• 多个实例同时启动，比如 systemd 和手敲 node 命令同时跑；
• 上一个进程崩溃但锁文件残留；
• 同目录下有多份配置导致会话存储路径指向了同一个文件。

排查按顺序来：先执行pgrep -fl openclaw看有没有残留进程，有就保留一个、杀掉多余的；再看配置目录里有没有.lock后缀文件，有就手动删除；最后检查 systemd 服务是不是多次拉起同一进程。走完这三步，问题基本都能解决。

5.2 启动后日志看不到任何输出

有朋友问我 systemd 跑起来后一条日志都看不到，怀疑是不是部署失败。这种情况大概率是日志输出去向没选对。终端里直接跑能看到输出，是因为输出到了标准输出和错误；到了 systemd 环境下，要用journalctl去看。执行journalctl -u openclaw -f就能看到实时滚动。如果还是没内容，查一下 service 文件里User是不是写错了导致进程起不来。这个排查点很小，但卡住新手一晚上完全有可能。

接入 Teams 后 Bot 没反应，先别怀疑 OpenClaw 本身，90% 的问题是平台侧配置不对。Teams 的 Bot 需要在 Azure 门户或 Teams 开发者平台注册，回调地址、Client Secret 任何一个填错都可能导致消息发不到 Agent。我的建议是先在测试频道用 Bot 发一条普通消息，看能否收到自动回复。收不到就去平台后台查事件日志，再看 OpenClaw 侧日志有没有收到请求，用这种“两头看日志”的方式能快速缩小问题范围。

5.3 OpenClaw 和 WorkBuddy 哪个好，怎么选

这个也是最近被问得比较多的。OpenClaw 和 WorkBuddy 在我看来并不是同一个思路的产品，硬要比的话，应该比的是“你到底想怎么用 AI 智能体”。我自己做了一个判断维度比表格，方便你参考：

我自己的选择倾向是：只要我有时间和精力维护，优先选能掌控源码和数据的方案，所以我在实际项目中用的是 OpenClaw。但如果你是给团队快速搭一个办公流程，或者不想花时间维护服务，商业化的 WorkBuddy 可能更省事。这个东西没有绝对好坏，关键是别拿一个需要折腾的工具去服务一个根本不想折腾的人。

5.4 会话目录与 Obsidian 联动提示

有朋友问 OpenClaw 能不能接 Obsidian 知识库，这个完全可以做，而且玩法很实用。核心思路是让 Agent 的工作目录直接指向 Obsidian 的 vault 文件夹，给它配好读取和写入的权限，然后通过 Skill 触发它整理笔记、汇总内容。但有个重要提醒：vault 目录本身的文件权限别搞错，否则 Agent 写坏的笔记会把整个知识库结构搞乱。我第一次接 Obsidian 时就因为权限设得太宽，让它直接在 vault 下创建了一堆临时文件，后面清理了半天。建议单独给这类笔记联动建一个“暂存区”，Agent 写的内容先进暂存区，确认没问题再手动合并进 vault。

6. 关于 OpenClaw 选型与安全边界的最后几句话

最后说点个人体会。我在第一次部署 OpenClaw 时犯过一个特别蠢的错误：直接在 root 下启动，结果在一次文件整理任务里，Agent 把缓存目录当成了清理目标，顺着软链接一顿操作，差点让整台服务器的用户目录结构全乱掉。那次之后我才老老实实建专用账号、配 systemd、给工作目录做隔离，再也没出过类似问题。

现在再回头看这份“六要六不要”，我觉得核心就是在强调一个词：边界。OpenClaw 的能力上限很高，但它的可靠程度完全取决于你给它画好的运行边界。权限边界、网络边界、密钥边界、Skill 边界，这些线画清楚之后，它确实能变成一个很省心的自动化助手；画不清楚，它就可能变成一台三天两头搞破坏的自动挖掘机。

如果你正准备上手 OpenClaw，我建议从今天开始只做一件事：先按第二条和第三条把独立用户与工作目录建好，再谈跑任务。就这么一个动作，能让你少走至少一半弯路。