导航

不花一分钱，18 个搜索引擎同时帮你干活：wigolo 是怎么做到的？

Posted on 2026-09-28 14:56  蝈蝈俊  阅读(20)  评论(0)    收藏  举报

没有 API Key，没有账单，没有隐私泄露。一个本地优先的搜索聚合器，正在重新定义 AI Agent 的搜索方式。

先说痛点

如果你用过 AI Agent 或者自己搭过 RAG 应用，大概率遇到过这个问题：搜索能力太贵了。

SerpAPI 按次收费，Bing Search API 要绑信用卡，Google Custom Search 每天限额 100 次。一旦 Agent 开始频繁搜索，账单就像脱缰的野马。更别提每次搜索请求都要把你的查询内容发给第三方 API，隐私也是个问题。

wigolo 的出现，给出了一条完全不同的路：不用任何商业搜索 API，直接在本地并行调用 18 个公共搜索引擎，在你自己机器上完成结果融合与重排序。

成本为零，密钥为零，隐私留在本地。

wigolo 到底做了什么？

一句话概括：它是一个本地优先的搜索聚合器，把 18 个公共搜索引擎的结果抓回来，用算法融合成一份更靠谱的列表，再交给你的 AI Agent 使用。

整个流程是这样的：

  1. 并行查询：你发起一个搜索请求，wigolo 同时向 18 个引擎发起请求

  2. 本地融合：用 RRF（倒数排名融合）算法把不同引擎的结果合并成一个统一列表

  3. 设备端重排：用一个本地运行的 ML 模型对结果重新打分，综合考虑语义相关性、域名质量、时效性、有多少引擎共同推荐等因素

  4. 内容增强：对排名靠前的结果抓取页面内容，提取可直接引用的证据片段

  5. 本地缓存：所有搜索和抓取过的页面存入本地知识库，下次遇到相似问题零延迟返回

关键在于，第 2 到第 5 步全部在你自己的机器上完成，不需要调用任何云端付费服务。

18 个引擎，都是谁？

这是大家最关心的部分。wigolo 的 18 个引擎分布在五个垂直领域，覆盖通用搜索、代码、文档、新闻、学术论文和图像。

通用搜索（6 个）

引擎 调用方式 密钥
Bing HTML 爬取 bing.com/search 无需
DuckDuckGo HTML 爬取 lite.duckduckgo.com/lite/ 无需
Wikipedia JSON API（OpenSearch） 无需
Brave JSON API api.search.brave.com ⚠️ 需 BRAVE_API_KEY，条件加载
Mojeek HTML 爬取 mojeek.com/search 无需，独立索引
Marginalia JSON API api2.marginalia-search.com 公开密钥 public，有速率限制

这里要特别说明一下 Brave：它确实需要 API Key，而且是条件加载——不配置 BRAVE_API_KEY 时不会启用。所以严格来说，wigolo 的“零密钥”模式实际可用的通用引擎是 5 个，Brave 属于可选增强。

Mojeek 和 Marginalia 是两个很有意思的补充。Mojeek 有自己独立的索引，不依赖 Google 或 Bing；Marginalia 专门索引小网络和长尾网站，能搜到很多主流引擎找不到的内容。

代码搜索（5 个）

引擎 调用方式 密钥
GitHub Code JSON API api.github.com/search/code 可选 WIGOLO_GITHUB_TOKEN
Stack Overflow JSON API StackExchange 2.3 无需
DevDocs 本地硬编码查表（22+ 库） 无需，零延迟
MDN JSON API developer.mozilla.org/api/v1/search 无需
Crates.io JSON API crates.io/api/v1/crates 无需

DevDocs 是个亮点：它根本不发起外部请求，而是本地维护了一张覆盖 22 个以上库的文档表（react、vue、typescript、python、go、rust、docker、git……），按别名匹配后直接生成 devdocs.io/{slug} 的 URL。零延迟，零爬取成本。

新闻搜索（1 个）

Bing News：通过 HTML 爬取 bing.com/search，带上 filters=tnews 和 form=YFNR 参数，解析新闻卡片。无需密钥。

学术论文（2 个）

引擎 调用方式 密钥
arXiv XML API（Atom Feed） 无需
Semantic Scholar JSON API api.semanticscholar.org/graph/v1 无需

这两个都原生支持日期过滤，对做文献综述特别有用。Semantic Scholar 还提供 AI 驱动的摘要和开放获取 PDF 链接。

图像搜索（2 个）

引擎 调用方式 密钥
DuckDuckGo Image 两阶段：HTML 抓 vqd token → JSON i.js 无需
Brave Image JSON API api.search.brave.com/res/v1/images ⚠️ 需 BRAVE_API_KEY

DuckDuckGo 的图像搜索走了一个两阶段流程：先从 HTML 页面提取 vqd token，再用这个 token 去请求 JSON 接口拿图像结果。虽然绕了一步，但完全免费。

本地与其他（2 个）

RSS Feed：查询本地 SQLite 数据库，用 FTS5 全文搜索索引，支持 BM25 排序和日期过滤。完全离线可用。

SearXNG：可选的外部自托管实例，属于遗留适配器，不是核心搜索路径的一部分。

为什么不需要 API Key？

这是 wigolo 最核心的设计选择。

第一，它直接适配公共引擎，不走聚合 API。

大部分引擎（Bing、DuckDuckGo、Mojeek、Stack Overflow、arXiv、MDN、Crates.io）都有公开的 HTML 页面或 JSON 接口，wigolo 直接请求这些端点并解析结果，完全绕过了 SerpAPI 这类商业聚合服务。没有聚合服务，自然就没有密钥和账单。

第二，核心计算全部在本地完成。

搜索结果的 RRF 融合、ML 重排序、语义嵌入，全部在你自己的机器上运行。不需要调用云端付费服务，也不需要把查询内容发给第三方。

第三，LLM 合成是可选增强项。

wigolo 的 search 工具本身完全不需要密钥。只有当你希望它用 LLM 来“合成”一个带引用的答案（format=answer），或者使用更高级的 research 和 agent 工具时，才需要配置一个免费的 LLM API Key。不配置的话，它返回原始的、结构化的证据资料，由你的 AI Agent 自行处理。

搜索会用无头浏览器吗？

不会。 这是很多人容易误解的地方。

wigolo 的搜索用的是轻量级的 HTTP 直接适配器，只向搜索引擎的公开端点发送请求并解析返回的数据。官方文档明确将其描述为 “direct engine adapters”，在默认的 searchBackend=core 模式下并行查询，完全不需要 Sidecar 进程或密钥。

无头浏览器是专门留给 fetch 抓取工具的，而且只在必要时才启用。fetch 采用分层升级路由：

  1. 先尝试普通 HTTP 请求，这是最快、最轻量的方式

  2. 如果检测到 SPA 壳或反爬挑战，才自动升级到无头浏览器进行 JavaScript 渲染

这样设计的原因很简单：搜索查询需要快速并行发出大量请求，轻量 HTTP 客户端可以在毫秒级完成；而启动无头浏览器会带来数百毫秒到数秒的开销，还会消耗大量内存和 CPU。把浏览器能力按需隔离到 fetch 工具中，既保证了抓取 JS 渲染页面的能力，又让搜索保持极致的轻量和快速。

反爬、限流、日期过滤怎么处理？

这些工程细节，wigolo 也有对应的方案：

  • 反爬：对 HTML 爬取类引擎（Bing、DDG、Mojeek）使用 User-Agent 轮转

  • 速率限制：Marginalia 有 429 熔断机制，其他引擎有重试和最小间隔控制

  • 日期过滤：Stack Overflow、arXiv、Semantic Scholar 原生支持；其他引擎靠后处理

  • 域名过滤：部分引擎支持 site: 运算符，其余靠后处理过滤

  • 缓存：RSS 和语义向量本地缓存，支持离线查询

所有引擎统一返回标准化的 RawSearchResult 格式，包含标题、URL、摘要、相关性分数、来源引擎、发布日期和证据分数。

// 所有引擎共享的参数基础
interface SearchEngineOptions {
  maxResults?: number;        // 结果数量 (默认: 10)
  timeoutMs?: number;         // 超时 (默认: 10000ms)
  timeRange?: string;         // 时间范围
  language?: string;          // 语言代码 (en, de 等)
  country?: string;           // ISO 3166-1 alpha-2 国家代码
  includeDomains?: string[];  // 限制域名范围
  excludeDomains?: string[];  // 排除域名
  fromDate?: string;          // ISO 8601 日期字符串
  toDate?: string;            // ISO 8601 日期字符串
  category?: 'general' | 'news' | 'code' | 'docs' | 'papers' | 'images';
}

// 输出标准化格式
interface RawSearchResult {
  title: string;
  url: string;
  snippet: string;
  relevance_score: number;    // 0-1
  engine: string;
  published_date?: string;    // ISO 8601
  evidence_score?: EvidenceScore;
}

谁适合用 wigolo？

如果你是以下几类人，wigolo 值得一试：

  • 个人开发者：想给自己的 AI Agent 加上搜索能力，但不想为 API 付费

  • 隐私敏感用户：不希望每次搜索都把查询内容发给商业 API

  • RAG 应用开发者：需要一个低成本、可本地部署的搜索层

  • 研究者：需要跨 arXiv、Semantic Scholar 等学术源做文献检索

唯一需要注意的是：由于依赖公共引擎的公开端点，稳定性和速度不如商业 API。但对于大多数非关键场景，这个 trade-off 是完全值得的。

怎么开始？

wigolo 是一个开源项目，GitHub 地址是 github.com/KnockOutEZ/wigolo。配置好之后，可以运行 npx wigolo doctor 查看当前环境中实际启用的引擎列表和状态。

不花一分钱，18 个引擎同时帮你干活。这件事本身，就足够让人心动了。