开源项目第163期：wigolo — 零 API Key、零费用的本地优先 Agent 网络搜索工具，对比 Tavily/Exa/Firecrawl

引言

“The go-to web for your AI coding agent — local-first search, fetch, crawl & research over MCP. No API keys, no cloud, $0/query.”

这是「每日一个开源项目」系列的第 163 篇。今天的项目是wigolo—— 一个专为 AI agent 设计的本地优先 Web 情报工具，通过 MCP 提供搜索、抓取、爬取、研究等能力，零 API Key，零查询费用。

给 AI agent 配「搜索工具」是一个看似简单实则分层很深的问题。Tavily、Exa、Firecrawl 这些云端服务已经很成熟，但它们都有一个共同特征：按查询计费、数据出境、需要注册账号。wigolo 的切入点是：搜索引擎的 raw data 是公开的，排序和提取的算法是可以本地跑的，为什么 agent 的每一次搜索都要付费、都要走云端？

1,218 颗 Star，创建于 2026 年 4 月，公开测试阶段。

你会学到什么

• wigolo 的 10 个工具及其设计逻辑
• 「字节级来源定位」和「可解释评分」是什么，为什么重要
• 本地优先架构：哪些组件本地跑，哪些需要选择性接入云端
• 与 Tavily、Exa、Firecrawl 的横向对比：各自的差异化定位
• 什么场景适合用 wigolo，什么场景云端工具更合适

前提知识

• 使用过 Claude Code 或任意 AI agent
• 了解 MCP（Model Context Protocol）的基本概念
• 对 AI agent 的工具调用机制有基本认知

项目背景

概述

wigolo 是一个 Node.js 进程，以 MCP server 形式暴露 10 个 Web 相关工具，让 AI agent 通过标准 MCP 协议调用搜索、抓取、爬取、提取等功能。

核心设计原则：

• 本地优先：缓存、向量索引、嵌入模型、重排序模型都跑在本地（~/.wigolo/）
• 零强制 API Key：搜索、抓取、爬取、提取、缓存、相似查找六个核心工具不需要任何 API Key
• 显式失败：Bot 拦截、失效引擎、陈旧缓存都会在结果里明确标注，不会伪装成空结果

项目信息

• 作者: KnockOutEZ
• 主语言: TypeScript
• 许可证: AGPL-3.0
• 状态: Public Beta
• 官网: knockoutez.github.io/wigolo

项目数据

• ⭐ GitHub Stars:1,218+
• 🍴 Forks: 83+
• 📄 许可证: AGPL-3.0
• 📅 创建时间: 2026-04-12

快速安装

# 一条命令完成初始化：下载浏览器引擎和本地模型，写入 MCP 配置npx wigolo init--agents=claude-code# 或多个 agent 同时配置npx wigolo init--agents=claude-code,cursor,codex# 检查所有组件健康状态npx wigolo doctor

需要 Node ≥ 20，约 1.5 GB 磁盘空间（浏览器引擎 + 本地 ML 模型）。

安装后所有核心工具立即可用，无需任何 API Key。如果需要research和agent工具的「综合答案」输出（而不是原始数据），接入一个免费的 Gemini key 是最大的质量提升：

exportWIGOLO_LLM_PROVIDER=geminiexportGEMINI_API_KEY=<aistudio.google.com 上的免费 key>

也可以用 Ollama 本地模型完全不出境：WIGOLO_LLM_PROVIDER=ollama。

10 个工具详解

核心检索工具

search— 多引擎并行搜索

• 18 个直连引擎适配器（不走中间代理 API）
• rank fusion 合并多引擎结果 + ML 重排序
• 传入 query 数组可并行发出多个查询（一次 MCP 调用扇出多个搜索）
• 每个结果附带可解释评分：semantic+lexical+engine_consensus三路得分

fetch— 分级路由页面抓取

纯 HTTP 请求 ↓（失败或检测到 SPA 标志） 无头浏览器（处理 JS 渲染） ↓（遭遇 Bot 挑战） 挑战清除流程 ↓（清除失败） 标注 blocked_by_challenge，不伪装成内容

学习每个域名的「需要哪一级抓取」，不重复踩坑。

crawl— 多页爬取

支持 BFS、DFS、sitemap 模式或仅建立站点地图（map-only）。遵守 robots.txt，有 per-domain rate limit，内置模板去重。

extract— 结构化提取

从页面提取：表格、JSON-LD、metadata、品牌资产、命名 schema（Article / Recipe / Product / …），或传入自定义 JSON Schema 提取任意结构。

记忆与发现工具

cache— 本地语义缓存

所有访问过的页面自动缓存。支持关键词查询和语义相似查询，离线可用。还提供缓存统计、清空、变更检测。

find_similar— 相似内容发现

找与某 URL 或概念相似的页面，三路融合：关键词 + 语义 + 实时 Web。

研究与自治工具

research— 深度研究

分解问题 → 并行发出子查询 → 抓取来源 → 合成带引用的报告（或生成结构化摘要由宿主 LLM 自行撰写）。

agent— 自治 gather 循环

自主规划 → 搜索 → 抓取 → 提取 → 综合，支持时间预算和可选输出 JSON Schema。

监控工具

diff+watch— 页面变更检测

查看某 URL 自上次访问以来发生了什么变化；设置定期监控，将变更推送到 webhook。

核心特性深度解析

字节级来源定位（Byte-Pinned Provenance）

这是 wigolo 在所有对比工具中独有的特性。每个搜索结果不只返回摘要，还附带：

{"excerpt":"Logical replication is a method of replicating data objects…","citation_id":"src-1","source_span":{"start":1042,"end":1305},"evidence_score":{"final":0.86,"semantic":0.91,"lexical":0.78,"engine_consensus":3}}

source_span精确到字节偏移量 —— agent 引用这段内容时，可以明确追溯到原文的哪个位置，不是「大概在这篇文章里」。

evidence_score是可解释的三路分数：语义相关度 + 词汇匹配度 + 多少引擎也返回了这个结果（engine_consensus）。弱结果被 wigolo 自身的评分器标记为 junk 并在结果里显示，不是悄悄过滤掉。

为什么重要：AI agent 在构建 RAG 或回答需要引用来源的问题时，字节级定位让引用可以真正可验证，而不是模糊的「参考了某篇文章」。

本地优先架构

AI agent（任意 MCP 客户端 / REST / SDK） ↓ wigolo 进程（单 Node 进程） │ ├── 搜索层 │ 18 个引擎直连适配器 │ rank fusion + ML 重排序（本地模型） │ ├── 抓取层 │ 分级路由（HTTP → 无头浏览器 → 挑战清除） │ per-domain 学习 + 缓存复用 │ ├── 本地存储（~/.wigolo/） │ 关键词索引 + 向量索引（本地嵌入模型） │ 浏览器引擎 + ML 模型 │ └── 可选接入（虚线） LLM API（仅用于 research/agent 综合答案） 聚合器后端（扩展搜索宽度，legacy 模式）

哪些组件是本地的：

• ✅ 搜索引擎直连适配器
• ✅ ML 重排序模型
• ✅ 向量嵌入模型（all-MiniLM-L6-v2等）
• ✅ 无头浏览器引擎
• ✅ 本地缓存（SQLite + 向量索引）

哪些是可选云端：

• 🔲 LLM 合成（research/agent输出综合答案时）
• 🔲 聚合器后端（扩宽搜索漏斗，可选）

横向对比：wigolo vs Tavily / Exa / Firecrawl

这是本文的重点部分。wigolo 在 README 里有一张对比表，但缺少对各工具定位和使用场景的深度说明。

功能矩阵

各工具的实际定位

Tavily— 专门为 AI agent 设计的搜索 API，目前是「RAG + agent 搜索」场景里最常被集成的付费服务。优势是产品成熟、LangChain/LlamaIndex 等框架原生支持、搜索质量经过专门优化；劣势是按查询计费，agent 频繁调用时成本会快速累积。

Exa— 定位为「语义 Web 搜索」，擅长理解查询的含义而不只是关键词匹配。有一个显著特点：官方文档页面、技术内容的检索质量很高（README 的基准测试里提到 Exa 能完整渲染官方文档的对比矩阵）。同样需要注册 + 按量计费。

Firecrawl— 专注于网页爬取和结构化提取，而不是搜索。主要优势是处理复杂 JS 渲染页面、大规模爬取任务、结构化数据提取的能力。适合「给定一批 URL，批量提取结构化内容」的场景，而不是「给定问题，搜索相关内容」。

wigolo— 试图把上述三种能力合并到一个本地工具里，同时消除 API Key 和费用。核心差异化：字节级来源定位、可解释评分、本地缓存（支持离线再查询）、$0 查询成本。

使用场景推荐

选 wigolo 的场景：

• 开发过程中频繁做技术文档查询（无需付费限制）
• 需要来源可追溯性（字节级定位 → agent 引用可核验）
• 隐私要求高，不希望查询内容传出本机
• agent 查询量大，云端 API 成本是问题
• 需要结合本地缓存做「记忆型」研究任务

选 Tavily 的场景：

• 需要开箱即用的生产级质量，不想维护本地依赖
• 已在 LangChain/LlamaIndex 生态，需要框架原生集成
• 查询量可控，按量付费可接受

选 Exa 的场景：

• 主要查询技术文档、学术内容，对语义相关性要求高
• 需要高质量的官方文档检索（文档页面渲染能力强）

选 Firecrawl 的场景：

• 批量爬取特定网站，提取结构化内容（非搜索场景）
• 大规模网页内容处理管道

一个诚实的限制

wigolo 的 README 里提到了一点：数据中心 IP 在 IP 信誉评分上不如家庭网络，某些有反爬措施的网站在云服务器上运行时清除率会低于本地。自托管场景需要注意这一点，README 里提供了可选代理方案。

其他接入方式

wigolo 不只是 Claude Code 插件，支持多种调用方式：

REST API

wigolo serve# 启动在 127.0.0.1:3333curl-sXPOST http://127.0.0.1:3333/v1/search\-H'Content-Type: application/json'\-d'{"query":"local-first software","max_results":5}'

跨越 loopback 的连接强制要求 bearer token，fail-closed 设计。

TypeScript / Python SDK

fromwigoloimportlocal_clientwithlocal_client()asclient:res=client.search(query="local-first web search",max_results=5)forrinres["results"]:print(r["title"],r["url"])

SDK 自动复用已运行的 daemon，或在需要时启动一个，调用结束后按需关闭。

框架集成

参考资源

官方链接

• 🌟GitHub: KnockOutEZ/wigolo
• 🌐官网: knockoutez.github.io/wigolo
• 📦npm: wigolo
• 📄文档: docs/README.md

总结

wigolo 的核心主张是：agent 的 Web 访问层不应该是一个持续计费的云端 API 黑盒。搜索引擎的原始数据是公开的，重排序和提取算法可以本地跑，查询历史可以缓存到本地语义索引里 —— 这些事情加在一起，就是一个零费用、数据留本地、可离线复用的 Web 情报层。

两个设计决策值得单独记：

字节级来源定位：在所有对比工具里独有。agent 引用搜索结果时，source_span给出字节偏移量，引用可以真正追溯到原文位置。对于需要「来源可验证」的研究类任务，这个特性直接减少了一层「AI 可能在编造引用位置」的不确定性。

显式失败而非沉默：Bot 拦截标注为blocked_by_challenge，失效引擎上报，弱结果被评分器标记为 junk 并显示在结果里。这种「始终告诉你它站在什么地基上」的设计，在 agent 场景里比「假装成功」要可靠得多。

如果你的 Claude Code 日常工作里有大量文档查询、技术信息搜索，或者正在构建需要 Web 搜索的 agent pipeline，wigolo 的npx wigolo init --agents=claude-code是目前成本最低的接入方式 —— 字面意义上的零成本。

探索 PrimeSkills —— 精选 AI agent 和技能工具，每一个都经过真实工作流验证。没有炒作，只有真正好用的工具。

访问我的个人主页，获取更多见解和有趣的产品。