在 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

三台机器部署 ClickHouse 高可用集群实战记录

本文是一份可发布版部署记录。真实 IP、域名、账号、密码、下载链接、业务目录名、机器唯一标识等敏感信息已经替换为占位符。命令中的 <...> 需要按自己的环境替换。 目标与拓扑 这次目标是用三台数据节点部署一套 ClickHouse 高可用集群,拓扑采用: 1 shard x 3 replicas 含义是:集群只有一个逻辑分片,三台机器都保存同一份数据的完整副本。任意一台数据节点宕机时,只要 ClickHouse Keeper 仍然有多数派,剩余节点仍可继续提供读写服务。 规划节点如下: 主机名示例地址角色ch-01<ch-01-ip>ClickHouse Server + ClickHouse Keeperch-02<ch-02-ip>ClickHouse Server + ClickHouse Keeperch-03<ch-03-ip&

By ladydd

折腾记(二):接入火山引擎实时语音 API,家庭语音助手体验直接拉满

接上篇 上一篇用全开源组件(Whisper + Hermes + Edge-TTS)搭了个语音助手,能跑,但体验就是"能用"二字: * 中文识别只有 70 分,方言基本歇菜 * 英文唤醒词"Alexa"喊着别扭 * 说完到回复要等 4-8 秒 * 它说话的时候你插不了嘴 这些问题靠堆开源组件很难根治。于是我去试了火山引擎(字节跳动)的语音服务,结果直接换了条路。 这篇分两段:先讲怎么用火山引擎的 ASR/TTS 替换掉开源组件(小改),再讲怎么上端到端实时语音模型(大改)。 第一段:先把 ASR 和 TTS 换成火山引擎 为什么换 我用豆包输入法的时候发现它语音识别准得离谱。一查,豆包用的就是字节自家的火山引擎 Seed-ASR。开通后有免费额度(

By ladydd

折腾记(一):用全开源组件给家里搭一个语音助手,对接自己的 Hermes Agent

起因 事情是从一块 ESP32-S3 开发板开始的。 我手上有一块 Seeed Studio XIAO ESP32-S3 Sense,带摄像头和麦克风。最初的想法很美好:用这块板子做一个无线语音终端,对着它说话,连到我服务器上跑的 Hermes Agent(一个自托管的 AI agent),让它回答我。 但折腾到一半我突然意识到一件事:我的麦克风、音响、服务器全在家里,为什么要绕一圈用 ESP32?直接把麦克风和音响插到服务器上不就行了? ESP32 那条路(做无线拾音终端)当然也有价值,但那是"为了学嵌入式而学",不是解决问题的最短路径。于是这个项目就从"嵌入式项目"变成了"在服务器上拼一个语音助手"。这篇就记录后者。 教训零:先想清楚你要解决的是什么问题。很多时候最优解比你最初设想的简单得多。 目标

By ladydd

Kiro 的三种代理设置方法:本地、服务端、Remote

作为kiro的骨灰级用户,这篇是我自己折腾 Kiro / Kiro Remote / Ubuntu Server 代理问题后的复盘。 核心不是“怎么配一个代理”,而是先判断:到底是谁在访问外网? 谁访问外网,代理就要配给谁。 0. 先说结论 Kiro 相关代理大概分三类: 场景真正访问外网的进程在哪里代理应该配在哪里本地 KiroWindows / Mac 本机本机 Clash / Proxifier / 系统代理服务端 Kiro / CLIUbuntu Server 上的 shell、CLI、node、kiro 进程Ubuntu 的环境变量,比如 HTTP_PROXY / HTTPS_PROXYKiro Remote远程 Ubuntu 上的 ~/.kiro-server 和 extensionHost远程 Ubuntu 的 Kiro Server

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