OpenClaw

2026年开篇，没有整理常规的技术知识点，反而想记录一下这几天部署Openclaw的全过程——从被“一键部署”的宣传吸引，到陷入各种依赖、配置的坑，再到最终成功运行，每一步都充满了折腾，也收获了不少实操经验，索性写成笔记，既是对这段经历的复盘，也希望能帮到后续想部署Openclaw的小伙伴，少走一些弯路。

先简单说说Openclaw是什么，避免大家和我最初一样，只知其名不知其详。Openclaw是一款开源的AI智能体，曾用名ClawdBot、Moltbot，核心是给AI装上“手”和“眼”，让原本只能“聊天”的AI拥有实际执行能力——比如操控浏览器、执行终端命令、读写文件，甚至能自主编写脚本、扩展技能，还能通过Telegram、iMessage等通讯软件远程交互，堪称“开源贾维斯”，这也是我执意要部署它的原因，想着能用它实现一些工作流程的自动化，提升效率。

原本以为，各大云厂商都已支持Openclaw的云端极简部署，加上官方宣传的“一键部署”，应该是件轻松的事，可真正动手才发现，“一键”只是开始，真正的折腾，从部署后的报错才正式拉开序幕。这几天的折腾，主要集中在三个核心坑点，每一个都让我卡了不短的时间，逐一记录下来，方便后续回顾。

一、坑点一：“一键部署”后，Gateway超时报错

最初，我直接按照官方指引，点击了“一键部署”，几分钟后系统提示部署完成，本以为可以直接上手测试，结果发送指令后，直接弹出报错：Error: gateway timeout after 15000ms，目标地址是ws://127.0.0.1:18789。

一开始我以为是部署失败，反复重新部署了两次，结果还是同样的报错。无奈之下，只能放弃“一键部署”的便捷，手动排查问题。通过终端查看进程状态，发现Openclaw的Gateway服务确实在运行（pid正常），但与之配套的Browser服务却未启动——这才意识到，报错的根源不是Gateway本身挂了，而是它无法与Browser服务建立连接。

后续通过ss-tlnp命令查看端口占用，确认18789端口（Gateway监听端口）正常，而Browser服务应占用的18800端口却处于无监听状态，进一步验证了“Browser服务未启动”的猜测。这一步也让我明白，所谓的“一键部署”，往往只完成了核心组件的安装，配套依赖和服务的启动，还需要手动排查和配置。

二、坑点二：Browser服务启动失败，源于依赖缺失

找到问题方向后，我尝试手动启动Browser服务，执行命令openclaw browser start，结果还是超时失败。这时候我开始怀疑，是不是缺少了必要的依赖。查阅相关资料后得知，Openclaw的Browser功能依赖Playwright框架，而Playwright又需要依赖Chromium浏览器内核，一旦缺少这个内核，Browser服务就无法正常启动。

于是，我通过ls ~/.cache/ms-playwright/命令查看，发现该目录为空，果然是Chromium未安装。接下来就是手动安装Chromium，执行npx playwright install chromium命令后，开始了漫长的下载过程——167MB的安装包，在服务器上下载了将近30分钟，期间反复查看下载进度，生怕出现网络中断的情况。

本以为安装完Chromium，Browser服务就能顺利启动，可再次执行启动命令，还是超时报错。这时候我彻底慌了，反复排查进程和端口，都没有发现异常，最后只能查看系统日志，才找到关键问题：Running as root without –no-sandbox is not supported. 原来，我是用root用户部署的，而Chrome在root权限下运行，必须添加–no-sandbox参数，否则会被限制启动。

找到问题根源后，修改Openclaw的配置文件（~/.openclaw/openclaw.json），在browser配置中添加”noSandbox”: true，同时指定executablePath为Chromium的安装路径，重启Gateway服务后，再次启动Browser，终于成功了——那一刻，真的有种“柳暗花明”的感觉。

三、坑点三：通讯渠道配置，踩中token和权限坑

解决了服务启动的问题，接下来就是配置通讯渠道，我选择了最常用的Telegram，按照官方文档提示，需要填写TELEGRAM_BOT_TOKEN，可配置完成后，始终无法建立连接，反复检查token是否正确，都没有问题。

折腾了一个多小时，才发现是权限问题——Openclaw需要读取配置文件中的token，而我部署时，配置文件的权限设置过高，导致服务无法读取。修改配置文件权限为644后，再次测试，仍然无法连接，进一步排查发现，是我在配置时，误将token填写到了错误的配置项中，正确的配置位置应该是channels.telegram.botToken，而非根目录下的token字段。

修正配置后，重启服务，终于成功通过Telegram与Openclaw建立连接，发送“打开浏览器”的指令，能够正常响应，那一刻，所有的折腾都有了回报。

四、折腾总结与感悟

这几天部署Openclaw的经历，总结下来就是“理想很丰满，现实很骨感”——原本以为的“一键部署”，实际却是“步步踩坑”，但也正是这些坑，让我对Openclaw的核心架构有了更清晰的认识：它的核心由Gateway（神经中枢）、Agent（思考驱动）、Skills（执行能力）、Memory（持久化记忆）四部分组成，每一个组件都不可或缺，任何一个环节出现问题，都会导致整个服务无法正常运行。

同时也总结了几个避坑要点，分享给大家：

1. 不要过度依赖“一键部署”，尤其是在Linux服务器上，手动排查进程、端口、依赖，才能快速定位问题；

2. 部署前，先确认Openclaw的核心依赖（Node.js、Playwright、Chromium等）是否齐全，避免出现“缺少依赖导致服务启动失败”的问题；

3. 若用root用户部署，务必在配置文件中添加–no-sandbox参数，否则Chrome无法启动；

4. 通讯渠道配置时，仔细核对token的正确性和配置位置，同时检查配置文件的权限，避免因权限不足导致服务无法读取配置。

折腾的这几天，虽然耗时又费力，但也让我深刻体会到，开源工具的部署，从来都不是“一键直达”，而是在不断踩坑、不断排查、不断解决问题的过程中，积累实操经验。现在Openclaw已经能正常运行，后续打算探索它的自动化脚本、技能扩展功能，后续有新的折腾经历，再继续补充记录。

最后想说，对于Openclaw这类开源AI智能体，部署的过程虽然折腾，但当它真正能帮你完成自动化任务时，你会发现，所有的付出都值得。如果你也打算部署Openclaw，希望这篇笔记能帮你少走一些弯路，顺利完成部署～