在 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

Mac 上 Skill CLI 无法执行的坑:最后其实一条命令就够了

我在做 Amazon skills 的过程中,逐步把本地 CLI 从 Python 脚本切到 Go 二进制。这样做的好处很明显:用户不用装 Python、不用配依赖,解压 skill 后直接运行。但在 macOS 上,我们反复遇到一个看起来很玄的问题:同一个二进制,在 Linux/Windows 上正常,在 Mac 上就是执行不了。 当时遇到的现象 常见报错大概有几类: * 双击或 agent 调用 CLI 时,系统提示文件来自未知开发者,无法打开。 * 终端里执行时提示 Permission denied。 * 已经 chmod +x 了,仍然被 macOS 拦截。 * Apple

By ladydd

当我把全世界人群的基因 PCA 跑出来后,看见了一个倒 L 型

最近我把之前学的一些分子人类学知识,终于真正落地了。 不是停留在看论文、看别人画图、看别人解释“人群结构”这些概念,而是自己把数据处理完,自己跑 PCA,自己把全世界不同人群放到一张图上。 然后那一刻,我真的被击中了。 图上出现了一个非常漂亮的倒 L 型。 一端是非洲,另一端逐渐拉向东亚,中间有中东、欧洲、南亚、欧亚大陆上的各种过渡人群。它不是那种随机散点图,而是有方向、有骨架、有历史感的结构。 我第一眼看到的时候,脑子里直接冒出一句话: 这不像是一张普通统计图,这像是人类迁徙史在二维空间里留下的影子。 当然,后来我也提醒自己,PCA 不能被过度浪漫化。它不是地图,也不是时间轴,更不是“谁从哪里走到哪里”的直接证据。PCA 本质上是把高维基因差异压缩到几个主成分上,用最大方差方向把样本摊开。它可以帮助我们观察人群结构、相似性、分化和混合,但不能单独承担全部历史解释。PCA 在群体遗传学里常用于观察 population structure

By ladydd

吞吐与延迟:一个厨房比喻讲透性能压测

写于 2026-06-26。背景: MCP 服务 跑在 3 台 ClickHouse(每台 16 核 / 64G,1 分片 3 副本)上。 我们花了一整轮做公网压测,把这套系统的极限、天花板和杠杆全摸清了。这篇把"吞吐 / 延迟 / 排队"这三个最容易混的概念讲透,配我们自己的真实实测数据。 一句话结论 我们这套系统的吞吐天花板 ≈ 76 req/s。 往里塞再多并发(100、200、300、500),每秒"做完"的还是大约 76 个,多出来的全在排队。系统不会崩,只会让每个人等得更久。 天花板能不能抬?

By ladydd

四卡 3090 本地模型部署复盘:Ollama 跑通 35B,以及 GPU0 掉卡问题

这次做的是一轮真实的本地模型部署摸底。 目标不是搭一个临时 Demo,而是把一台四卡 3090 GPU 机器接进自己的日常 AI 使用环境:本机跑 Open WebUI,负责账号、会话和前端配置;GPU 机器只负责模型推理。这样以后换模型、换推理框架、重启服务,都尽量不影响本机的使用入口。 最后结论比较清楚:qwen3.5:35b 的 GGUF Q4_K_M 量化版已经通过 Ollama 跑通,本机 Open WebUI 可以接入,热加载后的聊天速度也能用;但 GPU0 存在明显稳定性问题,重启后能短暂恢复,跑过负载后又会掉到 NVML 异常状态。 状态快照 当前能用的部分: * 本机 Open WebUI 已部署,

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