1. Ubuntu 上 OpenClaw 首次落地：从 openclaw.json 到 Tool 权限的完整配置
OpenClaw 是一个能在本地跑起来、通过聊天软件远程指挥电脑执行任务的智能体框架，你可以把它理解成"给大模型装上手和脚"——它不只是聊天，还能开浏览器、读写文件、跑命令。这篇聚焦 Ubuntu 24.04 上的首次落地，把~/.openclaw/openclaw.json的基础配置、Tool 开关清单、以及 401、local proxy failed、reading choices 这几类高频报错逐条拆开。适合刚装完 OpenClaw、发现它"只会说自己是聊天软件"、或者想用统一 Key 通道把模型接稳的人。
我试过在 Ubuntu 24.04 上从零装一遍，整个过程比想象中顺，但坑集中在两处：一是安装脚本跑完后模型通道没配对，二是 Tool 面板全灰导致它拒绝执行任何系统操作。前者表现为请求直接 401，后者表现为它一本正经地回你"我只是个语言模型"。这两件事其实都指向同一个文件——openclaw.json。
Ubuntu 版本越新越省事。24.04 上像 Comfast 812AC 这类网卡基本即插即用，不用再手动折腾驱动；如果你用 U 盘装系统时遇到只有安装程序花屏，多半是显卡驱动，在 UEFI 引导项里给内核参数加上quiet splash再进，闪屏就没了。装好系统后，一行命令拉起安装：
curl -fsSL https://openclaw.ai/install.sh | bash过程中会提示缺依赖，按提示sudo apt update补装即可。终端出现交互式配置界面，就说明进入安装程序了，接下来每一步的选择都会写进~/.openclaw/openclaw.json。这个文件是整篇的核心，后面 Tool 权限、模型通道、报错排查全绕不开它。
配置向导里第一个问题是个人使用确认，选 Yes；接着选 QuickStart，细节后面用openclaw configure再调。到 Model/auth provider 这一步，列表里有 OpenAI、Anthropic、Moonshot、Qwen、MiniMax 等一长串。这里建议先想清楚你的 Key 从哪来——如果每个 provider 单独申请，Key 管理会很碎。我后面会讲怎么用统一通道把 Base URL 和 Key 收敛到一处，先按向导走完。
选完 provider 后 Filter models 选 All providers，Default model 选 Keep current。到 Select channel 这一步很关键：先选 Skip for now。很多人在这里直接绑 Telegram 或飞书，结果通道没配好反而干扰排查。正确顺序是先让 OpenClaw 本地跑起来，再装插件接飞书：
openclaw plugins install @m1heng-clawd/feishu装完插件再回头配通道，思路会清晰很多。向导结束后，openclaw.json已经生成，但里面的模型通道和 Tool 权限都还是默认值，这正是后面报错的根源。先别急着聊天，打开这个文件看一眼结构，下一节我们逐字段改。
2. TaoToken 前置：把 openclaw.json 的模型通道收敛到统一入口
OpenClaw 默认让你在向导里选一个 provider，然后填对应的 Key。问题是：如果你同时想用 Kimi 做长文本、用 Qwen 做代码、偶尔切 Claude，就得在多个平台分别申请 Key、分别充值、分别管额度。更麻烦的是，OpenClaw 的 provider 列表里有些通道在国内网络环境下请求不稳定，表现为超时或 401。
TaoToken 在这里的角色是统一 Key/API 通道：它提供一个兼容 OpenAI 协议的 Base URL，你用一把 Key 就能访问多个模型。对 OpenClaw 来说，只要把 provider 指向这个 Base URL，模型 ID 填对应名称，就能跑通。官网入口在 https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= ，API 地址是 https://taotoken.net/api 。
具体到 OpenClaw 的配置，你需要三样东西：Base URL、API Key、Model ID。这三件套在后面的openclaw.json里会分别对应baseUrl、apiKey、model字段。Key 的获取在控制台的 API Keys 页面，模型 ID 则取决于你想调哪个——比如moonshot/kimi-k2.5、qwen/qwen-max这类写法，具体以文档里的模型列表为准。
为什么建议在 OpenClaw 里用统一通道而不是逐个 provider 配？三个实际原因。第一，openclaw.json里 provider 字段一旦写死某个厂商，切换模型要改文件、重启 gateway，而统一通道下你只改model一行就行。第二，401 报错在多个 provider 各自 Key 的场景下极难定位，统一通道只有一把 Key，排查面收窄。第三，Tool 调用会频繁发请求，额度分散在多个平台时你很难判断是哪个通道被限流。
需要提醒的是，TaoToken 是合规的 API 聚合通道，不是让你绕过任何网络限制的工具。它的价值在于把模型访问收敛成标准 OpenAI 协议，让 OpenClaw 这类框架少踩 provider 适配的坑。如果你所在环境本身无法直连某些模型服务，应该先解决网络合规问题，而不是指望通道来"翻"过去。
配置前先确认两件事：一是openclaw.json的路径确实是~/.openclaw/openclaw.json，二是 gateway 没在后台跑着（否则改完不生效）。可以用ps aux | grep openclaw看一眼。确认后，下一节直接给可复制的配置片段。
3. 可复制配置：openclaw.json 基础字段与 Tool 开关清单
打开~/.openclaw/openclaw.json，你会看到一个 JSON 结构。不同版本字段名略有差异，但核心就几块：provider 定义、model 选择、tool 权限、channel 配置。下面给一份可直接对照修改的片段，路径与原文一致，字段名以你本地实际为准，改之前先备份：
cp ~/.openclaw/openclaw.json ~/.openclaw/openclaw.json.bak然后是配置主体。把 provider 指向统一通道，Key 和 Base URL 填进去：
{ "provider": { "custom": { "baseUrl": "https://taotoken.net/api", "apiKey": "sk-你的Key", "type": "openai-compatible" } }, "model": { "provider": "custom", "name": "moonshot/kimi-k2.5" }, "tools": { "profile": "message", "browser": true, "shell": true, "filesystem": true } }这里有几个点要展开。baseUrl填https://taotoken.net/api，注意不要多加斜杠或路径，OpenClaw 会自己拼/v1/chat/completions。apiKey就是控制台拿到的 Key。type写openai-compatible，因为统一通道走的是 OpenAI 协议。model.name填你想用的模型 ID，比如moonshot/kimi-k2.5，具体可用值查文档。
Tool 部分是重点。默认情况下tools.profile是message，意思是 OpenClaw 只被允许"发消息"，不允许碰系统。这就是为什么它老说自己是聊天软件——不是它笨，是权限被关了。把profile改成message之外的值（比如full或按文档给的执行档位），再把browser、shell、filesystem显式设为true，它才有能力开浏览器、跑命令、读写文件。
改完保存，回到终端重启 gateway：
openclaw gateway重启后打开管理网页 http://127.0.0.1:18789/ ，进 agent 的 tool 面板，原本全灰的开关应该亮起来了。如果还是灰的，说明 JSON 没被正确解析——常见原因是多了一个逗号、少了一个引号，或者字段名拼错。用python3 -m json.tool ~/.openclaw/openclaw.json校验一下语法，报错会直接告诉你第几行有问题。
关于 Tool 开关的取舍：shell和filesystem权限很高，OpenClaw 默认关掉是有道理的。如果你只是想让它在飞书里帮你查资料、开网页，browser打开就够；要它整理本地文件再开filesystem；shell留给确实需要跑命令的场景。全开等于把电脑交给它，自己权衡。
配置改完别急着在飞书里发指令，先在本地验证一次请求能不能通，下一节给验证动作。
4. 验证请求：从本地 curl 到首个任务跑通
配置改完，最稳的验证顺序是：先确认模型通道通，再确认 Tool 生效，最后才接聊天通道。跳过前两步直接去飞书发消息，一旦报错你分不清是通道问题还是通道问题。
第一步，用 curl 直接打统一通道，确认 Key 和 Base URL 没问题：
curl -s https://taotoken.net/api/v1/chat/completions \ -H "Authorization: Bearer sk-你的Key" \ -H "Content-Type: application/json" \ -d '{ "model": "moonshot/kimi-k2.5", "messages": [{"role": "user", "content": "回复ok"}] }'返回里如果有choices数组且 content 是ok，说明通道通了。如果返回 401，是 Key 问题；如果返回reading choices相关错误，是响应结构没解析对，多半是 Base URL 多写了路径。这一步过了，再进 OpenClaw。
第二步，本地起 gateway 后，用 OpenClaw 自己的命令发一条测试消息。具体命令看openclaw --help，一般是openclaw chat "帮我打开浏览器搜索 Ubuntu 24.04"这类。观察终端日志：如果它开始调用 browser tool，日志里会出现 tool 调用记录；如果它回你"我只是聊天软件"，说明 Tool 权限没生效，回上一节检查tools.profile。
第三步，接飞书。装完@m1heng-clawd/feishu插件后，按插件文档填 App ID、App Secret 等，重启 gateway。然后在飞书里给机器人发一句"打开浏览器搜索今天的天气"。成功的话，你会在电脑上看到浏览器被拉起、自动输入搜索词。这一步跑通，整个链路就闭环了。
实测下来，最容易卡住的是第二步到第三步之间：本地 chat 命令能跑，但飞书里没反应。这通常是 channel 配置和 gateway 没同时生效——改完 channel 配置必须重启 gateway，且飞书机器人的回调地址要指向你本地的 18789 端口（或你配置的端口）。如果飞书那边提示回调失败，先确认 gateway 在跑、端口没被占。
验证通过后，建议把这次能跑通的openclaw.json再备份一份，命名带日期。后面调 Tool 或换模型时，出问题可以快速回滚。下一节把几个高频报错逐条对照。
5. 常见报错排查：401、local proxy failed、reading choices 逐条对照
这几个报错在 OpenClaw 首次落地时出现频率最高，每个的根因和修法都不一样，别混着猜。
401 Unauthorized。表现是请求直接被拒，日志里带 401。根因基本是 Key 问题：Key 填错、Key 过期、或者Authorization头没带上。排查顺序：先用上一节的 curl 单独测 Key，curl 通说明 Key 没问题，那就是openclaw.json里apiKey字段没被读到——检查字段名是否拼对、JSON 是否合法。如果 curl 也 401，去控制台确认 Key 状态和额度。注意 Key 前后不要有空格，复制时容易带上。
local proxy failed。这个报错通常出现在 OpenClaw 尝试通过本地代理转发请求时。根因有两类：一是你系统里设了HTTP_PROXY/HTTPS_PROXY环境变量，OpenClaw 继承了但代理不可用；二是openclaw.json里配了 proxy 字段但地址写错。排查：env | grep -i proxy看有没有残留代理变量，有就unset掉再重启 gateway。如果确实需要走代理，确认代理地址和端口正确。这个报错和网络合规无关，纯粹是本地环境变量污染。
reading choices 报错。完整形态类似error reading choices from response，意思是 OpenClaw 拿到了响应，但里面没有它期望的choices字段。根因几乎都是 Base URL 写错：比如你填了https://taotoken.net/api/v1，OpenClaw 再拼/v1/chat/completions就变成/api/v1/v1/...，返回的是错误页而非标准响应。修法：baseUrl只填到https://taotoken.net/api，不要带/v1。另外，如果模型 ID 填错，有些通道会返回非标准结构，也可能触发这个报错，对照文档确认模型名。
OAuth 相关报错。如果你在向导里选了 OpenAI 的 Codex OAuth 而不是 API Key，会走一套浏览器授权流程。报错常见于回调地址不匹配或授权超时。如果你用的是统一 Key 通道，根本不需要走 OAuth，直接在openclaw.json里配apiKey即可，绕开这一整类问题。
Tool 全灰、拒绝执行。这不是报错，是权限问题，但最容易被误判成 bug。回到openclaw.json把tools.profile从message改掉，显式打开需要的 tool，重启 gateway。改完去 http://127.0.0.1:18789/ 的 tool 面板确认开关状态。
排查时养成一个习惯：每次只改一个字段，改完重启 gateway 再测。一次改三处，出问题你不知道是哪处引起的。日志是最好的线索，openclaw gateway前台跑着，报错会实时打出来，别用后台模式排查。
6. 把通道接稳之后：OpenClaw 日常使用的几个实用动作
链路跑通只是开始，日常用起来还有几个动作能让它更顺手。
模型切换。统一通道的好处在这里体现：想从 Kimi 换到 Qwen，只改openclaw.json里model.name一行，重启 gateway 即可，不用动 Key 和 Base URL。如果你经常切，可以准备几份配置片段，用的时候替换。
Tool 按需开。别长期全开。查资料场景只开browser；整理文件时临时开filesystem；shell用完就关。每次改完重启 gateway，去管理网页确认开关状态。这样即使 OpenClaw 判断失误，影响面也可控。
日志留存。openclaw gateway前台跑时把输出重定向到文件，出问题能回溯：
openclaw gateway 2>&1 | tee ~/.openclaw/gateway.log飞书通道的调试。如果飞书里发消息没反应，先看 gateway 日志有没有收到回调。没有回调就是飞书侧配置问题（App ID、回调地址、权限），有回调但没执行就是 Tool 或模型问题。分开定位，别一起改。
配置备份。每次改openclaw.json前cp一份带日期的备份。这个文件承载了模型通道、Tool 权限、通道配置三块，改坏了整个 OpenClaw 就瘫。有备份，回滚只要一条cp。
最后，Key 和 Base URL 这两样东西建议单独记在一个地方，别散落在多个配置文件里。统一通道的意义就是收敛，配置也收敛，排查时才不慌。