Qwen

八月初，阿里 Qwen 團隊放了一顆炸彈。Qwen3.8-Max，2.4 兆引數的 MoE 架構，950 億活躍引數每 token，一百萬 token 上下文。 headline 讀起來像科技新聞——數字很大，但真正有意思的不是數字本身，而是這代產品定位的微妙轉變。 Qwen3.8-Max 不再只是一個「會寫程式的聊天機器人」。它的核心定位是 cowork——一個能在長週期任務中自主執行、自我修正、最終交付可運作成果的 agent。聽起來像行銷話術，但這次拿出來的案例確實有東西可看。 從「回答問題」到「完成任務」 過去一年，我們已經見識過不少 AI coding agent 的演示：寫一段程式碼、修一個 bug，或者生成一個小工具。這些展示都很好看，但現實中的工作往往比這複雜得多。 Qwen3.8-Max 的三個自主任務案例把門檻拉高了。第一個是讓模型從零開始建立一個叫 oh-my-cli 的 CLI 框架，完全自主運作超過十天。到七月三十日為止，這個專案累積了 265 個 commit、127 個 pull request 和 151 個 issue。模型自己把使用者回饋轉成 issue、分配給 agent、跑測試、修 bug，形成一個自我進化的迴圈。 第二個案例更誇張：給它一篇研究論文的連結和 GPU 資源，讓它自己重現實驗然後做得更好。模型花了大約五天、寫了七千六百行程式碼、跑了三十三輪 GPU 訓練，最後在 AIME24 數學基準上比原論文的方法又提升了 2.7 分。這不是寫一篇漂亮的分析報告，而是真正產出可執行的程式碼、訓練模型、驗證結果。 第三個案例是讓模型參加一個真實的競賽——天貓平臺的多模態對話意圖識別挑戰，526 個真人團隊競爭。模型在二十四小時內自己讀規則、寫程式、微調 BERT 和 RoBERTa 語言模型、結合視覺模型做整合，最後以 0.853 的準確率擊敗了 458 個團隊，排在第八十七名。 這些案例的共通點是：模型不是在回答一個明確的問題，而是在一個開放目標下持續運作、自我修正、最終交付成果。這跟過去我們對 LLM 的想像不太一樣。 Benchmark：看著好看，但別全信 Qwen 隨發布公佈了完整的基準分數表，涵蓋編碼代理、通用代理和一般能力三大類。不過這些分數全部是阿里內部跑出來的結果，沒有第三方獨立驗證。 Terminal-Bench 2.1 拿到 86.6，超過了 Claude Opus 4.8 和 Fable 5 的 84.6，但低於 GPT-5.6 Sol 的 88.8。PaperBench 拿到 93.0，超越所有對手。GPQA Diamond 是 92.6，跟上一代 Qwen3.7-Max 的 92.4 幾乎一樣，成長幅度不大。 ...

阿里巴巴在 2026 年 7 月 19 日的 Shanghai WAIC（世界人工智慧大會）上，正式揭開了 Qwen3-Max Preview 的面紗。這個被社群廣泛稱為 Qwen3.8-Max-Preview 的模型擁有 2.4 兆引數，採用稀疏混合專家（MoE）架構，是 Qwen 系列首款突破一兆引數門檻且具備原生多模態輸入能力的旗艦——文字、圖片、影片、檔案都能在同一個模型內處理。 阿里把它定位在「僅次於 Fable 5」。問題是：這個說法站得住嗎？下面的內容整理了多個獨立來源，拆解它的規格、能力、定價，還有對開發者可能造成的影響。 基本規格速覽 專案 規格 發布日期 2026 年 7 月 19 日（Preview） 總引數 2.4 兆（sparse MoE，活躍引數未公佈） 上下文視窗 100 萬 token 多模態支援 文字、圖片、影片、檔案輸入 思考模式 Thinking Mode + Function Calling + Built-in Tools API 相容性 OpenAI & Anthropic Messages API 目前可用性 Token Plan、Qoder、QoderWork（阿里自有平臺） 開放權重 「即將推出」，無具體日期或授權條款 發布背景：為什麼是現在？ 這個發布時機選得有意思。Kimi K3（2.8T）7/16 才出，Grok 4.5 和 GPT-5.6 Sol 分別是 7/8 和 7/9。Qwen3-Max Preview 卡在 Fable 5 促銷期結束的同一天亮相——開發者正在換模型的時候推新東西，時機抓得準。另外，中國監管機構 7/15 批准了 Apple–Alibaba Qwen 整合案，那時候 Qwen 的關注度本來就高。 ...

前言：當「單次提示完美」遇上「多輪對話崩潰」 最近 r/LocalLLaMA 上有一篇帖子引發了廣泛共鳴——一位使用者在 RTX 6000 上跑 Qwen 3.6 27B，發現它在單一提示（single prompt）下表現驚人，能輸出漂亮的 HTML 頁面、生成长內容；但一旦進入 Agentic Work（多輪工具呼叫代理工作），每四輪左右就會出現一次「完全腦死」的行為：亂改檔案、跳錯路徑、重複走相同流程…… 「它在單次提示下很優秀，但在 agentic work 中絕對崩潰。每隔幾輪就做一件完全腦殘的事。」 這篇文章的討論串長達數百則回覆，匯聚了數十位在地端部署 Qwen 系列模型的實戰經驗者。今天我們就來系統性地整理：Qwen 3.6 27B 在 Agentic Work 中為什麼會崩潰？核心原因是什麼？又該如何修復？ 一、問題全貌：什麼叫「四輪腦死」？ 根據原始帖者的描述，典型的崩潰行為包括： 症狀 具體表現 工具呼叫失敗 多工具呼叫時產生 malformed JSON，污染後續 context 思考區塊洩漏 </think> tag 遺失，導致 reasoning block 跨輪堆積 路徑跳躍 突然 cd / 到根目錄、讀取不存在的 .tokenring/linters/ 路徑 內容覆蓋錯誤 無視指導原則，直接覆寫既有文件 循環執行的 重複走相同決策路徑，無法自我修正 最關鍵的觀察是：這些問題不是隨機的，而是系統性的。 一位 vLLM 開發者指出：「每當模型有自由選擇工具/格式/參數的機會，就等於多擲一次骰子；8-12 輪之後，你幾乎保證會遇到一次壞結果。」 二、五大核心原因解析 1. preserve_thinking 未啟用（最常見的原因） Qwen 3.6 是首批原生支援「思考過程跨輪保留」的模型之一。預設情況下，如果沒有設定 preserve_thinking=true，模型在每一輪都會忘記自己上一輪的思考結論，導致它重複走相同的路徑、做出相同的錯誤決策。 多位使用者證實：只要加上 preserve_thinking=true，「腦死」頻率從每四輪一次降到幾乎看不見。 ...

前言 前陣子看到一篇來自 Quesma 的文章，作者在他的 MacBook Max M5（128GB RAM）上跑了 Qwen 3.6 系列模型後，得出一個頗具爭議的結論：27B 稠密模型在本地開發中才是最佳選擇，而不是 35B MoE 版本。 這個說法在 Reddit 的 LocalLLaMA 社群引發了熱烈討論——有人認同、有人反對。作為一個長期關注開源模型本地部署的人，我覺得這正是個好機會，把 Qwen 3.6 整個系列徹底盤點一遍，讓大家在實際部署前有個清晰的認知。 Qwen 3.6 家族全覽 Qwen 3.6 是阿里通義千問團隊在 2026 年 4 月推出的新一代模型家族，主要分為三大版本： 1. Qwen 3.6-Plus（旗艦閉源版） 透過阿里雲百煉 / DashScope API 提供 預設 100 萬 token 上下文視窗 採用混合線性注意力（Linear Attention）+ MoE 架構 估計活躍參數超過 4000 億 定價約 $0.29/100 萬輸入 token、$1.65/100 萬輸出 token，比 Claude Opus 4.6 便宜約 12 倍、GPT-5.4 便宜約 6 倍 2. Qwen 3.6-35B-A3B（開源 MoE 版） ...