四大AI联网搜索横评：Claude、Codex、Kimi K3与Qwen 120次实测

问题的核心已经改变

先说一个反直觉的结论：在这次120次评测中，唯一全部答对的是缓存模式的搜索。

四个月前，大多数人讨论AI搜索时还在纠结"它底层用了哪个搜索引擎"。现在这个问题已经过时了。Claude、Codex、Kimi K3和Qwen这四家，没有一家在官方文档里公布自己的搜索引擎。真正值得问的问题是：搜索在哪里运行，谁来调用它？

四款AI搜索工具对比测试

OpenAI把自研索引作为Codex的默认选项；Kimi则把搜索本身拆出来做成了独立API。这种变化不仅停留在文档层面，实测结果同样出人意料。

各家搜索的运行架构差异

在比较任何东西之前，先看机制层面的区别。

	Claude	Codex / OpenAI	Kimi	Qwen
搜索运行位置	Anthropic服务器端	OpenAI托管工具	你的代码调用API并回传结果	阿里云^广告DashScope；本地Qwen无搜索
时效控制	无	默认缓存，`--search`切换实时	Pro搜索支持时间窗口	7-365天窗口
每次搜索价格	$0.01	$0.01	$0.002-0.003	因地区而异
搜索引擎	未披露	未披露	未披露	未披露

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

Kimi正处于过渡期。内置的$web_search工具将在2026年10月20日退役，取而代之的是独立的REST API，比如/v1/tools/search。新API让你自己决定何时搜索、搜索几次，价格是其他方案的1/3到1/5，且只在实际返回结果时计费。

Qwen模型本身没有搜索能力。阿里云API提供搜索，但本地运行的Qwen只能靠你手动接入外部搜索工具。

文档里两个容易忽略的细节

Claude Code的WebSearch只返回标题和URL，不读取页面内容。读页面由WebFetch负责，而WebFetch会先用另一个模型调用做摘要。文档自己称这种设计"lossy by design"（有损是刻意的）。

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

我在写这篇文章时亲身踩到了"有损"的坑：让Claude Code的WebFetch去读Qwen文档，它报告找不到15 RPS限制和英文FAQ。改用grep直接搜原始HTML（约460KB），两条都找到了。一旦中间隔了一层摘要，"文档没写"可能只是"摘要丢了"。

文中反复出现的"服务端搜索"与"客户端搜索"，指的并不是物理位置，而是谁掌握搜索链路的控制权。服务端搜索（Claude、Codex）意味着：你的请求发出后，厂商在自家基础设施上完成检索、抓取、摘要，再把加工好的结果连同模型回答一起返回。你无法看到原始搜索结果，也无法在两次调用之间保留搜索状态。客户端搜索（Kimi新REST API、本地Qwen）则相反：搜索是一个独立的HTTP端点，由你的代码决定何时调用、调用几次、拿到什么结果后再喂给模型。这种区别带来三个实际后果。其一是可观测性：客户端模式下你能看到每一次查询词、命中的URL和原始片段，便于排查"是搜索没找到还是模型没读懂"。其二是可控性：可以插入自己的重排、去重或缓存层。其三是成本与延迟的权衡：多一次往返就多一次延迟，但只在返回结果时计费。文中强调"搜索在哪里运行"正在取代"用哪个引擎"，本质是控制权从厂商转移到开发者手里后，评测维度也随之从"引擎质量"变成了"链路整体质量"。

文中提到的Restful搜索API在实践中会碰到限流（rate limit）与静默降级的设计问题。云服务通常用每秒请求数（RPS或QPS）来限制调用频率，常见做法是超出后返回HTTP 429，并在响应头里给出Retry-After，让客户端自行退避重试。阿里云Qwen搜索在15 RPS后会静默跳过搜索——既不报错，也不返回"已跳过"的标记，只是让这次调用变成一个没有检索结果的普通请求。这种设计对调用方极不友好，因为流水线无法区分"搜了但没结果"和"根本没搜"，排查时只能靠比对延迟和计费日志。另一种常见现象是查询语言偏置：检索索引和查询改写模块往往以某种语言为主要训练或语料来源，导致用英文问中文站点内容时召回率骤降，而用站点母语提问则命中率上升。这两条只有在中文文档里写出来，也侧面说明厂商对不同语言用户提供的透明度并不对等——这一点值得所有自建搜索链路的开发者警惕。

测试方法

五个配置，8个问题，每个跑3次，共120条评分答案。

Claude：Claude Code搭配WebSearch/WebFetch
OpenAI实时：Responses API的web_search
OpenAI缓存：同上，加上external_web_access: false
Kimi K3：接入Kimi搜索API
本地Qwen：Ollama上运行，用同一个搜索函数

8个问题覆盖了训练截止后的新闻、日期陷阱、日文来源、时效性、文档细节、数字提取以及"是否存在"的诱导。其中q3是我自己写的书，q4是我自己当天发的文章——我选它们是因为确定答案，但这确实带来偏差，我宁愿主动说明。两题都是日文，也顺便测试各配置对日文来源的覆盖能力。

要理解这次评测的结论，需要先弄清几个评测术语。训练截止后的问题（post-cutoff questions）指的是答案产生于模型训练数据截止之后的事件，模型无法凭记忆回答，必须依赖检索，因此是检验搜索链路最干净的一类题。但这类题有天然缺陷：模型可能"恰好记得"某个相关背景，从而部分蒙对，所以通常要配合日期陷阱题（答案是某个容易被混淆的日期）和是否存在题（诱导模型对不存在的东西编造答案）来交叉验证。三次重复运行是为了区分"稳定正确"和"偶尔碰对"——如果同一配置三次给出不同答案，说明链路存在随机性，单次得分不可信。中位耗时而非平均耗时，是为了排除个别超长样本对均值的拉偏。需要注意的是，不同配置的耗时不可直接比较：Claude Code包含了agent的多轮决策循环，而直接API调用只有一次往返，这两者的时间结构完全不同，把它们并列在表里只是为了展示量级，而非性能优劣。

结果：缓存模式全对

配置	正确（/24）	部分正确	错误或无答案	中位耗时	平均搜索次数
Claude	21	1	2	22.0s	3.5
OpenAI实时	22	1	1	5.7s	2.3
OpenAI缓存	24	0	0	6.2s	2.7
Kimi K3	21	0	3	25.9s	4.0
本地Qwen	9	2	13	31.1s	1.7

发现一：缓存并不陈旧

缓存搜索24题全对。q4那篇文章当天下午5点多上线，我大约3小时后开始测试。缓存搜索在3次运行中都返回了正确标题。至少对我这个站点而言，"OpenAI维护的索引"在数小时内就刷新了。

来源质量上缓存有时也更优。q6问Kimi $web_search的退役日期，缓存模式引用的是Kimi官方文档；实时搜索答案相同，但有一次引用了一个非官方汇总站。覆盖面越广，混入非官方页面的概率也越高。

发现二：同样的搜索结果，不同的答案

Kimi K3和本地Qwen拿到了完全相同的搜索API，调用方式也完全一样。得分却是21比9，相差超过一倍。

Qwen的错误呈现出几种模式：

它坚信现在是2024年，这个信念压过了搜索结果。 q4的回答是："截至现在（2024年5月），一篇标注2026年10月14日的文章不存在，那是未来日期。"
它引用的来源和给出的答案互相矛盾。 q5三次运行都引用了5月21日的候选发布公告，却回答了7月28日的最终发布日期。
它编造了来源。 q3引用了一个不存在的Impress新闻稿URL（404），每次给出的错误日期还不一样。
它几乎不怎么搜。 平均1.7次，不到K3的4.0次的一半。

模型规模不同，这不是对Qwen整体的判决。但它说明了一件事：联网搜索的准确率不是搜索API单独决定的。

本地Qwen表现出的"坚信现在是2024年"，在模型评测中通常被归类为时间幻觉（temporal hallucination），其成因和普通的事实性幻觉不同。大语言模型的知识截止日期决定了它训练数据中最晚的时间点，但模型并没有一个内置时钟来告诉自己"今天是几号"。除非系统提示里显式注入当前日期，模型只能靠两种线索推断时间：一是训练数据的时间分布，二是当前对话上下文。当上下文没有明确日期时，模型会退回到训练数据里的"最近时间感"，于是2024年成了它的默认锚点。危险之处在于，这个内部锚点会压制外部证据——即使搜索结果明确标注了2026年的日期，模型仍可能判断"这是未来日期，不可能存在"，从而拒绝采纳。这与"不知道答案"不同，是模型主动否定了正确信息。缓解手段包括：在系统提示中硬编码当前日期、要求模型在回答前先复述检索到的时间戳、以及避免让模型单独判断"现在是什么时候"。

发现三：Kimi搜索API的两个缺口

K3三次错误全部集中在q4。它换了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排在最前。不过在正式运行中，模型们都没有掉进这个陷阱，K3和Qwen都自己调整了查询词。

顺带一提，即将退役的$web_search工具与K3不兼容——第二次调用（返回搜索结果的那次）每次都报400 tokenization failed。用普通函数调用传递搜索，如本次测试所做，则工作正常。

Claude的日文书籍困境

q3问的是一本日文书的出版日期，Claude在3次运行中有2次说找不到这本书、可能不存在。实际上该书在出版社的NextPublishing页面和乐天Books上都有列出，包含出版日期。

不过Claude在其他方面表现出了韧性。有一次q4，WebSearch没有检索到那篇文章，Claude转而通过站点地图找到文章并打开页面确认了标题和日期。由于WebSearch只返回标题和URL，按需抓取页面本就是设计的一部分，这次它派上了用场。Claude也经常主动注明自己只查了二手来源，避免下定论。22秒的中位耗时包含了Claude Code的agent循环，直接通过API调用搜索工具应该更快。

实操建议

研究和查资料时，把缓存搜索留作默认。 如果你用Codex，不必每次都加--search。更安全的设置并没有牺牲准确率。
对非英文来源，不要相信"找不到"。 没找到不等于不存在。当Claude说找不到时，换一种方式再查。
如果自己接入搜索，模型比搜索API更重要。 同样的搜索API，K3和Qwen差了超过两倍。先挑能读懂搜索结果的模型，再挑最便宜的搜索API。
让你的搜索工具返回失败信息。 Kimi搜索API在遇到site:时返回502。把失败传回给模型而不是让脚本崩溃，模型会换个说法重新搜索。

局限性

这是一个小规模测试：8个问题、3次运行。话题偏向Kimi K3和MCP，q3和q4是我自己的书和文章。Claude通过Claude Code运行，Codex结果是调用CLI底层API得到的。Qwen配置是本地35B模型接入Kimi搜索，而非Qwen官方搜索。各配置工作方式不同，耗时不可直接比较，也没有统计总成本。

下一步，我想直接通过API调用Claude的搜索工具，并试试阿里云上的Qwen官方搜索，以缩小各配置之间的差距。

搜索这个问题，已经从"用哪个引擎"变成了"搜索在哪运行、谁来调用"。这个变化的速度，比四个月前任何人预期的都快。