OpenClaw 从 0 到 1 搭建:本地部署 + 多账号调度全流程

凌晨两点。 Docker 容器终于跑通了。

屏幕上是 Telegram 里刚弹出的回复——”你好，我是你的 OpenClaw Agent ，已经准备就绪。”我盯着这行字看了十秒，然后起身去厨房倒了杯可乐。

上一篇写完 OpenClaw 和 Hermes 的对比之后，后台收到最多的留言不是”选哪个”，而是：”你选了 OpenClaw ，倒是教我怎么装啊。”

行。这篇就是来填坑的。

先搞清楚你要建的是什么

很多人一上来就 git clone，然后发现跑不起来，骂一句”文档写得什么玩意儿”就放弃了。

其实不怪文档。是很多人没搞清楚——OpenClaw 不是一个拿来就用的聊天机器人，它是一个网关。 你要做的是搭一座桥，把 Telegram/Discord/Slack/微信这些渠道，跟你想要用的 AI 模型连起来。

这座桥有三块地基：

三块地对齐了，桥才能通车。错一块，后面全是坑。

图 1 ： OpenClaw 的架构三层： Core 是桥墩， Provider 和 Channel 是两端接口

部署：其实就三行命令

如果你看过 OpenClaw 的 GitHub 仓库（ openclaw/openclaw ），会发现安装方式写了四种： Docker 、 Nix 、 Ansible 、 Bun 。

我自己试了一圈，Docker 是最稳的。另外几种不是不行，但依赖问题会让你在凌晨两点怀疑人生。

gitclonehttps://github.com/openclaw/openclaw.git cdopenclaw dockercomposeup-d 

三行。理论上是三行。

但——

第一个坑是环境变量。 

    OpenClaw 需要你在 .env 文件里填 API Key 。不是填一个，是至少填两个：一个给 AI Provider （比如 OpenAI 的 OPENAI_API_KEY），一个给 Channel （比如 Telegram 的 TELEGRAM_BOT_TOKEN）。

我的建议是：先把 .env.example 复制一份成 .env，然后逐个填，填一个测一个。 不要一口气全填完再启动，出了问题你根本不知道是哪部分的锅。

第二个坑是端口冲突。

     默认跑在 3000 端口。如果你本地已经有别的服务占了 3000 （比如我经常跑的 Next.js 项目）， docker compose 会报 bind: address already in use，然后容器起不来。去 docker-compose.yml 里把端口映射改一下，比如 3001:3000，重新 up -d。

第三个坑是网络。 

    如果你在国内，拉 Docker 镜像可能慢得像蜗牛。建议先把 Docker Hub 的源换成国内的，或者挂个代理再拉。这个不展开，懂的都懂。

三行命令之后，打开 http://localhost:3001（或者你改的端口），看到 OpenClaw 的 Web UI ，说明 Core 跑通了。

图 2 ：终端里的 Docker 日志 —— 看到 “Server ready” 那一行的时候，我知道地基打好了

接上你的第一个渠道：以 Telegram 为例

Core 跑通了只是桥墩立起来了。两端还没接。

Telegram 是最顺的渠道，我建议新手从这里开始试。

去 Telegram 找 @BotFather ，发 /newbot，按提示创建一个 Bot 。拿到 Token ，格式是 123456789:ABCdefGHIjklMNOpqrsTUVwxyz。

填进 .env：

TELEGRAM_BOT_TOKEN=你的Token 

重启容器：

dockercomposerestart 

然后去你的 Bot 里发一条消息。如果收到了回复——恭喜，第一辆车过桥了。

如果没收回复，查日志：

dockerlogsopenclaw-app-f 

最常见的三个问题：

Discord 的流程差不多，去 Discord Developer Portal 创建 Application ，拿到 Bot Token 和 Guild ID 。 Slack 稍微麻烦一点，要配置 OAuth 权限和 Event Subscriptions 。

我的建议是：先跑通一个渠道，再扩展。 不要一上来就同时配 Telegram + Discord + 微信，每个渠道的调试信息混在一起，你会疯的。

图 3 ： Telegram Bot 跑通的那一刻——最朴素的验证，最有成就感的瞬间

多账号调度：这才是 OpenClaw 的真正玩法

如果只接一个 Bot 、调一个模型，那用 OpenClaw 有点杀鸡用牛刀了。它真正的价值在于——一个 Core ，调度多个账号、多个模型、多个场景。

假设你有两个 Telegram Bot ：

OpenClaw 的路由配置让你可以在一个实例里同时跑这两个 Bot ，各自走不同的模型、不同的 prompt 、不同的插件权限。

配置在 config.yaml 里（或者 Web UI 里配，看你喜欢哪种方式）。核心概念就三个：

Agent：定义一个”人格”。用哪个模型、 system prompt 是什么、能调用哪些工具。

Channel：定义一个”入口”。 Telegram Bot Token 、 Discord Guild 、 Slack App 。

Route：把 Agent 和 Channel 连起来。”这个入口进来的消息，交给这个 Agent 处理。”

一个 Core 实例可以跑多个 Agent + 多个 Channel + 多条 Route 。这就是 OpenClaw 作为”网关”的核心设计——不是一对一，而是一对多、多对多的调度层。

我自己现在的配置是：

三张表，一个实例。换做别的方案，我可能得部署三套服务。

图 4 ：一个 Core ，多个 Agent ，多个 Channel——OpenClaw 的网关本质在这里体现得最清楚

插件：让 Agent 真的能干活

光聊天不够。 Agent 得能查天气、搜网页、跑代码、读文件——不然跟 ChatGPT 网页版有什么区别？

OpenClaw 的插件系统叫 ClawHub 。社区贡献了不少插件，安装方式一般是：

npminstall@openclaw/plugin-xxx 

然后在 Agent 配置里启用。

我目前开了三个插件：

插件的坑在于权限管理。如果你的 Agent 对外提供服务，一定要控制好它能调用哪些插件。给一个客服 Bot 开 code-interpreter ，等于给别人一个在你的服务器上跑任意代码的后门——这个不用我多说吧。

踩过的坑：一个诚实清单

部署到现在大概两周。列一下我真实踩过的坑，比文档里的 troubleshooting 实在：

这些问题文档里都有提到，但分散在不同章节。我帮你汇总了。

值不值得投入时间？

写到这里，估计有人想问：折腾这么一圈，值吗？

我的判断是——

如果你只需要一个聊天机器人，那不值。直接用 ChatGPT 、 Claude 、 Gemini 的网页版或者官方 App ，体验更好，不用折腾。

如果你需要多账号管理、多模型调度、多渠道接入，那 OpenClaw 是目前最轻量的方案之一。 Docker 三行起，配置一小时能跑通，扩展性足够用到中等规模。

如果你要做深度自动化的 Agent——自主规划、多步编排、操作文件系统——那 OpenClaw 可能不够。上一篇说过，这时候应该去看 Hermes 。

图 5 ：控制台里所有绿灯亮起的那一刻——你知道这座桥通车了

这篇文章够把桥搭起来了吗？

我觉得差不多了。剩下的——prompt 调优、插件开发、监控告警——是下一篇的事。

先把车开上桥吧。

💡温馨说明： 本文内容由「青城源码」团队结合 AI 辅助创作与人工校对整理而成，所有核心观点与实操步骤均经过人工验证。

        如果你也对 AI 自动化内容生成、 AI Agent 框架搭建、技术落地实操感兴趣，或是有相关项目开发、学习交流的需求，欢迎在后台私信咨询，我们会为你提供专属的技术交流与学习建议。

摘要： 3 行 Docker 命令启动 OpenClaw ， 1 小时跑通 Telegram 渠道，再多账号调度多个 AI 模型。附真实踩坑清单。

标签： #OpenClaw #AI Agent #本地部署 #Telegram Bot #多账号调度

关键词： OpenClaw 部署、 AI Agent 本地搭建、 Telegram Bot 、多账号管理、 Docker 部署