Mistral Large 4 的 133 個代理 Django 示範：它重現了 Django 早已修復的錯誤

Mistral Large 4 是 Mistral AI 暱稱為 Le Chonk 的 1.05 兆參數開放權重模型，於 2026 年 11 月 4 日以端到端安全研究員的身分亮相。Mistral 官方 X 帳號的一則貼文問這款模型能否「找出重大漏洞、證明它並修復它」，接著以 133 個代理、一個 Django 程式碼庫和一段 90 倍縮時影片作為回答。該貼文未指名任何 CVE。未發布修補程式。未提供執行時間、權杖數量、誤報數量，也沒有技術報告的連結。

時機縮小了範圍。Django 的安全團隊已於前一天，也就是 2026 年 11 月 3 日，在 6.1.3、6.0.10 和 5.2.19 中發布了六個 CVE 的修正（其中一個問題沒有列出 5.2 修補程式）。如果那批就是目標——而它是那一週新聞中唯一的 Django CVE 批次——那麼該示範不可能發現未知漏洞，因為這六個在影片發布前都已經公開並修補。它也不是重大漏洞。其中一個被評為中度；其餘五個被評為低度。

這並不代表這個示範毫無價值。這使它成為一種工作流程示範，而非一項發現主張；而對於任何正在決定開放權重模型能否在安全團隊的分流佇列中佔有一席之地的人來說，這項區別很重要。

Mistral 實際上展示了什麼

這則貼文很短：「Mistral Large 4 能找到重大漏洞、證明它並修復它嗎？我們在最近的 Django CVE 上測試了它。133 個代理會梳理程式碼、尋找缺陷、測試攻擊情境並確認錯誤。接著由 Le Chonk 修補。分診、重現、修補。以 90 倍速展示。」撰寫本文時，它已有 540 個讚、94 次轉發、107 則回覆和約 21,000 次瀏覽——是一則體面的產品貼文，而非漏洞揭露。

Mistral 自家的發行說明更詳細地描述了相同的工作流程。開放權重公告列出一個「Cyber Vulnerability Triage」代理，它會讀取收到的漏洞報告，在隔離沙箱中重現這些瑕疵，撰寫並反覆修改修補程式，並持續進行「直到金絲雀漏洞利用不再奏效」。這是該模型有文件記載的功能，且在影片發布前就已寫下。133 個代理的執行則是對它的公開演示。

90× 這個數字是播放速度，不是結果。若沒有來源影片的長度或該次執行的實際耗時，就無法換算成持續時間。兩小時執行的 90× 縮時影片，與兩天執行的 90× 縮時影片，在時間軸上看起來一模一樣。

Django 批次，以及為何「critical」並不貼切

Django 11 月 3 日的公告異常具體，這正是它可作為對照基準的原因。公告列出六個問題，每個問題都附有 CVE、回報者、受影響的分支集合以及修復提交。這些問題的嚴重性都還遠不及重大等級：

• CVE-2026-111362 — 中度。GeoJSON 幾何的 crs 成員可能導致 GDAL 在驗證、儲存或查詢期間發出網路請求或讀取本機檔案：一條 SSRF 與本機檔案讀取路徑。

• CVE-2026-108147 — 低。Base64 編碼的多部分上傳在 {{1}}上傳處理常式{{/1}}執行前就被緩衝，繞過了 {{2}}FILE_UPLOAD_MAX_MEMORY_SIZE{{/2}}，並可能導致記憶體耗盡。

• CVE-2026-111211 — 低。無效幾何表單值中的控制字元在記錄時未經逸出，可能導致日誌注入或偽造。

• CVE-2026-113593 — 低。{{1}}缺少與空白的 Vary 標頭值{{/1}}產生了相同的快取鍵，可能導致私有快取回應外洩的風險。

• CVE-2026-113733 — 低。僅具檢視權限的管理員使用者可看見某些自訂使用者模型的完整密碼雜湊。

• CVE-2026-114582 — 低。SpatialReference 字串輸入可能觸發 GDAL URL 擷取或檔案讀取；完整防護需要 GDAL 3.9 或更新版本。

這六個全都在同一天修復。這是 Django 的正常流程：安全公告、修補程式與 CVE 記錄會一起發布。某個模型若在一天後才「確認該錯誤」，它確認的是一個修復已存在於儲存庫、且重現步驟已刊載於公開報告中的錯誤。重現已回報的錯誤是分診佇列的首要工作，所以這是真正的工作——但這和找出一個錯誤不是同一回事。

Mistral 並未指明該 CVE 編號，因此無法對照特定的安全公告來查核這項說法。若目標漏洞不在十一月的批次之中，該篇文章便無從辨識其為何、發生於何時，也無法將生成的修補程式與上游修正進行比對。修補程式本身並未公開。

133 個 agent 是一個編排調度的數字

代理數量是設計選擇，不是分數。一條管線可以使用 133 個代理，因為它會針對每個檔案、每個假設或每條攻擊路徑各展開一個代理；同樣的工作也能用五個代理和更多回合完成。隨著數量改變的是成本、延遲和獨立嘗試的次數——而不是模型每個 token 的能力。

真正能讓這個數字有意義的指標，恰恰是缺失的那些：提出了多少個候選缺陷、其中有多少是誤報、每個已確認的錯誤需要多少個代理，以及這次執行消耗了多少 token。一個提出 200 個候選項才確認一個真實錯誤的系統，和一個只提出三個就確認一個的系統，是兩種不同的產品，而兩者都可以誠實地被描述為「133 個代理」。

Mistral 公開的描述顯示的是一個狹隘、可驗證的迴圈，而非開放式探索：在沙箱中重現、反覆修改修補程式、當金絲雀漏洞利用失敗時停止。這個迴圈正是 Django 示範所展示的。這是個好迴圈。它也是人類分診人員搭配除錯器與測試套件所執行的迴圈。

Mistral 確實有公布的安全數據

Mistral 的開放權重文章指出，在由廠商自行製作的圖表中，Mistral Large 4 在 Artificial Analysis Cyber Index 上拿下 51%，MiMo-V2.6-Pro 為 56%、DeepSeek-V4.1-Flash 1017 為 57%，而 Kimi K3 為 41%、GLM-5.3 為 36%。該指數測試模型能否在程式碼庫中發現漏洞、重現並驗證這些漏洞，以及修補它們——這與示範中的三個動詞相同。

同一篇文章報導，對惡意網路請求的平均拒絕率為 96.6%，Mistral 稱這是其在開放模型中所測得的最高值；在 B3 代理安全基準上的抗攻擊性為 97.1%，高於預覽版的 93.3%。十月的預覽頁面還列出，在 Mistral 自家的漏洞重現與修補測試中得分 82%，以及在 40 項 Cybench 挑戰中取得 93% 的成績；開放權重文章並未重複提及這兩個數字。

這些全都是廠商自行回報的結果。沒有任何一項經過獨立重現，而 Cyber Index 圖表是 Mistral 對第三方指數的呈現，並非排行榜截圖。這不代表這些數字有誤，而是代表它們只是宣稱，而示範影片也是同一系列中的另一項宣稱。

這裡存在一種真實的定位張力。一個被調校到能拒答 96.6% 惡意網路請求的模型，同時又以能重現漏洞利用與撰寫修補程式的能力來推銷。Mistral 的答案是推出一款專供滲透測試與紅隊演練的專用變體，並以審查機制與合約限制將其限定於自有或經授權的系統。開放權重的檢查點則是通用模型，其防護機制可由部署方自行調校——這正是為何雙用途問題是跟著權重走，而非跟著 API 走。

什麼會讓這個示範成為證據？

一個可信的端到端主張需要六樣東西。它們沒有一樣是稀奇古怪的；而它們全都沒出現在那篇貼文裡。

• 具名的 CVE，或沒有公開報告的錯誤——讓讀者能分辨「發現」與「重現」。

• 有漏洞的提交與已修補的提交，以便檢視差異。

• 在相同環境中進行前後對照重現，包含失敗與成功的漏洞利用。

• 假陽性數量：在有一個候選項存活之前，代理們提出了多少個候選項。

• 完整執行的實際耗時與權杖（token）成本，而非播放倍速。

• 由非 Mistral 的第三方獨立重跑。

把那些資料公開，論點就會改變。在那之前，誠實的描述應該是「Mistral 在一項公開的 Django 錯誤上示範了它的分診（triage）代理」，這是一個有用的產品展示，但比起文章第一句話所主張的，範圍要小得多。

在自己的程式碼庫上執行這個模式

開放權重是對安全團隊而言真正重要的部分。Mistral 於 2026 年 10 月 29 日根據 Mistral Ecosystem Open-Weight License 發布了該檢查點；這是一份修改版 MIT 授權，允許使用、修改、微調與商業化，但任何經營模型即服務業務的人都必須取得另行授權。該檢查點有 1.05 兆個參數，每個 token 啟用 490 億個參數，具備 100 萬 token 上下文，並有適用於 Blackwell GPU 的 NVFP4 變體。自行託管它是一項叢集採購，而非筆電下載，但它能將原始碼與發現保留在你的防禦邊界內——這正是安全團隊會選擇它而非 API 的原因。

這套工作流程比模型更具可移植性：測繪程式碼、產生候選缺陷、模擬攻擊、在沙盒中重現、修補，然後驗證該漏洞利用不再觸發。在每一種實作中，最薄弱的一步都是驗證器。撰寫修補的同一個模型並不是稱職的評判者；來自不同模型家族的第二個模型，在取得差異檔與重現方式後，能抓出相當比例的不良修補，而第一個模型卻會為這些修補辯護。

這正是路由發揮作用的地方。Mistral Large 4 並不在 OrcaRouter 的型錄中——它是在 Mistral 自家 API 上提供服務，也可下載供自行託管——但 OrcaRouter 把200 多個其他模型放在同一把相容 OpenAI 的 API 金鑰之後，對供應商定價零加成，具備自動容錯移轉，還有一套路由 DSL，能把提供第二意見的驗證器組合進同一次呼叫中。分流管線不需要單一模型樣樣精通；它需要撰寫修補程式的模型與審查修補程式的模型是不同的一個，而用一把金鑰比簽兩份供應商合約更省成本，同樣能達成這個目標。

值得關注的主張

Mistral 具備一款可信資安產品的各項要素：開放權重、有文件記載的分流流程、強勁的拒答指標，以及一項衡量正確動詞的基準測試。但它在公開場合還沒有的，是一個模型找到尚未修復之問題的案例。下一次示範應該指名該錯誤、公開差異補丁，並讓其他人實際執行。在那之前，133 個代理的影片展示的是編排能力，而非發現問題的證據——而「critical」這個詞所承擔的分量，已超出 Django 批次所能支持的程度。