Qwen-Agent's Python executor is not sandboxed, and the note sits in the news section

The Python executor is not sandboxed, and the note is a news item

One sentence in this repository matters more than the rest of the feature list, and it is easy to miss because of where it sits. It appears in the news section, attached to the September 2024 entry about a maths demo, and it says the python executor is not sandboxed and is intended for local testing only, not for production use. The note is attached to the Qwen2.5-Math Tool-Integrated Reasoning demo, so check how any code execution you enable is isolated before exposing an agent to untrusted input.

For QwQ and Qwen3 you are told to disable the server's tool parser

The model service section contains an instruction that will save you a long debugging session. If you run your own OpenAI-compatible service with vLLM, the project recommends, for QwQ and Qwen3, that you do not add the automatic tool choice and hermes tool call parser parameters, because Qwen-Agent parses the tool outputs from vLLM on its own. For Qwen3-Coder the recommendation is the opposite: enable both, use vLLM's built-in tool parsing, and combine it with the use_raw_api parameter. The consequence is that the server configuration is model-specific, and a vLLM command line copied from a tutorial is wrong for half the model families here. Configure the server per model and check it with the matching example.

A tool is a class, a description string and a parameters schema

The customisation story is three base classes and a decorator. LLMs inherit from class BaseChatModel and come with function calling, tools inherit from class BaseTool, and higher-level agents derive from class Agent, with class Assistant provided as a built-in you can also subclass. To add a tool you decorate a class with register_tool and give it a description that tells the agent what the tool does and parameters that tell it what the input is. The mechanism is worth understanding because of what it implies. The description string is the only thing the model has, so it is prompt surface rather than documentation, and a vague description produces a model that calls the tool wrongly. And the tools on an agent are a permission surface: the set of tools on an agent is the set of things it can do to your systems.

The four extras are capability switches, and one of them is the dangerous one

The stable install is one line, and the line is the interesting part:

pip install -U "qwen-agent[gui,rag,code_interpreter,mcp]"

The file then documents what each extra in the double brackets buys: gui for the Gradio-based interface, rag for retrieval support, code_interpreter for the code interpreter, and mcp for Model Context Protocol, with a plain qwen-agent install for the minimal requirements. So the minimal package and the full one are not the same product at different sizes, they are different capabilities. That makes the extras a per-environment decision rather than a convenience, since a development machine and a deployed service should not necessarily have the same set. The GUI extra also carries a floor of its own, because the file notes the Gradio upgrade requires Python 3.10 or higher.

A zero-series version, and a 2026 example the packaged release predates

The version story is the maintenance story here. The published releases are v0.0.24, v0.0.25 and v0.0.26, all three of them in May 2025, with 0.0.26 on 2025-05-29, and the last push recorded for the repository is 2026-03-04. The news section, meanwhile, describes work from 2026, including an open-sourced Qwen3.5 with a usage example added in February 2026 and a documentation site and evaluation benchmark added in January 2026. So a newcomer following the documentation will be pointed at a demo that their installed package predates by about nine months, and the package version they can install from an index is a zero-series number, even though the README calls the PyPI package the stable version. Installing from a source checkout is a different proposition from installing the package, and the file offers both, with the source route being a clone and an editable install.

pip install gives you the framework and not the server

The packaging file has one line that explains the shape of the project. Packages are found with find_packages, excluding examples and qwen_server and their subpackages. So neither the example applications nor the server are importable from an installed qwen-agent, even though both are in the repository, along with a run_server.py at the root and a browser extension directory with its own English and Chinese documentation. The consequence is that the framework is a library you can install, and the server and the browser assistant are checkout-only components. That is a defensible split for a project whose examples are meant to be read, but it means the deployment story for anything that runs as a service is a repository clone rather than a dependency. The version string, incidentally, is read out of the package's own __init__ module with a regular expression, so the single source of version truth lives in the code rather than in the packaging file.

The examples are indexed by model, and that is the shape of the API

The examples directory is the real reference, and its filenames tell you how the framework is expected to be used: one agent per model, with files for Qwen3.5, Qwen3, Qwen3-Coder, Qwen3-VL and QwQ, plus others for an omni model, audio, retrieval, a model context protocol agent backed by SQLite, a weather bot, a custom tool, and group chat. There are also two function-calling examples, one of them explicitly about calling functions in parallel, several cookbooks as notebooks covering database manipulation, a mind map, a drive guide and thinking with images, and quick chats against an OpenAI-compatible endpoint. If you are starting now, the example for the model you actually run is the file to read first, because the differences between those agents are the API surface rather than incidental detail. Alongside them the repository holds the browser extension, the DeepPlanning benchmark, the documentation directory and the tests.

Editorial conclusion

Qwen-Agent fits a team standardising on Qwen models that wants the tool-calling plumbing in one place and that will read the examples for the model it actually runs. Be careful with anything reachable by untrusted input, because the README states the python executor in its Qwen2.5-Math demo is not sandboxed and is intended for local testing only. Before you install, choose the extras per environment, since the minimal package and the full one differ by whether the agent can execute code at all. Then configure the model server for the model you picked: for QwQ and Qwen3 the project tells you to leave automatic tool choice and the hermes parser off because Qwen-Agent parses the output itself, while for Qwen3-Coder it tells you to enable both and pass use_raw_api. And pin with care, because the newest package release is 0.0.26 from 2025-05-29 while the last push recorded was 2026-03-04.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. QwenLM/Qwen-Agent on GitHub
4. README
5. Releases