6个搜索工具，我做了自动路由

我的机器上装着六个搜索工具。听上去很离谱，但它们是陆续装上的——每装一个都是因为前一个在某件事上不灵。

问题不是"哪个最好"。**没有哪个最好。**问题是我记不住什么时候该用哪个，于是大部分时间都在用最顺手的那一个，哪怕它是错的。

所以我做了件事：把它们包成一个命令，让脚本判断该用谁。下面是实测数据和完整实现。

先说结论

如果只记一句：查资料用带日期的，写材料用带引用编号的，要截图和抽字段用能爬的。

一、为什么一个工具不够

先说个反常识的：这些工具的检索准确率其实差不多。

我用三组中英文查询（技术类、时政类、资讯类）各测 10 条结果，统计"关键词命中数"：

打平。 都是 5 分上下，差那 0.3 分基本是噪音。

所以选型根本不该看"谁搜得准"。真正的差异在附加能力——搜到之后，它能给你什么：

• 能不能告诉你这条什么时候发布的
• 能不能给结果编号，让你在材料里标注来源
• 能不能一次把正文给你，而不是让你再点开链接
• 能不能截图、能不能按你指定的字段抽数据

这些才是决定"这个活能不能干"的东西。

二、两个真正拉开差距的指标

1. 有没有发布日期

我写材料要核对时间线，这条是刚需。

实测 10 条结果里带日期字段的数量：

其他工具基本是 0。 anysearch 是唯一每次都给 date: 字段的——中文查询 10/10，英文 8/10。

这一条的差距有多大：用别的工具，你要知道一篇文章什么时候发的，得逐条点开抓页面。10 条就是 10 次额外请求。anysearch 直接给你。

还有个附带好处：命中权威源特别准。我查政策类内容，首条直接是官方网站，5 条结果全是正规来源。

2. 有没有引用编号

写需要溯源的材料时，[1][2][3] 这种编号是刚需——你得让每句话都能对上来源。

只有 wigolo 给这个。 它还会给每条结果的 evidence_score 分量（哪几个维度合的、各占多少），甚至能告诉你两个来源的说法矛盾。

代价是慢：实测平均 4.1 秒，是 anysearch 的 2.5 倍。

顺便说个最容易踩的坑。wigolo 拿正文要传两个参数，不是文档里写的那一个：

# 只传这个，正文会被静默丢弃
{"query": "...", "include_content": True}

# 必须两个都传，才能拿到正文
{"query": "...", "include_content": True, "include_full_markdown": True}

第一个参数决定"要不要去抓"，第二个决定"抓到后要不要给你"。只传第一个，它抓完页面再把正文清空——**这设计真的很容易让人以为自己遇到了 bug。**我一开始就是这么误判的，还在报告里写成了缺陷，后来翻源码才发现在 core-provider.js 里有一行主动清空：

if (!input.include_full_markdown) {
  for (const r of items) r.markdown_content = void 0;
}

补上第二个参数，同一次请求直接返回 39163 字符正文。这条教训我记下了：看到"功能不生效"，先翻源码，别急着提 issue。

三、抓取能力和搜索是两回事

搜索是"给你网址"，抓取是"给你内容"。这两件事常常被混着比较，但它们根本不是一回事。

同一个网页，两个工具实测：

三个反直觉的发现

第一，Cloudflare 谁都过不去。

网上流传"crawl4ai 能过反爬"。实测不能。 我拿一个 Cloudflare JS 挑战的站点测，crawl4ai 返回 1 个字符、SUCCESS=False；它的历史日志里也留着 Blocked by anti-bot protection 的记录。别为这个去装它。

第二，wigolo 报 500 别急着重试失败。

它首次抓某官方网站时报 Redirect loop detected（HTTP 500），第二次就成功了。一次性重定向问题，不是坏了。我现在看到它报 500 都先重试一遍。

第三，crawl4ai 的日志不是错误。

它把进度打在 stderr：[INIT] [FETCH] [SCRAPE] [COMPLETE]。这些全是正常输出。我第一次看到红字一片以为它崩了，其实早抓完了。脚本里加 2>/dev/null 就清静了。

crawl4ai 真正独占的三件事

截图和按指定字段抽取，其他工具都没有。这是我留着它的唯一理由。

四、自动路由：一个命令解决选择困难

真正的痛点不是"工具不够好"，是我记不住该用哪个。

于是写了个脚本，叫 s：

s "关键词"                    # 自动选工具
s 600519                     # 纯数字 → 自动识别成股票代码
s https://example.com/xxx    # 识别出 URL → 自动切抓取模式
s deep "关键词"               # 先检索拿列表，再抓正文

路由逻辑

核心就一段判断，思路比代码重要：

case "$input" in
  # 1. 是 URL → 抓取，不是搜索
  http*)
    crawl4ai fetch "$input" ;;

  # 2. 纯 6 位数字 → 股票代码
  [0-9][0-9][0-9][0-9][0-9][0-9])
    anysearch stock "$input" ;;

  # 3. 关键词里带金融词 → 走金融垂直域
  *股价*|*行情*|*市值*|*财报*)
    anysearch finance "$input" ;;

  # 4. 带学术词 → 走学术域
  *论文*|*DOI*|*文献*|*期刊*)
    anysearch academic "$input" ;;

  # 5. 其他 → 默认 anysearch（最快 + 带日期）
  *)
    anysearch search "$input" ;;
esac

默认选 anysearch 的理由：它最快（1.6 秒），而且唯一带日期。日常查询用它，命中率和别人一样，但你额外白拿一个时间戳。

需要指定时的开关

自动路由覆盖 80% 的情况，剩下 20% 给你显式指定：

s -w "关键词"        # 强制 wigolo，要引用编号
s -n 5 "关键词"      # 指定条数
s shot <url>         # 截图
s crawl <url> 2 20   # 爬站：深度 2，最多 20 页
s cache "关键词"     # 查本地缓存，不走网络

一个意外收获：垂直领域检索

anysearch 有 40 个垂直子域，这是它最被低估的能力。

查股票不给你网页摘要，直接给数值字段：

Price: 1257.12 | MarketCap: 1570290684627 | Avg200: 1358.60

宏观数据也是结构化的：

{"1y":3,"5y":3.5,"date":"20260820"}

涵盖金融、学术、法律、医疗、能源、农业等 16 个大类。这是"搜索引擎"和"数据接口"的区别。

五、踩坑记录

这些都是我真实撞过的，不是抄文档：

最重要的一条：那次"中文搜索全废"的误判。我当时已经准备写进报告了，最后逐层排查发现是我自己的测试方法有 bug——命令行里内联的中文被转成了 GBK 编码，工具收到的是一串乱码。改用正确的请求方式后，同一个查询返回 9-10 条全对的结果。

日志里留着铁证："query": "��������Ԥ��"。

教训：排查"工具坏了"之前，先用最简单的方式验证一遍，确认不是自己传错了参数。

六、怎么选

三条别做的事

1. 别指望任何工具过 Cloudflare —— 实测 crawl4ai 也过不去，这是误解。
2. 别用一个工具干所有事 —— 它们的检索准确率打平，但独占能力完全不同。
3. 别信"功能不生效"的第一直觉 —— 先翻源码或换个调用方式，多半是参数问题。

最后

这套东西的价值不在于工具多，而在于我不再需要记住什么时候该用哪个。

六个工具，一个命令。路由脚本本身不到 100 行，改起来也简单——想加新工具，就在 case 里加一条规则。

真正花时间的部分其实是排查那些"看起来像 bug、其实是自己搞错"的问题。但这也是唯一能让你真正知道工具边界的方式——文档往往滞后于实现，还会漏掉关键参数。

如果觉得有帮助，点个「赞」和「在看」支持一下 👇