我们用Qwen 3.8-Max做了一个AI大模型宇宙：效果竟然胜过GPT5.6！

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