120次评分后，我发现AI搜索的真相不在引擎

同一个搜索接口，喂给两个不同的模型，一个答对21次，一个只答对9次。这不是模型参数量的差距，是它们读搜索结果的方式不同。

有人把Claude、Codex、Kimi K3和本地Qwen放在一起，用同样的8个问题各跑3遍，5种配置一共评了120次。测试时间在2026年10月14日晚上。结果里最扎眼的一条是：唯一全对的配置，恰恰是那个默认不联网的。

搜索到底跑在哪

四个月前大家还在问"底层用的是哪家搜索引擎"。现在这个问题已经不太成立了——四个厂商没有一个在文档里正式点名自己的搜索后端。

Claude和OpenAI把搜索跑在自己的服务器上，再把结果交给模型。Claude返回的结果是加密的，必须原样传回去才能继续对话。

Kimi正处在过渡期。内置的$web_search工具将在2026年10月20日退役，替代品是独立的搜索和网页抓取REST API。用新接口，什么时候搜、搜几次由你决定，价格是其他方案的三分之一到五分之一，只在调用成功并返回结果时计费。

Qwen模型本身没有搜索能力。阿里云API提供搜索，但本地跑的Qwen只能靠外接搜索工具才能查东西。

两个藏在文档里的细节

Claude Code的WebSearch只返回标题和URL，不读页面内容。读页面是WebFetch的活，而且它会先用另一个模型调用把页面总结一遍。文档自己管这叫"设计上就是有损的"。

阿里云的Qwen搜索在每秒超过15次请求时会静默跳过搜索。没有报错，搜索就是不发生。FAQ里还提到英文提问经常触发不了搜索，建议用中文提问或强制搜索。这两条只出现在中文文档里。

测试者自己就踩了这个坑：让Claude Code的WebFetch去读Qwen文档，它报告说没找到15 RPS那条和英文FAQ。直接对原始HTML跑grep，两条都在。中间隔了一层总结，"它没这么说"可能只是"总结把它丢了"。

缓存没有过期

Codex CLI的网页搜索默认不是实时的，跑在"缓存"模式下，对着OpenAI自己维护的索引查。文档给的理由是降低提示注入风险。

测试前他以为实时搜索在需要新信息的问题上会赢。数据打了脸：缓存搜索24次全对。其中一篇文章当天下午5点多才上线，测试在约三小时后进行，缓存搜索三次都返回了正确标题。

来源质量上缓存有时也更好。问$web_search何时退役，缓存引用的是Kimi官方文档，实时搜索答案相同，但有一次引用了一个非官方汇总站。

同样的结果，不同的答案

Kimi K3和本地Qwen拿到的是完全相同的搜索API，用法也完全一样，得分却是21比9。

Qwen的错误有几类固定模式：

• 它坚信现在是2024年，这个信念压过了搜索结果。面对一篇2026年10月14日的文章，它说"截至现在（2024年5月），这个日期的文章不存在，那是未来日期"
• 来源和答案互相打架。三次都引用了5月21日的候选版公告，却回答了7月28日的正式版日期
• 编造来源。引用了一个根本不存在的新闻稿URL（404），每次给出的错误日期还不一样
• 它几乎不怎么搜。平均1.7次，不到K3的4.0次的一半

模型规模不同，这不构成对Qwen整体的判决。它说明的是：网页搜索的准确率不是搜索API单独决定的。

Kimi搜索API的两个缺口

K3三次失手全在同一道题上。它把查询改了12遍，始终没找到那篇当天发布的文章——页面还没进Kimi的搜索索引。问题不在模型，在索引新鲜度。

第二个缺口：带site:操作符的查询返回HTTP 502。K3和Qwen都试过用site:kenimoto.dev找特定页面，搜索API每次返回非JSON错误页，第一次运行还直接把脚本搞崩了。现在这个工具会把失败返回给模型，让它改写查询重试。

直接打搜索API也暴露了措辞有多重要。搜"Kimi K3 release date Moonshot AI"，"date"会喧宾夺主，返回时区网站和JavaScript Date文档。只搜"Kimi K3"，官网、论文和GitHub排在最前。实际测试里两个模型都没掉进这个坑，它们自己改了查询。

另外，即将退役的$web_search工具跟K3不兼容，第二次调用（返回搜索结果那次）每次都报400 tokenization failed。走常规函数调用把搜索传进去则一切正常。

Claude卡在一本日文书上

同一道题，Claude三次里有两次说找不到这本书，可能不存在。这本书在出版社的NextPublishing页面和乐天图书上都有条目和发售日期。

它在别处很执着。有一次WebSearch没搜到那篇文章，Claude通过站点地图找到并打开页面确认了标题和日期。因为WebSearch只返回标题和URL，需要时去抓页面本来就是设计的一部分，这次它奏效了。Claude还经常主动说明自己只查了二手来源，避免下确定结论。

22秒的中位数包含了Claude Code的agent循环，直接通过API调用搜索工具应该更快。

接下来怎么用

把缓存搜索留作研究默认项。用Codex的话不必每次都传--search，更安全的设置并没有在准确率上吃亏。

非英语来源的"没找到"别当真。没找到不等于不存在，Claude这么说的时候，换个方式再查一遍。

自己接搜索的话，模型比接口更重要。同一个搜索API，K3和Qwen差了两倍多。先挑一个会读搜索结果的模型，再挑最便宜的搜索API。

让自己的搜索工具把失败返回出去。Kimi的搜索API在site:查询上返回502，把失败传回去而不是让脚本崩溃，模型会改写查询再搜一次。

这个测试规模不大：8个问题、3次运行，题目偏向Kimi K3和MCP，其中两道还是测试者自己的书和文章。Claude走的是Claude Code，Codex结果是调用CLI底层API得到的，Qwen配置是本地35B模型接Kimi搜索，不是Qwen官方搜索。各配置工作方式不同，耗时不能直接比较，这次也没统计总成本。