DashScope 官网与 Qwen Code 搜索路由：阿里云 Web Search 服务、API 差异和治理清单

从 DashScope 官网接入 Qwen Web Search 的团队，已经不能把搜索当成一个单独开关。Alibaba Cloud Model Studio 的联网搜索文档现在描述了三条 API 路径：OpenAI-compatible Responses API 通过 tools 启用搜索，Chat Completions 通过 enable_search 启用搜索，原生 DashScope 协议则提供更丰富的搜索来源返回控制。与此同时，Qwen Code 文档也把开发者引向 Alibaba Cloud Bailian WebSearch MCP server，用工具化方式做 retrieval。对 operators 来说，DashScope web search routing 现在关乎 protocol、citation behavior、search strategy、region 和 billing，而不只是让哪个 Qwen model 回答 prompt。

DashScope web search routing 改了什么

Model Studio 官方指南列出了三种启用联网搜索的方式。在 Responses API 路径中，应用把 web_search tool 加入请求，也可以同时加入 web_extractor 和 code_interpreter。这条路径目前适用于部分 Qwen Max、Plus、Flash 与 Qwen3.x snapshots。在 OpenAI-compatible Chat Completions 路径中，应用传入 enable_search: true；Python client 通过 extra_body 传递，Node.js 示例则作为顶层字段传递。在原生 DashScope 路径中，同样使用 enable_search，并配合 result_format="message"。

关键运营细节在于，这几条路径并不等价。Alibaba 的 capability table 显示，基础 web search 在 DashScope、Chat Completions 和 Responses 中都支持，但 source return、citation-style markers、early source return、domain restriction、freshness controls 和 vertical search 并不是统一暴露。DashScope 拥有最完整的控制面。Chat Completions 支持不少高级 search options，但 source-return fields 的呈现方式不同。Responses 更简单、更适合 agent-native 架构，但表格明确标注若干高级控制不支持。

同一页面还说明了 search strategy 的选择。turbo 是速度与质量的默认平衡。max 会扩大 retrieval，适合更完整的结果。agent 可在支持的 model families 上执行 multi-round search and synthesis，而 agent_max 为部分 Qwen3 Max thinking-mode workloads 增加 web extraction。这会把搜索从 boolean feature 变成 router 必须显式选择的 cost and latency tier。

为什么 DashScope web search routing 对 AI gateways 重要

对 model router 来说，web search 会改变 request 的形状。普通 chat request 主要是 model ID、messages 和 sampling controls。grounded-search request 还会加入 tool eligibility、retrieval budget、accepted domains、freshness expectations、citation needs，有时还会产生独立 tool billing line。如果 gateway 把所有 Qwen traffic 压平成一个 generic provider profile，它就无法判断应该选择 Responses、Chat Completions、原生 DashScope，还是 MCP。

Provider matrix 同样重要，因为 DashScope 按地域列出了支持 web search 的 models。中国内地、global 与 international 区域的 model 和 snapshot 覆盖并不完全一致。部分 Qwen3.7 与 Qwen3.6 models 在 web search 上是 Responses-only。部分较旧的 Qwen3 Max search modes 要求使用 agent 或 agent_max。Model Studio 托管的第三方 models，包括 DeepSeek 与 Kimi 条目，也有各自的 availability boundaries。在北京可用的 route，迁移到新加坡、弗吉尼亚或法兰克福时，可能失败，也可能静默丢失某个 capability。

因此 DashScope web search routing 是一个 policy problem。Router 需要知道 credential 属于哪个 endpoint、每个 model 支持哪个 API surface、某个 workload 允许哪种 search strategy，以及 downstream application 需要 source objects 还是只需要 grounded text。已经采用 DashScope OpenAI Responses API migration 的团队，不应默认所有搜索 workloads 都应该走 Responses。仍然基于旧版 Qwen DashScope API routing baseline 运行的团队，也应把 web-search capability metadata 加进同一份 provider configuration。

DashScope web search routing 应编码哪些决策

实用的 DashScope web search routing policy 应拆成四条 lanes。

1. Fast grounded answers。 当用户只需要当前答案、不需要 structured source objects 时，用最低延迟的 Chat Completions 或 DashScope 路径，并采用 turbo search。
2. Cited research output。 当应用必须接收 search sources、citation markers、early source return、domain filters 或 freshness controls 用于 audit 时，优先使用原生 DashScope。
3. Agent-native workflows。 当 agent stack 已依赖 responses.create、built-in tools 与 stateful response chaining 时，使用 Responses API，同时接受部分 search knobs 不可用。
4. Tool-hosted retrieval。 当 Qwen Code 或其他 MCP-capable agent 需要把 retrieval 当成显式 tool，而不是 model-side generation parameter 时，使用 Bailian WebSearch MCP server。

这些 lanes 应该在 gateway logs 中可见。只显示 qwen-plus 的 cost report 不够。Operators 需要知道请求是否使用了 enable_search、运行了哪个 search_strategy、是否请求 source return、哪个 region 处理了调用，以及 fallback 是否降级掉 search capability。

TheRouter 用户应关注或尝试什么

先为 DashScope search 增加 capability map。跟踪每个 model ID、region、endpoint、protocol surface、supported search strategies、source-return support，以及 model 是 pinned 还是 floating。对 production workloads，不要把 pinned model snapshots 与 floating search behavior 混在一起，除非你能接受 capability drift。

然后决定 fallback 的含义。如果 max 或 agent search path 失败，fallback 到 plain chat 可能会产出自信但没有 grounding 的答案。在许多 enterprise contexts 中，这比返回 controlled error 更糟。更安全的 fallback order 通常是 same-protocol same-region retry，然后 cheaper search strategy，然后拥有等价 search controls 的 alternate region，最后只有在 caller 明确允许时才进入 no-search model。

最后，把 search logs 接入与普通 model calls 相同的 cost and governance layer。Search-enabled requests 应携带 workload owner、allowed domains、freshness policy、source-return requirement、model ID、region、strategy 与 fallback outcome。TheRouter AI routing documentation 应把这些字段当作一等 request metadata，而不是临时 provider flags。

DashScope web search routing 检查清单

在广泛启用 DashScope web search routing 前，先问：

1. 哪些 workloads 需要 structured source objects，而不是 grounded prose？
2. 哪些 models 在所需 API surface 和 region 上支持 web search？
3. turbo、max、agent 和 agent_max 是否允许共用同一个 budget pool？
4. Fallback 能否保留 citation 与 source-return contract？
5. Logs 是否显示 endpoint、region、search strategy 和 source-return settings？
6. MCP search tools 是否与 model-side enable_search requests 分开治理？

DashScope web search routing 的价值在于把当前信息带入 Qwen workflows。风险则来自把它当作隐藏 provider flag。真正受益的团队，会把 search 当作独立 capability 来 route，并为它配置自己的 protocol choices、source guarantees 与 budget controls。