OpenClaw 中 web_search + web_fetch 最佳实践速查表

OpenClaw 中 web_search + web_fetch 最佳实践速查表

OpenClaw 中 web_search + web_fetch 最佳实践速查表

摘要:本文帮助读者明确 OpenClaw 网络搜索工具和不同搜索技能的的职责边界,理解“先搜索、再抓取、后总结”的最佳实践,并能更稳定地在 OpenClaw 中使用 tavily-searchweb_fetch 完成网络信息搜索任务。主要内容包括:解决 OpenClaw 中 web_searchtavily-searchweb_fetch、原生 provider 与扩展 skill 容易混淆的问题、网络搜索能力分层说明、OpenClaw 原生搜索 provider 与 Tavily/Firecrawl 扩展 skill 的区别、标准工作流、提示词模板、命令行验证、常见误区与排障方法。

导读:如果你还没有为 OpenClaw 安装 Tavily-Search 、Agent-Reach 或平替的搜索技能,先阅读以下文章:Tavily-Search 安装 (TODO)Agent Reach 安装与 OpenClaw 网络搜索能力扩展指南

目录


一、核心结论

在 OpenClaw 里,最容易混淆的几个概念是:

  • web_search
  • tavily-search
  • web_fetch
  • 原生搜索 provider
  • 扩展 skill

最准确、最实用的理解方式是:

  • ​**web_search**​:统一的网页搜索能力接口/抽象能力
  • ​**web_fetch**​:统一的网页读取/抓取能力接口
  • 原生 provider​:OpenClaw 直接支持配置的搜索后端
  • 扩展 skill​:用户手动安装后接入的额外搜索/抓取能力
  • ​**tavily-search**​:属于扩展 skill,不是 OpenClaw 2026.3.13 当前配置向导里的原生 provider

一句话记忆:

搜索负责找,抓取负责读;原生 provider 是 OpenClaw 自带接线,Tavily / Firecrawl 是后装扩展能力。

二、OpenClaw 2026.3.13 的搜索能力层次

1)原生可配置的 web search provider

在 OpenClaw 2026.3.13 版本中,配置向导当前原生支持以下搜索 provider:

  • Brave Search # 需要 API Key,有免费额度,但需要绑定信用卡
  • Gemini (Google Search) # 需要 API Key,依赖 Google 服务,国内需代理
  • Grok (xAI) # 需要 API Key,国内访问限制多,文档较少
  • Kimi (Moonshot) # 需要 API Key,中文理解优秀,国际内容覆盖可能较弱
  • Perplexity Search # 需要 API Key,国内需代理

OpenClaw 配置导向提示如下:

◆ Choose web search provider │ ● Brave Search (Structured results · country/language/time filters) │ ○ Gemini (Google Search) │ ○ Grok (xAI) │ ○ Kimi (Moonshot) │ ○ Perplexity Search 

这些属于:

  • OpenClaw 原生支持
  • 用户可在配置时直接选择
  • web_search 能力的默认后端候选

2)需要用户自行安装和配置的 skill

以下能力不是当前版本配置向导里原生可选的 web_search provider,而是需要用户自行安装:

  • Firecrawl
  • Tavily

它们属于:

  • 扩展 skill
  • 需要手动安装
  • 需要单独配置 API key 或依赖
  • 安装后可以补充搜索、抓取或 AI 优化检索能力

所以:

Brave / Gemini / Grok / Kimi / Perplexity 是原生 provider;
Firecrawl / Tavily 是额外安装的扩展 skill。

三、从使用者视角理解整体结构

OpenClaw 的统一能力接口

能力来源

原生 provider
Brave / Gemini / Grok / Kimi / Perplexity

扩展 skill
Tavily / Firecrawl

🔎 web_search
搜索关键词 / 找来源 / 找链接

📄 web_fetch
打开页面 / 抓取正文 / 读取细节


四、一句话理解关系

web_searchweb_fetch 是 OpenClaw / agent 提供给你的统一能力接口,像“遥控器”;
Brave、Gemini、Grok、Kimi、Perplexity 是 OpenClaw 原生支持的搜索 provider,像内置频道”;
Tavily、Firecrawl 是用户后装的扩展 skill,像“额外加装的频道模块”;
你配置了哪个 provider 或安装了哪个 skill,agent 就更可能通过对应能力去完成搜索或抓取。

五、web_search、原生 provider、扩展 skill、web_fetch 的关系

1)web_search 是能力层

web_search 说的是“网页搜索”这件事本身,不一定绑定某一个具体产品名。

它可以由以下两类来源来实现:

  • 原生 provider
  • 扩展 skill

2)原生 provider 是 OpenClaw 内建支持的后端

在 OpenClaw 2026.3.13 中,以下属于原生 provider:

  • Brave Search
  • Gemini
  • Grok
  • Kimi
  • Perplexity Search

这些更接近:

  • 安装时可直接选
  • 配置体验更原生
  • 默认就是 OpenClaw 官方接入的搜索后端

3)Tavily / Firecrawl 属于扩展 skill

它们不是当前版本配置向导里直接列出的原生 provider,而是:

  • 用户单独安装
  • 手动配置
  • 作为扩展能力接入 OpenClaw

所以:

  • tavily-search 不是当前版本原生 web_search provider 列表的一员
  • 但它依然可以提供高质量网页搜索能力
  • 在实际使用中,它可以充当 web_search 的一种补充实现

4)web_fetch 是网页读取能力

web_fetch 的职责通常是:

  • 打开具体 URL
  • 读取页面内容
  • 抓取正文
  • 提取细节

所以它不负责“找页面”,而负责“读页面”。


六、推荐的理解模型

模型 1:能力层

  • web_search:找来源
  • web_fetch:读来源

模型 2:实现层

  • 原生 provider:Brave / Gemini / Grok / Kimi / Perplexity
  • 扩展 skill:Tavily / Firecrawl

模型 3:具体环境中的最佳实践

假定当前额外安装了:

  • tavily-search
  • agent-reach

web_fetch 是当前 agent 已可用的 tool。

所以你当前更适合的工作流是:

  1. 先用 tavily-search 搜索
  2. 再用 web_fetch 阅读
  3. 必要时用 agent-reach 协调多步任务
如何安装 tavily-search:(TODO:有空补上安装实践记录) 如何安装 agent-reach` :Agent Reach 安装与 OpenClaw 网络搜索能力扩展指南

七、最推荐的使用分工

tavily-search 负责什么

适合:

  • 找最新资料
  • 找新闻
  • 找论文入口
  • 找官方文档入口
  • 找多个候选来源
  • 为后续精读做召回

web_fetch 负责什么

适合:

  • 已经有 URL
  • 已经知道要读哪个页面
  • 读取正文
  • 抓取细节
  • 提取发布日期、作者、版本号、参数说明
  • 核对页面中是否真的写了某句话

agent-reach 负责什么

适合:

  • 协调多步任务
  • 提高外部能力被调用的概率
  • 强化“先搜索、再阅读、再总结”的工作流
  • 降低模型直接凭已有知识回答的概率

八、标准工作流

工作流 A:你没有 URL

  1. tavily-search 搜索
  2. 获取候选来源
  3. 选择最相关来源
  4. web_fetch 读取

工作流 B:你已有 URL

  1. 直接用 web_fetch 读取

工作流 C:复杂多步任务

  1. agent-reach 协调任务
  2. 先搜索
  3. 再阅读
  4. 最后总结

适合:

  • 你还没有具体网址
  • 你要查“最新”“最近”“本周”“本月”
  • 你需要候选来源列表
  • 你要找新闻、论文、公告、文档入口
  • 你不确定先读哪个页面

典型任务:

  • 最近一周 AI 新闻
  • 某个框架最近更新了什么
  • 某个 API 的官方文档入口
  • 某个研究方向最近有哪些论文

十、什么时候优先用 web_fetch

适合:

  • 你已经有 URL
  • 你只想读某个页面
  • 你需要正文
  • 你需要页面细节
  • 你要提取参数、版本号、发布日期等信息

典型任务:

  • 阅读官方文档页面
  • 总结新闻正文
  • 提取博客文章要点
  • 查看 release note 里的变更项

十一、OpenClaw 中推荐的标准流程

没有

用户问题

是否已有明确 URL?

直接用 web_fetch

先用 web_search 能力搜索

在你当前环境里可由原生 provider 或 tavily-search 实现

得到候选来源 / 链接

再用 web_fetch 读取


十二、最常用的对话提示词模板

1)搜索后再读取

先使用 tavily-search 搜索这个主题,列出 5 个最相关来源;再使用 web_fetch 打开最相关的 1 个页面并总结。主题:multimodal RAG 最新论文 

2)只搜索,不精读

使用 tavily-search 搜索:最近一周关于 OpenAI 模型发布的新闻,只给我来源列表和一句话摘要。 

3)官方来源优先

使用 tavily-search 搜索 Kubernetes Ingress 官方文档,优先官方来源;再用 web_fetch 打开最相关页面并总结。 

4)搜索新闻

先用 tavily-search 搜索最近一周 AI agent 相关新闻,再给我按时间排序的摘要。 

5)搜索论文

先使用 tavily-search 搜索 multimodal RAG 相关论文,优先 arXiv 和官方论文页面,再使用 web_fetch 阅读最相关页面并总结。 

6)多步任务协同

这是一个多步任务。请通过 agent-reach 协调当前可用能力,不要直接凭已有知识回答。先使用 tavily-search 搜索高质量来源,再使用 web_fetch 阅读最相关页面,最后给出带来源的结论。主题:最近一个月关于 AI agent memory 的研究进展。 

十三、命令行直测速查

下面这些命令用于直接测试 tavily-search skill 本体。

基础搜索

# 作用:执行最基础的一次 Tavily 搜索。# 语法:node <脚本路径> "<查询词>"# 规则:# - 查询词建议放在双引号中# - 适合快速验证插件和 API key 是否生效node ~/.openclaw/skills/liang-tavily-search/scripts/search.mjs "python async patterns"

指定结果数量

# 作用:控制返回结果数。# 语法:node <脚本路径> "<查询词>" -n <数量># 规则:# - 常见范围 1 到 20# - 数量越多,召回越广,但噪声可能增加node ~/.openclaw/skills/liang-tavily-search/scripts/search.mjs "React hooks tutorial"-n10

指定搜索深度

# 作用:调整搜索深度,在速度和相关性之间取平衡。# 语法:node <脚本路径> "<查询词>" --depth <模式># 规则:# - 可选值:ultra-fast、fast、basic、advanced# - basic 最通用# - advanced 适合研究型任务node ~/.openclaw/skills/liang-tavily-search/scripts/search.mjs "machine learning evaluation benchmarks"--depth advanced 

搜索新闻

# 作用:把搜索主题切换为新闻类。# 语法:node <脚本路径> "<查询词>" --topic news# 规则:# - 适合最新事件、产品发布、政策变化# - 如果不是新闻类查询,建议用默认 generalnode ~/.openclaw/skills/liang-tavily-search/scripts/search.mjs "AI regulation Europe"--topic news 

限定时间范围

# 作用:限制搜索结果的时间范围。# 语法:node <脚本路径> "<查询词>" --time-range <范围># 规则:# - 可选值:day、week、month、year# - 适合“最近一周”“最近一个月”这类查询node ~/.openclaw/skills/liang-tavily-search/scripts/search.mjs "OpenAI API updates"--topic news --time-range week 

限定域名

# 作用:只保留指定域名结果。# 语法:node <脚本路径> "<查询词>" --include-domains <域名列表># 规则:# - 多个域名通常用逗号分隔# - 适合官方文档、论文站点、可信来源筛选node ~/.openclaw/skills/liang-tavily-search/scripts/search.mjs "Python asyncio gather" --include-domains docs.python.org 

排除域名

# 作用:排除某些不想要的域名。# 语法:node <脚本路径> "<查询词>" --exclude-domains <域名列表># 规则:# - 多个域名通常用逗号分隔# - 适合过滤低质量或无关站点node ~/.openclaw/skills/liang-tavily-search/scripts/search.mjs "LLM benchmarks" --exclude-domains pinterest.com,reddit.com 

输出 JSON

# 作用:输出原始 JSON,方便调试和脚本二次处理。# 语法:node <脚本路径> "<查询词>" --json# 规则:# - 适合程序消费# - 不适合纯人工阅读node ~/.openclaw/skills/liang-tavily-search/scripts/search.mjs "vector database comparison"--json

返回更完整内容

# 作用:尝试返回更完整的页面内容,而不只是摘要片段。# 语法:node <脚本路径> "<查询词>" --raw-content# 规则:# - 输出会更长# - 更适合研究和离线分析node ~/.openclaw/skills/liang-tavily-search/scripts/search.mjs "multimodal RAG survey" --raw-content 

多参数组合

# 作用:组合数量、主题、时间范围、域名过滤等参数。# 语法:# node <脚本路径> "<查询词>" -n <数量> --topic <主题> --time-range <范围> --include-domains <域名列表># 规则:# - 参数越明确,结果通常越稳定# - 适合研究型和高价值查询node ~/.openclaw/skills/liang-tavily-search/scripts/search.mjs "multimodal RAG papers"-n8--topic general --time-range year --include-domains arxiv.org,acm.org 

十四、在对话中怎么更稳定触发正确流程

推荐写法 1:明确步骤

先使用 tavily-search 搜索高质量来源,再使用 web_fetch 阅读最相关页面,最后总结。 

推荐写法 2:强调不要直接回答

不要直接凭已有知识回答。先使用 tavily-search 搜索,再使用 web_fetch 阅读来源,然后给出结论。 

推荐写法 3:强调这是最新信息

这是一个需要最新信息的问题。请先使用 tavily-search 搜索最近一周相关资料,再使用 web_fetch 阅读最相关页面。 

推荐写法 4:强调官方来源

先使用 tavily-search 搜索,优先官方来源;再使用 web_fetch 打开最相关页面并提取关键信息。 

推荐写法 5:加入 agent-reach 强化多步协同

请通过 agent-reach 协调当前可用能力,不要直接回答。先使用 tavily-search 搜索高质量来源,再使用 web_fetch 阅读关键页面,最后输出带来源的总结。 

十五、常见误区

误区 1:把 web_search 当成固定插件名

web_search 往往是“网页搜索能力”的泛称,不一定是某个具体 skill 名。

误区 2:把原生 provider 和扩展 skill 混为一谈

  • Brave / Gemini / Grok / Kimi / Perplexity 是 OpenClaw 原生 provider
  • Tavily / Firecrawl 是用户自行安装的扩展 skill

误区 3:把 web_fetch 当成搜索工具

web_fetch 一般负责“打开页面”,不是“找页面”。

误区 4:以为装了 tavily-search 就不需要 web_fetch

tavily-search 更适合召回来源,web_fetch 更适合精读页面。两者配合效果最好。

误区 5:以为 provider、skill、tool 是同一层

  • provider:底层服务来源
  • skill:扩展能力封装方式
  • tool / interface:agent 暴露给你的能力入口

误区 6:以为 agent-reach 是搜索工具

agent-reach 更适合作为多步任务协调层,而不是单独的搜索引擎替代品。


十六、推荐默认策略

如果没有 URL

先用 tavily-search

如果有 URL

直接用 web_fetch

如果问题涉及最新信息

先用 tavily-search,必要时限定时间范围

如果需要精读

tavily-search,后 web_fetch

如果需要官方来源

先用 tavily-search 找官方页面,再用 web_fetch

如果任务是多步研究

加入 agent-reach 协调“搜索 → 阅读 → 总结”


十七、排障速查

情况 1:脚本报 TAVILY_API_KEY not set

说明当前 shell 没拿到环境变量。

# 作用:检查当前 shell 是否已经有 TAVILY_API_KEY。# 语法:echo "$TAVILY_API_KEY"# 规则:# - 有输出表示变量已生效# - 空输出表示变量未生效echo"$TAVILY_API_KEY"

情况 2:tavily-search 已安装,但对话里没触发

通常不是安装失败,而是提示词不够明确。

建议直接这样写:

不要直接回答。先使用 tavily-search 搜索,再使用 web_fetch 阅读来源,最后给出结论。 

情况 3:旧会话行为异常

新开一个会话再试,避免旧上下文干扰工具选择。

情况 4:想确认 skill 本体是否可用

# 作用:绕过会话层,直接测试 tavily-search skill 脚本本体。# 语法:node <脚本路径> "<查询词>"# 规则:# - 这是最稳的插件可用性验证方法node ~/.openclaw/skills/liang-tavily-search/scripts/search.mjs "latest papers on multimodal RAG"

情况 5:复杂任务总是只用一个工具

尝试在提示词中显式加入:

这是一个多步任务。请通过 agent-reach 协调当前可用能力,先搜索,再阅读,最后总结。 

十八、术语表

web_search

网页搜索能力的抽象接口,重点是“找来源”。

web_fetch

网页读取能力接口,重点是“读页面”。

provider

底层搜索/能力提供方,例如:

  • Brave
  • Gemini
  • Grok
  • Kimi
  • Perplexity

skill

额外安装的扩展能力封装,例如:

  • Tavily
  • Firecrawl
  • agent-reach

基于 Tavily 的扩展搜索 skill,可用于补充或增强 web_search 能力。

agent-reach

用于协调多步任务、强化外部能力调用的 skill,不是传统搜索引擎替代品。


十九、一句话总结

  • ​**web_search**​:搜索能力的抽象接口
  • 原生 provider​:Brave / Gemini / Grok / Kimi / Perplexity
  • 扩展 skill​:Tavily / Firecrawl / agent-reach
  • ​**web_fetch**​:网页读取与抓取能力

最佳实践是:

先用搜索能力找来源(你当前常用 tavily-search),再用 web_fetch 读来源;复杂任务再用 agent-reach 协调。

Read more

前端环境配置(nvm、nodejs、npm)

前端环境配置(nvm、nodejs、npm)

一、安装nvm 1. 下载vnm url: https://nvm.uihtm.com/doc/download-nvm.html 2. 解压文件后双击exe文件进行安装 3. 选择nvm的安装地址,我是安装在D:\App\nvm 4. 选择nodejs的安装地址,我是安装在C:\Program Files\nodejs 5. 点击next 一直点击 完成安装; 6. 找到nvm的settings.txt文件打开后: 给该文件添加这两行命令: node_mirror: https://npmmirror.com/mirrors/node/ npm_mirror: https://npmmirror.com/mirrors/npm/ 二、环境变量配置 1.

【DeepSeek R1部署至RK3588】RKLLM转换→板端部署→局域网web浏览

【DeepSeek R1部署至RK3588】RKLLM转换→板端部署→局域网web浏览

本文为DeepSeek R1 7B 以qwen为底座的LLM在瑞芯微RK3588 SoC上的完整部署流程,记录从开发板驱动适配烧录开始,到最终的开发板终端访问模型和局域网web访问模型的完整流程,有不足之处希望大家共同讨论。 文章目录 * 一、项目背景介绍 * 二、所需工具介绍 * 1.硬件工具 * 1.X86 PC虚拟机Ubuntu20.04 * 2. 准备NPU驱动为0.9.8的RK3588开发板 * 2.软件工具 * 三、获取.safetensors模型权重 * 四、safetensors转RKLLM * 1.转换环境搭建 * 2.模型转换 * 五、RKLLM模型板端部署及推理 * 六、集成开源gradio工具实现web访问 一、项目背景介绍 先来介绍下项目背景吧,目前有一个空闲的firefly出厂的搭载瑞芯微RK3588 SoC的arm64开发板,样式如图所示: 博主之前主要进行CV领域的模型的RK开发板部署,对于LLM和VLM的接触并不算多,但现在大模型是趋势所向,并且瑞芯微及时的完成了针对各开源

想做多语言项目?试试Hunyuan-MT-7B-WEBUI快速部署方案

想做多语言项目?试试Hunyuan-MT-7B-WEBUI快速部署方案 你有没有遇到过这样的情况:手头有个跨境项目,要同时处理日语产品说明、西班牙语用户反馈、维吾尔语政策文件,甚至还有藏文古籍数字化需求——可翻来翻去,不是翻译质量差强人意,就是部署起来像在解一道高数题?在线工具不敢传敏感数据,本地跑模型又卡在CUDA版本、依赖冲突、显存爆炸上……最后只能靠人工硬啃,进度一拖再拖。 Hunyuan-MT-7B-WEBUI 就是为这种真实困境而生的。它不讲大道理,不堆参数,不做“实验室里的冠军”,而是把腾讯混元团队打磨出的最强开源翻译模型,连同网页界面、一键脚本、预装环境,全打包进一个镜像里。你不需要懂Transformer结构,不用查PyTorch兼容表,甚至不用打开终端敲命令——点一下,等两分钟,就能在浏览器里开始翻译38种语言。 这不是又一个“需要调参、需要写代码、需要配环境”的AI工具。这是你今天下午就能用上的多语言工作台。 1. 为什么这款翻译镜像值得你立刻试试? 1.1 它真能覆盖你没想过的语言 很多翻译模型标榜“支持多语言”,但实际打开列表一看:英、法、

前端实现Word文档在线编辑与导出:基于mammoth.js与Blob对象的完整解决方案

如何在浏览器中直接编辑Word文档并导出?本文将深入探索一种基于mammoth.js和Blob对象的完整技术方案。 在当今的Web应用开发中,实现文档的在线编辑与导出已成为常见需求。无论是企业内部系统、教育平台还是项目管理工具,都迫切需要让用户能够在浏览器中直接编辑Word文档,而无需安装桌面软件。本文将详细介绍如何利用mammoth.js和Blob对象实现这一功能,并对比其他可行方案。 一、为什么选择mammoth.js与Blob方案? 在Web前端实现Word文档处理,主要有三种主流方案:浏览器原生Blob导出、mammoth.js专业转换和基于模板的docxtemplater方案。它们各有优劣,适用于不同场景。 mammoth.js的核心优势在于它能将.docx文档转换为语义化的HTML,而非简单复制视觉样式。这意味着它生成的HTML结构清晰、易于维护和样式定制。配合Blob对象,我们可以轻松将编辑后的内容重新导出为Word文档。 与直接使用Microsoft Office Online或Google Docs嵌入相比,mammoth.js方案不依赖外部服务,能更好地