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

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)

这也是最近 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。