
使用 Qwen-Agent 构建 Qwen3 智能体安装、模型接入、工具调用与流式应用实战【免费下载链接】Qwen1.5Qwen3 is the large language model series developed by Qwen team, Alibaba Cloud.项目地址: https://gitcode.com/GitHub_Trending/qw/Qwen1.5Qwen-Agent 是基于 Qwen 系列模型的指令跟随、工具使用、规划与记忆能力构建 LLM 应用程序的开发框架本指南以 Qwen3 为核心演示如何用几行代码快速搭建一个具备工具调用能力的智能体Agent。读完本文你将掌握 Qwen-Agent 的安装方式、三种大模型后端接入方法vLLM/SGLang、DashScope 原生与 OpenAI 兼容模式、MCP 工具与内置工具的声明方式以及如何通过Assistant组件实现流式对话与函数调用解析。Qwen-Agent 是什么面向 Qwen 的 LLM 应用开发框架Qwen-Agent 是官方提供的 Agent 开发框架它建立在 Qwen 的四大能力之上指令跟随instruction following、工具使用tool usage、规划planning与记忆memory。在 Qwen3 时代这套框架尤其重要——Qwen3 在工具调用tool calling能力上表现出色而 Qwen-Agent 在内部封装了工具调用模板tool-calling templates和工具调用解析器tool-calling parsers开发者无需手工拼接复杂的提示词即可让模型理解工具签名、输出结构化的函数调用大大降低了编码复杂度。在当前仓库中Qwen-Agent 教程被收录于 docs/source/framework/qwen_agent.rst与 函数调用完整指南 同属 Framework 板块。README 中也将 Qwen-Agent 定位为官方推荐的 Tool Use 方案它提供了对这些 API 的封装以支持工具使用或函数调用并附带 MCP 支持见 README.md。也就是说无论你是想把 Qwen3 接到企业内部 API、网页抓取、代码执行还是接入任意 MCP 服务Qwen-Agent 都能提供一个开箱即用的抽象层。安装 Qwen-Agent核心包与可选扩展从 PyPI 安装稳定版本即可开始pip install -U qwen-agent[gui,rag,code_interpreter,mcp] # 或者使用最小依赖安装 # pip install -U qwen-agent方括号内是可选依赖extra按需取用可选依赖用途[gui]基于 Gradio 的图形界面GUI支持[rag]检索增强生成RAG支持[code_interpreter]代码解释器Code Interpreter支持[mcp]模型上下文协议Model Context Protocol支持其中 MCP 支持与本文的工具声明方式直接相关——后文的工具示例正是通过 MCP 配置来声明外部工具的。如果你只想跑通最小流程pip install -U qwen-agent即可若需要图形界面、检索或代码执行能力再按需追加对应 extra。接入大模型后端三种配置方式与思考模式控制Qwen-Agent 通过llm_cfg字典来描述要使用的大模型。它支持三种典型的接入方式分别对应不同的部署场景。以下代码定义了 LLM三种方式任选其一代码来自 qwen_agent.rstimport os from qwen_agent.agents import Assistant # 定义 LLM llm_cfg { # 方式一接入由 vLLM/SGLang 启动的、兼容 OpenAI API 的自建服务端点 model: Qwen/Qwen3-32B, model_server: http://localhost:8000/v1, # api_base api_key: EMPTY, # generate_cfg: { # # 使用 vLLM/SGLang 的 OAI API 时通过如下方式传入是否启用思考模式的参数 # extra_body: { # chat_template_kwargs: {enable_thinking: False} # }, # # # 注意 # # 当响应内容是 thinkthis is the thought/thinkthis is the answer 这种 # # 思考内容内嵌在 content 中的形式时需要开启该参数 # # 当响应已将推理内容与正文分离为 reasoning_content 和 content 两个字段时无需开启。 # # 该参数会影响工具调用的解析策略。 # # thought_in_content: True, # }, } # llm_cfg { # # 方式二使用 DashScope 提供的模型服务 # model: qwen3-235b-a22b, # model_type: qwen_dashscope, # # # generate_cfg: { # # # 使用 DashScope API 时通过如下方式传入是否启用思考模式的参数 # # enable_thinking: False, # # }, # } # llm_cfg { # # 方式三使用 DashScope 提供的、兼容 OpenAI 的模型服务 # model: qwen3-235b-a22b, # model_server: https://dashscope.aliyuncs.com/compatible-mode/v1, # api_key: os.getenv(DASHSCOPE_API_KEY), # # # generate_cfg: { # # # 使用 DashScope OAI API 时通过如下方式传入是否启用思考模式的参数 # # extra_body: { # # enable_thinking: False # # }, # # }, # }三种方式的关键差异如下方式一vLLM/SGLang OpenAI 兼容端点model_server填写自建推理服务的api_base即http://host:port/v1api_key在服务未做鉴权时可随意填写如EMPTY。本地部署 Qwen3 的具体启动命令可参考仓库中的 vLLM 部署指南 与 SGLang 部署指南。方式二DashScope 原生服务通过model_type: qwen_dashscope指定走 DashScope 原生协议模型名使用 DashScope 侧的名称如qwen3-235b-a22b。方式三DashScope OpenAI 兼容模式model_server指向https://dashscope.aliyuncs.com/compatible-mode/v1api_key从环境变量DASHSCOPE_API_KEY读取避免把密钥明文写死在代码里。思考模式的开关与工具解析策略Qwen3 是混合思考模型hybrid thinking model同一模型可在思考模式与非思考模式间切换。在上述配置的generate_cfg中Qwen-Agent 针对不同 API 提供了不同的开关方式vLLM/SGLang OAI API通过extra_body.chat_template_kwargs.enable_thinking控制默认开启思考DashScope 原生 API通过generate_cfg.enable_thinking直接控制DashScope OAI API通过extra_body.enable_thinking控制。特别值得关注的是thought_in_content参数方式一中的注释部分当模型响应把思考内容与正文混合在同一个content字段里形如thinkthis is the thought/thinkthis is the answer时需要开启该参数而当服务端已经将推理内容拆分为独立的reasoning_content字段与content字段时则无需开启。这个参数直接影响工具调用的解析策略——Qwen-Agent 需要知道思考内容以何种形态返回才能准确地从生成结果中提取出tool_call结构。关于思考模式与think/think标记的底层格式可进一步阅读 核心概念文档 中的 Thinking 一节。为智能体定义工具MCP、内置工具与自定义工具要定义智能体可用的工具官方文档给出了三条路径使用 MCP 配置文件、使用 Qwen-Agent 集成的内置工具或自行集成其他工具。以下示例同时展示了前两种# 定义工具 tools [ {mcpServers: { # 可以在此指定 MCP 配置 time: { command: uvx, args: [mcp-server-time, --local-timezoneAsia/Shanghai] }, fetch: { command: uvx, args: [mcp-server-fetch] } } }, code_interpreter, # 内置工具 ]MCP 服务器声明mcpServers字典遵循 MCPModel Context Protocol的客户端配置规范每个 key 是一个 MCP 服务器的名字command与args指定如何启动该服务器。上例用uvx拉起mcp-server-time获取时间指定上海时区和mcp-server-fetch抓取网页内容。只要你的机器上有对应的 MCP 服务器包Qwen-Agent 就会自动启动并与之通信。内置工具直接以字符串形式传入工具名例如code_interpreter代表代码解释器安装时需带上[code_interpreter]可选依赖。Qwen-Agent 会替你把内置工具转换为模型可识别的函数签名。自定义工具你完全可以在 Python 中自行编写函数并通过function_list传入让模型按需调用详见下文函数调用协议一节中关于functions的说明。Qwen3 对 MCP 的支持在 概念文档 中被特别强调Qwen3 模型针对编码与智能体能力进行了优化同时加强了对模型上下文协议MCP的支持因此通过 MCP 接入外部工具是当前最贴合官方推荐的做法。组装 Assistant 并开始流式交互把前面定义好的llm_cfg与tools交给Assistant组件一个具备工具调用能力的智能体就建成了# 定义智能体 bot Assistant(llmllm_cfg, function_listtools) # 流式生成 messages [{role: user, content: https://qwenlm.github.io/blog/ Introduce the latest developments of Qwen}] for responses in bot.run(messagesmessages): pass print(responses)Assistant是 Qwen-Agent 提供的高级组件把 LLM 与工具列表打包成一个能自主规划、调用工具、汇总结果的智能体实例。llm参数接收上面的llm_cfgfunction_list接收工具定义列表。bot.run(messagesmessages)返回一个生成器逐轮产出响应responses是消息列表这里的循环逐帧消费流式结果结束后打印最终响应。示例中用户直接丢了一个 URL 并让模型介绍 Qwen 的最新进展——模型会自主决定调用fetch工具抓取页面再基于抓取结果作答这正是工具使用 规划能力的直观体现。Assistant会自动处理多轮工具调用模型请求调用工具 → 智能体执行工具并把结果回填 → 模型基于工具结果生成最终答案整个过程对使用者透明。源码级解析Qwen-Agent 如何封装工具调用为什么 Qwen-Agent 能把工具调用变得如此简单仓库中的 函数调用完整指南 给出了权威解释Qwen-Agent 包含了 Qwen3 函数调用的 canonical规范实现它通过模板把函数调用能力透明地提供给 OpenAI 兼容 API。具体来说模板封装Qwen3 采用 Hermes 风格的工具调用模板。模型在 system 消息中看到tools包裹的函数签名JSON Schema并以tool_callXML 标签输出结构化调用。这一格式的完整定义可见 概念文档 的 Tool Calling 一节其 Jinja 模板实现则保存在 qwen3_nonthinking.jinja 中——从源码结构看Qwen-Agent 的封装正是基于此类模板把拼模板的脏活全部消化在框架内部。快捷获取模型若你的 API 端点本身不支持函数调用Qwen-Agent 提供get_chat_model快捷函数得到一个具备函数调用能力的模型推理封装from qwen_agent.llm import get_chat_model llm get_chat_model({ model: Qwen/Qwen3-8B, model_server: http://localhost:8000/v1, api_key: EMPTY, generate_cfg: { extra_body: { chat_template_kwargs: {enable_thinking: False} # 默认 True } } })工具描述格式Qwen-Agent 当前以functions而非 OpenAI 风格的tools为主。两者结构等价区别仅在于外层包装tools中的每个元素是{type: function, function: {...}}而 Qwen-Agent 直接使用内层的function字段。从tools转换只需一行functions [tool[function] for tool in TOOLS]结构化结果解析调用llm.chat(messagesmessages, functionsfunctions)同样是生成器后模型生成的工具调用会被解析进消息的function_call字段包含name要调用的函数名与argumentsJSON 格式字符串的参数。在思考模式下消息还会额外携带reasoning_content字段保存推理过程之后才是function_call。开发者只需遍历响应、检查function_call、执行真实函数、再把结果以{role: function, name: ..., content: ...}回填给模型即可完成一轮工具闭环。深入函数调用协议并行调用与多步调用理解了封装之后还需要了解协议本身的几个关键约束详见 概念文档 与 函数调用指南并行工具调用Qwen3 支持一次生成多个tool_call即模型可同时发起多个工具调用例如同时查询今天与明天的气温框架与模板均原生支持并行解析。多轮 / 多步工具调用Qwen3 支持多步工具调用——先调用一个工具、根据结果再决定下一步动作。工具结果在模板中以特殊用户消息tool_response包裹模型据此继续规划。需要注意的是思考块think在多步工具调用中应保留在相应轮次而非只出现在最终轮。参数格式生成的工具调用中arguments应为对象类型而非字符串类型function_call.arguments是 JSON 字符串需要json.loads后再传给真实函数。思考模型的注意事项对于 Qwen3 这类推理模型不推荐使用基于停用词stopwords的工具调用模板如 ReAct 风格因为模型可能在思考部分输出这些停用词导致工具调用解析出现意外行为——这也是 Qwen-Agent 采用结构化的tool_call模板而非 ReAct 方案的原因。容错意识即便提示词与模板正确模型生成也不保证始终严格遵循协议。生产代码中应做好解析失败工具调用格式错误的兜底与重试策略若特定场景下生成质量不达预期可微调模板增加约束最终方案则是用自有数据微调模型。小结通过本指南你已走通安装 Qwen-Agent → 接入大模型 → 声明工具 → 构建 Assistant → 流式交互的完整链路三种 LLM 接入方式覆盖了自建 vLLM/SGLang 服务与云上 DashScope 服务MCP 配置与内置工具让外部能力接入变得声明式而框架内部封装的 Hermes 风格工具调用模板与解析器则让你无需关心tool_call的拼接细节。想要进一步深入建议继续阅读仓库中的 函数调用完整指南含逐步调试的完整示例、核心概念文档模板与控制 token 底层原理以及 Qwen-Agent 官方仓库 中更详细的示例与 MCP cookbook。【免费下载链接】Qwen1.5Qwen3 is the large language model series developed by Qwen team, Alibaba Cloud.项目地址: https://gitcode.com/GitHub_Trending/qw/Qwen1.5创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考