千问团队刚放出了 Qwen3.7-Plus——官方称之为"目前最强的多模态智能体模型"。关键词不是"多模态"，而是"智能体基座"。这意味着它不是又一个能看图说话的模型，而是把视觉理解和语言推理焊进同一套行动回路里，让模型既能读屏幕、看图表，又能写代码、调工具、跑工作流。
从文本强手到多模态智能体
Qwen3.7 的文本能力已经站稳了：编码、数学、长文推理都在第一梯队。但纯文本模型有一个结构性短板——它看不到用户正在面对的东西。你把一张错误截图丢给它，它只能靠你用文字描述；你把一份 PDF 报表贴进去，它得先 OCR 再分析，链路长、信息损。
Qwen3.7-Plus 的做法是：在 Qwen3.7 的文本底座上，把视觉-语言能力做一体化升级，同时完整保留编码、工具调用、生产力工作流的智能体能力。换句话说，"眼睛"不是外挂的插件，而是和"大脑""手脚"同一条神经总线。
多模态交互混合：不是拼接，是融合
公告里提到的"多模态交互混合"是核心差异点。传统做法是先跑视觉模型提取特征，再丢给语言模型生成回答——两阶段 pipeline，中间有信息瓶颈。Qwen3.7-Plus 把视觉理解和语言推理放在同一个基座里联合训练，模型在生成下一步动作时，可以直接引用它"看到"的内容，而不是依赖中间摘要。
这对智能体场景尤其关键。一个能操控浏览器的 agent，需要同时理解页面布局、读取图表数值、判断按钮位置，然后决定点击哪里或输入什么。如果视觉和语言是分离管线，延迟和误差都会叠加；融合基座则可以在同一轮推理中完成"看-想-做"。
实际上手：用 DashScope API 调用 Qwen3.7-Plus
下面给出一个可直接运行的 Python 示例，通过阿里 DashScope OpenAI-compatible API 向 Qwen3.7-Plus 发送一张图片加文本的混合请求，并启用工具调用能力。
先安装依赖：
pip install openai
然后运行以下脚本（将 YOUR_DASHSCOPE_API_KEY 替换为你自己的密钥，图片路径替换为实际文件）：
import base64
from openai import OpenAI
# DashScope 的 OpenAI 兼容接口
client = OpenAI(
api_key="YOUR_DASHSCOPE_API_KEY",
base_url="https://dashscope.aliyuncs.com/compatible-mode/v1",
)
def encode_image(image_path: str) -> str:
"""将本地图片编码为 base64，用于多模态请求"""
with open(image_path, "rb") as f:
return base64.b64encode(f.read()).decode("utf-8")
# 构造多模态消息：图片 + 文本指令
image_b64 = encode_image("screenshot.png") # 替换为你的图片路径
messages = [
{
"role": "user",
"content": [
{
"type": "image_url",
"image_url": {"url": f"data:image/png;base64,{image_b64}"},
},
{
"type": "text",
"text": (
"请分析这张截图中的错误信息，"
"然后给出修复建议。如果需要执行命令，"
"请直接输出可运行的 shell 命令。"
),
},
],
}
]
# 调用 Qwen3.7-Plus（模型名以官方文档为准，发布初期可能为 qwen3.7-plus）
response = client.chat.completions.create(
model="qwen3.7-plus",
messages=messages,
temperature=0.3,
)
print(response.choices[0].message.content)
如果你想让模型主动调用工具（比如查日志、跑脚本），可以加上 tools 定义：
tools = [
{
"type": "function",
"function": {
"name": "run_shell_command",
"description": "在终端执行一条 shell 命令并返回输出",
"parameters": {
"type": "object",
"properties": {
"command": {"type": "string", "description": "要执行的 shell 命令"},
},
"required": ["command"],
},
},
}
]
response = client.chat.completions.create(
model="qwen3.7-plus",
messages=messages,
tools=tools,
tool_choice="auto",
)
msg = response.choices[0].message
# 如果模型决定调用工具，解析工具调用内容
if msg.tool_calls:
for tc in msg.tool_calls:
print(f"工具调用: {tc.function.name}({tc.function.arguments})")
else:
print(msg.content)
这段代码展示了 Qwen3.7-Plus 的两个核心能力在同一请求中联动：视觉理解（读截图）+ 工具调用（决定执行什么命令）。这正是"智能体基座"的含义——模型不是被动回答问题，而是根据所见内容主动规划动作。
什么时候值得切换到 Qwen3.7-Plus
几个判断维度：
- 你的 agent 需要看东西：浏览器自动化、UI 测试、图表分析、文档审阅——这些场景视觉是刚需，Qwen3.7-Plus 的融合基座比"视觉模型 + 文本模型"拼接方案更稳。
- 你已经在用 Qwen3.7 的文本能力：升级路径平滑，API 兼容，编码和工具调用能力不降级，只是多了眼睛。
- 纯文本场景不需要急着换：如果你的工作流只涉及文本生成和代码补全，Qwen3.7 本身已经够强，Plus 的额外视觉能力不会带来文本质量的跳升，反而推理成本更高。
需要注意的点：
- 多模态请求的 token 消耗高于纯文本，图片会按分辨率折算为额外 token，成本和延迟都会上升，建议在确实需要视觉输入时才附带图片。
- 模型名和具体参数（如是否支持 streaming、最大图片数）以 DashScope 官方文档为准，发布初期可能有调整。
- 工具调用的可靠性依赖 prompt 设计——给模型一个清晰的角色定义和动作边界，比放任它自由发挥效果好得多。
一句话总结：Qwen3.7-Plus 不是"Qwen3.7 加了个视觉插件"，而是把视觉理解焊进了智能体的行动回路。如果你的 agent 需要同时看和做，这是一个值得认真评估的基座选择。