wigolo 能省搜索 API 费，但别把“本地免费”理解成零成本
如果你现在为 Tavily、Exa、Firecrawl 一类云端搜索或抓取接口按调用付费，wigolo 确实给了另一条路：把搜索、抓取、排序、缓存尽量搬回自己的机器。但它更像“把账单从 API 调用费搬到本地算力、磁盘、网络和运维”，而不是把总成本归零。
项目当前 package.json 版本为 0.2.1，README 仍把它标成 public beta；核心定位是给 AI Agent 提供本地优先的搜索、抓取、爬虫、提取、缓存和研究工具。
源 源
哪些地方是真的“免费”
项目 README 明确写着，search、fetch、crawl、extract、cache、find-similar 这些核心工具不需要 API Key；默认搜索直接连公共搜索引擎，本地完成 reranker 和 embeddings，并把结果缓存到本机。源
但 research、agent 和 search 的 answer 模式要生成完整文字答案时，需要外接 LLM；不配云端模型也可以使用本地 Ollama，但那时成本变成本机推理资源。README 对这条边界写得很清楚：不配 LLM 时，这几个能力返回的是结构化证据，而不是已经写好的报告。源
所以，对“我只是想让编码 Agent 搜网页、抓文档、做缓存”的个人开发者，wigolo 有机会明显减少按次调用费；对“我要稳定地产出研究报告”的工作流，搜索层免费不等于整条链路免费。
部署门槛不是一条 npx 命令那么简单
官方 Quickstart 要求 Node ≥ 20，并建议准备约 1.5 GB 空闲磁盘，用来放浏览器引擎和本地模型。源
平台差异也会直接影响能力。官方 troubleshooting 写明：Linux ARM64 上，核心 search、fetch、crawl、extract、cache 可以工作，但语义功能目前不可用；find_similar、embeddings 和语义缓存排序会退回关键词匹配。如果你在 ARM 小主机或 ARM 云服务器上跑，不能把 x64 上的完整能力直接照搬过去。源
这类差异决定了“本地免费”适合什么机器。开发者自己的 x64 工作站，磁盘和 CPU 已经是沉没成本；短生命周期 CI、低配 VPS 或 ARM64 环境，则可能把省下来的 API 费换成冷启动、资源占用和能力退化。
最容易漏算的一笔账：反爬失败之后的代理
wigolo 的抓取链路会从普通 HTTP 逐级升级到更强的抓取方式；如果目标站仍被反爬挑战挡住，它会返回 blocked_by_challenge，而不是把挑战页伪装成正文。源
问题在于，官方自己也承认数据中心 IP 有天然上限：VPS、CI、云服务器的 IP 信誉较低，有些站点即使客户端逻辑没问题也过不了挑战；官方给出的可选方案是使用与合法研究用途匹配的代理。源
代理是不是付费、多少钱，本文没有取到官方统一数字，也不应该替你编。真正的判断是：如果你的目标网站经常需要住宅或移动代理，wigolo 的“每次查询 $0”仍可能成立，但你的整体检索成本并不为零。成本只是从搜索 API 账单转移到了代理、机器和维护上。
搜索质量：项目展示能说明“可用”，不能证明“全面持平”
README 的 Benchmark 是项目自己做的一次四方演示：在同一个 Claude 会话里，让 WebSearch、wigolo、Tavily、Exa 处理同一个查询，并展示四者都收敛到相同核心答案。源
这能证明项目至少有一个可复现的成功案例，但它不是独立第三方、大样本测试。更关键的是，README 自己在 FAQ 里也写明：日常 Agent 查询可以达到其所称的 parity，但付费工具在部分深度提取边缘场景仍然占优。源
所以，“能不能替代 Tavily/Exa”没有一个统一答案。你如果最在意的是日常技术搜索、本地缓存、可审计摘录和降低调用费，可以把 wigolo 当候选；你如果最在意的是长尾召回、深度结构化提取、生产 SLA，就不能用这次官方演示当成替代结论。
“数据不出本地”也要读完整
项目的隐私文档说明，缓存、模型、配置等状态默认存在 ~/.wigolo，本身没有一个厂商后端接收你的数据；遥测默认关闭。源
但这不等于“查询从不离开机器”。同一份官方文档也写明，wigolo 会向搜索引擎和你要访问的网站发起网络请求；如果你配置了云端 LLM，合成阶段还会连接对应 LLM 提供商。源
更准确的说法是：wigolo 的本地状态和缓存不需要上传到 wigolo 自己的云服务，但正常搜索仍会访问公共网络。对隐私敏感的团队，应该按这条真实网络边界做评估，而不是只看“local-first”三个字。
怎么决定要不要换
如果你的主要负担是高频技术搜索，已有一台稳定的本地开发机，能接受 public beta，也愿意自己排查问题，wigolo 值得先拿一小组真实查询做对照测试。先测你自己的查询集，比看官方演示更有意义。
如果你的工作流跑在 ARM64 Linux、短生命周期 CI、低配 VPS，或者大量目标站对数据中心 IP 严格反爬，那么不要先算“省下多少 API 费”，先算代理、机器、冷启动和维护时间。
如果这是生产依赖，最稳妥的切换方式不是一次性停掉原有商业 API，而是先并行跑：同一批真实查询同时走 wigolo 和现有服务，记录召回、引用正确性、失败率和人工返工，再决定哪些查询可以迁移。飞出国更关心这张账，因为真正昂贵的通常不是一次 API 调用，而是错误结果进入后续自动化之后的返工。
这篇哪里可能过时或不适用
package.json 截至 2026-08-31 仍是 0.2.1，README 仍标 public beta。Linux ARM64 语义不可用、磁盘约 1.5 GB、Node ≥ 20 以当时官方文档为准。
本文没有取 Tavily、Exa、Firecrawl 的现行官方价，所以没有做具体金额比较。官方 Benchmark 是项目自证，不能推出第三方一致结论。