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

GitHub Copilot AI 编程超全使用教程,从入门到精通

GitHub Copilot AI 编程超全使用教程,从入门到精通

前言 作为 GitHub 推出的 AI 编程助手,GitHub Copilot 凭借强大的代码补全、自然语言交互、自动化开发等能力,成为了开发者提升编码效率的 “神器”。它能支持主流 IDE(VS Code、IntelliJ IDEA、Eclipse 等)、终端等多环境,还可自定义配置、切换 AI 模型,适配个人和团队的不同开发需求。本文结合 GitHub 官方文档和实际使用经验,用通俗易懂的方式讲解 Copilot 的完整使用方法,从环境搭建到高级技巧,再到故障排除,一站式搞定 Copilot AI 编程! 一、GitHub Copilot 核心能力一览 在开始使用前,先快速了解 Copilot 的核心功能,清楚它能帮我们解决哪些开发问题: 1. 智能代码补全:

【实践】操作系统智能助手OS Copilot新功能测评

【实践】操作系统智能助手OS Copilot新功能测评

一、引言         数字化加速发展,尤其人工智能的发展速度越来越快。操作系统智能助手成为提升用户体验与操作效率的关键因素。OS Copilot借助语言模型,人工智能等,对操作系统的自然语言交互操作 推出很多功能,值得开发,尤其运维,系统操作等比较适用,优化用户与操作系统的交互模式。本次测评,按照测评指南进行相关测评,得出下面的测评报告。 二、OS Copilot简介         OS Copilot 是一款致力于深度融合于操作系统的智能助手,它旨在成为用户与操作系统交互的得力伙伴 。通过先进的自然语言处理技术和机器学习算法,OS Copilot 能够理解用户多样化的指令,将复杂的操作系统操作简单化。         在日常使用场景中,无论是文件管理、应用程序的操作,还是系统设置的调整,OS Copilot 都能提供高效的支持。例如,在文件管理方面,用户无需手动在层层文件夹中查找文件,只需通过描述文件的大致信息,如创建时间、文件内容关键词等,就能快速定位到目标文件。         对于应用程序,它不仅能根据用户的使用习惯智能启动,还能在应用程序运行时进行优化,确保

PyTorch实战——基于文本引导的图像生成技术与Stable Diffusion实践

PyTorch实战——基于文本引导的图像生成技术与Stable Diffusion实践

PyTorch实战——基于文本引导的图像生成技术与Stable Diffusion实践 * 0. 前言 * 1. 基于扩散模型的文本生成图像 * 2. 将文本输入编码为嵌入向量 * 3. 条件 UNet 模型中的文本数据融合机制 * 4. 使用 Stable Diffusion 模型生成图像 * 相关链接 0. 前言 在本节中,我们将为扩散模型添加文本控制能力。学习如何通过文字描述来引导图像生成过程,实现从"纯噪声+文本"生成图像,而不仅是从纯噪声生成。 1. 基于扩散模型的文本生成图像 在扩散模型的 UNet 模型训练流程中,我们仅训练模型从含噪图像中预测噪声。为实现文生图功能,需使用以下架构,将文本作为额外输入注入 UNet 模型: 这样的 UNet 模型称为条件 UNet 模型 ,或者更精确地说,是文本条件 UNet

百考通AIGC检测:精准识别AI生成内容,守护学术与创作诚信

在人工智能技术迅猛发展的今天,AI写作工具已成为学术研究、内容创作的常用辅助手段。然而,当高校明确要求"论文不得使用AI生成内容",当期刊对投稿稿件进行严格的AIGC(AI生成内容)检测,当企业招聘中"原创能力"成为核心评估指标,如何确保内容的原创性,避免因AI痕迹引发的学术不端或职业风险,已成为无数研究者与创作者的共同焦虑。百考通AIGC检测服务,以"精准识别AI生成内容,守护学术与创作诚信"为使命,为用户提供专业、可靠的AI内容识别解决方案,让每一份产出都经得起权威检测的考验。 精准检测:技术赋能学术诚信 百考通AIGC检测系统采用多维度分析模型,能够深度识别文本中的AI生成特征。不同于简单的关键词匹配,系统通过语义结构分析、语言模式识别、逻辑连贯性评估等技术手段,精准区分人类写作与AI生成内容。例如,当系统检测到文本中存在"过度流畅的句式结构"、"缺乏个性化表达"、"逻辑跳跃但表面连贯"等典型AI特征时,