[RFC] 091 - 联网搜索支持深度爬取

[arvinxx]

背景

自 #6447 上线以来，大家对于搜索功能提出了诸多新的期待，本 RFC 将实现其中一个提到次数极多的需求：网页内容抓取。

早在两年前，我就做了 LobeChat 当时的第 3 个插件：网页爬虫。这个插件虽然我们很少宣传，其貌不扬，但是在我长达近 2 年的日用过程中保持了非常好的稳定性与使用体验，因此本 RFC 将会把该插件的核心实现思路预置进应用本体中，通过进一步的优化来提升抓取成功率和抓取性能。

爬虫插件的核心思路很简单，就 2 步：

1. 获取网页 html
2. 将 html 转成 Markdown

但中间其实有一些开发的门槛。

获取网页 html

比如获取网页 html 这个事情虽然听起来很简单，但是目前市面上存在的网页很多是 SPA 的，都没法正常获取到 html 内容。以及有些网站是用了 Cloudflare 做了反爬保护，因此工程实现上难度还是有的。

而我当年的实现思路非常简单粗暴，通过服务端起一个 puppeteer 实例仿真一个浏览器环境，这样所有的 SPA 都能正常读取到，能解决 90% 以上的问题（Cloudflare墙的问题就忽略了，这个应该无解）。而服务端 puppeteer 实例有非常专业的解决方案就是 browserless 。当年做完那个插件以后在我的 2c8g 机器上启动了 browserless 镜像，到现在都没出现过任何问题，很稳定地供整个 LobeChat 社区免费使用到现在

但这个方案存在的问题就是整个请求速度会较慢，因为走 puppeteer 启动页面可能就要1 ~ 2秒，然后等页面资源完全加载完毕（确保 spa 下页面能完全显示出来）也有 1 ~ 10 秒不等，因此本次实现会做一轮优化升级。补充一个性能更加的 naive 获取方案。

html 转 markdown

这里用的库是 Readability, 可以智能地识别到页面中的关键元素，尽量减少干扰的 html 元素。然后利用 node-html-markdown 库就可以轻松完成 html 到 markdown 的解析转换。

但在过去的使用中我发现这个方案也存在一些问题，比如某些网站 Readability 可能无法正常识别准（ 比较典型的是 github 的代码文件页面），需要中间做一些工程转换。

社区优秀读取器方案集成

此外，还有需要搞的一个事情是例如 jina 提供了 https://r.jina.ai/ 这样开箱即用的免费读取器，我也希望在 LobeChat 中有效利用起来。

设计思路

综合上述要点，本 RFC 的设计思路关键包含以下部分：

multi crawl impl 模式

通过实现不同的 crawl impl (Implement)，来集不同抓取实现的优势，目前准备实现的模式有：

• naive: 最朴素的请求 html 解析模式，速度最快，针对 SSR 类型的页面有不错的支持，但 SPA 解析就为空了；
• browserless: 基于 browserless 的网页解析模式，速度相对较慢，但是针对 SPA 类解析效果比较理想，可以自部署 browserless 实例或直接使用他们的云服务；
• jina: Jina 推出的免费网页读取器 (https://jina.ai/reader) ，不带 api key 时有 一分钟 20 次请求限制，如果带上 api key 则能到 200 rpm ，更多 rpm 诉求的话也可以氪金支持 Jina；

然后通过定义 crawl 的调度顺序，即可顺序式地进行页面抓取。本次实现的抓取顺序为 ['naive','jina','browserless'] ，未来也会允许用户进行自定义配置。

如果社区中更多更好的 craw 实现也欢迎提出和贡献。

URL 转换规则

针对类似 github 文件页面的场景，比较合适的是提供一种 url 转换的功能，例如原始链接为 https://github.com/lobehub/chat-plugin-web-crawler/blob/main/api/v1/_utils.ts ，通过访问 https://github.com/lobehub/chat-plugin-web-crawler/raw/refs/heads/main/api/v1/_utils.ts 即可看到源代码。因此内置一些网站的转换解析规则，即可大大提升这类页面的解析效果。

https://github.com/$org/$repo/blob/$branch -> https://github.com/$org/$repo/raw/refs/heads/$branch

此类规则比较适合遇到后一起进行完善。

智能过滤开关

Readability 的实现其实是做了一层页面元素的智能过滤，但是某些场景下这个解析又会造成关键页面的内容丢失，例如 https://www.qiumiwu.com/standings/yingchao 这个页面的解析就有问题，如果回退到全 html 解析则正常。因此还是需要一个规则配置用于做开关控制。

实施进展

• ✨ feat: support web page crawl in the search #6582

[Sun-drenched]

话说触发深度爬取的策略是什么呢？搜索引擎得到的网页都会爬取吗

[arvinxx]

这个准备通过prompt提示来做，相当于会给 ai 挂两个工具，一个search，一个 crawl ，ai 自行判断需要 crawl 哪些页面。

比如说：

Case1: 用户直接发了一个链接，那么正常来说 ai 就会调用 crawl 来读这个网页内容。
Case2: 而用户问了一个问题，ai 做了一次搜索后没有从搜索的摘要中获得答案，但是觉得可能哪几个链接可能会包含相关的内容，然后就会再调用一次 crawl 去读这几个链接。

交互效果上会类似现在同时开启联网搜索 + 爬虫插件。但新版本里就不需要开爬虫插件了，同时也会优化爬取的性能和交互体验（目前爬虫插件每次都只能爬一个链接，也比较慢）。

[skymkmk]

赞！刚想到这一点准备提一个 feature request 就看见 RFC 了。

有一个建议，现在有两个预装插件，一个是 Artifacts 另一个是 Web Browsing。由于应用已经为网络搜索在快捷栏中设置了一级公民地位，是否考虑将 Web Browsing 这个插件在插件列表中隐藏掉？

[amDosion]

我最近也在研究puppeteer，利用它的CDP协议获取特定的XHR提取里面的内容，在利用CLP整理里面的类容，感觉还是不错的，我只是说一下自己的思路，
不过我对比了playwright，由于playwright支持手机指纹，有些内容获取会比pc快，😂

[arvinxx]

@skymkmk 这个应该是bug。你是不是把 dalle 隐藏了？判断逻辑没写对，导致隐藏了dalle 就显示出来了 Web Browsing

[skymkmk]

@skymkmk 这个应该是bug。你是不是把 dalle 隐藏了？判断逻辑没写对，导致隐藏了dalle 就显示出来了 Web Browsing

是的，可以修一下 XD

[arvinxx]

@skymkmk 已经修复了

[arvinxx]

这一层收集一些同类产品情况

[arvinxx]

Grok 应该不支持阅读 SPA ？也不支持读 github

[Sun-drenched]

豆包——AI编程充分支持读GitHub仓库，感觉可以借鉴

[arvinxx]

有点羡慕了，我也想要这个 🤡 看看未来能不能做吧

[arvinxx]

一个测试用例：

query: 给我分析下 follow 的 electron 自动更新是怎么做的.

调用了 20 轮工具，耗费 1.2 美金，调研结果如下：

---

根据我收集的信息，现在我可以为你分析 Follow 应用的 Electron 自动更新实现机制。

Follow 应用的 Electron 自动更新机制分析

Follow 是一个基于 Electron 的开源 RSS 阅读器应用，它实现了完善的自动更新机制。以下是其自动更新实现的详细分析：

1. 核心更新技术栈

Follow 应用使用了以下核心技术来实现自动更新：

• electron-updater：主要的自动更新库，提供了检查更新、下载更新和安装更新的功能
• electron-forge：用于构建和发布应用
• 自定义 GitHub Provider：定制了 GitHub 更新源的实现

2. 更新架构设计

Follow 应用的更新系统设计了两种更新方式：

1. 完整应用更新：更新整个 Electron 应用，包括主进程和渲染进程
2. 渲染层热更新：只更新渲染层（Web 部分）代码，不需要重新安装应用

这种设计使得轻量级的 UI 和功能更新可以通过热更新快速部署，而涉及到底层变更的更新则通过完整应用更新进行。

3. 更新检测和下载流程

3.1 更新初始化

在主进程文件 index.ts 中，应用启动时调用 registerUpdater() 函数初始化更新系统：

app.whenReady().then(async () => {
  // ...其他初始化代码
  registerUpdater()
  // ...
})

3.2 更新配置

在 updater/configs.ts 中定义了更新的基本配置：

export const appUpdaterConfig = {
  // 是否启用渲染层热更新
  enableRenderHotUpdate: !isDev,
  // 是否启用应用更新
  enableAppUpdate: !isDev,

  app: {
    autoCheckUpdate: true,
    autoDownloadUpdate: true,
    checkUpdateInterval: 15 * 60 * 1000, // 15分钟检查一次更新
  },
}

3.3 更新器注册

在 updater/index.ts 中的 registerUpdater 函数中：

1. 根据平台选择合适的更新器（Windows 使用自定义的 WindowsUpdater）
2. 配置更新源信息（GitHub）
3. 注册更新事件监听器
4. 设置定期检查更新的计时器

export const registerUpdater = async () => {
  if (disabled) {
    return
  }

  // 禁用自动下载，通过事件控制
  autoUpdater.autoDownload = false
  autoUpdater.allowPrerelease = channel !== "stable"
  autoUpdater.autoInstallOnAppQuit = true
  autoUpdater.autoRunAppAfterInstall = true

  // 设置更新源
  const feedUrl = {
    channel,
    provider: "custom" as "github",
    repo: GITHUB_REPO,
    owner: GITHUB_OWNER,
    releaseType: channel === "stable" ? "release" : "prerelease",
    updateProvider: CustomGitHubProvider,
  }

  autoUpdater.setFeedURL(feedUrl)

  // 注册更新事件
  autoUpdater.on("checking-for-update", () => {
    logger.info("Checking for update")
  })
  
  autoUpdater.on("update-available", async (info) => {
    // 先尝试渲染层热更新
    if (appUpdaterConfig.enableRenderHotUpdate) {
      const isRenderUpgraded = await upgradeRenderIfNeeded()
      if (isRenderUpgraded) {
        return
      }
    }

    // 如果配置了自动下载，则下载更新
    if (appUpdaterConfig.app.autoDownloadUpdate) {
      downloadAppUpdate()
    }
  })
  
  // 其他事件处理...

  // 设置定期检查更新
  setInterval(() => {
    if (appUpdaterConfig.app.autoCheckUpdate) {
      checkForAppUpdates()
    }
  }, appUpdaterConfig.app.checkUpdateInterval)
}

4. 自定义 GitHub Provider

Follow 应用实现了自定义的 GitHub Provider (CustomGitHubProvider) 来处理从 GitHub 获取更新的逻辑。这个自定义 Provider 继承自 BaseGitHubProvider，主要增强了以下功能：

1. 支持不同发布渠道（stable、beta 等）
2. 根据语义化版本号选择合适的更新版本
3. 从 GitHub Releases 的 Atom feed 中解析更新信息

5. 渲染层热更新机制

在 updater/hot-updater.ts 中实现了渲染层的热更新功能：

1. 从 GitHub 获取最新的 manifest.yml 文件，包含渲染层的版本信息
2. 比较本地和远程的版本，决定是否需要更新
3. 如果需要更新，下载渲染层资源包并解压替换本地文件

热更新的判断逻辑：

export const canUpdateRender = async (): Promise<[CanUpdateRenderState, Manifest | null]> => {
  const manifest = await getLatestReleaseManifest()
  
  // 检查应用是否支持该版本的渲染层
  const appSupport = mainHash === manifest.mainHash
  if (!appSupport) {
    return [CanUpdateRenderState.APP_NOT_SUPPORT, null]
  }

  // 检查版本是否相同
  const isVersionEqual = appVersion === manifest.version
  if (isVersionEqual) {
    return [CanUpdateRenderState.NO_NEEDED, null]
  }

  // 检查提交是否相同
  const isCommitEqual = GIT_COMMIT_HASH === manifest.commit
  if (isCommitEqual) {
    return [CanUpdateRenderState.NO_NEEDED, null]
  }

  // 需要更新
  return [CanUpdateRenderState.NEEDED, manifest]
}

6. 版本更新策略

Follow 应用使用语义化版本号来控制更新策略：

1. 在 updater/utils.ts 中定义了 shouldUpdateApp 函数，通过比较版本号决定是进行完整应用更新还是渲染层热更新：
   • 主版本号或次版本号变更：进行完整应用更新
   • 补丁版本号变更：只进行渲染层热更新
   • 带有特定后缀（如 .app）的版本：强制进行完整应用更新

export const shouldUpdateApp = (currentVersion: string, nextVersion: string) => {
  if (nextVersion.includes("app")) {
    return true
  }
  // x.y.z 的 x 或 y 不同，需要更新应用
  const [x1, x2] = [safeMajor(currentVersion), safeMajor(nextVersion)]
  const [y1, y2] = [safeMinor(currentVersion), safeMinor(nextVersion)]
  
  if (x1 !== x2 || y1 !== y2) {
    return true
  }
  return false
}

7. 更新安装流程

当更新下载完成后，Follow 应用会通知用户并提供安装选项：

autoUpdater.on("update-downloaded", () => {
  downloading = false
  logger.info("Update downloaded, ready to install")

  const mainWindow = getMainWindow()
  if (!mainWindow) return
  const handlers = getRendererHandlers<RendererHandlers>(mainWindow.webContents)

  // 通知渲染进程更新已下载
  handlers.updateDownloaded.send()
})

用户确认后，调用 quitAndInstall 函数安装更新：

export const quitAndInstall = () => {
  const mainWindow = getMainWindow()

  destroyMainWindow()
  logger.info("Quit and install update, close main window, ", mainWindow?.id)

  setTimeout(() => {
    logger.info("Window is closed, quit and install update")
    autoUpdater.quitAndInstall()
  }, 1000)
}

8. 发布配置

Follow 应用使用 electron-forge 进行构建和发布，在 forge.config.cts 中配置了发布相关的选项，包括：

1. 针对不同平台的打包配置
2. 签名和公证配置（macOS）
3. 发布到 GitHub Releases 的配置

总结

Follow 应用的 Electron 自动更新机制具有以下特点：

1. 双层更新策略：通过完整应用更新和渲染层热更新相结合，提高更新效率
2. 自定义更新源：定制 GitHub Provider，支持不同发布渠道和版本选择
3. 智能版本判断：基于语义化版本号决定更新方式
4. 定期检查更新：定时自动检查更新，保持应用最新
5. 用户友好的更新体验：通知用户更新状态，提供安装选项

这种设计使得 Follow 应用能够灵活高效地进行更新，既保证了用户体验，又提高了开发和部署效率。

[1oca1h0st]

我看Dify对接的是https://www.firecrawl.dev/ ，也是自己部署社区版或用官方的实例。

[arvinxx]

jina 的都不用注册就可以用了，效果也还行。或者有时间的话可以对比下效果？

[AnotiaWang]

Firecrawl 自部署可以用 SearXNG 作为搜索引擎（最近刚支持的）。不过感觉目前官方对自部署的支持力度一般，文档写得比较基础，一些进阶的 use case 都没有说明

[1oca1h0st]

• 我试试jina
• Firecrawl我有自部署的版本，我试试更新下看看是否能与SearXNG联动..这个特性听起来好像很好

[Sun-drenched]

• 我试试jina
• Firecrawl我有自部署的版本，我试试更新下看看是否能与SearXNG联动..这个特性听起来好像很好

话说Firecrawl自部署资源占用得多吗？特别是爬取网页的时候

[1oca1h0st]

• 我试试jina
• Firecrawl我有自部署的版本，我试试更新下看看是否能与SearXNG联动..这个特性听起来好像很好

话说Firecrawl自部署资源占用得多吗？特别是爬取网页的时候

没有特别的注意哦...我用的Oracle的4c24g的arm，所以没关注..

[m0eak]

爬取完的markdown有没有办法能够一键迁移到知识库里啊

[arvinxx]

知识库 2.0 有计划做这个~

[sunqr97]

遇到一个问题，当前联网搜索+深度爬取似乎无法自动终止，我问了一个比较简单的问题，检索+爬取一直在生成了十几条，然后我手动停止了这个进程

[sunqr97]

[arvinxx]

试下关闭历史记录限制？

[Sun-drenched]

你是不是用的DeepSeek V3

[m0eak]

我的sonnet 3.7为什么是这样的，是不是也是上游的问题啊

[arvinxx]

是的，估计别的低端模型套壳了吧

[acotor]

目前有看到模型调用深入搜索 crawlSinglePage。
请问目前支持在 lobechat 中配置自建 browserless 和自己提供的 jina 服务吗？如何配置？

[arvinxx]

有环境变量，BROWSERLESS_URL 和 JINA_API_KEY

[ken0311]

目前深度爬取默认使用naive模式爬取，但是部分网站（微信公众号文章）虽然能够获取到内容，但内容不全（只有标题），但使用jina就可以获得完整的内容，是否能够让用户自定义爬取工具的顺序，优先（强制）使用jina

使用naive模式爬取的内容

使用jina reader 获得的内容

[arvinxx]

我加个微信公众号的规则吧。后续也可以一起共建这些规则：https://github.com/lobehub/lobe-chat/blob/main/packages/web-crawler/README.zh-CN.md#%E5%A6%82%E4%BD%95%E8%B4%A1%E7%8C%AE-url-%E8%A7%84%E5%88%99