Qwen Web Search

Enable web search for Qwen requests and correctly handle search engines and citation results.

Qwen Web Search lets supported Qwen models access web information and return source citations when the response allows it. It is useful for weather, news, product updates, and other tasks that require recent information.

Qwen search can be provided through Chat extension fields, a built-in Responses tool, or a model-native search framework. Their enabling methods and citation structures differ, so choose the one listed for the current model.

The model must explicitly support the search endpoint

Do not infer from the Qwen family name that enable_search, Responses Web Search, or search engine selection is available. Confirm the model and protocol in the Model marketplace.

Enable search through Chat

Earlier documentation records enable_search as the primary Qwen Chat path:

curl 'https://api.agtcloud.cn/v1/chat/completions' \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer your-api-key' \
  --data '{
    "model": "MODEL_ID",
    "messages": [
      {
        "role": "user",
        "content": "What is the weather in Hangzhou today? Include the sources."
      }
    ],
    "enable_search": true
  }'

enable_search is a model- or channel-specific extension field, not a common parameter for every Chat model. If an SDK type does not expose the field, use a raw HTTP request or the SDK's extension parameter mechanism, and follow the actual model documentation.

Use built-in search through Responses

When the current model supports Responses Web Search, you can use the built-in tool structure:

curl 'https://api.agtcloud.cn/v1/responses' \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer your-api-key' \
  --data '{
    "model": "MODEL_ID",
    "tools": [
      {
        "type": "web_search_preview"
      }
    ],
    "input": "What is the weather in Hangzhou today? Include the sources."
  }'

A Responses result can contain web_search_call, a text Output Item, and url_citation. See the Responses Reference for the complete structure.

Choose a search engine or Provider

A native Qwen search framework might support multiple search Providers. This configuration belongs to a specific model, Agent framework, or channel capability and is not a unified AGTCloud Chat field.

When the current model documentation explicitly provides Provider options:

The default Provider reduces configuration and can preserve server-side fallback behavior.
A specified Provider is appropriate when the source scope, retrieval quality, or compliance boundary must be controlled.
Provider credentials and permissions should remain on the server and must not appear in the Prompt or browser code.
Whether the tool automatically switches when a Provider is unavailable depends on the current implementation; the client must still handle failures.

Do not present search engine names and default ordering from older documentation as a long-term platform commitment.

Read answers and citations

Different endpoints can return:

Endpoint	Answer	Citations
Chat extension	`choices[].message.content`	Annotations, links, or numbered sources provided by the response
Responses	Message Output Item	`url_citation` in `annotations`
Native search framework	Answer generated by the framework	Numbered source list or source objects returned by the Provider

If the answer text uses numbers such as [1] and [2], the client must also obtain the source URLs that correspond to those numbers. Do not display a number without a destination link.

{
  "answer": "Rain showers are expected in Hangzhou today.[1]",
  "sources": [
    {
      "index": 1,
      "title": "Source title",
      "url": "https://example.com/weather"
    }
  ]
}

This example shows data that an application can organize for presentation. It is not a fixed AGTCloud API response Schema.

Native search versus custom functions

Built-in Web Search is intended for public web information. To query enterprise search, orders, or a private knowledge base, use Tool Calling to call your own controlled service.

Text returned by a custom tool does not automatically gain trustworthy citations. The application should return source metadata as well and preserve the relationship between the answer and its sources in the final interface.

Failures and fallback behavior

Symptom	Action
`enable_search` is rejected	Confirm whether the model and channel support the extension field, or select a registered Responses endpoint
Search did not run	Check whether the question needs recent information and confirm that the enabling field reached the upstream service
A citation number has no source URL	Do not render it as a clickable citation; state that the response is missing complete source information
The Provider is unavailable	Switch or retry a limited number of times according to the current tool rules; do not loop indefinitely through Providers
Search results conflict	Show sources and dates instead of letting the model hide important differences

Pre-production checklist

The current model explicitly supports enable_search or the selected Responses tool.
The SDK does not silently drop model extension fields.
Chat, Responses, and native search results use separate parsers.
Citation numbers map to real titles and URLs.
Provider configuration and credentials never enter the client Prompt.
Empty results, search failures, and missing sources each have clear fallback behavior.

See the Chat Completions Reference for common Chat fields. If a request fails, see Errors and troubleshooting.