Qwen3.8 Max 跑分：官方成绩与生产实测差距

快速结论：Qwen 已在 2026 年 8 月 3 日正式版中发布大型 Benchmark 组合。其中 Terminal-Bench 2.1 为 86.6、PaperBench 为 93.0、SWE-bench Pro 为 67.7、HLE 为 43.6、OmniDocBench 1.5 为 92.1。这些是Qwen 官方厂商成绩，不是独立复现，也不是 EvoLink 路由实测。

有价值的问题不是“Qwen3.8 综合第几”，而是“哪些证据足以改变生产路由”。EvoLink 正式路由已经可用，但本文尚未伪造站内实测结果；下一步应运行 20–50 个相同任务，补充成功率、延迟、重试、工具调用、人工修正时间和成功任务成本。

编程、Agent、推理与多模态证据矩阵

早期第三方实测能告诉我们什么

Trilogy AI 在 7 月 19 日发布的一项早期仓库架构对照测试，让 Qwen3.8 Max Preview 与 Kimi K3 处理一个包含 269 个文件的任务。盲审后 Kimi 得分 83，Qwen 得分 80。Qwen 在部分系统边界和可重放元数据决策上更强；Kimi 完成更快、Token 更少，并更完整地覆盖生命周期状态。

这项结果有价值，因为它公布了任务结构、错误、Token 和定性差异。但它不构成通用 Benchmark，因为只有一个任务、每个模型一次会话，而且使用了不同订阅端点：Qwen 使用国际 Token Plan，Kimi 使用 Kimi Code。客户端、缓存、路由容量和发布期流量都属于结果的一部分。

正确结论是方法论：

• 对两个模型使用冻结输入；
• 除输出结构外，还要审核事实声称；
• 区分模型行为与路由行为；
• 同时报告延迟、Token 和质量；
• 尽可能对审查者隐藏模型身份；
• 不只发布总分，也发布失败分析。

路由合同也是结果的一部分。引用的 Qwen 运行使用 Token Plan 端点和交互式编程 Harness；Qwen 个人版条款禁止把该订阅 Key 复用于自定义后端、自动化脚本或非交互批处理。因此，83 比 80 比较的是两个带日期的端到端评测路径，不是两个可互换的生产 API。

社区对速度、冗长、循环或编程质量的反馈可以增加测试思路，但不能证明模型的普遍上限，因为 Prompt、工具、客户端和预期各不相同。

Qwen3.8 仍然缺少哪些证据

生产团队要有信心解读模型，市场还需要更广泛的证据。

完整官方 Benchmark 披露

有用的厂商表格应该说明模型版本、推理设置、工具权限、Prompt 策略、试验次数、评分方式和竞品配置。只有分数而没有 Harness，很难复现或公平比较。

独立的编程与 Agent 复现

编程 Benchmark 不能只覆盖孤立函数生成。生产证据应包含仓库探索、多文件修改、测试、工具调用、失败恢复和审查。

多模态任务证据

Qwen 文档说明 Preview 支持视觉理解。独立测试应拆分 OCR、视觉证据定位、文档理解、图表推理、抽帧后的视频画面分析和幻觉；这里不假定其原生支持视频输入。

延迟与 Token 效率

没有服务数据的能力结论并不完整。模型可能得分很好，但输出很长、推理 Token 很多或延迟不可预测，从而改变产品体验和成本。

路由稳定性与生命周期

Preview 可能在观察期内变化。测试必须记录准确模型 ID、日期、渠道、区域、客户端和配置，否则后续运行可能测的是另一个 Preview。

可复现的访问权限

如果测试凭证在政策或运维层面不能承载目标工作负载，该 Benchmark 就无法在生产中复现。应记录路由是否允许交互式评测、自动回归、自定义应用后端和批量流量，并把访问政策就绪度与模型质量分开评分。

为什么公开跑分经常误导生产团队

Benchmark 把性能压缩成一个分数，产品团队运营的却是包含延迟、工具、重试、计费、回退和人工审查的系统。

这些盲区对 Qwen3.8 尤其重要，因为 Preview 正被当作编程和 Agent 模型讨论。Agent 价值取决于状态、工具、恢复和停止行为，而不只是最终响应。

未来 EvoLink Qwen3.8 的评测门槛

生产可用 API 路由出现后，EvoLink 才能通过路由无关的测试套件评估 Qwen3.8，并决定默认、专用或升级角色。在此之前，这只是协议，不是已发布测试结果，也不是现在投入大型 Token Plan 测试预算的理由。

1. 冻结任务集

先从小规模 Pilot 开始，只有路由与初步结果值得继续时才扩大。任务应有明确验收标准，并包含目前由 Qwen3.7 Max、Kimi K3、Claude、GPT 或其他现实基线处理的工作。

2. 锁定环境

记录：

• 准确模型 ID 和日期；
• 供应商路由与区域；
• system prompt 与 user prompt；
• 推理设置；
• 可用工具与权限；
• 超时、重试和回退策略；
• 输入与输出 Token；
• 是否命中缓存。

不要把工具丰富的编程客户端与裸 API 路由放在一起，并假装唯一变化只是模型。

3. 先评验收，再评风格

先使用硬性验收：测试、Schema、引用、数字准确性和必需交付物；再审查可维护性、清晰度和用户偏好。

一个实用评分卡是：

生产得分 = 验收率
         - 严重缺陷率
         - 人工介入惩罚
         - 超时惩罚

成本和延迟应与得分并列，而不是藏进一个混合权重数字。

4. 计算成功任务的经济性

通过验收的任务成本 = 模型调用 + 重试 + 回退调用 + 审查时间 + 修复

QwenCloud 上游价格与 EvoLink 实时价格属于不同商业渠道。经济性评测应使用同一渠道的实际账单与成功任务成本；Preview Credits 只能作为历史实验记录。

5. 分配路由角色，而不是通用排名

评测输出应该是一条策略：

在 EvoLink 启用并验证 Qwen3.8 路由前，“仅列入观察”是正确的当前角色。

如何解读新出现的 Qwen3.8 跑分

分享新结果前，先问八个问题：

1. 发布者是谁——模型厂商、对比模型厂商，还是独立评测者？
2. 使用了哪个准确的 Qwen3.8 Build 和路由？
3. 是否启用推理，强度是多少？
4. 是否允许工具、浏览或代码执行？
5. 跑了多少次？
6. Prompt 与评分能否复现？
7. 结果是否衡量产品真正执行的任务？
8. 是否包含延迟、Token、重试和失败？

如果缺少这些字段，就把分数标为方向性证据，不要放进“谁赢了”表格。

给 EvoLink 用户的建议

为每一个分数保留可复现证据

每次评测都应保存模型 ID、路由、日期、区域、客户端版本、Thinking 档位、工具权限、Cache 状态、Prompt Hash、运行次数、Judge 与验收规则。缺少这些字段时，模型修订或路由变化可能被误判为能力提升。

报告平均值时也要保留失败分布。四次成功、一次无限循环的模型，可能不如平均分略低但稳定完成的模型。无效 Tool Call、Malformed JSON、媒体不支持、拒答、超时、重试和人工修正都必须进入分母。

常见问题

Qwen3.8 的 Benchmark 得分是多少？

不存在可靠的单一综合分。Qwen 已公布多类别厂商成绩，包括 Terminal-Bench 2.1 86.6、SWE-bench Pro 67.7、HLE 43.6 和 OmniDocBench 1.5 92.1；这些不能折算成一个通用排名。

Qwen3.8 真的仅次于 Fable 5 吗？

这仍是对 Qwen 自有评测组合的厂商解读，不是独立验证的通用排名。更可靠的方法是按工作负载决定路由角色。

Qwen3.8 有独立实测吗？

已有少量第三方工作负载测试，包括一次匹配的仓库架构对比。它们提供了有价值的观察，但范围太窄，不能建立综合排名。

Qwen3.8 编程能力好吗？

编程是核心发布场景，但生产团队应该测试仓库修改、工具、恢复、测试和审查，而不是只依赖宣传标题中的单一跑分。

应该如何比较 Qwen3.8 与 Kimi K3？

使用冻结输入、相同权限、相同验收标准、多次试验，并分别衡量质量、延迟、Token、人工介入和成本。

Token Plan Credits 能用于 Benchmark 成本对比吗？

不能。Token Plan Credits 只能描述 Preview 订阅实验；生产对比必须使用匹配运行时实际供应商或 EvoLink 路由收取的价格。

Qwen3.8 测试应该包含哪些基线？

包含产品实际能够路由的模型：Qwen3.7 Max 代表上一代稳定性，Kimi K3 代表当前长上下文挑战者，再加入高难任务当前使用的 Claude 或 GPT 路由。

Qwen3.8 什么时候适合生产？

当准确路由、ID、价格、限制、行为和 Fallback 都经过验证，并在重复真实任务中达到验收门槛时。

来源

• QwenCloud 模型发布日志
• Qwen3.8 Max 技术发布与 Benchmark
• Qwen3.8 发布帖
• Qwen Token Plan 概览
• Qwen 文本生成模型列表
• Qwen OpenAI 兼容 Chat API 参考
• Qwen Token Plan FAQ
• Trilogy AI：Qwen3.8 Max 与 Kimi K3 Benchmark

下一步：连接评测 Harness