
1. 龙虾 openclaw 搜索网络资讯失效的典型场景你给 openclaw 发一句「帮我查一下最近三天关于某个技术话题的新闻」它要么回你一段明显是旧数据的总结要么直接报错说搜索失败要么干脆绕开搜索、用模型自己的记忆瞎编一段。这种「看起来在搜、其实没搜到」的情况绝大多数不是模型变笨了而是 web_search 和 web_fetch 这条链路中间断了。openclaw 内置的联网能力其实分成两个独立技能。web_search 负责「找」它默认走 Brave Search API把关键词变成一批候选结果并且会顺手做一层整理返回比较干净的摘要。web_fetch 负责「读」它用 HTTP 协议直接把某个 URL 的页面抓下来但抓下来的原始 HTML 还需要模型再提炼一遍才能变成人话。这两个技能是串联关系先搜到链接再抓正文。任何一环出问题你看到的都是「搜不到资讯」。我见过最常见的三种表现。第一种是搜索源本身没配好Brave Search API 的 key 缺失或者额度耗尽web_search 直接返回空数组模型拿不到任何链接只能自己编。第二种是鉴权失败key 格式不对、被截断、或者环境变量没注入请求发出去被 401 挡回来。第三种是抓取环节挂了搜索明明返回了链接但 web_fetch 去抓的时候遇到反爬、超时、或者页面是纯 JS 渲染的抓回来一堆空标签模型提炼不出内容。还有一个容易被忽略的点频率限制。如果你用的是某些 coding plan 套餐通常 5 小时 1200 次调用超了就会限速。这时候搜索请求会被排队甚至丢弃表现和「搜索源坏了」一模一样。所以排查的第一步不是急着换工具而是先确认到底是搜索源、鉴权、抓取还是配额的问题。这篇就按这条链路给你一份能逐项对照的排查清单每一步都有可复制的配置和验证动作。2. TaoToken 前置准备把模型调用和搜索链路分开看在动手排查之前先把一个概念理清楚openclaw 的「搜索不好用」和「模型不好用」是两件事。模型负责理解你的意图、决定要不要搜、以及把搜到的内容总结成人话搜索技能负责真正去网上拿数据。很多人一遇到搜索失败就去换模型其实方向错了。我自己的做法是把模型调用统一走 TaoToken 这个入口这样模型侧的稳定性和搜索侧的问题可以分开定位。TaoToken 是一个聚合式的模型调用服务官网在 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 地址是 https://taotoken.net/api 。它的作用是让你用一个统一的 Base URL 和 Key 去调用不同模型省得每个模型单独配一套鉴权。对于 openclaw 这种需要频繁调用模型来决定「搜不搜、怎么搜」的场景把模型入口固定下来排查时就能排除掉「是不是模型侧鉴权挂了」这个变量。具体来说你需要准备三样东西我把它叫做「三件套」Base URL、API Key、Model ID。Base URL 填 https://taotoken.net/api API Key 在控制台生成Model ID 按你实际要用的模型填。这三件套在 openclaw 的模型配置里填一次之后所有对话都走这个入口。如果你还没生成 Key可以去 API Keys 页面拿https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite 。生成之后先别急着填进 openclaw用 curl 单独验证一下这个 Key 能不能通这一步能帮你排除掉后面一半的困惑。curl https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer 你的_API_KEY \ -H Content-Type: application/json \ -d { model: 你的_Model_ID, messages: [{role: user, content: 只回复两个字通了}] }如果这条命令返回了正常的 JSON说明模型侧的三件套没问题搜索失败就一定是 web_search 或 web_fetch 的事。如果这条就报 401那先解决鉴权别往下查搜索。这个「先隔离变量」的习惯能让你少走很多弯路。另外提一句openclaw 的搜索技能配置和模型配置是分开存放的。模型走 TaoToken搜索走 Brave 或 Tavily两者互不影响。所以你在排查时看到 401 要先判断是哪个环节返回的——是模型调用被拒还是搜索 API 被拒。报错信息里的 URL 域名能帮你快速区分。3. 可复制的 web_search 与 web_fetch 配置片段这一节给你可以直接抄的配置。openclaw 的技能配置一般放在项目根目录的配置文件里常见的是 JSON 或 TOML 格式。下面我按两种搜索源分别给片段你按自己用的那个改。先说 Brave Search API 的配置。Brave 的 key 需要在它的开发者后台申请拿到之后填进配置。注意 Brave 目前是付费的免费额度很有限这也是很多人搜索突然失效的原因——额度用完了。{ skills: { web_search: { provider: brave, api_key: 你的_BRAVE_API_KEY, base_url: https://api.search.brave.com/res/v1/web/search, count: 10, timeout_ms: 15000 }, web_fetch: { provider: http, timeout_ms: 20000, max_bytes: 2000000, user_agent: Mozilla/5.0 (compatible; openclaw/1.0) } } }再说 Tavily 的配置。Tavily 对登录用户每月给 1000 Credits普通体验基本够用而且它返回的结果本身就是整理过的对模型更友好。key 的格式是 tvly- 开头的一串字符。{ skills: { web_search: { provider: tavily, api_key: tvly-你的_TAVILY_KEY, base_url: https://api.tavily.com/search, search_depth: basic, max_results: 8, include_answer: true }, web_fetch: { provider: http, timeout_ms: 20000, max_bytes: 2000000, user_agent: Mozilla/5.0 (compatible; openclaw/1.0) } } }如果你更习惯 TOML等价写法是这样[skills.web_search] provider tavily api_key tvly-你的_TAVILY_KEY base_url https://api.tavily.com/search search_depth basic max_results 8 include_answer true [skills.web_fetch] provider http timeout_ms 20000 max_bytes 2000000 user_agent Mozilla/5.0 (compatible; openclaw/1.0)几个参数值得单独说。timeout_ms别设太短很多资讯站点响应慢15 秒以下容易误判为失败。max_bytes控制抓取页面的最大体积设太小会截断正文设太大又浪费 token200 万字节是个比较稳的值。user_agent一定要填一个正常的浏览器标识否则很多站点会直接拒绝你的抓取请求这就是 web_fetch 抓回空内容的常见原因。配置改完之后openclaw 一般需要重启或者重新加载技能才能生效。如果你是通过对话让它「安装技能」它会自己写配置但写进去的 key 有时会被截断所以装完一定要打开配置文件核对一遍 key 的完整性。我踩过的坑就是 key 中间少了一位排查了半天才发现是复制时漏了。4. 逐项验证从搜索源到抓取的成功结果长什么样配置写完不算完得逐项验证。我习惯按「搜索源 → 鉴权 → 抓取」的顺序每一步都单独测这样哪一步挂了立刻能定位。第一步单独测搜索源。用 curl 直接打 Brave 或 Tavily 的接口绕开 openclaw看返回什么。curl -X POST https://api.tavily.com/search \ -H Content-Type: application/json \ -d { api_key: tvly-你的_TAVILY_KEY, query: openclaw web_search 配置, max_results: 5 }如果返回的 JSON 里有results数组并且每个元素带url和content说明搜索源和鉴权都没问题。如果返回 401是 key 的问题返回 429是频率或额度的问题返回空数组是查询词或 provider 配置的问题。第二步测 web_fetch。随便拿一个上一步返回的 url让 openclaw 去抓或者直接用 curl 模拟curl -sL https://某个搜索结果页面的URL \ -H User-Agent: Mozilla/5.0 (compatible; openclaw/1.0) \ | head -c 2000正常情况你应该看到一堆 HTML里面有正文文字。如果看到的是空的、或者一堆script没有实际内容说明这个页面是 JS 渲染的web_fetch 这种纯 HTTP 抓取拿不到需要换支持渲染的抓取方式或者换一个静态页面源。第三步端到端测。在 openclaw 里发一句明确的搜索指令比如「搜索 openclaw web_search 配置给我三个来源链接和每个链接的一句话摘要」。成功的返回应该包含真实的 URL、每个 URL 对应的摘要、以及摘要内容和 URL 主题相关。如果摘要和 URL 对不上或者 URL 是编的说明模型在没拿到搜索结果的情况下自己编了回到第一步查搜索源。一个健康的端到端结果大概长这样模型先调用 web_search 拿到 5 到 8 条结果然后对其中 2 到 3 条调用 web_fetch 抓正文最后综合成一段带引用的回答。你可以在 openclaw 的日志里看到这两类调用记录。如果日志里只有模型调用、没有 web_search 调用说明模型压根没触发搜索技能那要检查技能有没有被正确注册为默认搜索技能。验证通过之后建议把这三个 curl 命令存成一个脚本下次再出问题直接跑一遍两分钟就能定位。这比每次重新翻配置高效得多。5. 本篇常见报错排查401、local proxy failed、reading choices、OAuth这一节把几个高频报错逐个拆开。你遇到的具体报错大概率就在下面这几个里。401 Unauthorized。这个最常见也最好定位。先看报错里的域名如果是taotoken.net那是模型侧的三件套没配对回去检查 Base URL、API Key、Model ID如果是api.search.brave.com或api.tavily.com那是搜索源的 key 有问题。搜索源的 401 通常是 key 被截断、过期、或者环境变量没注入。检查方法就是把配置里的 key 复制出来和后台显示的一字不差地比一遍。注意有些编辑器会自动去掉行尾空格也可能把特殊字符转义用cat -A 配置文件能看到隐藏字符。local proxy failed。这个报错说明 openclaw 在尝试通过本地代理发请求但代理没起来或者端口不对。如果你没有特意配代理那大概率是环境变量里残留了HTTP_PROXY或HTTPS_PROXY。检查一下env | grep -i proxy如果有输出而且你并不需要代理就把它 unset 掉再重启 openclaw。这个报错和搜索源本身无关是网络出口配置的问题。reading choices 相关报错。这类报错通常出现在模型返回结构不符合预期的时候比如你期望它返回一个带choices数组的 JSON但实际拿到的是别的东西。常见原因是 Model ID 填错了调到了一个不兼容的接口或者 Base URL 少了/v1路径。回到三件套核对Base URL 是 https://taotoken.net/api 完整的 chat 接口路径是/v1/chat/completionsModel ID 要和平台文档里列出的完全一致。改完用第 2 节那条 curl 再测一次。OAuth 相关报错。如果你用的是 Claude Code 这类需要 OAuth 授权的工具报错可能出现在 token 刷新环节。OAuth 的 token 有有效期过期后需要重新授权。检查你的授权配置里 refresh token 是否还在以及系统时间是否准确——时间偏差过大会导致 token 校验失败。如果是通过 openclaw 间接调用确认 openclaw 用的鉴权方式和你手动测的一致别一个用 OAuth 一个用 API Key混用必然报错。排查时有个通用技巧把 openclaw 的日志级别调到 debug然后复现一次失败日志里会打印出实际发出的请求 URL、请求头和返回状态码。对照这些信息上面四类报错基本都能一眼定位。别靠猜靠日志。6. 稳定获取网络资讯的后续配置建议把上面的链路跑通之后还有几个配置能让你的搜索长期稳定不至于过几天又失效。第一给搜索源设一个额度监控。Brave 和 Tavily 都有用量查询接口你可以写个定时任务每天查一次剩余额度快用完时提前换源或充值。Tavily 每月 1000 Credits如果你每天搜几十次大概半个月就会见底提前知道比突然失效强。第二web_fetch 加一个失败重试。很多站点偶发超时重试一次就成功了。在配置里加retry: 2和retry_delay_ms: 1000能显著降低「抓取失败」的误报率。第三把常用的搜索源做成可切换的。配置里别写死一个 provider留一个环境变量控制比如SEARCH_PROVIDERtavily这样 Brave 额度用完时改个变量就能切到 Tavily不用改代码。第四模型侧继续走 TaoToken 的统一入口。这样无论你换哪个模型Base URL 和 Key 都不用动搜索排查时也能稳定排除模型变量。需要长期跑编码或 Agent 任务的可以看看 Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite 它适合高频调用的场景。想先验证模型对话效果的去模型对话页试试https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite 。接入细节和参数说明都在文档里https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 。最后说个实操习惯每次改完搜索配置别直接问一个复杂问题先用「搜索 X返回三个链接」这种最简单的指令验证链路。链路通了再上复杂任务。这样出问题时你能确定是配置问题还是任务本身的问题。搜索技能这东西配置对了就一劳永逸配置错了就天天报错差别就在你有没有按这条清单逐项验证过。