Qwen3.8-Flash 来了,100万上下文、Agent、Coding 都加强了

简介: 8月26日,通义千问发布Qwen3.8-Flash-Next:125B参数、每Token仅激活6B,原生支持26万Token、可扩展至100万上下文;Coding、Agent与工具调用能力显著增强,面向真实软件工程任务,推动大模型从“回答问题”迈向“完成工作”。

8 月 26 日,Qwen 团队发布了 Qwen3.8-Flash-Next。

这次更新有几个信息很抓眼球:

125B 主模型参数,每个 Token 只激活约 6B;原生支持 26 万 Token 上下文,可扩展到 100 万;Coding、Agent、工具调用能力继续增强。

同时,Qwen Cloud 上的生产版本命名为 Qwen3.8-Flash,默认就是 100 万 Token 上下文。

如果只是日常聊天,这些数字可能没那么有感觉。

但如果你是开发、测试、运维或者其他 IT 从业者,这次更新其实很值得看。

因为从 Qwen3.8-Flash 身上能看到一个越来越明显的趋势:

大模型正在从“回答问题”,继续往“完成工作”走。

而软件研发,恰好是这一轮变化最明显的场景之一。

Qwen3.8-Flash模型体验地址👇

技术报告:https://github.com/QwenLM/Qwen3.8-Flash-Next/blob/main/tech_report.pdf
技术博客:https://qwen.ai/blog?id=qwen3.8-flash-next
Hugging Face:https://huggingface.co/Qwen/Qwen3.8-Flash-Next?spm=a2ty_o06.30285417.0.0.1d73c921FsyOPe&file=Qwen3.8-Flash-Next
ModelScope:https://modelscope.cn/models/Qwen/Qwen3.8-Flash-Next?spm=a2ty_o06.30285417.0.0.1d73c921XAP2dV&file=Qwen3.8-Flash-Next
千问AI平台:https://www.qianwenai.com/models/qwen3.8-flash
01 先说最直观的:上下文来到 100 万 Token
Qwen3.8-Flash-Next 原生上下文长度达到 262,144 Token,并且可以扩展到 1,000,000 Token;Qwen Cloud 提供的 Qwen3.8-Flash 则默认支持 1M 上下文。

100 万上下文到底意味着什么?

以前使用 AI Coding,很多人的操作是:

复制一段代码 → 丢给模型 → 问它哪里有问题。

或者测试同学:

复制一段需求 → 让模型生成测试用例。

这当然能用,但跟真实的软件工程还有很大距离。

因为真正做一个项目,模型要理解的东西远不止一段代码。

比如一个支付需求改动,测试人员可能同时要看:

PRD 和需求变更
接口文档
前后端代码
数据库表结构
上下游服务
历史测试用例
历史 Bug
日志
Git Commit / Diff
监控信息
过去最大的一个问题就是:

这些东西根本塞不进去。

上下文越来越长之后,AI 才有机会从“看懂一个文件”,逐渐走向“理解一个项目”。

当然,100 万 Token 不代表把整个公司代码库一股脑塞进去就完事了。

真正落地依然涉及代码检索、知识库、上下文管理、权限控制等工程问题。

但模型能够处理的上下文上限提高,确实给复杂研发任务提供了更大的空间。

02 Coding 能力,已经不是“帮你补几行代码”了
这次 Qwen 官方给出的测试成绩里,Coding 是一个明显重点。

例如:

SWE-bench Pro:62.5

SWE-bench Multilingual:81.0

DeepSWE 1.1:58.7

这些 Benchmark 和以前单纯考“写一道算法题”不太一样,更偏向真实软件工程:理解代码仓库、定位问题、修改代码、解决 Issue。([Qwen][1])

这也是最近 AI Coding 最明显的一次变化。

前两年大家谈 AI 编程,更多想到的是:

“帮我生成一个 Java 方法。”

现在已经越来越像:

“你自己去代码仓库里找问题,然后把它解决掉。”

这两件事不是一个量级。

现在 Codex、Claude Code、Qwen Code 这类 Coding Agent 的工作模式,越来越接近:

读取代码 → 搜索项目 → 分析依赖 → 修改文件 → 执行命令 → 跑测试 → 根据结果继续调整。

甚至这次 Qwen 官方已经专门给出了接入 Claude Code 和 Codex 的方式,Qwen API 同时兼容 Anthropic 协议和 OpenAI Responses 协议。

所以,如果现在对 AI Coding 的理解还停留在:

“代码补全工具”

其实已经有些滞后了。

03 Agent 能力,也在明显加强

另外一个值得关注的关键词就是:

Agent。

这次 Qwen3.8-Flash-Next 在官方公布的 Toolathlon Verified 工具调用评测中拿到了 73.5,长流程办公任务 CoWorkBench 为 73.9。

分数本身不是最重要的。

重要的是现在厂商越来越重视一件事:

模型能不能自己调用工具完成任务?
因为聊天模型和 Agent 最大的区别之一就在这里。

你问 ChatGPT:

“帮我分析一下为什么这个接口测试失败了。”

它给你一段分析,这是 AI 助手。

但如果它可以自己:

读取接口文档 → 调测试平台 → 执行接口 → 获取 Response → 查询日志 → 查看数据库 → 分析原因 → 修改测试脚本 → 再执行一次

这时候性质就完全不一样了。

它已经开始进入真正的软件研发流程。

04 这件事对测试行业影响其实更直接
为什么我们一直强调测试从业者要关注 Agent?

因为测试工作天然就适合被拆成大量“工具调用”。

举个很现实的例子。

现在很多测试团队已经开始使用 AI 生成测试用例:

需求文档

大模型

测试用例
这属于第一阶段。

但再往后发展,很可能变成:

读取需求

分析代码 Diff

查询历史 Bug

识别影响范围

生成测试用例

调用自动化测试平台

执行测试

读取失败日志

分析异常

输出测试报告
这里面只有其中几步是在“生成内容”。

剩下的大部分工作,本质上都是:

模型 + 工具 + 工作流。

所以未来 AI 测试真正的核心,很可能不是单独研究:

Prompt 怎么写得更好?

而是研究:

怎么让模型拥有完成测试任务所需要的上下文和工具。

这就涉及到:

企业知识库、RAG、MCP、Tool Calling、Agent、自动化测试平台、CI/CD。

这些东西开始逐渐连起来了。

05 100 万上下文,对测试其实特别有用
测试工作的一个特点是:

信息非常散。

需求在需求平台。

代码在 Git。

测试用例在测试管理平台。

Bug 在 Jira。

接口文档在 Swagger。

日志在 ELK。

监控又在另外一套系统。

一个经验丰富的测试工程师之所以能判断风险,很多时候并不是因为他会执行多少测试用例。

而是因为他能把这些信息串起来。

例如:

这个接口虽然只改了一个字段,但它会不会影响订单状态?

这个模块以前是不是出过类似 Bug?

这次代码修改到底影响到了哪些下游服务?

哪些历史测试用例需要重新执行?

这类问题,其实非常吃上下文。

长上下文 + 代码能力 + 企业知识库组合起来之后,AI 才更有可能真正参与:

需求理解
变更影响分析
测试范围判断
历史缺陷关联
测试用例生成
而不是每次只看一小段材料,然后给一个看起来正确、实际上不了解业务背景的答案。

06 还有一个容易被忽略的变化:成本
AI 真正进入企业之后,不能只看模型强不强。

还有一个非常现实的问题:

贵不贵。

如果一个测试 Agent 每天要反复读取代码、需求、日志,再调用十几次甚至几十次模型,那么调用量和普通聊天完全不是一个级别。

Qwen 官方披露,Qwen3.8-Flash-Next 相比 Qwen3.7-Plus,训练成本约为后者的 1/9,同时也在降低推理成本。其架构采用 125B 主模型,但每 Token 只激活约 6B 参数。

官方在发布时给 Qwen3.8-Flash 公布的 Qwen Cloud 定价为:

输入:0.16 美元 / 百万 Token

输出:0.47 美元 / 百万 Token。

截至 8 月 26 日官方发布文章时,API 标注为即将开放。

这其实是 Flash 模型很重要的一层意义。

企业需要的未必永远是“能力最强的那个模型”。

很多业务真正需要的是:

能力足够强,同时速度、成本、吞吐量也能接受。

尤其是自动化测试、客服、代码 Review、日志分析这类高频任务。

一天跑几次和一天跑几十万次,完全是两套经济账。

07 这还是一次 Qwen4 架构的“提前剧透”
这次发布还有一个值得关注的点。

Qwen 官方明确表示:

Qwen3.8-Flash-Next 同时也是 Qwen4 新架构的一次提前预览。

这次主要调整了四个方向:

Attention、Residual、Embedding、Optimization。

其中一个比较容易理解的是 Qwen Sparse Attention(QSA)。

长上下文最大的麻烦之一,就是上下文越长,Attention 的计算和显存访问成本越高。

QSA 的思路,可以粗略理解成:

不是每次都把前面所有内容重新仔细看一遍,而是先找到真正重要的内容,再重点关注。

Qwen 官方给出的测试中,在 100 万 Token 上下文下,QSA Attention Kernel 的 Prefill 和 Decode 最高分别实现 7.6 倍和 4.9 倍加速。

对于普通用户来说,不需要研究这些架构细节。

但这背后的方向其实很清楚:

模型越来越大,但每次计算不一定越来越贵;
上下文越来越长,但不能简单靠堆算力解决;
Agent 越来越复杂,对推理效率的要求反而越来越高。
这也是下一代模型架构正在重点解决的问题。

08 测试工程师真正要关注的,不是哪家模型跑分第一
现在几乎每隔一段时间就会发布一个新模型。

今天 Qwen,明天 DeepSeek,后天可能又是 Claude、Gemini 或 GPT。

如果每一个模型出来,我们都只是比较:

谁参数更大、谁 Benchmark 高了两分、谁又超过谁了。

其实意义并没有那么大。

对于测试从业者,更值得关注的是模型能力变化背后的工作方式变化。

从最近这一轮模型更新来看,几个方向已经越来越清楚:

长上下文让 AI 能理解更多项目级信息。

Coding让 AI 从生成代码走向修改真实代码仓库。

Tool Calling让 AI 可以连接测试平台、数据库、浏览器、命令行和内部系统。

Agent让 AI 可以把这些能力串起来,连续完成一个复杂任务。

这几个能力如果单独看,都不算特别新。

但当它们逐渐组合到一起之后,软件测试的工作方式就会开始发生变化。

写在最后
Qwen3.8-Flash 这次发布,我觉得真正值得关注的并不是某一个跑分。

而是一个越来越明显的信号:

大模型正在从“给答案”,走向“做事情”。

对于测试行业来说也是一样。

AI 测试的下一阶段,很可能不会只是:

帮我们多生成几条测试用例。

而是让 AI 真正进入:

需求分析、代码理解、风险识别、用例设计、自动执行、问题定位和质量反馈。

测试工程师当然没必要看到一个新模型就开始焦虑。

但有一件事情值得提前准备:

过去我们学习的是怎么使用测试工具;接下来,我们还要开始学习怎么把 AI 变成测试工具的一部分。

而 Qwen3.8-Flash 这次更新的 100 万上下文、Coding、Agent 和 Tool Calling,恰好都在把这件事情往前推。

相关文章
人工智能 缓存 前端开发
11992 62
人工智能 JavaScript 开发工具
4798 17
Web App开发 人工智能 API
1372 1
人工智能 Java BI
1451 1
开发工具 Swift git
1963 6
人工智能 JavaScript 测试技术
2378 2
人工智能 自然语言处理 安全
946 0
人工智能 JavaScript 测试技术
1183 4
缓存 JavaScript Shell
2096 3

热门文章

最新文章