DashScope Web Search routing: Qwen API, Qwen Code MCP и governance в Alibaba Cloud

DashScope web search routing больше не выглядит как один переключатель для команд, которые строят agents на Qwen. Документация Alibaba Cloud Model Studio по web search описывает три API-пути: OpenAI-compatible Responses API с tools, Chat Completions с enable_search и native DashScope protocol с более богатыми настройками возврата источников. Отдельно документация Qwen Code направляет разработчиков к Alibaba Cloud Bailian WebSearch MCP server для retrieval в формате tool. Для operators решение о routing теперь касается protocol, citation behavior, search strategy, region и billing, а не только выбора Qwen model для ответа на prompt.

Что изменилось в DashScope web search routing

Официальный guide Model Studio показывает три способа включить connected search. В пути Responses API приложение добавляет tool web_search, при необходимости вместе с web_extractor и code_interpreter. Этот путь сейчас относится к выбранным Qwen Max, Plus, Flash и Qwen3.x snapshots. В OpenAI-compatible Chat Completions приложение передает enable_search: true; Python clients отправляют параметр через extra_body, а примеры Node.js — как поле верхнего уровня. В native DashScope path тот же переключатель enable_search используется вместе с result_format="message".

Важная операционная деталь: эти пути не равны. Capability table Alibaba говорит, что basic web search поддерживается в DashScope, Chat Completions и Responses, но source return, citation-style markers, early source return, domain restriction, freshness controls и vertical search раскрыты не одинаково. У DashScope самая богатая control surface. Chat Completions поддерживает многие advanced search options, но не возвращает source-return fields тем же образом. Responses проще и естественнее для agent-native архитектуры, но таблица помечает часть расширенных controls как unsupported.

Та же страница описывает выбор search strategy. turbo — стандартный баланс скорости и качества. max расширяет retrieval ради более полных результатов. agent может выполнять multi-round search and synthesis на поддерживаемых model families, а agent_max добавляет web extraction для отдельных Qwen3 Max thinking-mode workloads. Поэтому search становится не boolean feature, а cost and latency tier, который router должен выбирать явно.

Почему 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, native DashScope или MCP.

Provider matrix тоже критичен, потому что DashScope перечисляет web-search-capable models по географии. Mainland China, global и international sections имеют разное покрытие models и snapshots. Некоторые Qwen3.7 и Qwen3.6 models поддерживают web search только через Responses. Некоторые старые Qwen3 Max search modes требуют agent или agent_max. Third-party models, размещенные в Model Studio, включая DeepSeek и Kimi entries, имеют собственные availability boundaries. Route, который работает в Beijing, может сломаться или тихо потерять feature при переносе в Singapore, Virginia или Frankfurt.

Из-за этого DashScope web search routing становится policy problem. Router должен знать, к какому endpoint относится credential, какую API surface поддерживает каждый model, какая search strategy разрешена для workload, и нужны ли downstream application source objects или достаточно grounded text. Команды, уже прошедшие DashScope OpenAI Responses API migration, не должны считать, что каждый search workload автоматически идет в 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. Используйте самый низколатентный поддерживаемый путь Chat Completions или DashScope с turbo search, когда пользователю нужен только актуальный ответ без structured source objects.
2. Cited research output. Предпочитайте native DashScope, когда application обязано получить search sources, citation markers, early source return, domain filters или freshness controls для audit.
3. Agent-native workflows. Используйте Responses API, когда остальной agent stack уже зависит от responses.create, built-in tools и stateful response chaining, принимая, что часть search knobs недоступна.
4. Tool-hosted retrieval. Используйте Bailian WebSearch MCP server, когда Qwen Code или другой MCP-capable agent нуждается в retrieval как явном tool, а не как model-side generation parameter.

Эти lanes должны быть видны в gateway logs. Cost report, где написано только qwen-plus, недостаточен. Operators должны видеть, использовал ли request enable_search, какой search_strategy был выполнен, запрашивался ли source return, какой region обработал call и не потерял ли fallback search capability.

Что пользователям TheRouter стоит проверить или попробовать

Начните с capability map для DashScope search. Отслеживайте каждый model ID, region, endpoint, protocol surface, supported search strategies, source-return support, а также pinned или floating статус model. Для production workloads не смешивайте pinned model snapshots с floating search behavior, если вы не готовы к silent capability drift.

Затем определите, что означает fallback. Если путь max или agent search падает, fallback к plain chat может дать уверенный, но ungrounded ответ. Во многих enterprise contexts это хуже, чем controlled error. Более безопасный fallback order обычно такой: same-protocol same-region retry, затем более дешевая search strategy, затем alternate region с эквивалентными search controls, и только потом no-search model, если caller явно разрешил это.

Наконец, отправляйте search logs в тот же cost and governance layer, что и обычные model calls. Search-enabled requests должны нести workload owner, allowed domains, freshness policy, source-return requirement, model ID, region, strategy и fallback outcome. TheRouter AI routing documentation — правильное место, чтобы считать эти поля first-class request metadata, а не случайными provider flags.

Checklist для DashScope web search routing

Перед широким включением DashScope web search routing спросите:

1. Каким workloads нужны structured source objects, а не только grounded prose?
2. Какие models поддерживают web search на нужной API surface и в нужном region?
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. Больше всего выиграют команды, которые route search как отдельную capability со своими protocol choices, source guarantees и budget controls.