在 Mac mini 上把 OpenClaw 跑起来:从证书坑到 Qwen 接入(实战记录)

这篇记录的是我在一台 Mac mini(中国大陆网络环境)上安装并跑通 OpenClaw 的全过程:从一键安装开始,接入阿里 DashScope 的 OpenAI 兼容接口(Qwen),一路踩到 Node TLS 证书链问题,最后用 nvm 彻底解决,并成功进入 openclaw tui

背景与目标

我想在本机快速体验 OpenClaw(一个可执行工具调用的 AI Agent 框架)。目标很明确:

  • 在 macOS 上装起来
  • 不依赖海外大模型(尽量不需要外网)
  • 用 Qwen(DashScope 的 OpenAI-compatible 接口)作为模型后端
  • 最终能启动到交互界面(TUI)

环境

  • 设备:Mac mini
  • Shell:zsh
  • 网络:大陆网络(优先走国内接口)
  • 模型:DashScope OpenAI-compatible(Qwen)

先说结论:能跑通的最短路径

  1. 用 nvm 安装 LTS Node(避免 Homebrew Node 的证书链坑)
  2. 用 npm 全局安装 OpenClaw
  3. 用 Custom Provider 接入 DashScope 的 OpenAI-compatible endpoint
  4. 跳过所有非核心集成(channels/skills 依赖/hook/Google Places/Notion 等)
  5. openclaw tui 启动

下面按实际踩坑顺序复盘。

Step 1:安装 OpenClaw

我最开始走的是「能最快开始」的思路:先把 OpenClaw 装起来再说。

安装方式有两条:

  • 一键脚本(方便但依赖你当前 Node 环境)
  • npm 安装(更可控,适合排障后固化)

后面事实证明:想稳定,最终还是应该落回「nvm + npm」这条路。

Step 2:确定国内可用的模型接入方式(Qwen / DashScope)

在 onboarding 时选择:

  • Provider:Custom Provider
  • Endpoint compatibility:OpenAI-compatible
  • Base URL:https://dashscope.aliyuncs.com/compatible-mode/v1
  • API Key:DashScope Key

关键点:

  • Base URL 只能填“服务根”,不要带具体路径(不要填 /models、不要填 /chat/completions

我中途就犯过一次错:把 Base URL 填成了 .../v1/models,导致验证直接 404。

Step 3:第一个大坑——NODE_EXTRA_CA_CERTS 指向不存在的证书文件

症状:

  • OpenClaw / Node 请求报 fetch failed
  • 并出现类似:
    • Ignoring extra certs ... /opt/homebrew/etc/ca-certificates/cert.pem
    • UNABLE_TO_GET_ISSUER_CERT_LOCALLY

排查方式:

  • 看环境变量:printenv NODE_EXTRA_CA_CERTS
  • 查 shell 配置:grep -n "NODE_EXTRA_CA_CERTS" ~/.zshrc ...

最终在 ~/.zshrc 找到类似:

  • export NODE_EXTRA_CA_CERTS=$(brew --prefix)/etc/ca-certificates/cert.pem

处理:

  • 注释/删除这行
  • source ~/.zshrc

但这还没完。

Step 4:第二个大坑——curl 能通,但 Node 仍然 TLS 失败

我用 curl 打 DashScope:

  • curl <https://dashscope.aliyuncs.com/compatible-mode/v1/models> -H "Authorization: Bearer ..."

返回一大段 JSON —— 说明网络和 key 都没问题。

但 Node 继续失败:

  • node -e "fetch('.../models', { headers: { Authorization: 'Bearer ...' }})..."

仍然报 UNABLE_TO_GET_ISSUER_CERT_LOCALLY

这意味着:

  • 系统证书链 OK(curl 走系统链)
  • 你当前 Node 的 TLS/证书链环境不 OK

我一开始用的是 Homebrew 的 Node(甚至还遇到 v23 这种非 LTS 线),换到 node@22 也仍然失败。

Step 5:最终解法——改用 nvm 的干净 Node(关键转折点)

这一步是全程的“破局点”。

安装 nvm:

  • curl -o- <https://raw.githubusercontent.com/nvm-sh/nvm/master/install.sh> | bash

加载 nvm(或重开终端):

  • export NVM_DIR="$HOME/.nvm"
  • [ -s "$NVM_DIR/nvm.sh" ] && . "$NVM_DIR/nvm.sh"

安装并切到 Node 22:

  • nvm install 22
  • nvm use 22

验证 Node 是否已切换:

  • which node 应该指向 ~/.nvm/...

再跑同样的 Node fetch 测试:

  • 能返回大段 JSON

到这里就确认:TLS 问题被彻底解决。

Step 6:在 nvm 的 Node 下安装 OpenClaw

  • npm install -g openclaw@latest

安装完成后就可以继续 onboarding。

Step 7:onboarding 的关键选择(少折腾原则)

为了今晚“先跑起来”,我采用了一个非常有效的策略:

  • 非核心集成全部跳过

具体包括:

  • Channel:Skip for now
  • Search:先选 DuckDuckGo(免 key)
  • Skills:Yes(先启用基本能力)
  • Missing dependencies:Skip for now
  • Google Places / Notion / hooks 等:一律 No / Skip

这样可以最大概率避免再进入一轮“配置地狱”。

Step 8:启动与复盘

我在 onboarding 中选择了:Hatch in TUI。

所以之后启动不是直接 openclaw,而是:

  • openclaw tui

如果你只运行 openclaw 看到 Usage 帮助,说明 CLI 正常,但你还没进入交互模式。

最终结果

  • OpenClaw 成功安装
  • DashScope(Qwen)自定义 OpenAI-compatible endpoint 验证成功
  • 成功进入 openclaw tui
  • 今晚目标达成

常用命令速记

  • 进入交互:openclaw tui
  • 重新配置:openclaw onboard
  • 新开终端如果找不到命令:先 nvm use 22

Read more

把 Codex CLI 的登录态"搬"到一台新服务器

场景:你在一台老机器上早就登录好了 Codex CLI,现在开了台新服务器、装好了 codex,但它没登录。你不想在新机上重新走一遍 OAuth 网页授权(有时候服务器上根本打不开浏览器),只想把老机器上那份"已经登录好的身份"复制过去。 这篇讲的就是这个搬运动作的完整方法论——为什么能搬、怎么搬、有哪些坑。命令里所有隐私都用占位符,照着换成你自己的即可。 一、先理解一件事:Codex 的登录就是一个文件 这是整个操作的地基。Codex CLI(ChatGPT OAuth 登录模式下)的登录状态,不在什么系统钥匙串里,也不在环境变量里,就是家目录下一个单独的 JSON 文件: ~/.codex/auth.json 它长这样(字段名是真的,值我打码了): { "auth_mode": "

By ladydd

哨兵机制:让 Agent 一触即醒

0. 一句话点破本质 **让"等"发生在便宜的子进程里,让贵的 agent 只在有事时醒。**心跳解决"最迟多久必有人查岗",探针解决"事情一发生几乎立刻有人到场"——两个机制回答的是两个不同的问题,谁也替代不了谁。 1. 机制全貌:会自杀的轮询进程 + 宿主的"尸体通知" 我的实现只有两块积木: 积木一:一个有明确死法的后台循环 # 放行任务的同时,后台挂上(run_in_background) for i in $(seq 1 20); do 信号=$(ssh data "tmux capture-pane -t dna

By ladydd

Agent 心跳机制·设计与实现

0. 一句话点破本质 **心跳不是闹钟,是"带着完整世界快照的自我唤醒"。**闹钟只解决"什么时候醒";心跳真正要解决的是你点出的那个问题——醒来的那个瞬间,清楚自己是谁、任务到哪了、这一跳该干什么。我所有跑得好的心跳,提示词都写得像给一个失忆的陌生人看的;所有出过事的心跳,都是因为假设"我还记得"。 1. 第一性原理:为什么"醒来知道干啥"这么难 一个长期任务里的 agent 面临三重失忆: 1. 上下文会被压缩——多轮之后早期细节只剩摘要,心跳打进来时,那条心跳提示词可能是上下文里唯一高保真的任务描述 2. 世界在你睡着时变了——下属可能干完了、卡死了、跑偏了,你脑子里的"进度"从睡着那刻就开始过期 3. 任务本身会变—

By ladydd

我没手动映射 3000,公网为什么还能访问?一次 UPnP 误开孔复盘

写在前面:标题里的“自己打开”只是当时的主观感受。路由器没有失控,也不存在神秘穿透。真正发生的是:排障自动化从局域网主动调用了 UPnP AddPortMapping,路由器按协议新增了公网映射。 1. 原本的设计边界 家里的 Open WebUI 跑在一台 Ubuntu 主机的 Docker 中: 内网主机 192.168.x.x:3000 路由器上手动配置的入口是: 公网 TCP 13000 → 内网主机:3000 外部用户不直接访问家宽端口,而是先到云端 Caddy: 用户浏览器 → https://ai.example.com (云端 Caddy) → http://home.example.com:13000 (DDNS → 家宽公网

By ladydd
陕公网安备61011302002223号 | 陕ICP备2025083092号