作者丨李娜
我让 Qwen 3.8-Max 从零搭建了一个 3D 大模型演进宇宙网站，又和 GPT-5.6 做了迭代对比。
（Qwen3.8-Max 运行成果截图）
效果上限方面，Qwen 3.8-Max 展现了远超 GPT-5.6 的交付细节；
效率和成本代价方面，Max 高完成度背后是低效，而且因为无法自主判断任务终点导致了额度耗尽中断；
适用场景方面，追求快速迭代、低成本原型，GPT 依然是首选，但在不计成本追求极致性能的场景，Qwen 3.8-Max 提供了一个昂贵但有效的国产替代。
2.4 万亿参数之后，
Max3.8 为什么开始强调 Agent?
8 月 3 日，阿里正式发布 Qwen 3.8-Max。
从规格看，它依然足够醒目：2.4 万亿总参数、约950 亿激活参数、100 万Token 上下文，覆盖文本、代码和视觉任务，并计划开放 Max 权重和 27B 小模型。榜单、规模、价格和开源，延续着 Qwen 过去几年的竞争路线。
（阿里 Qwen3.8 max 官方技术博客截图）
但到了这一代，仅靠这些已经很难解释 Max 的差异化。
相比 Kimi K3 用 KDA 混合线性注意力、Stable LatentMoE 建立起鲜明的架构叙事，Qwen3.8-Max 没有公布同等分量的新基础架构；它的价格相较海外旗舰仍有竞争力，却没有低到足以单独改变模型选择；2.4T 权重即使开放，其主要价值也更偏向云厂商、企业和研究机构，而不是普通开发者直接本地部署。当头部模型已经普遍拥有很高的基础能力，“更大、更强、更开放”正在越来越难成为一款旗舰模型独有的理由。
Qwen3.8-Max 这次把更多篇幅留给了另一个方向：长程 Agent。正式版技术博客中，模型规格和榜单很快被带过，真正占据篇幅的是 16 天自主开发、125 小时科研复现、数百轮芯片优化，以及编程、办公场景中的端到端执行项目。它们共同强调一种能力：模型能否在真实环境中调用工具、接收反馈、检查结果并继续修改，把复杂任务持续推向完成。
这也为 Max 找到了一个更明确的位置。它不必像中小模型那样承担普及和本地部署，而是负责抬高 Qwen 体系的能力上限，再由 Qwen Code、办公 Agent 和阿里云把这种能力送进具体工作流。但是它的实际能力如何，这也是我们在后面实测中需要关注的地方。
Agent 能力从哪里来？
Max 把训练重心放在真实环境 RL
Qwen3.8-Max 没有用一套新的基础架构来定义这一代，官方技术报告里显示"Qwen 3.8-Max 基于 Qwen 3.5 的架构基础构建”，对 Agent 能力提升的主要解释，落在了真实环境中的RL(强化学习训练)上。
（阿里 Qwen3.8 max 官方技术博客截图：RL 训练环境数量与能力增长曲线，随着 RL 训练环境从 0 增加到 4000 左右，综合分数从 SFT 基线约 0.474 提高到最佳检查点 0.725，官方把它作为持续扩展 RL 训练带来能力提升的证据。）
这里的“真实环境 RL"，并不是让模型在更大的题库里反复做题，而是把它放进接近实际工作的环境：模型需要读取项目、调用工具、执行代码、观察页面、接收测试结果，再根据反馈继续修改。训练目标也不再只是生成一段更符合标准答案的文本，而是让模型逐渐学会一条完整的工作闭环：
规划任务、采取行动、检查结果、发现问题，再决定下一步。
这也是 Agent 能力与普通生成能力之间最关键的区别。一次生成只需要给出答案，Agent 则必须理解当前状态，选择工具，并根据外部环境返回的结果不断调整策略。
（图：Qwen3.8-Max 扩展真实环境
强化学习系统的三项关键机制）
为了扩大这种能力，Qwen3.8-Max 公开了三项训练工程。
第一项是环境解耦。官方将任务、工作空间和 Agent Harness 拆成三个可以独立扩展的维度。第二项是统一奖励系统。代码是否执行成功、文本是否符合要求、视觉结果是否正确、Agent 行为是否合理，被纳入同一套评价机制。
（图：Qwen3.8-Max 在不同 Agent Harness 中的官方测试表现。该图主要用于说明其跨 Harness 训练与泛化方向。）
第三项是在线数据均衡。不同任务类型、难度、工作空间和 Harness 中的训练数据被动态配平，避免模型只在少数场景中表现出长程能力。
oh-my-cli 项目，
因此，Qwen3.8-Max 真正强化的，模型在外部反馈中持续行动的能力。官方展示的 16 天自主开发、125 小时科研复现和数百轮芯片优化的项目，本质上都依赖同一种机制：模型采取行动，环境返回结果，模型再根据结果进入下一轮执行。
这也解释了为什么“长程”不能只用运行时间衡量。一个任务持续十几个小时，可能意味着模型在有效修正，也可能意味着它陷入了重复读取、低收益修改和无效验证。真正需要验证的是，这套反馈循环能否把项目不断推向完成，而不是单纯让模型一直工作。
如果 Max 的 Agent 能力确实来自这种真实环境训练，那么它进入复杂项目后，应该表现出更强的持续推进、自我检查和错误修正能力。但同一套执行循环也可能带来更长的时间、更高的 Token 消耗，以及更难判断何时结束的问题。
接下来的实测，验证的正是这条执行闭环是否真正存在，以及它为了提高完成度，需要付出多大的代价。
测试一：从零生成一个
3D 大模型演进宇宙星图
Qwen3.8-Max 这次最重要的能力叙事，是长程 Agent。为了验证这项能力，我通过 Qwen Code，把模型接入一个真实的本地开发环境。它可以直接读取文件、修改项目、运行命令并检查结果。
第一道题是从零生成一个可交互的 3D 的大语言模型从开始至今的演进网站。
我要求它使用 React、Vite 和 Three.js，把不同模型公司设计成宇宙中的星系，把历代大模型设计成沿轨道分布的星球。用户需要能够旋转和缩放场景，点击模型查看档案，通过时间轴观察模型演化，并使用搜索功能快速定位目标。
同时，我明确要求它不能用静态图片、CSS 伪 3D 或者普通圆形卡片冒充三维场景。核心内容必须是真正运行在浏览器中的 WebGL 空间。
最终项目真正搭建了 WebGL 三维场景。OpenAI、Anthropic、Google、Alibaba Qwen、DeepSeek 和 Moonshot AI/Kimi 被设计成六个星系，28 个模型分布在不同轨道上，页面实现了旋转缩放、模型检索、节点聚焦、档案展示和时间轴筛选。
更重要的是，这些功能不是孤立拼接的。切换 2022—2026 时间轴后，场景中的模型数量会真实变化；当选中的模型被当前年份排除时，档案面板也会同步关闭。这说明它理解了不同状态之间的依赖关系，而不只是完成了几个独立组件。
这个项目最明显的问题出现在视觉精修上：视觉问题更具体：球体在部分角度下出现了明显的低模感；场景中偶尔有白色小方块悬浮；点击主体球后没有预期反馈。UI 方面，名称标签在密集区域相互遮挡；镜头拉近时大型星球会占据大半屏幕；边缘标签有时被裁切。星系之间颜色和轨道有区分，但星球本身材质变化有限。整体氛围已经建立，但镜头控制、信息避让和空间层次还需要更多精修。
工程层面也留下了一些问题。构建后的 JavaScript 文件接近 1MB，Vite 给出了包体积警告；自动验收脚本虽然覆盖了主要交互，但页面地址和模型数量存在硬编码，后续扩充数据时可能与项目本身失去同步。
综合来看，Qwen3.8-Max 已经能够独立处理技术选型、项目搭建、多文件协作、三维交互、错误修复和交付验证，把一份复杂需求推进到可以运行的前端 MVP。它的短板主要集中在视觉精修、复杂空间构图、性能优化和长期可维护性上。
测试二：同一项目迭代， ChatGPT 5.6 VS Qwen3.8 Max 对比
第一轮测试结束后，Qwen3.8-Max 已经从零生成了一套可运行的"AI 宇宙星图”，但距离真正可交付的产品还有明显差距，有些功能未完成、有些功能完成存在 Bug，同时还有项目优化的需求。
第二题我们在已有的版本继续迭代：
为了让两款模型真正进入开发流程，我分别通过 Qwen Code 和 ChatGPT 桌面版 Codex 调用 Qwen3.8-Max 与 GPT-5.6。两者拿到相同代码和相同需求，要求它们继续完成三类工作：优化 3D 视觉与整体氛围，补全最新模型数据并改进搜索和时间轴交互，同时增加“返回全景”、搜索飞行高亮和深度档案等产品级功能。因此这轮测试主要比较它们对已有项目的理解、修改、验证和收敛能力。
（需要说明的是，Agent 框架和工具链也会影响表现，所以结果代表两款模型在各自官方开发环境中的综合能力，而非完全隔离工具后的裸模型成绩。）
先上结论：
GPT-5.6 表现得像一个手上有忙不完的项目的高效外包商。它的逻辑是‘功能优先’，只要 3D 结构跑通、核心按钮有效，它就迅速收尾、宣布任务完成。它给出的虽然是可运行的 MVP（最小可行性产品），但缺乏灵魂。
而 Qwen 3.8-Max 则展现出了一个有强迫症的顶级架构师的特质。它不满足于‘代码能跑’，而是把大量的时间‘浪费’在对球体质感的打磨、光影折射的校准以及镜头推移的平滑度上。
GPT-5.6:37 分钟完成任务
(GPT5.6 运行成果截图)
ChatGPT 一侧运行约37 分钟，Codex 额度消耗约6%。
它的优势首先是快。Codex 很快识别出项目结构和需要修改的文件，完成了球体材质、点击交互、时间轴和比较功能等调整，也编写了本地截图与验证脚本。项目能够正常构建，它还明确列出了移动端、低性能 GPU 和构建分包等未验证项。
从工程流程看，这次执行相当利落：读取项目、修改代码、运行构建、有限验证，然后宣布完成。没有陷入长时间的工具重试，也没有消耗大量额度。
但真正打开页面后，问题出现了。Codex 完成了相当一部分功能层的需求，却没有把这些修改充分转化为产品层的改善。星球虽然比第一版更接近球体，但材质、光影和空间纵深依然有限；画面更像一个结构完整的 3D 数据面板，而不是我所描述的、兼具科幻感与浪漫气质的宇宙导航界面。
更明显的是，2026 年的最新模型数据并没有完整补上，原有的示例和占位内容也没有被彻底清理。搜索、聚焦和详情等功能有所改善，但最终的整体完成度仍然低于提示词要求。
它更像一个效率优先的工程助手，擅长快速把修改落到代码中，但对视觉质量、数据完整性和产品是否真正达到发布状态的判断相对宽松。
Qwen3.8-Max：三个半小时，更高的完成质量
我们可以从页面截图中明显看出，Qwen 3.8 Max 页面的完成度则明显更高。球体的体积、纹理和空间层次得到加强，公司主体与普通模型节点的区分更加清楚，搜索与镜头聚焦也更接近一个“宇宙导航”入口。页面整体氛围更符合最初要求的深空、科幻与浪漫感。
在数据更新上，Qwen 也尝试联网补充 2026 年的模型信息，并清理原有的示例内容。相比 GPT-5.6 较快达到能够构建和运行”的状态，Qwen 继续处理了视觉效果、数据完整性和产品细节，换来了更高完成度，也消耗了更多时间和 Token。
第二轮迭代中，Qwen Code 累计运行3 小时 29 分钟，发起195 次模型请求，处理约 1664 万输入 Token 和 21.6 万输出 Token，其中约 1475 万输入 Token 命中缓存，缓存率为88.6%。
任务最终因 Token Plan 滚动额度耗尽而中断，后台返回429 insufficient_quota。当时 100 万 Token 上下文窗口只使用了约 21.86 万 Token，占总容量的 21.9%。这次中断与上下文容量无关，限制来自持续工具调用、多轮验证和反复修改产生的时间与额度消耗。
从执行效率看，Qwen 付出了更高代价。它进行了更多轮代码修改和页面检查，也经历了验证超时与持续重试。任务中断前，它虽然遵循提示词完成了项目开发，但是还没有完成对项目的验收。
Qwen3.8 Max 的更高完成度， 来自更深的执行循环
这轮对比中，实测中，Qwen3.8-Max 的页面完成度高于 GPT-5.6。它通过反复读取代码、修改和验证来迭代细节；GPT-5.6 则更快满足主要功能后即收尾。两者对“完成”的定义不同：GPT 接受“可用”，Qwen 追求“更接近产品要求”。
这种倾向并非只出现在本次测试中。独立开发者 Thomas Wiegold 使用四项固定任务测试 Qwen3.8-Max 时，发现它在每项任务中都是耗时最长的模型。其中一项扑克模拟任务的核心功能约 20 分钟已经完成，模型随后又花费近一小时调整角色行为；他最终将 Qwen 概括为“质量很高，但速度很慢”。这类测试样本有限，无法代表所有场景，却与本轮观察到的持续打磨和反复验证高度相似。
社区所说的“过度思考”，本质上包含两类消耗。一类发生在模型推理阶段，模型投入过多 Token 分析、检查和修正；另一类发生在 Agent 执行阶段，系统不断重新读取文件、调用工具、运行测试和返回结果。本轮测试只能确认第二类消耗非常明显，无法根据现有日志精确判断其中多少来自模型，多少来自 Qwen Code 的任务策略(注：Qwen Code 本身也会影响这一结果，无法全部归因为基座模型。)
这套执行方式的优势很清楚：模型愿意检查更多问题，不会过早停在“代码能跑”的阶段。代价也同样清楚：任务运行 3 小时 29 分钟，经历多次验证超时和持续重试，最终因额度耗尽中断，更高完成度依赖更深的执行循环，但后续每一轮修改带来的收益正在下降。
因此，长程 Agent 的评价还要加入时间、预算和完成判断。上下文足够长，只解决了模型能否持续理解项目的问题；工具调用是否有效、验证是否重复、任务能否及时结束，决定这份能力最终需要付出多大成本。
进入真实工作流后，多一轮读取、验证和重试，都会转化为 Token 费用、等待时间和人工验收压力。Qwen3.8-Max 已经证明自己能够把复杂项目推向更高完成度。它接下来需要证明的，是能否减少收益有限的循环，在可控预算内完成验收并结束任务。
但与此同时，Qwen 3.8-Max 的这种“固执”也向行业揭示了另一种此前被忽视的选择。
在工程界，高质量的收敛往往比盲目的速度更昂贵。GPT-5.6 代表的是“效率优先”的逻辑，它在最短的时间内提供一个“能用”的框架，将剩下的精修工作留给人类；而 Qwen 3.8-Max 则代表了“结果导向”的路线。
阿里官方技术博客曾提到，Qwen 能够完全由 AI 自主运行 16 天完成复杂项目（如 oh-my-cli）。此前我们对这个数字缺乏体感，但通过这次‘宇宙星图’实测，我们找到了证据：
虽然我们只观测了它 3.5 小时的行为，但 Qwen 展现出的那种不达目的不罢休的收敛能力、面对 429 报错依然试图优化的细节，让我们窥见了其在长达 16 天的长程开发中，不断自我修正、最终逼近项目终态的可能性。
这实际上是为高预算、高复杂度场景提供了另一种“暴力美学”的解法：在那些人工成本极高、或者人类专家也难以处理的复杂系统工程（如大规模代码重构、芯片级底层优化）中，这种“不计代价”的闭环迭代，或许正是跨越 AGI 落地鸿沟的有效路径。
Max 守住前沿牌桌， Agent 才是阿里的扩张通道
两轮测试之后，Qwen3.8-Max 的轮廓已经比较清楚：它具备较强的长程任务能力，也愿意投入更多计算，把项目推向更高完成度；代价则是更长的运行时间、更多工具调用和更高的 Token 消耗。
Max 已经通过榜单和实际任务证明了 Qwen 的能力上限，但商业层面的问题比模型能力更复杂：如此庞大的旗舰模型，很难独自承担扩大采用和进入工作流的任务。
阿里押下的赌注，是让不同模型和产品分担不同角色：Max 负责前沿能力，小模型扩大开发者采用，Qwen Code 和千问办公承接具体任务，阿里云负责 API、部署和企业交付。
这种分工已经开始在产品侧显现。8 月 3 日，千问办公与 Qwen3.8-Max 正式版同步开放。这个动作释放出一个清楚的信号：阿里希望 Max 进入代码、文档、表格、网页和企业知识库，处理真实工作，而不只停留在聊天框和排行榜里。
这也让实测中暴露的问题变得更重要。对个人用户而言，多运行几个小时可能只是等待；进入企业工作流后，反复读取项目、持续调用工具和迟迟无法结束任务，都会转化为 Token 费用、交付延迟和人工验收成本。长程 Agent 不能只证明自己能够持续推进任务，还要在可控预算内完成验收，并判断什么时候已经达到交付标准。
因此，Max 在阿里体系中的位置已经比较明确：它负责守住前沿模型的牌桌，为整个 Qwen 体系提供能力上限；真正承担扩张任务的，是更容易采用的小模型、能够进入实际流程的 Agent 产品，以及阿里云提供的企业交付能力。
阿里的目标也不只是一款更强的模型，而是把 Qwen 变成覆盖开发、办公和企业服务的 Agent 能力底座。Max 能否真正产生规模化价值，最终取决于这份能力能否通过模型之外的执行系统，以最适合、更稳定的方式进入真实工作。
我们用 Kimi K3 搓了一颗火影螺旋丸，只花 129 元就顶一个前端团队？
2026-07-29
豆包 2.1 Pro 实测：Agent 自主性极强，代码「规矩、干净、可运行」
2026-07-10
