我們給 Qwen3.7-Plus 測試了 10 個真實錯誤與 15 道 AIME 數學題，其表現均超越了旗艦模型。

摘要

2026 年 5 月中旬，Qwen3.7-Max 和 Qwen3.7-Plus 低調出現在 LM Arena 上。@Alibaba_Qwen 以「阿里在文字排名第 6，在視覺排名第 5」定下了社群預期。6 月 2 日，阿里雲通義千問團隊正式發布了這款多模態代理模型。目前該模型已上線阿里雲百煉（Model Studio）與 Qwen Chat，API 訪問路徑為

1alibaba/qwen3.7-plus

官方定位非常明確：Plus 是高性價比的多模態模型；Max 是文字旗艦模型。

我們花了一個下午的時間，針對 Qwen3.6-plus、Qwen3.7-plus 和 Qwen3.7-

1Max

以下測試結果應被視為 5 項任務級觀察，而非通用的模型排名：

1. BugFind-10 單次運行：Plus 通過了所有外部 pytest 檢查。在這一套包含 10 個任務、官方 Stirrup 腳本和單次運行設置下，Plus 獲得 10/10 的評分，而 Max 和 3.6-Plus 為 9/10。這僅代表該設置下的任務適配度，不應被推廣為通用的編碼排名。
2. 數學測試：開啟思考模式的 Plus 與 Max 單次運行分數持平。在 15 道競賽級數學題中，Plus 和 Max 均正確回答了 14 道；在此次運行中，Qwen3.7-plus 的單題耗時遠低於 Qwen3.7-Max（113 秒 vs 303 秒）。
3. 代際速度躍升：在代理任務中，Qwen3.7-plus 的端到端吞吐量達到 147.5 t/s，而 Qwen3.6-plus 僅為 41.5 t/s，實現了 3.55 倍的提升。上一代無法完成的數學任務，現在已能輕鬆處理。
4. 多模態仍有瑕疵：在我們的受控多模態測試中，Qwen3.7-plus 能正確回答簡單的圖片問題，但對官方範例圖片
   textCopy

   1dog_and_girl.jpeg

   的描述卻是「火車和人群」。
5. 部分能力接近 Max，且具備延遲優勢：在本次測試的多項指標中，Qwen3.7-plus 在保持較低延遲的同時，結果接近 Qwen3.7-Max。這並非聲稱其總體排名超越。

以下是完整的測試數據、方法論以及給工程主管的模型選型建議。所有對比均限定在本次小樣本、單次運行及固定腳本的範圍內。

0. 模型能力與排行榜背景

阿里 Qwen 的產品線在 3.6 世代已形成固定格局：Max = 文字旗艦，Plus = 多模態長上下文模型。3.7 版本延續了這一邏輯：

1. 官方如何定位 Plus？

阿里 Qwen 的發布文案 將核心訊息縮減為一句話：

「一個模型。看見、思考、編碼、行動。」

其核心賣點為：具備統一 GUI 與 CLI 操作的多模態交互混合代理、多功能編碼代理，以及跨代理框架的泛化能力。Qwen 核心開發者 shuai bai_ 進一步解釋：

我們的目標是將多模態 AI 從被動的圖片說明生成轉變為主動的問題解決者：一個能看見、能推理、能寫代碼、能操作介面並驗證結果的實體。這是邁向真正代理型多模態智慧的一步。

官方線程中的效能數據給出了關鍵定位：

• 文字效能「接近 Max 水準」（廠商聲稱）
• 多模態改進重點在於核心代理能力：複雜的視覺理解、視覺推理、工具使用以及代碼/GUI 執行

2. 我們的評估方法：四類任務與一條鐵律

為了確保測試公平，我們維護了一套名為 BugFind-10 的測試集：包含 10 個涵蓋價格計算、陣列邊界、路徑處理、併發、JSON、SQL、緩存行為、Unicode 及配置等的真實 Bug。每個 Bug 均配有 pytest 測試用例。模型必須在官方 Stirrup 代理框架內運行，使用本地代碼執行工具，並自主完成「復現 → 定位 → 修改生產代碼 → 運行測試」的全循環。

為什麼要建立自己的測試集？

公共排行榜存在三種常見的失效模式：

1. 記憶與洩露：旗艦模型在舊題目上已達到飽和。我們選擇了 AIME 2025，這是一項在模型訓練截止日期後發布的競賽，因此更能抵禦污染。
2. 廠商自測數據可能偏離獨立復測：同一指標會因數據集版本、是否開啟思考、是否允許使用工具而產生顯著差異。
3. 代理基準測試依賴於腳本框架：不同的代理框架會使分數產生 2-3 個百分點的變動。我們將框架鎖定為官方 Stirrup 並加入了外部驗證。

四項測試任務

我們的鐵律：代碼分數僅以外部 pytest 為準

這是整個評測的基礎。它直接回應了 Hacker News 的關切，即模型聲稱「測試通過」是不足夠的。

流程：

1. 代理在工作區修改代碼，自行運行 pytest，並編寫 CHANGELOG。
2. 我們將修改後的生產代碼複製到隔離環境中，獨立運行 pytest。
3. 我們僅發布第 2 步的退出代碼和錯誤堆疊。

類比：代理是考生。我們不僅閱讀它交上來的答案，還要將答案帶到另一個房間重新批改，而不是信任它自己聲稱的「成功」。

3. 代碼與代理能力

三模型總覽

Plus 獲得更好的單次 BugFind 結果出乎意料：

1. Plus 是本次測試中唯一 10/10 的運行結果。
2. Max 使用的調用次數最少，但未獲得滿分。 3.7-Max 僅進行了 20 次調用。它傾向於「長時間思考並進行一次重大修改」，迭代次數較少。相比之下，3.7-Plus 使用了 52 次調用，更願意編輯、運行、檢查反饋後再編輯。
3. Plus 的執行時間最短且吞吐量最高。 對於 IDE 代理體驗而言，這比排行榜上的 Elo 分數重要得多。

一個任務，三種修復哲學：以 task05 為例

此任務測試無效 JSON 不能被靜默吞噬的規則。解析遇到壞數據時，不能假裝成功並返回空物件，必須明確報告錯誤。原始 Bug：

plaintextCopy
1def safe_parse(data: str):
2    try:
3        return json.loads(data)
4    except Exception:
5        return {}   # Bug: swallows the exception

測試要求：

• 對於 this is not json { 這類輸入，函數不能返回空字典 {}。
• 對於不帶大括號的無效輸入（如 bad），必須拋出異常。

Max 的方法（外部測試 ✗）：拋出自定義 JSONParseError。 這看起來是個乾淨的解決方案，但它在處理 this is not json { 時立即拋出異常，導致測試甚至無法運行第一個斷言。然而 Max 的 CHANGELOG 卻自信地寫道「27 個通過」。這正是必須進行外部驗證的原因：代理的自我評估與外部審計往往存在差異。

3.6-Plus（外部 ✗）：在同一第一關卡失敗。

3.7-Plus（外部 ✓）：

plaintextCopy
1if re.search(r'[\{\[\]\}]', data):
2    return {"error": str(e), "raw": data}
3raise ValueError(f"Invalid JSON: {e}") from e

對於包含括號的畸形輸入，它返回一個可與

1{}

為什麼 Max 在此任務中沒拿滿分？從調用次數來看： 3.7-Max 傾向於「長時間思考並進行一次重大修改」。在需要與環境進行反覆交互的代理編碼任務中，更多的迭代可能有助於覆蓋 Max 在本次運行中遺漏的邊界情況。這指向了一個常被忽視的事實：在代理任務中，「更深度的推理」並不一定意味著更穩定的交付。善用工具反饋同樣重要。

工程建議：

• 對於代理任務，與環境博弈的意願（Plus 進行了 52 次對話和 98 次代碼執行）比最小化迭代更重要。
• 在交互式 Bug 修復中，一個「拋出異常」的方案並不總是比返回可區分的髒數據更有用。

4. 推理與數學：思考模式是一個成本決策

Qwen3.7 系列強調「混合思考」，通過

1enable_thinking

成本比較：

思考開關的邊際效益

開啟推理後，Plus 達到了與 Max 相同的單次運行 AIME 分數。 但 Plus 單題僅需 113 秒，Max 則需 303 秒。Max 更長的延遲在本次測試中並未帶來更高的分數。

在 8 道小學應用題中，兩種模式準確率均為 100%。開啟思考僅多消耗了 24% 的 Token。結論很明確：

簡單任務關閉思考以節省成本；困難任務開啟思考以獲取準確率。 全域開啟推理意味著在簡單請求上支付超過 4 倍的費用卻沒有任何精準度提升。該開關的價值在於它允許你根據任務難度動態路由。

5. 速度、代際差距與一個被迫終止的任務

代理吞吐量對比

實際端到端速度（來自

1runner_summary.json

• 3.7-Plus: 147.5 t/s
• 3.7-Max: 51.8 t/s
• 3.6-Plus: 41.5 t/s

代際改進（3.6 到 3.7 Plus）約為 3.55 倍。同代 Plus 與 Max 之間約為 2.85 倍。

代際差距最顯著的例子來自 3.6-Plus 的數學測試。我們嘗試加入 3.6-Plus 的結果，但它太慢而無法完成：推理過程在每道題上都觸發了上限，單題輸出達到 16K-52K Token，耗時 297-932 秒。前 6 道題就耗費了 46 分鐘。對於生產環境而言，後者往往比「能不能解」更重要。

給工程團隊的建議：對於思考模型，傳統的超時和

1max_tokens

6. 多模態測試：受控圖通過，官方範例失敗

Arena 視覺排行榜將 Plus 排在第 16 名左右。我們的測試顯示：高排名與單圖失敗可以並存。

選型建議：與其閱讀排行榜，不如在自己的業務領域（OCR、圖表、UI 截圖、發票）中運行 20-50 張圖像，這遠比排行榜可靠。

7. 成本：本次測試的代價

本次評測包含三個模型、四類任務，共耗費約 200 萬 Token，測試成本約為 USD2-3。

洞察：嚴謹的評估成本僅相當於一頓飯錢。團隊應將這些錢花在重新運行自己的任務上，而不是花在行銷文案上。

代理成本的核心不在於單價，而在於「調用次數 × 單次歷史長度」。 優化應聚焦於歷史壓縮、子代理分解和緩存。

8. 模型選型建議

9. 限制與披露

本文為一下午的深度快照，非學術論文：

1. 單次運行：未進行 pass@k 測試。
2. 無水平對比：未測試 Claude、GPT 等競賽對手。
3. 樣本限制：多模態測試僅 n=2。
4. 定價預估：請參考百煉平台最新價格。

結語

在 2026 年的 AI 模型潮中，只有可復現的審計級證據才是技術決策的硬通貨。對工程師而言，官方敘事負責願景，而

1outputs/