1. 飞书群里机器人抢答问题到底出在哪openclaw 接入飞书群聊之后最容易被忽略的成本不是模型单价而是调用次数。群里每来一条消息如果多个机器人账号各自判断一遍、各自请求一次大模型一天下来调用量会远超预期。我见过一个典型场景四个机器人开发、测试、产品、项目管理挂在同一个群里用户发一句「周末有什么安排」四个机器人都觉得跟自己有关于是四条相似回复刷屏同时产生四次远程大模型调用。这个问题的本质不是模型不够聪明而是消息在进入大模型之前缺少一层「该不该处理」的判断。openclaw 的飞书通道默认会把群消息分发给配置了该账号的 AgentAgent 再决定是否回复。判断逻辑如果只靠关键词或者简单的 检测就会出现两类浪费一类是无关消息被送进大模型另一类是多个机器人对同一条消息重复判断。前者浪费 token后者浪费并发。适合读这篇的人已经在飞书里跑 openclaw 机器人、发现调用量偏高、想在不牺牲响应质量的前提下把次数压下来的同学。下面我会从统一 Key 通道和降频触发规则两个角度给出可复制的 config.toml 骨架、判断函数写法以及用日志验证调用次数下降的方法。核心思路是把远程大模型调用收敛到「确实相关」的消息上其余消息只记录、不请求。2. 用 TaoToken 统一 Key先把调用通道理清楚在讲降频之前得先把 Key 和 API 通道统一。openclaw 的飞书多账号架构下如果每个机器人账号各配一套 Key、各写一个 baseUrl后面做调用统计和限流会非常痛苦。我的做法是让所有需要远程大模型能力的 Agent 走同一个通道本地小模型判断则走本地地址两者分开配置。TaoToken 在这里的角色是统一的大模型 API 入口。你可以在官网了解它的接入方式API 地址是 https://taotoken.net/api。把远程调用集中到一个 Key 上好处有三个调用量在一个地方看得到、限流策略可以统一施加、切换模型时不用改多个账号配置。具体操作上先去控制台创建一个 Key。打开 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite 在 API Keys 页面生成一个密钥复制保存。这个 Key 后面会写进 openclaw 的远程模型配置里。如果你还没决定用哪个模型可以先用模型对话页面试一下响应风格地址是 https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite 确认没问题再落到配置里。需要强调的是本地小模型判断比如 Ollama 跑的 gemma2和远程大模型处理是两条独立的通道。本地判断走 http://localhost:11434/v1远程处理走 TaoToken 的 API 地址。这样设计的原因是判断这一步要快、要便宜、要能离线而真正生成回复才需要远程大模型的能力。把两者混在一个通道里降频就无从谈起。3. config.toml 骨架与降频触发规则openclaw 的配置可以用 config.toml 组织。下面这份骨架把飞书账号、本地判断模型、远程处理模型、降频规则分开写你可以直接照着改。注意 apiKey 和 baseUrl 要替换成你自己的值远程部分用上一步在控制台拿到的 Key。# openclaw config.toml 骨架 [channels.feishu] enabled true # 飞书多账号每个机器人一个 account [channels.feishu.accounts.devbot] appId cli_xxx_dev appSecret xxx agent dev [channels.feishu.accounts.qabot] appId cli_xxx_qa appSecret xxx agent qa # 本地小模型只做相关性判断不生成回复 [smartFilter] enabled true model gemma2-cpu:latest baseUrl http://localhost:11434/v1 apiKey ollama timeoutMs 3000 cacheTtlMs 300000 # 远程大模型真正生成回复统一走 TaoToken [llm] provider taotoken baseUrl https://taotoken.net/api apiKey sk-你的TaoToken密钥 model claude-3-5-sonnet maxTokens 1024 # 降频触发规则 [throttle] # 被 或私信直接放行不经过本地判断 bypassOnMention true bypassOnDm true # 同一会话内N 秒内相同内容只判断一次 dedupWindowSec 30 # 每个账号每分钟最多触发的远程调用次数 maxRemoteCallsPerMin 6 # 判断为不相关时只记录历史不请求远程 recordOnlyWhenIrrelevant true这份配置里降频的关键在[throttle]段。bypassOnMention和bypassOnDm保证明确指向机器人的消息不被误过滤dedupWindowSec解决同一条消息被多个账号重复判断的问题maxRemoteCallsPerMin是最后一道闸防止突发流量把远程调用打满recordOnlyWhenIrrelevant让不相关消息仍然进入历史记录只是不触发远程请求。判断逻辑本身要结合 Agent 身份。每个 Agent 的工作目录下放一个 IDENTITY.md写明它是谁、负责什么。判断函数读取这个文件作为 system prompt 的一部分让本地小模型知道「这条消息跟当前机器人有没有关系」。以开发机器人为例IDENTITY.md 里写清楚它只处理代码、接口、配置类问题那么「测试报告什么时候出」这类消息就会被判为不相关。// gate.js 中的相关性判断 async function callRelevanceModel({ message, config, agentIdentity }) { const resp await fetch(${config.baseUrl}/chat/completions, { method: POST, headers: { Content-Type: application/json, Authorization: Bearer ${config.apiKey}, }, body: JSON.stringify({ model: config.model, messages: [ { role: system, content: 你是消息相关性判断助手。\n【机器人身份】\n${agentIdentity}\n 相关消息针对该机器人、询问其能力、请求其帮助。\n 不相关群成员闲聊、与机器人职责无关的讨论。\n 只输出 JSON{relevant: true/false}, }, { role: user, content: 判断${message} }, ], max_tokens: 50, temperature: 0.1, response_format: { type: json_object }, }), }); const data await resp.json(); return JSON.parse(data.choices[0].message.content).relevant true; }这段函数只做一件事返回 true 或 false。返回 false 时消息进入历史记录但不调用远程大模型。返回 true 时才走[llm]段配置的 TaoToken 通道生成回复。判断和生成彻底分离是降频能生效的前提。4. 验证请求日志里看调用次数有没有降配置写完必须验证。openclaw 的日志会记录每次消息进入和每次远程请求。你可以开两个终端一个跑机器人一个跟踪日志。# 终端 1启动 openclaw日志输出到文件 openclaw start --log-level debug 21 | tee openclaw.log # 终端 2统计远程调用次数 grep -c POST https://taotoken.net/api openclaw.log # 统计本地判断次数 grep -c localhost:11434 openclaw.log # 看被过滤掉的消息 grep recordOnly openclaw.log | tail -20验证时按三步走。第一步在群里发一条明确 开发机器人的消息日志里应该出现一次本地判断如果 bypassOnMention 生效则直接跳过判断和一次远程调用。第二步发一条跟开发无关的闲聊日志里应该只有本地判断没有远程调用并且出现 recordOnly 标记。第三步连续发五条相同内容由于 dedupWindowSec 的存在本地判断应该只发生一次后续命中缓存。如果远程调用次数没有下降先检查[smartFilter]的 enabled 是否为 true再检查判断函数的 baseUrl 是否指向本地。常见的情况是判断函数误配成了远程地址导致「判断」这一步本身就在消耗远程调用那就本末倒置了。判断准确率方面本地小模型在 2B 到 3B 参数量级别对「是否相关」这种二分类任务通常能到九成左右。边界情况主要是模糊消息比如「这个配置怎么写」既可能问开发也可能问测试。这类消息宁可放行也不要误杀因为漏掉一条相关消息的体验损失比多调用一次大模型更大。你可以在 throttle 里给这类消息留一个白名单关键词。5. 本篇常见错排查报错一本地判断超时消息全部被丢弃。现象是日志里大量 timeout机器人不回复。原因是 Ollama 没启动或者模型没拉下来。先确认ollama list里有 gemma2-cpu:latest再确认 11434 端口可访问。timeoutMs 不要设太小本地小模型首次加载会慢给到 3000ms 比较稳。报错二远程调用返回 401。说明 TaoToken 的 Key 没配对或者 config.toml 里 apiKey 还留着占位符。去控制台重新确认 Key注意不要有多余空格。如果用的是环境变量注入检查变量名是否和配置里引用的一致。报错三所有消息都被判为不相关。大概率是 IDENTITY.md 没读到agentIdentity 传了空字符串本地模型没有判断依据。检查工作目录路径拼接是否正确加一行日志把 identity 内容打出来确认。报错四多个机器人仍然重复回复。检查 dedupWindowSec 是否生效以及多个账号是否共享同一个缓存实例。如果每个账号进程独立缓存不共享需要在网关层做去重而不是在单个账号内做。报错五maxRemoteCallsPerMin 触发后消息被静默丢弃。这是限流生效的表现但体验不好。建议在触发限流时给用户一个「稍后再试」的提示而不是完全不响应。限流阈值根据群活跃度调整6 次每分钟对大多数群够用特别活跃的群可以放宽到 10 次。6. 后续怎么接按场景选入口降频配置跑通之后下一步取决于你的使用场景。如果你主要是在排障和接入阶段需要反复确认 Key 和通道是否正常建议从 API Keys 和接入文档入手先把通道稳定性验证好地址是 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite 和 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 。如果你还在对比不同模型的判断效果和回复质量可以先用模型对话页面快速试不用每次都改配置重启机器人地址是 https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite 。如果你的机器人要长期跑在群里、还要接编码类 Agent 做持续任务那调用量和并发会更高适合用 Coding Plan 把额度固定下来避免按次计费在高峰期失控地址是 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite 。选哪个入口取决于你现在是「调通」阶段还是「长期跑」阶段两者配置重点不一样。