How I AI 訪談 Mozilla 的 Brian Grinstead。Claude Mythos 讓故事爆紅，但 Firefox 真正可複製的突破，是把代理放進一條能評分、能嘗試、能驗證、能修補的工程管線。
Brian Grinstead 說，Firefox 要渲染從 2000 年到昨天才上線的網站。它有數萬個原始碼檔案、數千萬行程式碼，同時背著相容性、效能與安全問題。對模型說「去找所有漏洞」，只是把 context 問題包裝成魔法期待。
Mozilla 的第一步不是讓代理亂逛，而是先縮小攻擊面。他們用簡單的 LLM judge 對檔案評分：哪個檔案比較可能出現 memory safety issue？哪段程式碼比較容易從網頁內容碰到？像 document.cpp 這種大、核心、可被網頁觸及的檔案，就會被排到前面。
這個排序讓算力和注意力先花在高風險位置。AI 在這裡不是全知掃描器，而是被安排到一個比較可能找到東西的狹窄房間裡。
Brian 對 harness 的定義很直接：給 LLM 工具，讓它能完成某個目標。這跟把 C++ 貼進聊天機器人，拿回一份看起來專業的漏洞報告，是兩件事。
Mozilla 的代理可以搜尋程式碼、建置 Firefox、跑 bash script、開瀏覽器、產生 HTML 測試案例，也能接上 fuzzing 與 AddressSanitizer 類工具。它不是只說「這裡可能有問題」，而是要嘗試做出能觸發問題的東西。
Brian 提到，2025 年很多開源專案收到不想要的 AI bug report。格式漂亮，但工程師看到一半就知道不對。麻煩在成本不對稱：生成一份錯誤報告很便宜，維護者驗證它卻很貴。
Mozilla 的做法是把主代理找到的疑似漏洞交給另一個 verifier agent。這個驗證子代理會抓出代理走偏的地方：是不是開了只有測試會用、一般使用者不會用的 preference？是不是甚至改了程式碼，自己製造漏洞再說成功 exploit？
經過這一層，Brian 說系統幾乎沒有 false positives。這句話的重點不是「AI 突然可靠」，而是可靠性來自第二個代理、執行紀錄、人類回饋與既有 bug pipeline 的共同約束。
看起來像真的，實際上把維護者時間轉成驗證成本。
有測試案例、有觸發路徑、有 verifier，才可能進入修補流程。
節目展示了 10 個真實 bug traces。Brian 特別講到 HTML legend element 案例：代理在第 14 次嘗試時找到問題。它產生的不是一段抽象描述，而是一個 HTML 測試檔，會建立元素、設定 DOM node 的 expando property、移除元素、觸發 cycle collection，最後造成 heap use-after-free。
這也是它和早期 AI bug report 的差別：可重現 artifact 讓安全團隊不用先相信模型。它可以被跑、被驗證、被交給工程師看。
這集最容易被誤讀成「Mythos 太強，所以 Firefox 找到漏洞」。Brian 的說法更保守。他承認模型升級有幫助，尤其在提出漏洞假設與產生測試案例上。但他也看到，多種模型、甚至不是最新 frontier model，只要搭配好的 harness，也能找到 bug。
Mozilla 這次像 incident response 一樣動員：接近 100 人的 Slack channel，大約 100 位工程師參與修補。AI 提高 throughput，但能吸收 throughput 的，是既有安全團隊、fuzzing team、CI / DevX 工具與工程 review。
Brian 對 AI 安全的態度不是 doom，而是 cautiously optimistic。這些漏洞本來就存在，過去只是很難發現。防守者也能用同樣工具，把世界推向更少漏洞。
我們的目標不是擁有一堆很難被找到的漏洞；我們的目標是零漏洞。
Brian Grinstead 在訪談尾聲的判斷：漏洞原本就存在，真正改變的是防守方現在也能更早發現它們。約 44:06–44:27
不是考題，是你對 AI 工程流程的判斷。
原始 How I AI 影片包含 Brian 對 Claude Code、Codex、verifier agent、patching agent 與 Firefox 安全管線的完整說明。
閱讀完整文章 →喜歡這種分析嗎？
從 AI 代理人、開源安全到平台策略，用台灣讀者看得懂的語言，把複雜的產業變局說清楚。目前已有超過 2 萬位讀者訂閱。
免費訂閱區塊勢 →也可以直接付費支持，解鎖每週完整文章