Claude 和 Gemini 3 都能联网检索，但走的路径不同。Claude 把搜索拆成工具调用，Gemini 3 则把 Google Search 的 Grounding 能力接入生成流程。两种方案在延迟、网页处理和引用方式上各有取舍。

一、两条搜索路径

Claude 的流程比较直观：调用 WebSearch 查找页面，再用 WebFetch 读取 HTML，必要时在沙盒里运行 Python 过滤无关内容。这套 Agent 循环适合处理长文档和结构不统一的网页，代价是步骤多、耗时也更长。

Gemini 3 依赖 Google Search 提供的结构化检索结果。模型可以直接使用搜索系统预先提取的 Snippets，省去下载和解析完整网页的部分成本，因此搜索与生成之间的延迟更低。

二、什么时候触发搜索

每次联网都会增加时间和调用成本。Claude 主要依靠模型规划来决定是否调用搜索工具。例如，问题涉及刚更新的框架或具体报错时，模型可以主动生成搜索指令。

Gemini 3 使用 Dynamic Retrieval。系统评估当前问题与模型已有知识的匹配程度，低于阈值时触发搜索。两种机制都在解决同一个取舍：能直接回答的问题少走一步，时效性或事实风险较高的问题先查资料。

三、搜索结果怎样进入回答

Claude 可以在沙盒中编写过滤代码，从网页里提取 API 参数、代码片段或指定段落。它对页面结构的适应性较强，处理过程也会占用更多推理和工具调用时间。

Gemini 3 接收 Google Search 返回的结构化文本块，并在 API 响应中提供来源和文本映射元数据。开发者可以据此查看回答片段对应的参考 URL，用于展示引用或继续核查。

四、第三方 API 为什么会失去搜索能力

Grounding、WebSearch 和动态过滤都依赖服务端基础设施。官方 API 和云平台会按各自协议传递工具定义、搜索载荷与引用元数据。第三方网关如果统一改写请求格式、裁剪工具字段，或关闭额外计费的搜索能力，模型仍能对话，联网功能却可能失效。

因此，采购中转服务时不能只看模型名称。还要实际测试搜索工具是否可调用、引用元数据是否完整，以及长网页处理是否符合预期。

结语

Claude 更擅长自行查找和处理网页，Gemini 3 更依赖 Google Search 的结构化检索与来源映射。选哪一种，要看任务更在意长文档处理、响应延迟还是引用链路。所谓“完整能力”最终要靠一次真实请求验证。