部署日志｜OpenClaw（Moltbot）上云的一天

部署日志｜OpenClaw（Moltbot）上云的一天

一、目标

我的目标是： 把 Moltbot（OpenClaw）部署到 Google Cloud 的 Kubernetes 集群中，并通过公网域名对外提供服务。

---

二、第一阶段：本地构建 + Kubernetes 部署（成功）

我按照 ChatGPT 给出的方案，在本机（macOS，Apple M3）上：

1. 拉取 OpenClaw 项目
2. 构建 Docker Image
3. 推送到远端镜像仓库
4. 通过 YAML / Helm 部署到 GKE

这个过程中踩了两个典型坑：

1. 镜像地址配置错误

   • registry / repository 概念混淆
   • YAML 中路径重复，导致 ImagePull 一直失败

2. 架构不兼容

   • 本机是 Apple Silicon（ARM64）
   • Kubernetes 节点是 x86_64（AMD64）
   • 最终必须用 docker buildx 构建 多架构镜像 才能正常运行

解决这些问题后，OpenClaw v0.1 已成功运行在云端 Kubernetes 中。

---

三、第二阶段：公网暴露 + Pairing 报错（误判）

随后我做了两件事：

1. 配置域名 colorisvoid.com
2. 通过 Ingress 将服务暴露到公网

网页可以访问，但出现了一个关键错误：

pairing required

我最初的判断是： 👉 这是一个需要“绕过/关闭”的功能

于是我开始尝试：

• 查代码
• 查配置
• 查社区
• 尝试升级到 v0.3 版本，以为新版本才能“关闭 pairing”

结果是： 花了整整一个下午（约 4 小时），在 v0.3 上反复踩坑、反复失败。

---

四、关键认知转折：工具选择的问题

这时我意识到一个本质问题：

• ChatGPT 不是 Agent

• 它不能：

  • 自己跑命令
  • 自己读 Kubernetes 日志
  • 自己对失败做闭环验证

所以调试流程变成了：

我跑命令 → 复制日志 → 发给 ChatGPT → 再跑下一步

这个交互模式，在复杂系统（K8s + 网络 + 安全）下，效率极低。

---

五、切换到 Cursor：效率质变

后来我改用 Cursor（支持 AI Agent）：

• 可以直接读我本地代码
• 可以运行 kubectl / gcloud
• 可以自动分析日志
• 可以自主试错并修复

结果是：

几十分钟内，Cursor 就把 OpenClaw 稳定部署到了云端

---

六、最终结论：我对 Pairing 的误解

部署完成后我才真正理解：

1. Pairing 不是 Bug

2. Pairing 是一个必要的安全机制

   • 所有外部设备接入前
   • 必须由服务器端授权

3. 它既安全，又好用

也就是说：

我下午那 4 个小时，其实是在试图“移除一个本来就不该移除的功能”

而 v0.1 本身就已经正确支持了这一机制。

---

七、最终成果：真正用起来了

在朋友 酷猫 的技术支持下，我完成了最后一公里：

1. 使用 Telegram 的 @BotFather 创建 Bot

2. 将 Bot 与 OpenClaw 服务器完成 pairing

3. 现在可以：

   • 通过 Telegram 和 Bot 对话
   • 让 Bot 在我的云端服务器上执行任务

---

八、总结（给未来的自己）

1. 技术上

   • 我对 Kubernetes、Docker 架构、多架构镜像、Ingress、远端设备接入的理解都更扎实了

2. 方法论上

   • ChatGPT 适合“讨论与理解”
   • AI Agent 才适合“复杂系统调试”

3. 认知上

   • 安全机制往往不是障碍，而是设计的核心
   • 试图“绕过设计”，往往是最大的时间浪费

昨天走了不少弯路，但这些弯路，最终都变成了我对系统、工具和 AI 协作方式的真实理解。