0 Fork 0

mirror of https://github.com/QwenLM/qwen-code.git synced 2026-11-11 12:12:19 -10:00

Files

T

qqqysandqqqys eb383fd3bb feat(core): enable the built-in web_search by default on ModelStudio Standard/Token Plan (#11348 )

* feat(core): enable the built-in web_search by default on ModelStudio Standard/Token Plan

web_search was opt-in and needed enabled=true, a search model selector, and a modelProviders entry with an envKey even though a ModelStudio user's primary entry already satisfies every condition. Declare a dashscope search backend on the Standard API Key and Token Plan presets and let the registry derive the search side channel from the primary model's entry when nothing is configured explicitly. Entries matching no preset are adopted when their host is a DashScope endpoint, covering hand-written entries and the workspace-specific Token Plan hosts; Coding Plan endpoints stay out until they are verified.

Explicit model/env configuration keeps working for any DashScope-compatible entry. Auto derivation fails silently so users on other providers see no notice, enabled=false (or ENABLE_WEB_SEARCH=false) turns the tool off, and bare/safe mode always does.

* fix(core): derive the env-only web_search backend from the resolved generation config

The auto path read the runtime model snapshot, which is empty when the tool registry is built — detectAndCaptureRuntimeModel() runs after createToolRegistry() — and which only carries apiKeyEnvKey when a modelProviders entry supplied it, so a pure OPENAI_BASE_URL / OPENAI_API_KEY setup never registered web_search. Read the resolved generation config instead, which the ModelsConfig constructor already has, and fall back to the auth type's default key variable when no entry named one.

Also correct the docs: the default Auto approval mode lets the classifier approve searches without prompting, and a Custom Provider entry on a DashScope host is adopted like a hand-written one.

* fix(core): keep a failed web_search backend derivation from breaking the tool registry

Reading the generation config to derive the search backend assumed a complete Config surface, so a test double that stubs getModelsConfig() without getGenerationConfig() threw while the registry was being built and took every other tool down with it. Derivation is opportunistic: an unexpected Config shape should cost web search alone, so catch and fall back to the silent no-backend result. Give the subagent-manager double the accessor it was missing.

* chore: re-trigger CI

The Qwen Code CI workflow was not scheduled for 0149317b95 (every other workflow on that commit ran); this empty commit re-runs it.

* fix(core): address web search review findings

---------

Co-authored-by: qqqys <[email protected]>

2026-09-09 04:08:29 +00:00

4.9 KiB

Raw Permalink Blame History

Qwen Code tools

Qwen Code includes built-in tools that the model uses to interact with your local environment, access information, and perform actions. These tools enhance the CLI's capabilities, enabling it to go beyond text generation and assist with a wide range of tasks.

Overview of Qwen Code tools

In the context of Qwen Code, tools are specific functions or modules that the model can request to be executed. For example, if you ask the model to "Summarize the contents of my_document.txt," it will likely identify the need to read that file and will request the execution of the read_file tool.

The core component (packages/core) manages these tools, presents their definitions (schemas) to the model, executes them when requested, and returns the results to the model for further processing into a user-facing response.

These tools provide the following capabilities:

Access local information: Tools allow the model to access your local file system, read file contents, list directories, etc.
Execute commands: With tools like run_shell_command, the model can run shell commands (with appropriate safety measures and user confirmation).
Interact with the web: Tools can fetch content from URLs.
Take actions: Tools can modify files, write new files, or perform other actions on your system (again, typically with safeguards).
Ground responses: By using tools to fetch real-time or specific local data, responses can be more accurate, relevant, and grounded in your actual context.

How to use Qwen Code tools

To use Qwen Code tools, provide a prompt to the CLI. The process works as follows:

You provide a prompt to the CLI.
The CLI sends the prompt to the core.
The core, along with your prompt and conversation history, sends a list of available tools and their descriptions/schemas to the configured model API.
The model analyzes your request. If it determines that a tool is needed, its response will include a request to execute a specific tool with certain parameters.
The core receives this tool request, validates it, and (often after user confirmation for sensitive operations) executes the tool.
The output from the tool is sent back to the model.
The model uses the tool's output to formulate its final answer, which is then sent back through the core to the CLI and displayed to you.

You will typically see messages in the CLI indicating when a tool is being called and whether it succeeded or failed.

Security and confirmation

Many tools, especially those that can modify your file system or execute commands (write_file, edit, run_shell_command), are designed with safety in mind. Qwen Code will typically:

Require confirmation: Prompt you before executing potentially sensitive operations, showing you what action is about to be taken.
Utilize sandboxing: All tools are subject to restrictions enforced by sandboxing (see Sandboxing in Qwen Code). This means that when operating in a sandbox, any tools (including MCP servers) you wish to use must be available inside the sandbox environment. For example, to run an MCP server through npx, the npx executable must be installed within the sandbox's Docker image or be available in the sandbox-exec environment.

It's important to always review confirmation prompts carefully before allowing a tool to proceed.

Learn more about Qwen Code's tools

Qwen Code's built-in tools can be broadly categorized as follows:

File System Tools: For interacting with files and directories (reading, writing, listing, searching, etc.).
Shell Tool (run_shell_command): For executing shell commands.
Monitor Tool (monitor): For running long-lived shell commands that stream output back as background task notifications.
Web Fetch Tool (web_fetch): For retrieving content from URLs.
Web Search Tool (web_search): For searching the web. Available at startup when a supported provider can back it.
Todo Write Tool (todo_write): An opt-in tool for creating and managing structured task lists during coding sessions.
Agent Tool (agent): For delegating complex tasks to specialized subagents.
Exit Plan Mode Tool (exit_plan_mode): For exiting plan mode and proceeding with implementation.

Additionally, these tools incorporate:

MCP servers: MCP servers act as a bridge between the model and your local environment or other services like APIs.
- MCP User Guide: Configure MCP servers and manage them from Qwen Code
- Web Search via MCP: Connect additional web search services (Bailian, Tavily, GLM) through MCP
Sandboxing: Sandboxing isolates the model and its changes from your environment to reduce potential risk.

4.9 KiB Raw Permalink Blame History