★ FEATURED ARTICLE 在Mac上配置OpenClaw默认模型很多人第一反应是“改一行配置就够了”但真到用的时候才会发现问题通常不是不知道怎么改而是改完以后OpenClaw没按你想的走。OpenClaw这类本地网关式工具把模型选择拆成了默认模型、备用模型、推理模型三条链路再加上全局配置、用户配置、项目配置三层覆盖任何一个环节理解偏差都会出现“我明明设了A实际却在用B”的尴尬。本文的目标读者是那些已经装上OpenClaw、手里有几个不同渠道的模型、想让日常请求稳定跑在某个模型上的人。我会从配置的存储位置、选择模型时的权衡、实际修改步骤到Mac环境特有的环境变量坑再到最终的状态验证把整个链路完整过一遍。提示下面所有命令和文件内容均以常见的openclaw命令行工具为例。如果你的机器上用的是图形界面版本原理一致只是配置入口不同。1. 动手配置前先把 OpenClaw 的“默认模型”机制理清楚1.1 默认模型不是“一个字符串”是“一条请求链路”OpenClaw 这个工具的定位是一个轻量的本地模型路由层。它本身不产生模型推理能力只是把所有模型请求统一收口再按规则转发到不同的终端。也就是说你在配置文件里写的“默认模型”实际上是一个指向某个终端的模型ID终端别名/模型别名。请求进来时OpenClaw 按顺序做判断当前对话属于哪个项目项目有没有覆盖配置有没有指定特别的推理任务如果都没有才会落到全局默认模型。所以默认模型是兜底的那个而不是唯一生效的那个。我见过太多配置没生效的案例默认模型明明配好了但对话一直没走默认链路。原因就是在项目目录下残留了一个项目级配置文件里面提前指定了另一个模型。这个文件优先级更高全局配置根本没机会生效。1.2 全局、用户、项目三层配置的覆盖关系OpenClaw 的配置体系按范围分成三层从下往上优先级递增层级配置文件位置作用范围典型场景全局~/.openclaw/config.toml当前用户的全部项目设定一个最稳定的兜底模型用户~/.config/openclaw/config.toml当前用户按用户维度生效在多台电脑间同步个人偏好项目项目根目录/.openclaw/project.yml仅当前项目仓库级专用模型有些版本为了兼容旧习惯还会读取环境变量OPENCLAW_MODEL。环境变量优先级其实最高这也是后面第 5 节要重点讲的坑你明明没配环境变量但某个启动脚本里顺手export了一个全局配置就全被盖掉了。1.3 默认模型、备用模型、推理模型各管各的这个区分非常关键。OpenClaw 在较新的版本里把“模型”拆成了三个槽位default普通对话、常规任务都走这里追求的是综合能力和响应速度。fallback当默认模型连接失败、返回异常或超时的时候自动降级用通常是另一个渠道的模型目的是保证服务不中断。thinking在复杂推理类任务里使用通常是更强但更慢的模型。如果你只设置了default别嫌OpenClaw“不听话”——某些场景它本来就会自动切thinking。我的建议是三个槽位都显式配置一遍让行为完全可控。2. macOS 上定位配置文件路径找错后面全白搭2.1 不同安装方式配置路径完全不一样Mac 上装 OpenClaw 最常见的有三种方式通过包管理器安装比如brew install openclaw默认会装到/opt/homebrew/bin/openclawApple Silicon或/usr/local/bin/openclawIntel。直接下载二进制解压大多数人会解压到某个自定义工具目录下运行对应的可执行文件。通过图形界面安装包安装安装后通常在/Applications目录中配置默认放在~/Library/Application Support/OpenClaw/。前两者配置文件默认都是~/.openclaw/config.toml最后一种配置一般在~/Library/Application Support/OpenClaw/config.json或者同目录的config.toml取决于版本。路径差异很容易让新手蒙圈所以第一件事不是急着改而是确认你自己的实际路径。2.2 用命令确认 OpenClaw 当前读的是哪个配置与其猜不如直接问工具本身。先在终端里运行which openclaw openclaw doctorwhich只能让你知道可执行文件在哪看不出配置路径openclaw doctor会输出一份环境检查报告里面会明确列出正在使用的配置目录、模型标识和默认配置文件位置。我建议把openclaw doctor的输出截图或复制一份存成基准记录以后配置乱了随时对照。如果doctor子命令不存在退而求其次直接搜索配置文件find ~ -maxdepth 3 -name config.toml -path *openclaw*这个命令足够把最常见的配置文件揪出来比你在访达里一层层点文件夹快得多。2.3 改配置前先做一次备份这句话我几乎每次都会说改工具配置前先备份尤其在你准备直接编辑TOML的时候。OpenClaw的配置整体就是一个目录复制两秒就完成cp -r ~/.openclaw ~/.openclaw.bak.$(date %Y%m%d)如果实际配置文件在~/Library/Application Support/OpenClaw你就相应替换路径。备份完再改心态完全不一样改坏了随时能回滚。3. 选默认模型时的三条参考线3.1 速度与稳定性优先作为一个默认模型它承担的是高频兜底责任。我日常有大量简单请求改个措辞、写段正则、解释一段报错。这些请求如果每次都要等十几秒体验会非常差。默认模型要选那种响应快、连接成功率高的而不是单纯看“哪个最强”。你可以在正式切换前先手动用目标模型连续发几十条普通请求观察一下平均响应时间和失败率。我实测过一个大家都很看好的大模型晴天用着很爽但一到高峰期就频繁超时。这种模型适合当推理模型不适合当默认模型。3.2 上下文长度直接决定使用体验上下文长度可以决定你要不要频繁把长文档拆给模型。拿我自己的用法举例默认模型的上下文窗口在 32k 以上我就可以放心把整个项目核心文档塞进去如果只有 8k一段完整的代码文件可能就被截断了。如果你的日常工作要频繁处理大段文本、长代码文件、完整报错栈那默认模型的上下文窗口最好不要低于 16k。不然天天被截断很烦躁。3.3 成本与配额要算细账除非你的用量很小价格这个东西早晚会成为约束。我见过不少人把最大最强模型设成默认月底一看账单大量本可以走小模型的普通请求全花在了大模型上。要清楚默认模型不等于最强模型它等于“最常用模型”。有个原则可以抄作业复杂任务手动切大模型常规任务全部交给默认模型。这也是我目前用着最舒服的搭配方式。3.4 我目前的默认模型搭配策略下面是一个参考样例你要替换成自己实际能拿到的模型ID。假设我有三个模型可用本地轻量模型、云上均衡模型、云端强推理模型。默认模型local/light-v8用于日常对话、修改文案、写小脚本。速度快访问成本低复杂逻辑会力不从心。备用模型cloud/core-v32覆盖场景更广主链路失败时自动顶上来。推理模型cloud/deep-v72在代码架构分析、复杂调试、长文档梳理时手动调用。这种组合既保证日常体验也留了后手。不同模型各有偏好不必照搬但结构可以借鉴一个快、一个稳、一个强。4. 实操通过命令和配置文件修改默认模型4.1 CLI 命令改模型如果 OpenClaw 自带命令行配置能力通常是这样设置openclaw config set model.default local/light-v8 openclaw config set model.fallback cloud/core-v32 openclaw config set model.thinking cloud/deep-v72这类命令一般会直接改写当前生效的配置文件而且会做基本校验提示你字段是否存在。命令返回成功再用状态命令确认一遍最稳妥。需要说明的是CLI改的通常是“当前生效层级”。如果你人在某个项目目录里它很可能会改到项目级配置而不是全局配置。想改全局最好先cd ~或者用配置命令自带的--global参数具体以工具帮助信息为准。4.2 直接编辑 TOML完整参考如果不支持CLI或者你想同时改多个字段直接编辑文件更直观。以~/.openclaw/config.toml为例[model] default local/light-v8 fallback cloud/core-v32 thinking cloud/deep-v72 [model.options] temperature 0.2 max_tokens 4096 timeout 30字段含义解释一下default默认模型所有未匹配到其他规则的请求都会走它。fallback默认模型异常时降级到备用模型。thinking需要展示深度推理过程时使用的模型。temperature越低越稳定默认任务我习惯设0.2。timeout请求超时时间单位秒建议30秒以上避免模型响应慢时过早中断。改完保存后重启 OpenClaw 服务进程确保新配置被加载killall openclaw 2/dev/null; openclaw serve /dev/null 21 如果你用的是图形界面版重启应用即可。4.3 修改后先做基线验证配置改完第一时间不是写业务而是打一个最基础的请求确认链路是通的openclaw run 你好请回复OK正常会看到返回内容并且日志里会出现一条匹配默认模型ID的记录。如果走了其他模型ID说明配置没有被真正加载按照第 5、6、7 节的排查思路往下走。5. macOS 专属的坑终端环境变量和加载顺序5.1 为什么终端里正常自动化脚本里全乱套OpenClaw 在很多场景下不是直接被终端使用而是被自动化脚本、后台任务调度执行。macOS 上这类程序一般不在交互式 Shell 里启动不会依次加载~/.zshrc、~/.zprofile这些文件所以你在终端里export OPENCLAW_MODEL...脚本里不一定生效。macOS 上交互式终端 Shell 的读取顺序通常是/etc/zprofile~/.zprofile/etc/zshrc~/.zshrc如果你把环境变量写在~/.zshrc凡是没有走这个文件启动的进程都拿不到这个变量。这也是很多“明明设了却不生效”问题的根源。5.2 用 launchctl 向 GUI 环境注入变量如果你希望 OpenClaw 从 Finder 启动或从其他图形界面工具里启动时也能读到默认模型可以用launchctl在用户级设置环境变量launchctl setenv OPENCLAW_MODEL local/light-v8重启你需要使用的应用后它会从用户环境中带上这个变量。注意这种方式设置的是登录会话级别的变量并不会写入.zshrc。清掉就用launchctl unsetenv OPENCLAW_MODEL这里有个细节只有当你确实依赖环境变量来指定模型时才需要这样设置。如果模型直接写在配置文件里就不必被环境变量问题绕进去。5.3 密钥与 Token 的安全存放涉及模型端点时很多终端需要密钥。Mac 上我推荐把它们放进系统的钥匙串而不是硬编码在配置文件里。这样既方便读取也能避免配置文件备份或分享时把密钥一并交出去。另外配置文件如果放在~/.openclaw下默认权限可能过于开放。执行chmod 700 ~/.openclaw把敏感配置保护起来。这个习惯我是在一次备份后发现备份文件里带出了密钥才养成的。6. 按项目隔离默认模型让不同目录跑不同模型6.1 项目级配置覆盖全局OpenClaw 支持在项目根目录下放一个.openclaw/project.yml作用范围仅限当前目录。非常适用于“这个仓库里我要一直用大模型做代码分析其他仓库不用”的场景。model: default: cloud/core-v32 thinking: cloud/deep-v72和全局配置相比项目配置的优先级更高。把项目配置纳入版本管理之后团队里其他人拿到仓库自动就能用同一套模型设定不需要每个人手动改一遍。6.2 管理多项目时的目录策略我的习惯是同一类工作放在同一个顶层目录下目录里再各放各的project.yml。因为 OpenClaw 寻找项目级文件时会向上逐级查找如果当前工作目录没有就会往上级目录找。如果你一个大的工作目录下所有子项目都想用同一种模型直接在父目录放一份project.yml就够了不用每个子目录都放。这个行为非常实用但也埋了一个隐患你以为当前项目没有配置文件其实某个上级目录带了一份。排查时用状态命令看一眼最有效。6.3 查看当前到底用了哪个模型在每个项目目录内运行openclaw model status输出会展示“当前项目配置”“全局默认”“最终生效模型”三段信息。不用猜直接告诉你是哪条规则生效是不是被项目级配置覆盖了。7. 配置之后的验证与排障7.1 状态命令怎么看openclaw model status的大致输出可以简化理解为这样project: demo-blog config file: .openclaw/project.yml default: cloud/core-v32 (project override) fallback: cloud/core-v32 thinking: cloud/deep-v72 effective: cloud/core-v32只要看到effective那一行和你想要的一致就能放心往下继续。这里有个容易忽略的小点配置项没有被显式设置时很多工具会把备用模型默认等同于默认模型。所以别看到 fallback 显示了个模型就以为是自己改出来的。7.2 通过日志确认实际走了哪个模型如果状态命令显示正确但实际请求还是不对就要看日志。OpenClaw 日志里通常包含一条类似“model selected: xxx”的记录。在 macOS 上日志一般位于~/Library/Logs/OpenClaw/或者通过命令直接输出到终端。看日志时建议过滤关键词tail -f ~/.openclaw/logs/run.log | grep -E model selected|fallback triggered|timeoutfallback triggered出现说明默认模型链路已经出过问题自动切到了备用模型。这时候如果发现所有请求都在走备用模型说明主线链路坏了要去排查终端密钥、配额或网络连接。7.3 常见问题快速排查表现象可能原因处理方式修改了全局配置却仍未生效项目级配置文件覆盖检查当前目录及上层目录有没有project.yml明明改对了却在用旧模型进程没重启重启 OpenClaw 服务进程或应用在终端能用自动化脚本里不能用脚本没读取 Shell 启动文件改用配置文件或用launchctl setenv日志中出现 fallback 触发默认模型端点异常检查默认端点密钥、配额、网络提示配置格式错误手动改 TOML 少写了标点优先用 CLI 或本地编辑器校验语法这张表基本覆盖了我在 Mac 上配置 OpenClaw 默认模型时遇到的高频问题对照处理可以省下大把时间。最后补一句经验默认模型配置这种事建议纳入版本管理不要只躺在单台机器里。我会在主目录维护一份配置模板新环境装好后直接套上去几分钟就能复现一套完整的工作环境。配置本身不复杂复杂的是“你以为配置完了”之后那堆隐性坑希望这篇文章能让你少踩几个。
阅读完成 · 觉得有帮助？
