Cherry Studio v2 变更解读URL 上下文能力合并进 Web Search 开关【免费下载链接】cherry-studio Cherry Studio 是一款支持多个 LLM 提供商的桌面客户端项目地址: https://gitcode.com/CherryHQ/cherry-studio导读Cherry Studio v2 对聊天输入框的网页工具入口做了一次重要的收敛原来独立的「URL Context」按钮被移除从提示词中抓取 URL对应 Gemini 的 urlContext、Anthropic 的 web fetch以及客户端自带的web_fetch工具不再单独开关而是与网页搜索一起由同一个Web Search 开关统一控制。本文基于仓库中 2026-08-01-url-context-merged-into-web-search.md 的变更记录结合源码中 Web 工具路由WebToolRoutes、provider 原生插件与客户端内置工具的实现讲清这次合并的来龙去脉、底层路由决策逻辑以及用户和开发者分别需要做什么。变更概览独立 URL Context 按钮被移除变更前与变更后变更前聊天输入框里存在两个独立入口——「Web Search」开关与「URL Context」按钮二者可分别打开或关闭。用户可能只开启 URL Context 而不开启网页搜索。变更后独立的「URL Context」按钮消失。抓取 URL 的能力与网页搜索绑定打开 Web Search 开关即同时启用搜索与 URL 抓取关闭开关则两者同时关闭。被合并的三条 URL 抓取路径这次合并涉及的「URL 抓取」在 Cherry Studio 中有三种实现形态取决于模型/提供商的支持情况Gemini 原生 URL ContextGoogle 侧的 server-side 能力Anthropic web fetchAnthropic 提供的 provider 原生抓取能力客户端web_fetch工具Cherry Studio 自带的 agentic 工具由模型在对话中调用。它们对应源码中的常量WEB_SEARCH_TOOL_NAME web_search与WEB_FETCH_TOOL_NAME web_fetch见 builtinTools.ts以及 provider 侧的工具插件providerToolPlugin(urlContext)与providerToolPlugin(webSearch)。底层机制一个开关如何同时驱动搜索与抓取WebToolRoutes按能力独立路由源码 provider.ts 定义了 Web 工具的路由模型export type WebToolRoute client | server | none export interface WebToolRoutes { webSearch: WebToolRoute webFetch: WebToolRoute reasons?: PartialRecordwebSearch | webFetch, WebToolUnavailableReason }webSearch与webFetch两条能力各自独立路由但路由决策的入口条件都由同一个webSearchEnabled驱动。在 resolveWebToolRoutes 的实现中const clientSearchAvailable options.webSearchEnabled supportsClientTools options.clientSearchAvailable const clientFetchAvailable options.webSearchEnabled supportsClientTools options.clientFetchAvailable const serverSearchEligible options.webSearchEnabled provider ? isBuiltinWebSearchAvailable(model, provider, options.endpointType) : false const serverFetchEligible options.webSearchEnabled provider ? isBuiltinWebFetchAvailable(model, provider, options.endpointType) : false可见webSearchEnabled是搜索与抓取两条能力共同的“总闸”——这正是本次变更“一个开关同时控制两者”的代码级印证。开关关闭时客户端工具与 server 侧能力全部不可用开关打开时再按模型与 provider 的能力分别把webSearch、webFetch路由到serverprovider 原生、clientCherry 自带工具或none。路由的选择顺序对每条能力路由选择遵循「优先侧 回退侧」策略modelToolsPreferred决定优先哪一侧const selectRoute (clientAvailable: boolean, serverAvailable: boolean): WebToolRoute { if (options.modelToolsPreferred) { return serverAvailable ? server : clientAvailable ? client : none } // 否则优先 client再回退 server }这印证了变更记录中的说明“哪一侧执行provider 原生还是 Cherry 自己的工具仍由模型/提供商自动决定”。例如Gemini 模型在支持原生 Web 工具且无函数工具冲突时搜索与抓取走server普通模型则注入客户端的web_search/web_fetch工具由模型自主调用模型不支持或功能冲突如googleToolConflict、openaiMinimalConflict时对应能力路由为noneUI 依据WebToolUnavailableReason提示原因。server 侧provider 原生能力插件当路由决策为server时请求构建阶段会注入对应的 provider 原生插件providerUrlContext.tsexport const providerUrlContextFeature: RequestFeature { name: provider-url-context, applies: (scope) scope.webToolRoutes?.webFetch server, contributeModelAdapters: () [providerToolPlugin(urlContext)] }providerWebSearch.ts当webToolRoutes.webSearch server且存在 provider 搜索插件配置时注入providerToolPlugin(webSearch, ...)覆盖 Anthropicweb_search_20250305、Gemini grounding 等能力。其注释特别强调provider 原生搜索与 agenticweb_search内置工具共用 wire 名web_search因此请求路由保证二者只注入一个不会重复。client 侧Cherry 自带的抓取工具当路由为client时注入 agentic 的 WebFetchTool.tsexport function createWebFetchToolEntry(): ToolEntry { return { name: WEB_FETCH_TOOL_NAME, codec: makeEntitiesCodec({ contentKey: content }), namespace: web, defer: auto, tool: webFetchTool, applies: (scope) scope.webToolRoutes?.webFetch client } }模型先通过web_search获得候选 URL再调用web_fetch传入已知 URL 获取可读正文。其查找逻辑封装在共享的webLookup核心中Claude Code 的 MCP bridge 复用同一套实现保证两条运行路径行为一致。路由决策的单一事实来源值得开发者注意的是路由决策不在能力解析模块中发生。capabilities.ts 的注释明确说明scope.webToolRoutes由resolveWebToolRoutes/finalizeWebToolRoutes产出的最终计划是唯一事实来源同时约束 client 工具注入与 server feature 注入capabilities 模块只负责为已选定的 server 侧物化搜索插件配置。因此当你排查“为什么某个模型没有 URL 抓取”时应首先检查WebToolRoutes的决策结果与reasons字段而不是能力标志。这对用户意味着什么之前只开 URL Context、不开网页搜索的用户会发现那个按钮消失了但无需任何手动迁移现在打开 Web Search 开关后只要模型/provider 支持就能直接从提示词中读取 URL 并获取页面内容旧的per-assistant URL-context 设置会被自动丢弃不再单独存在。用户需要做什么按变更记录操作非常简单使用 Web Search 开关即可无需其他操作若希望 URL 抓取走 Cherry 自带工具而非 provider 原生能力需要配合 v2 的全局 Web Search 设置完成配置。配套的 v2 Web 工具变更建议一并阅读本次合并属于 v2「web-tools」重构链条的一部分发布说明中建议与以下两条变更合并呈现2026-05-08-web-search-main-side-tools.mdbreakingWeb Search 不再使用 renderer 侧服务与按助手选择 provider聊天开关改为优先使用模型原生 Web Search否则注入基于全局默认配置的关键词搜索与 URL 抓取工具黑名单订阅源与字符/token 单位选择被移除截断长度一律按 token 解释。2026-05-06-web-search-provider-capabilities.mdnoticeWeb Search 设置拆分为关键词搜索默认 provider与URL 内容抓取默认 provider两个选择器Jina Reader并入单一Jina条目并新增内置Fetchprovider 用于 URL 抓取。对用户而言这意味着在设置 → Web Search中分别配置好搜索与抓取的默认 provider含必要的 API Key / API Host即可让聊天中的 Web Search 开关同时驱动两种能力。若依赖 Jina应配置合并后的Jina条目。旧 v2 开发数据中引用已移除的jina-readerprovider id、旧的chat.web_search.default_provider键或扁平apiHost结构的覆盖不会被保留需要重新配置。开发者验证路径仓库为 Web 工具路由提供了较完整的测试覆盖可作为本次变更的回归参考路由决策矩阵provider.serverTools.test.ts覆盖 Gemini/Claude/OpenAI 等模型在开关与偏好组合下的路由结果provider 原生能力注入internalFeatures.test.ts、buildAgentParams.test.ts客户端工具行为WebSearchTool.test.ts、builtinTools.test.ts渲染层展示MessageWebSearch.test.tsx。小结本次「URL Context 合并进 Web Search 开关」是一次典型的入口收敛式变更UI 上少了一个按钮但底层WebToolRoutes的双能力独立路由模型让搜索与抓取仍能按模型/provider 自动选择最优执行侧。对最终用户记住“Web Search 开关 搜索 URL 抓取总闸”即可对开发者理解resolveWebToolRoutes的决策与reasons字段是排查一切 Web 工具相关问题的正确起点。【免费下载链接】cherry-studio Cherry Studio 是一款支持多个 LLM 提供商的桌面客户端项目地址: https://gitcode.com/CherryHQ/cherry-studio创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/9/19 23:27:51 · 阅读 1.2k Cherry Studio v2 变更解读：URL 上下文能力合并进 Web Search 开关
Cherry Studio v2 变更解读URL 上下文能力合并进 Web Search 开关【免费下载链接】cherry-studio Cherry Studio 是一款支持多个 LLM 提供商的桌面客户端项目地址: https://gitcode.com/CherryHQ/cherry-studio导读Cherry Studio v2 对聊天输入框的网页工具入口做了一次重要的收敛原来独立的「URL Context」按钮被移除从提示词中抓取 URL对应 Gemini 的 urlContext、Anthropic 的 web fetch以及客户端自带的web_fetch工具不再单独开关而是与网页搜索一起由同一个Web Search 开关统一控制。本文基于仓库中 2026-08-01-url-context-merged-into-web-search.md 的变更记录结合源码中 Web 工具路由WebToolRoutes、provider 原生插件与客户端内置工具的实现讲清这次合并的来龙去脉、底层路由决策逻辑以及用户和开发者分别需要做什么。变更概览独立 URL Context 按钮被移除变更前与变更后变更前聊天输入框里存在两个独立入口——「Web Search」开关与「URL Context」按钮二者可分别打开或关闭。用户可能只开启 URL Context 而不开启网页搜索。变更后独立的「URL Context」按钮消失。抓取 URL 的能力与网页搜索绑定打开 Web Search 开关即同时启用搜索与 URL 抓取关闭开关则两者同时关闭。被合并的三条 URL 抓取路径这次合并涉及的「URL 抓取」在 Cherry Studio 中有三种实现形态取决于模型/提供商的支持情况Gemini 原生 URL ContextGoogle 侧的 server-side 能力Anthropic web fetchAnthropic 提供的 provider 原生抓取能力客户端web_fetch工具Cherry Studio 自带的 agentic 工具由模型在对话中调用。它们对应源码中的常量WEB_SEARCH_TOOL_NAME web_search与WEB_FETCH_TOOL_NAME web_fetch见 builtinTools.ts以及 provider 侧的工具插件providerToolPlugin(urlContext)与providerToolPlugin(webSearch)。底层机制一个开关如何同时驱动搜索与抓取WebToolRoutes按能力独立路由源码 provider.ts 定义了 Web 工具的路由模型export type WebToolRoute client | server | none export interface WebToolRoutes { webSearch: WebToolRoute webFetch: WebToolRoute reasons?: PartialRecordwebSearch | webFetch, WebToolUnavailableReason }webSearch与webFetch两条能力各自独立路由但路由决策的入口条件都由同一个webSearchEnabled驱动。在 resolveWebToolRoutes 的实现中const clientSearchAvailable options.webSearchEnabled supportsClientTools options.clientSearchAvailable const clientFetchAvailable options.webSearchEnabled supportsClientTools options.clientFetchAvailable const serverSearchEligible options.webSearchEnabled provider ? isBuiltinWebSearchAvailable(model, provider, options.endpointType) : false const serverFetchEligible options.webSearchEnabled provider ? isBuiltinWebFetchAvailable(model, provider, options.endpointType) : false可见webSearchEnabled是搜索与抓取两条能力共同的“总闸”——这正是本次变更“一个开关同时控制两者”的代码级印证。开关关闭时客户端工具与 server 侧能力全部不可用开关打开时再按模型与 provider 的能力分别把webSearch、webFetch路由到serverprovider 原生、clientCherry 自带工具或none。路由的选择顺序对每条能力路由选择遵循「优先侧 回退侧」策略modelToolsPreferred决定优先哪一侧const selectRoute (clientAvailable: boolean, serverAvailable: boolean): WebToolRoute { if (options.modelToolsPreferred) { return serverAvailable ? server : clientAvailable ? client : none } // 否则优先 client再回退 server }这印证了变更记录中的说明“哪一侧执行provider 原生还是 Cherry 自己的工具仍由模型/提供商自动决定”。例如Gemini 模型在支持原生 Web 工具且无函数工具冲突时搜索与抓取走server普通模型则注入客户端的web_search/web_fetch工具由模型自主调用模型不支持或功能冲突如googleToolConflict、openaiMinimalConflict时对应能力路由为noneUI 依据WebToolUnavailableReason提示原因。server 侧provider 原生能力插件当路由决策为server时请求构建阶段会注入对应的 provider 原生插件providerUrlContext.tsexport const providerUrlContextFeature: RequestFeature { name: provider-url-context, applies: (scope) scope.webToolRoutes?.webFetch server, contributeModelAdapters: () [providerToolPlugin(urlContext)] }providerWebSearch.ts当webToolRoutes.webSearch server且存在 provider 搜索插件配置时注入providerToolPlugin(webSearch, ...)覆盖 Anthropicweb_search_20250305、Gemini grounding 等能力。其注释特别强调provider 原生搜索与 agenticweb_search内置工具共用 wire 名web_search因此请求路由保证二者只注入一个不会重复。client 侧Cherry 自带的抓取工具当路由为client时注入 agentic 的 WebFetchTool.tsexport function createWebFetchToolEntry(): ToolEntry { return { name: WEB_FETCH_TOOL_NAME, codec: makeEntitiesCodec({ contentKey: content }), namespace: web, defer: auto, tool: webFetchTool, applies: (scope) scope.webToolRoutes?.webFetch client } }模型先通过web_search获得候选 URL再调用web_fetch传入已知 URL 获取可读正文。其查找逻辑封装在共享的webLookup核心中Claude Code 的 MCP bridge 复用同一套实现保证两条运行路径行为一致。路由决策的单一事实来源值得开发者注意的是路由决策不在能力解析模块中发生。capabilities.ts 的注释明确说明scope.webToolRoutes由resolveWebToolRoutes/finalizeWebToolRoutes产出的最终计划是唯一事实来源同时约束 client 工具注入与 server feature 注入capabilities 模块只负责为已选定的 server 侧物化搜索插件配置。因此当你排查“为什么某个模型没有 URL 抓取”时应首先检查WebToolRoutes的决策结果与reasons字段而不是能力标志。这对用户意味着什么之前只开 URL Context、不开网页搜索的用户会发现那个按钮消失了但无需任何手动迁移现在打开 Web Search 开关后只要模型/provider 支持就能直接从提示词中读取 URL 并获取页面内容旧的per-assistant URL-context 设置会被自动丢弃不再单独存在。用户需要做什么按变更记录操作非常简单使用 Web Search 开关即可无需其他操作若希望 URL 抓取走 Cherry 自带工具而非 provider 原生能力需要配合 v2 的全局 Web Search 设置完成配置。配套的 v2 Web 工具变更建议一并阅读本次合并属于 v2「web-tools」重构链条的一部分发布说明中建议与以下两条变更合并呈现2026-05-08-web-search-main-side-tools.mdbreakingWeb Search 不再使用 renderer 侧服务与按助手选择 provider聊天开关改为优先使用模型原生 Web Search否则注入基于全局默认配置的关键词搜索与 URL 抓取工具黑名单订阅源与字符/token 单位选择被移除截断长度一律按 token 解释。2026-05-06-web-search-provider-capabilities.mdnoticeWeb Search 设置拆分为关键词搜索默认 provider与URL 内容抓取默认 provider两个选择器Jina Reader并入单一Jina条目并新增内置Fetchprovider 用于 URL 抓取。对用户而言这意味着在设置 → Web Search中分别配置好搜索与抓取的默认 provider含必要的 API Key / API Host即可让聊天中的 Web Search 开关同时驱动两种能力。若依赖 Jina应配置合并后的Jina条目。旧 v2 开发数据中引用已移除的jina-readerprovider id、旧的chat.web_search.default_provider键或扁平apiHost结构的覆盖不会被保留需要重新配置。开发者验证路径仓库为 Web 工具路由提供了较完整的测试覆盖可作为本次变更的回归参考路由决策矩阵provider.serverTools.test.ts覆盖 Gemini/Claude/OpenAI 等模型在开关与偏好组合下的路由结果provider 原生能力注入internalFeatures.test.ts、buildAgentParams.test.ts客户端工具行为WebSearchTool.test.ts、builtinTools.test.ts渲染层展示MessageWebSearch.test.tsx。小结本次「URL Context 合并进 Web Search 开关」是一次典型的入口收敛式变更UI 上少了一个按钮但底层WebToolRoutes的双能力独立路由模型让搜索与抓取仍能按模型/provider 自动选择最优执行侧。对最终用户记住“Web Search 开关 搜索 URL 抓取总闸”即可对开发者理解resolveWebToolRoutes的决策与reasons字段是排查一切 Web 工具相关问题的正确起点。【免费下载链接】cherry-studio Cherry Studio 是一款支持多个 LLM 提供商的桌面客户端项目地址: https://gitcode.com/CherryHQ/cherry-studio创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考