不花一分钱，18 个搜索引擎同时帮你干活：wigolo 是怎么做到的？ - 蝈蝈俊
内容提要
wigolo 是一个本地优先的开源搜索聚合器，无需商业 API 密钥和费用。它并行调用 18 个公共搜索引擎，在本地用 RRF 算法融合结果，并通过本地 ML 模型重排序，兼顾语义、域名质量与时效性。搜索全程在用户机器完成，隐私不外泄。LLM 合成答案属可选功能。适合个人开发者、隐私敏感用户及 RAG 应用开发者，但稳定性与速度不及商业 API。
延伸解读
“零密钥”并非全部引擎免费
文章强调 wigolo 无需商业 API 密钥，但实际通用搜索中 Brave 需要配置 BRAVE_API_KEY 才会启用，属于条件加载。因此严格意义上的零密钥通用引擎只有 5 个，Brave 是可选增强。读者在评估“完全免费”时，需注意这一区别，避免误以为所有 18 个引擎都无需任何配置即可使用。
本地融合与重排序如何提升结果质量
wigolo 用 RRF 算法将 18 个引擎的结果合并，再通过本地 ML 模型综合语义相关性、域名质量、时效性以及多引擎共同推荐等因素重新打分。这种设计不依赖云端付费服务，既保护隐私，又能利用多源信号筛选出更可靠的条目。对于需要高质量搜索结果的 RAG 应用，这种本地重排序机制是核心价值之一。
搜索与抓取的分层设计
搜索请求使用轻量 HTTP 适配器并行发出，保证毫秒级响应；而抓取工具 fetch 则采用分层升级：先尝试普通 HTTP，遇到 SPA 壳或反爬挑战才启用无头浏览器。这种隔离避免了搜索时启动浏览器带来的高开销，同时保留了抓取 JS 渲染页面的能力。读者可据此理解 wigolo 在速度与功能之间的权衡。
适用场景与稳定性权衡
wigolo 适合个人开发者、隐私敏感用户、RAG 应用开发者和需要跨学术源检索的研究者。但由于依赖公共引擎的公开端点，其稳定性和速度不如商业 API。文章指出，对于大多数非关键场景，这一 trade-off 是值得的。读者在采用前应评估自身对搜索可靠性和响应速度的要求，必要时保留商业 API 作为备选。
Q&A
wigolo 是什么？它主要解决什么问题？
wigolo 是一个本地优先的开源搜索聚合器，它不需要商业 API 密钥和费用，直接在本地并行调用 18 个公共搜索引擎，用 RRF 算法融合结果，并通过本地 ML 模型重排序。它主要解决 AI Agent 和 RAG 应用中搜索能力太贵、隐私泄露的问题。
wigolo 的搜索流程是怎样的？
流程包括：1) 并行查询 18 个引擎；2) 本地用 RRF 算法融合结果；3) 设备端 ML 模型重排序，考虑语义相关性、域名质量、时效性等；4) 对靠前结果抓取页面内容提取证据片段；5) 所有搜索和抓取页面存入本地知识库，支持离线零延迟返回。第 2 到 5 步全部在本地完成。
wigolo 真的完全不需要 API 密钥吗？
wigolo 的 search 工具本身完全不需要密钥，但 Brave 引擎需要可选的 BRAVE_API_KEY，不配置时不会启用。因此严格来说，零密钥模式下实际可用的通用引擎是 5 个。另外，LLM 合成答案、research 和 agent 工具需要配置免费的 LLM API Key，但这是可选增强项。
wigolo 支持哪些类型的搜索引擎？
wigolo 的 18 个引擎覆盖五个垂直领域：通用搜索（Bing、DuckDuckGo、Brave、Mojeek、Marginalia）、代码（GitHub、Stack Overflow）、文档（MDN、DevDocs、Crates.io）、新闻（Bing News）、学术论文（arXiv、Semantic Scholar）和图像（Bing Images、DuckDuckGo Images）。此外还支持 RSS Feed 和可选的 SearXNG。
wigolo 适合哪些人使用？
wigolo 适合个人开发者（想给 AI Agent 加搜索但不想付费）、隐私敏感用户（不希望查询内容发给商业 API）、RAG 应用开发者（需要低成本可本地部署的搜索层）以及研究者（需要跨 arXiv、Semantic Scholar 等学术源检索）。
wigolo 有什么局限性？
由于依赖公共引擎的公开端点，wigolo 的稳定性和速度不如商业 API。但对于大多数非关键场景，这个 trade-off 是值得的。
wigolo 如何处理反爬和速率限制？
wigolo 对 HTML 爬取类引擎使用 User-Agent 轮转来反爬；对 Marginalia 有 429 熔断机制，其他引擎有重试和最小间隔控制；日期过滤方面，Stack Overflow、arXiv、Semantic Scholar 原生支持，其他引擎靠后处理；域名过滤部分引擎支持 site: 运算符，其余靠后处理。
