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

Web Components跨框架组件库探索

1. 前言 在网约车业务早期阶段,产品需求迭代迅速,为了支持快速试错与灵活交付, 内部形成了多种技术栈并存的局面:历史项目基于 Vue2,新业务则转向 React。同时,由于早期各项目独立推进,尚未形成统一的设计规范和组件标准,不同项目在组件实现方式、样式规范与交互体验上存在较大差异。 这种多样化在短期内带来了灵活性,使团队能够快速响应业务需求,但随着项目规模和业务复杂度的增加,也逐渐演变成了技术挑战: * 组件复用困难:相同功能组件需要在不同框架中重复实现。 * 维护成本增加:功能或样式的调整须在多套组件库中分别修改。 * 用户体验不一致:不同框架实现可能导致交互和视觉风格不统一。 为解决这些问题,我们移动端前端团队今年开始探索一种能够“一次开发,多处复用”的组件库方案。 2. 目标与场景 2.1. 核心目标 为了解决团队多框架并存、组件重复开发和体验不一致的痛点,我们确定了三大核心目标: * 统一设计规范:建立标准化设计体系和组件规范,确保视觉风格与交互行为在各业务线、各技术栈中保持一致。 * 跨框架复用:构建框架无关的组件实现层,使同一组件可在 Vue

WebUI界面响应慢?优化前端缓存策略,加载速度提升50%

WebUI界面响应慢?优化前端缓存策略,加载速度提升50% 📌 问题背景:语音合成服务的用户体验瓶颈 在部署基于 ModelScope Sambert-Hifigan 的中文多情感语音合成服务后,尽管模型推理质量高、环境稳定,但在实际使用中发现:当用户频繁输入相似或重复文本时,WebUI界面仍会重新发起请求、等待后端合成音频,导致响应延迟明显,尤其在长文本场景下体验较差。 虽然项目本身已对依赖项(如 datasets==2.13.0、numpy==1.23.5、scipy<1.13)进行了深度兼容性修复,并通过 Flask 提供了稳定的 API 与 WebUI 双模式服务,但前端缺乏有效的缓存机制,使得相同内容的语音请求被反复处理,浪费计算资源且拖慢整体响应速度。 本文将围绕该语音合成系统的 WebUI 层面,提出一套轻量级前端缓存优化方案,实现相同文本请求的毫秒级响应,实测页面加载与播放延迟降低 50%以上。

Java Web 拦截机制实战指南:Filter 与 Interceptor 深度解析

一、理解核心概念 在 Java Web 开发中,过滤器(Filter)和拦截器(Interceptor)是两种核心的请求处理机制。它们虽然都能对请求进行拦截和处理,但定位截然不同: * Filter 是 Servlet 容器的"守门人",位于应用最外层 * Interceptor 是 Spring MVC 的"执法官",位于框架内部 二、Filter:Servlet 容器的第一道防线 2.1 本质与特点 Filter 是 Java Servlet 规范 定义的组件,由 Servlet 容器(如 Tomcat)直接管理,不依赖任何框架,

openclaw喂饭教程!在 Linux 环境下快速完成安装、初始化与 Web UI 配置

openclaw喂饭教程!在 Linux 环境下快速完成安装、初始化与 Web UI 配置

前言 OpenClaw 是一款开源的 AI Agent 工具,但对第一次接触的用户来说,完整跑通流程并不直观。本文以 Linux 环境为例,详细记录了 OpenClaw 的安装、初始化流程、模型选择、TUI 使用方式,以及 TUI 与 Web UI 认证不一致导致的常见问题与解决方法,帮助你最快速度把 OpenClaw 真正跑起来 环境准备 1)安装nodejs curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash - sudo apt install -y nodejs > node