OpenClaw v2.7.9 通道绿了却不说话TaoTokenhttps://taotoken.net/?utm_sourcetaotoken_aicg_blog_end先把结论放这儿——微信通道参数和模型参数在 config.yml 里是两段互不相干的配置。ClawBot 插件扫码授权只解决了「消息进得来」没人负责「话出得去」。于是你会看到一个很迷惑的画面通道状态显示 connected微信里私信发得出去机器人这边一条回执都没有日志还不报错只留下一串「收到消息」的记录。原文 3.2、3.3 两节讲的是插件启用和扫码授权那两步不用重做二维码再扫十遍也不会让模型开口。真正缺的是第六节那句「接入主流大模型增强 AI 对话」——它只有一句话没落到 config.yml 的哪一行也没说 Base URL 填什么、Key 从哪来。这篇按排障的路子走先用日志确认卡在哪一层再补齐模型段最后发一条测试私信做闭环跑通了才回头动心跳和重试。如果你还在本地openclaw init --mode local --channel weixin、云端 docker-compose、命令行 npm 三种部署之间犹豫先别急。三种部署改的是同一个model段只是 config.yml 的位置不同第 3 节会把三个落点都写清楚。1. 先分清 connected 是哪一层的状态weixin.log 三段式排障1.1 connected 只代表 ClawBot 插件这一层通了通道状态是插件向微信侧做授权回执和心跳之后拿到的结果它证明的是三件事扫码授权换到的凭证还有效、app_id和token这一组参数没写错、消息能被投递到 OpenClaw 进程里。它完全不涉及模型侧——也就是说哪怕model段整段缺失通道照样可以是 connected。这两层的耦合极弱弱到你在控制台看到的绿色和模型能不能回话没有半点关系。很多人第一次遇到「通道通了但不接话」下意识会去查二维码是不是过期、插件是不是没启用、要不要重新授权一次。这些动作都在 channel 层打转做完了状态还是绿的问题还在原地。正确的第一反应是把收到的私信当成一次请求沿着日志看它走到了哪一步断掉。1.2 一条私信进来日志里应该有三段痕迹以本地部署为例日志目录通常跟配置文件同级路径类似./logs/weixin.logdocker-compose 部署则落在你挂载出去的./data/logs/weixin.log。用tail -f挂着然后从手机微信给机器人发一条「你好」正常链路会出现三段第一段是入站通常带openid、msgid、时间戳表示 ClawBot 已经把消息交给 OpenClaw 了。第二段是请求组装这一段的信号最有价值——它会打印本次要调用的 provider、model、base_url。第三段是出站表示回复已经交给微信侧发送。tail -f ./logs/weixin.log | grep -E inbound|provider|outbound如果日志里第一段、第三段都有中间那段是空的或者中间那段出现了类似provider not configured、no model available、empty completion这类提示答案就明确了消息进来了、回复发不出去卡在模型调用上。日志文案随版本可能略有差异但断点的位置是固定的——中间那一段没有内容就是模型段没生效。提示排障期间把runtime.log_level临时调到debug模型请求的参数会打印得更完整比如实际使用的 base_url 和 model 名。改完记得验证完再调回去否则日志体积涨得很快。1.3 排障期间先别动扫码和插件开关这一条听起来像废话但踩过的人不少。排障需要一个稳定的对照组如果一边查日志一边重新扫码、重启插件、改app_secret日志里的现象会互相覆盖你分不清是模型段生效了还是刚才那次重新授权把连接重置了。所以第 1 节的产出只有一个确认卡在模型侧。确认之后3.2、3.3 的插件配置和扫码授权保持原样一个字都不用改。2. config.yml 里的 model 段Base URL 与 Key 从哪来2.1 打开官网注册并创建一把 API Key模型侧需要两样东西一个能收请求的接口地址一把能通过鉴权的 Key。这两样都在 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 拿到——注册账号、进控制台、创建 API KeyKey 一般只在创建时完整显示一次复制后先存进你的密码管理器或者本地.env别直接贴在聊天窗口里。这里要区分两个地址混用是后面 404 的高发原因用途地址说明注册、创建 Key、看模型广场、查用量https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end给人点的页面填进 config.yml 的 Base URLhttps://taotoken.net/api给程序调的接口地址末尾不加/v1创建好 Key 之后顺手在模型广场把你要用的模型 ID 抄下来下一步马上要用。2.2 model 段怎么写字段名以你初始化的模板为准不同版本 OpenClaw 初始化的 config.yml 模板字段名会有细微差别判断依据很简单初始化时终端打印出来的那份模板。下面这份是 v2.7.9 常见结构改之前先跟你的模板对一遍键名别硬套。# config.yml runtime: mode: local # local / cloud与初始化时的 --mode 对应 log_level: info channel: weixin: enabled: true plugin: clawbot app_id: YOUR_WX_APP_ID app_secret: YOUR_WX_APP_SECRET token: YOUR_WX_TOKEN heartbeat: interval: 30s retry: 3 model: provider: openai # 走兼容协议字段名以你的模板为准 base_url: https://taotoken.net/api api_key: YOUR_API_KEY model: 以 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 模型广场为准 timeout: 60s max_tokens: 1024三个地方值得单独强调。base_url用https://taotoken.net/api末尾不要带/v1也不要把官网页面地址那串带 UTM 的链接填进来——那是给人点的不是给程序调的。api_key填你刚创建的那把占位符YOUR_API_KEY只是示意。model字段写模型广场里实际存在的 ID别凭印象写。2.3 模型 ID 别凭记忆填抄列表最省事模型 ID 对不上日志里的表现是请求发出去了、马上被打回来提示模型不存在或者找不到对应模型。这一类的排查成本其实很低只要你不是凭记忆写。打开模型广场把列表里的 ID 原样复制连大小写和中间的连字符一起复制粘进 config.yml 就完了。列表会更新所以以你配置当天的列表为准别用半年前文章里的 ID。另外如果同一套微信客服后面想换更便宜或更快的模型改的只是model这一行base_url和api_key不用动。这也是把它放在配置文件里而不是硬编码进业务逻辑的好处。3. 本地 init、docker-compose、npm 三种部署config.yml 各在哪3.1 本地openclaw init --mode local --channel weixin生成的那份本地模式最简单初始化命令跑完当前目录或者它提示的 profile 目录下会生成 config.yml 和配套的日志目录终端一般会把路径打印出来。直接用编辑器打开这份文件把 2.2 的model段补进去然后重启进程让配置重新加载。# 目录结构大致是这样具体以初始化输出为准 # ./config.yml # ./logs/weixin.log openclaw restart # 或者直接 CtrlC 之后重新启动改完不要急着发私信先确认启动日志里没有解析报错。YAML 对缩进很敏感model段如果层级比channel低一级或者多缩了两个空格进程启动时就可能把整段忽略掉表现跟没配一模一样。3.2 云端 docker-compose注意挂载的不是镜像里的默认文件容器部署的坑集中在一点你改的是宿主机的文件容器读的可能是镜像内自带的默认配置。确认 compose 文件里 config.yml 和日志目录都挂出来了services: openclaw: image: openclaw/openclaw:2.7.9 restart: unless-stopped ports: - 8080:8080 volumes: - ./data/config.yml:/app/config.yml - ./data/logs:/app/logs environment: - OPENCLAW_CONFIG/app/config.yml如果你是通过环境变量注入部分配置注意不要把模型配置拆成一半写在环境变量、一半写在 config.yml。同一份配置有两个来源时很容易出现「我以为改了、其实被另一处覆盖了」的情况。建议模型段统一写在挂载进去的 config.yml 里。改完执行docker compose restart openclaw然后从宿主机的./data/logs/weixin.log看日志不用进容器。3.3 npm 全局安装配置路径看初始化输出别猜命令行 npm 部署通常是先npm install -g装一个全局版本再执行 init。这种情况下配置文件不在当前项目目录而是在用户目录下常见形式是~/.openclaw/config.yml。这个路径不保证在所有版本里都一样所以最稳的办法是回看初始化时终端打印的那几行路径照着改。# 路径以初始化输出为准下面只是常见形态 # ~/.openclaw/config.yml openclaw --version # 先确认跑的是不是 v2.7.9改完同样重启进程再用日志确认生效。三种部署到这里其实走的是同一件事找到真正被读取的那份 config.yml把model段补上重启验证。4. 发一条测试私信用 weixin.log 确认模型真的接上话了4.1 测试私信怎么发才有对照价值发之前先做两件小事日志tail -f挂上时间点记住。然后从微信发一条内容明确、不容易被缓存或去重逻辑吞掉的私信比如「现在几点」或者「你是谁」别连发三条一模一样的——消息去重可能把后两条吃掉你反而以为模型只回了一次。发完等三到五秒。如果模型段配好了微信侧应该看到回复如果没看到日志里一定有痕迹往下走 4.2。4.2 日志里看到什么才算真的通了打通之后中间那段请求记录会有实际内容调用的是哪个 provider、base_url是什么、model是什么、请求耗时多少、返回了多少 token。这一段是排障的锚点——它一旦有内容说明模型侧已经在参与这次对话了。反过来段落顺序也很说明问题日志现象判断只有入站没有后续消息没进入处理流程查插件与授权有入站、有 provider 行但报错模型段被读到了是参数问题有入站中间整段空白model 段没被读到检查缩进与字段名三段齐全但微信没显示查出站发送与消息去重看到第三行请回到 2.2 检查 YAML 层级看到第二行直接跳到 4.3。4.3 401、404、model not found 三个错对号入座401基本只有一个原因Key 不对。可能是复制时漏了尾巴、可能是 Key 被删除或者轮换了、也可能配置里还残留着上一次的旧 Key。解决办法是重新在控制台创建一把替换api_key字段重启进程。404大多是地址拼错了。重点检查两处base_url是不是写成了带 UTM 的官网页面地址以及末尾有没有多一个/v1。填进配置的应该是https://taotoken.net/api末尾不带/v1。model not found一类的提示就是模型 ID 对不上。回模型广场把 ID 原样复制一遍注意别用中文引号或者全角字符包住。注意同一个报错在不同版本里的文案可能不同别死记字符串看它的类型就够了——鉴权类、路由类、模型类三类分别对应上面三种改法。5. 通完再调 4.1 的心跳间隔与重试次数别把重试变成重复回复5.1 heartbeat 间隔跟你微信侧的超时窗口对齐心跳的作用是告诉微信侧「这个连接还活着」。间隔设得太短请求密度上来日志噪音大也更容易触发限频设得太长连接容易被判定为不活跃断开之后靠重连救回来消息就可能有几秒到几十秒的不可用窗口。调这个值的方法很朴素改heartbeat.interval重启挂日志观察一两个小时看有没有断开重连的记录。如果这段时间里断连频繁就把间隔往短了调一档如果一直很稳就没必要为它牺牲体积小的日志。至于具体填多少和你的部署环境、网络质量有关没有普适的最优值。5.2 retry 次数和消息去重是成对出现的重试的语义是「这次请求没拿到结果再试一次」。问题在于微信的消息处理不是完全幂等的场景——如果模型其实已经生成并发出去了只是回执丢了重试会让同一条私信被回两次。用户端看到的就是机器人「复读」。保守的做法是把heartbeat.retry保持在较小值先观察日志里重试命中率高不高。如果重试基本不触发说明链路够稳不用加如果经常触发优先查链路本身而不是无脑加次数。同时确认 OpenClaw 侧是否有基于msgid的去重逻辑有的话把它开着。这里的原则是心跳和重试属于稳定性参数它调的是「连接稳不稳」不是「模型答得好不好」。模型答得好不好取决于你选了哪个模型那是model字段的事。6. 换模型、看用量把私域客服长期跑起来走到这一步你应该已经能在日志里看到完整的入站、请求、出站三段微信里也能收到模型生成的回复。剩下的事情更偏日常运维观察哪些问题被问得最多、哪些回复质量一般然后决定要不要换一个更适合客服场景的模型。换模型只改一行。在模型广场挑好 ID替换 config.yml 里的model重启进程再发一条测试私信确认。base_url和api_key不用碰这也是把模型接入独立成一段配置的意义——换模型不用碰微信通道的任何参数。用量和调用记录在控制台看。排障做完之后建议去对一下这次测试私信有没有被记上账包括调用次数和 token 消耗如果发现记录明显比实际发的消息多多半是重试在频繁命中回到 5.2 把重试调保守一点。地址还是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end Key 管理、模型广场、用量都在这个控制台里。如果后面要把这套私域客服接到更多的对话场景或者想在同一把 Key 下测试多个模型的回复质量可以先去 模型对话 里直接用同一把 Key 发几条消息横向比一比确认哪个模型更适合你的客服话术再回来改 config.yml。长期跑的话Coding Plan 里能看到套餐额度是否够用需要新建或轮换 Key 就进 控制台 API Keys。最后留一句提醒通道 connected 是插件层的事模型接不接得上话是 model 段的事这两件事在排障时千万别混着查。先用 weixin.log 把断点定位清楚再动手改配置一次只改一个字段改完就重启验证——这套顺序能帮你省掉大部分「明明改了却没生效」的时间。