AI 趨勢日報：2026-05-09

AI 效率翻倍，卻不代表你的工作安全——Cloudflare 用一份聲明，宣告了整個時代的轉向

Cloudflare 裁員 20% 的規模與背景

2026 年 5 月 7 日，Cloudflare 宣布裁員逾 1,100 人，約佔 5,156 名員工的 20%，是公司 16 年歷史上首次大規模裁員。裁員範圍橫跨工程、HR、財務、行銷等所有部門及全球各地，唯一例外是有收入配額的銷售職位。

值得注意的是，這次裁員並非發生在公司財務困境之中。Q1 2026 財報同步顯示：營收達 6.398 億美元，年增 34%，創歷史新高；未來績效義務更達 25 億美元，同樣年增 34%。Reuters 最早披露消息後，股價當日重挫 18–24%，與 Block、Oracle 等因 AI 裁員消息而股價反升的公司形成鮮明對比——市場對此舉的解讀明顯存在分歧。

離職員工的遣散條件相對優渥：2026 年底前全額底薪、美國員工年底前持續醫療保險、股票加速歸屬至 8 月 15 日（含免除一年懸崖條款）。CEO Matthew Prince 在官方部落格強調，此次重組是「重新想像公司內每一個流程、團隊與職位」，而非成本削減。

AI 時代科技業裁員潮的結構性變化

Cloudflare 提供了一個具體的量化錨點，足以說明 AI 轉型對就業結構的衝擊烈度。過去三個月，公司內部 AI 使用量激增逾 600%，員工每日執行數千次 AI agent 工作階段；部分員工的生產力甚至達到過去的 100 倍。

名詞解釋
AI agent 工作階段：指員工利用 AI 代理人自動執行一系列多步驟任務的完整流程，有別於單次問答式 AI 使用——代理人可連續推理、呼叫工具，大幅壓縮人工介入需求。

2025 年 11 月成為公司內部的轉折點，各團隊回報生產力大幅提升。CEO Prince 明確點名「支援型職位」 (support roles) ：在 AI 代理時代，提供後端人工支援的職位「不再是推動公司前進的角色」。這不是個人績效評估，而是整個職能類別的系統性淘汰，官方將其定義為「agentic AI era」的必然調適。

這也標誌著科技業裁員敘事框架的關鍵轉變：裁員不再僅是困境企業的止血手段，而成為高速成長公司主動重組人力結構、擁抱 AI 效率的戰略宣言。

求職者的真實困境：社群聲音分析

HN 討論串 (#48054423) 匯聚了大量被這波浪潮波及的工程師與求職者，留下了與官方敘事截然不同的聲音。用戶 xp84 寫道：「希望沒有人讓你覺得這是你自己的問題。這正是我今年的親身經歷——這跟四年前完全不一樣。是市場變了。」

用戶 smsm42 的留言揭露了另一層殘酷：「我看到幾十個職缺，簡歷幾乎完美吻合，但沒有一家公司回覆過我。」政府統計的百萬職缺數字與求職者的實際感受之間，存在巨大落差。

更深層的困境在於現實壓力徹底瓦解了求職者的談判籌碼。有房貸、家庭負擔、COBRA 健保即將到期的求職者，幾乎無力「懲罰」不誠信的雇主。smsm42 直接點明：「不是每個人都有底氣拒絕所有 offer，等待理想雇主出現。」

名詞解釋
COBRA：美國的醫療保險延續計畫，允許離職員工在一定期限內自費維持原雇主提供的健保——對有家庭的求職者而言，保險到期是極大的時間壓力來源。

對雲端產業與開發者生態的連鎖效應

Cloudflare 的裁員範圍涵蓋工程部門，這對依賴其基礎設施的開發者生態尤為值得關注。Cloudflare Workers、R2 物件儲存、AI Gateway、D1 資料庫等服務的產品路線圖穩定性與技術支援品質，在人力大幅縮減後是否受影響，需要持續追蹤。

BloomTech 創辦人 @Austen 在 X 上提供了更宏觀的視角：「Cloudflare 去年招聘了 2,000 人，今年裁員 1,000 人。很難找到另一家核心業務被 AI 吞噬得如此徹底的公司。」這種一年內劇烈擴縮的節奏，反映了科技業在 AI 轉型期重新評估人力需求的高度不確定性。

股價重挫而非上漲，說明市場對 Cloudflare 此舉並非全然買單。究竟是高瞻遠矚的戰略轉型，還是執行風險過高的提前賭注？公司聲稱「只做這一次」，並預測 2027 年員工總數將超過 2026 年任何時間點——這一承諾本身，將是下一個關鍵的觀察指標。

對開發者的影響

依賴 Cloudflare Workers、R2、AI Gateway 等基礎設施的開發者，需關注工程團隊縮編後的產品路線圖穩定性。短期內技術支援品質和 bug 回應速度可能受到影響，建議評估是否需要備援方案或替代服務。

更廣泛的啟示是：AI agent 工具鏈正在快速成熟。開發者若能主動整合 AI agent 工作流程，將在下一波人力結構調整中處於更有利的位置。

對團隊／組織的影響

工程領導者需要重新評估「支援型職位」的邊界：在 AI 生產力工具普及後，哪些職能仍需要人類判斷力，哪些可以被代理化？這個問題的答案正在快速演變，延遲評估的代價是落後於競爭對手的人力效率。

招募策略上，此案例可能加速科技業轉向「少但精」的人力配置——招聘具備 AI 協作能力的全棧型工程師，而非分工細碎的支援型職位。

短期行動建議

• 盤點個人工作中佔用最多時間但含金量最低的重複性任務，優先探索 AI agent 接管的可行性
• 若目前擔任支援型職位，主動向核心業務方向靠攏，建立可量化的業務影響力指標
• 追蹤 Cloudflare 及其他科技公司的 AI 生產力公開數據，作為評估自身職位風險的參考基準

產業結構變化

就業市場的結構性分化正在加速：AI 無法取代的高創造力與核心決策型職位，與可被代理化的支援型職位之間的薪資差距與就業穩定性，將在未來 2–3 年內顯著拉大。

HN 社群揭示的「職缺虛胖」現象——統計數字顯示數百萬職缺，但求職者投遞後石沉大海——可能反映企業正在更謹慎地篩選「AI 時代仍有不可替代性」的人才，而非廣泛招聘。

倫理邊界

AI 效率提升的紅利由股東和管理層享受，轉型成本卻由中低層員工承擔——尤其是本身沒有資本緩衝的支援型職位從業者。

「AI 創造新工作」的傳統安慰論在現實中面臨時間差挑戰：新工作在哪裡、何時出現，對一個 COBRA 健保快到期的求職者而言，是沒有意義的遠期承諾。

長期趨勢預測

若 Cloudflare 的 2027 年員工反超承諾兌現，將為「AI 轉型重組不等於永久裁員」的論述提供實證支持，可能引發更多科技公司跟進類似的主動重組。

若股價持續承壓且產品品質下滑，則將成為「AI 轉型敘事透支市場預期」的教科書案例。

無論哪種結局，Cloudflare 裁員都已成為 AI 時代企業人力決策的重要參照點——2026 年 5 月這個時間點，將在業界討論 AI 對就業的影響時被反覆提及。

ds4.c 證明「單一模型＋單一硬體」的專屬引擎路線，已能在 Mac 上提供可用的大模型推理效能。

章節一：Antirez 的新挑戰：從 Redis 到 AI 推理引擎

antirez 從 Redis 時代就偏好直攻關鍵瓶頸，ds4.c 延續同一哲學。這次他把焦點從資料結構轉到推理路徑，刻意避開層層包裝。

他在專案中直言現代開發過於繁瑣，因而選擇 C 加 Metal 手刻核心。量子位的報導也把這次跨界定位成效能工程師對 AI 基礎設施的直接回應。

章節二：DeepSeek V4 本地推理的技術瓶頸與突破

本地跑 2840 億參數模型的難點，不只在「能載入」，更在記憶體頻寬與 prefill 成本。ds4.c 用非對稱量化，把容錯較高的 routed experts 壓到 2-bit。

同時 shared experts、projections 與 routing 維持 Q8，避免品質崩塌。這種拆分讓 128GB 機器達到可用生成速度，回應了「塞得進卻跑不動」的典型困境。

章節三：Apple Silicon 上的大模型推理實踐

Apple Silicon 的統一記憶體讓 128GB 與 512GB 容量可直接承接模型狀態，ds4.c 因此能對 Metal 執行圖做更貼近硬體的調校。實測顯示 M3 Ultra 在長提示 prefill 可達 468 t/s。

磁碟 KV 快取把注意力狀態持久化，讓 agent 重啟後不必重做昂貴 prefill。這對需要反覆迭代上下文的開發流程，會比單次跑分更具實務價值。

章節四：開源推理引擎生態的競爭格局

ds4.c 不是要取代通用框架，而是把「極窄優化」推到極致。當通用引擎要兼容百種模型時，單模型專屬引擎在特定硬體上更容易拉開效能差距。

HN 與其他開源作者已出現平行路線，例如 Qwen3 專屬實作。這代表生態可能分化為通用層與專屬層並行，企業將依場景在可攜性與峰值效率間做取捨。

ds4.c 的關鍵不在「支援很多模型」，而在「把單一模型跑到足夠快且可重複」。它把可用性建立在窄範圍深度最佳化，而非通用抽象。

環境需求

建議使用 128GB 以上統一記憶體的 Apple Silicon 裝置，並預留高速儲存空間給 KV 快取。若要穩定長上下文吞吐，512GB 機型更有餘裕。

最小 PoC

# 1) 取得專案
git clone https://github.com/antirez/ds4
cd ds4

# 2) 依 README 準備模型與權重
# 3) 啟動服務後，使用 OpenAI 相容端點驗證
curl http://127.0.0.1:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"deepseek-v4-flash","messages":[{"role":"user","content":"hello"}]}'

驗測規劃

先分離 prefill 與 generation 兩段測速，避免只看單一 t/s 指標。再加入冷啟動與熱啟動對照，量化磁碟 KV 快取對實際工作流的縮時效果。

常見陷阱

• 把短提示跑分誤當長上下文效能，導致容量與頻寬估算失真。
• 未控管快取鍵與提示模板版本，造成命中率下降與結果不可比。

上線檢核清單

• 觀測：prefill t/s、generation t/s、KV 命中率、重啟後首 token 延遲。
• 成本：記憶體占用、磁碟 IO 放大、持續運行功耗。
• 風險：模型版本綁定、量化回歸、API 相容性變更。

競爭版圖

• 直接競品：llama.cpp 對 DeepSeek V4 Flash 的實驗分支、其他 Apple Silicon 在地推理引擎。
• 間接競品：雲端託管推理服務、通用多模型代理平台。

護城河類型

• 工程護城河：單模型深度最佳化、貼近硬體的 kernel 與記憶體路徑控制。
• 生態護城河：OpenAI／Anthropic 雙協議相容，較易嵌入既有 agent 工具鏈。

定價策略

專案採 MIT 授權，商業價值更可能落在整合服務、部署運維與場景化方案，而非核心執行器本體收費。

企業導入阻力

• 單模型路線與企業多模型策略可能衝突。
• 高記憶體硬體門檻，初期資本支出仍不低。

第二序影響

• 促使更多「模型綁硬體」專屬引擎出現，擠壓純通用框架的效能敘事。
• 帶動本地 agent 產品把差異化重心轉向工作流與快取策略。

判決值得投入 PoC（聚焦特定場景）

若團隊任務以固定模型與長上下文 agent 為主，ds4.c 的效能與相容性已足以啟動實驗。若目標是廣泛多模型平台，仍應把它定位為局部加速器而非唯一底座。

實測吞吐

M3 Max(128GB) 在 Q2 短提示下，prefill 約 58.52 t/s，generation 約 26.68 t/s。M3 Ultra(512GB) 短提示可到 prefill 84.43 t/s、generation 36.86 t/s。

長上下文表現

M3 Ultra(512GB) 在長提示 Q2 測試中，prefill 可達 468 t/s。這代表長上下文場景的等待成本，已接近可接受的互動級體驗。

能耗觀察

M3 Max 峰值功耗約 50W，對桌面端連續推理具實用意義。若任務可本地閉環，整體能耗與雲端費用有機會出現新平衡點。

LLVM/Swift 之父用 MLIR 打造 AI 原生語言，Beta 版本清算舊債、穩定 API

章節一：從 Chris Lattner 的願景到 1.0 Beta

Chris Lattner 是 LLVM 編譯器框架與 Swift 語言的原始設計者，2022 年與前 Google 工程師 Tim Davis 共同創辦 Modular Inc.，全力開發 Mojo 語言。

Mojo 的核心願景是成為「開發者面對 CPU、GPU 與加速器時所需的唯一程式語言」，讓工程師不必在 Python 的易用性與 C++ 的效能之間反覆切換。

v1.0.0b1 發布於 2026 年 5 月 7 日，是 Phase 1 路線圖收尾的重要里程碑，重點在確立 GPU/CPU kernel 開發的 API 穩定性。Phase 2 的 async 支援與 private members，以及破壞性較大的 Mojo 2.0，均留待 1.x 穩定後才推進。

Modular 宣布將在 1.0 正式版釋出時開源編譯器，語義化版本控制與穩定／不穩定 API 標記將成為 1.x 系列跨函式庫互通的基礎。Lobste.rs 社群帖子在 29 小時內無評論，但獲得 20 個 upvote，反映審慎觀望的社群態度。

章節二：Mojo 核心特性：Python 超集 × 系統級效能

此版本最顯眼的語法變更是棄用 fn 關鍵字，改以 def 為唯一函式宣告語法。Python 開發者看到熟悉語法，底層卻具備統一閉包、型別精化與非 null 指標等系統語言能力。

名詞解釋
Unified Closures（統一閉包）：無狀態閉包自動提升為頂層函式，支援 ref 捕獲語意，可直接用作 C FFI 回呼，免去 Python ctypes 的額外封裝層。

UnsafePointer 預設改為非 null 設計，需表達 nullability 時須使用 Optional[UnsafePointer[T]]，指標語意更接近 Rust。標準函式庫集合預設啟用邊界檢查，越界錯誤準確回報至使用者呼叫位置。

String 與 StringSlice 新增 UAX #29 grapheme cluster 分段，正確處理組合字符、emoji ZWJ 序列與旗幟 emoji。Type Refinement 讓編譯器從 where 子句與 comptime if 自動收窄型別，大幅減少手動 trait_downcast 需求。

章節三：與 Python、Rust、Julia 的定位差異

Python 在 AI/ML 領域無所不在，但效能瓶頸始終是痛點——GPU kernel 開發前線需借助 CUDA C++ 或 Triton 才能突破限制。Rust 雖有完善記憶體安全語意，但 GPU 開發生態薄弱，學習曲線對 AI 研究者也相對陡峭。

Julia 在科學計算有所建樹，但社群規模與工具鏈成熟度仍不及 Python 生態。Mojo 以 MLIR 後端為核心，直接生成針對 GPU、TPU 與 ASIC 的程式碼，不依賴單一架構的 LLVM IR。

名詞解釋
MLIR(Multi-Level Intermediate Representation) ：LLVM 子專案的多層中間表示框架，允許編譯器在 GPU thread block、tensor 運算等不同抽象層次分別最佳化，比純 LLVM 更適合 AI 加速器目標碼生成。

在「易用性 vs. 效能」光譜上，Mojo 是目前最接近中間點的選項，以 Pythonic 語法包裹系統級能力——這是 Lattner「AI 開發者唯一語言」願景的核心賭注。

章節四：對 AI/ML 開發工作流的實際影響

GPU 支援範圍顯著擴展：新增 AMD MI250X 與 NVIDIA B300(sm_103a) 支援，覆蓋主流訓練叢集；Apple Metal 後端新增 print() 除錯支援、動態 threadgroup 記憶體與 M5 MMA 矩陣運算 intrinsics，讓 Apple Silicon 用戶可直接存取矩陣硬體加速。

預設邊界檢查降低 AI kernel 開發中難以追蹤的記憶體越界錯誤；grapheme cluster 支援讓多語言 NLP 資料前處理更正確，對 CJK 字符、阿拉伯文或混合 emoji 序列的工作流有直接助益。

新增統一 Reflection API 入口點 reflect[T]()，取代分散的 struct_field_* 系列函式，讓 AI 框架開發者撰寫泛型 kernel 時能更簡潔查詢型別元資訊。

Mojo v1.0.0b1 的技術核心在於三個正交機制，共同實現「Python 語法可讀、系統語言可控」的設計目標。

環境需求

需透過 Modular 官方工具鏈安裝，支援 Linux x86_64 及 macOS(Apple Silicon) 。GPU 加速需確認驅動版本：NVIDIA CUDA 12.x 或 AMD ROCm 6.x；Apple Metal 後端建議 macOS 14+。

最小 PoC

def add(x: Int, y: Int) -> Int:
    return x + y

def main():
    print(add(40, 2))

驗測規劃

遷移後執行編譯器警告掃描，確認無殘餘 fn 宣告。對集合操作加上邊界測試，確認越界錯誤回報至使用者呼叫位置。若有 GPU kernel，需在目標硬體（MI250X 或 B300）執行冒煙測試。

常見陷阱

• 誤以為 def 語意等同 Python：Mojo 的 def 仍具靜態型別推斷與 ownership 語意，不能套用 Python 動態型別直覺
• 忽略 UnsafePointer 非 null 設計：舊有 null 檢查邏輯需重構，否則 null 語意悄悄失效
• 仍使用負索引（如 x[-1]）：此版本已升為編譯期錯誤，需改用顯式長度計算
• 仍使用 NDBuffer：須遷移至 TileTensor，兩者 API 不完全相容

上線檢核清單

• 觀測：邊界錯誤是否準確指向使用者呼叫位置（而非函式庫內部）
• 成本：NDBuffer 遷移至 TileTensor 的工程時間，視現有使用量而定
• 風險：Beta 階段 API 可能在 1.0 RC 前仍有小幅調整，建議持續訂閱官方 changelog

競爭版圖

• 直接競品：Triton（OpenAI，Python-like GPU kernel 語言，已有 PyTorch 整合）、CUDA C++（NVIDIA，成熟但學習曲線陡峭）
• 間接競品：Julia（科學計算，GPU 透過 CUDA.jl）、Rust with cudarc（記憶體安全，但 GPU 生態薄弱）

護城河類型

• 工程護城河：Chris Lattner 主導的 MLIR 多後端架構，深度整合 Apple Metal、AMD ROCm、NVIDIA CUDA 的編譯器能力，短期內難以複製
• 生態護城河：若 1.0 開源後吸引 AI 框架採用，上下游依賴將形成顯著轉換成本

定價策略

Mojo 語言工具鏈目前免費，Modular 商業化路徑主要透過 MAX 推理平台實現。編譯器開源後工具鏈完全開放，商業模式聚焦於平台服務而非授權費，企業採用障礙較低。

企業導入阻力

• Beta 階段 API 穩定性存疑，架構師難以承諾生產環境採用時間表
• 社群生態規模仍遠小於 Python + CUDA 組合，第三方函式庫覆蓋率有限
• 編譯器尚未開源，供應商鎖定風險使部分企業保持觀望

第二序影響

• 若獲主流 AI 框架採用，Triton 的社群地位將面臨直接競爭壓力
• Apple Silicon 深度整合可能加速 Mac 作為 AI 推理開發機器的市場定位
• 開源後若社群快速成長，可能與 PyTorch 生態形成互補而非取代關係

判決先觀望（Beta 品質可期，生態待驗證）

v1.0.0b1 在語法清理與 API 穩定化方向正確，MLIR 後端技術路線具備說服力。然而生產環境採用仍需等待 1.0 正式版與編譯器開源，關鍵問題是社群生態能否在開源後快速起飛。

效能基準現況

Mojo v1.0.0b1 主要是語法與 API 穩定化里程碑，官方未在此版本發布系統性 benchmark 數字。

歷史參考數字

Modular 早期基準測試顯示，Mojo 在 Mandelbrot 集合計算上比純 Python 快約 35,000 倍，與 C 的差距不到 2 倍。這些數字基於特定場景，需審慎解讀；正式版 benchmark 預計在 1.0 穩定版釋出時一同發布。

這不是單一模型秀，而是「可驗證的 AI 漏洞工廠」正式成形。

章節一：Claude Mythos Preview 的漏洞挖掘成果

2026 年 4 月，Mozilla 以 Claude Mythos Preview 對 Firefox 做自動化安全分析，單次即確認 271 個未知漏洞。這批問題已在 Firefox 150 修補，並涵蓋高風險沙盒與記憶體類缺陷。

其中包含 15 到 20 年舊漏洞，顯示模型可碰到長期難抵達路徑。3 個漏洞取得 CVE，且 271 件中高嚴重性占多數，安全價值不只在「量」，也在可利用風險密度。

章節二：Mozilla Agentic AI 安全管線架構解析

Mozilla 採四階段流程：Discovery、Validation、Triage、Lifecycle Integration，核心是先找線索，再用動態測試驗真。這讓輸出從可疑訊號，轉成可修補的工程工作單。

名詞解釋
Agentic 管線是指模型可連續執行多步任務，包含分析、產生測試、執行與回報，不只停在文字建議。

系統以多台臨時 VM 平行掃描不同目標，再集中回報到共用儲存並與既有 bug 庫去重。模型升級時可直接替換，讓管線效能隨模型能力同步提升。

章節三：AI 驅動漏洞發現 vs 傳統安全審計效率

Firefox 月修補量從過往 20 到 30 件，先升至 60 到 70 件，最終在 4 月達 423 件。關鍵不是單純更會讀碼，而是能自動建立並執行 PoC，先做自我驗證再交人審。

早期 GPT-4 與 Sonnet 3.5 因假陽性高而難規模化，凸顯唯讀靜態分析的天花板。Mythos 補上 fuzzing 難覆蓋路徑，讓防禦方首次用可負擔成本逼近攻擊方搜索強度。

章節四：開源軟體安全的新範式

Project Glasswing 把模型能力、資安流程與產業協作綁在一起，合作方跨雲端、晶片、金融與開源基金會。這代表漏洞研究正從個體高手模式，轉向組織化與基礎設施化。

同時也有雙重用途風險，因此 Mythos 僅限審核存取，並搭配額度補助與後續揭露節奏。Mozilla 計畫把此流程前移到 commit 前，安全審計將更接近持續整合日常。

這次突破在於把模型推理能力，封裝進可並行、可驗證、可追蹤的安全生產線。單點模型再強，若沒有驗證與去重機制，仍會被假陽性拖垮。

環境需求

需要可拋棄 VM 叢集、可程式化測試框架、以及與缺陷系統整合的 API。若沒有動態執行能力，只做靜態摘要通常會被誤報淹沒。

最小 PoC

# 1) 指定目標模組
scan_agent --target dom/html --mode discovery --out findings.json

# 2) 對候選缺陷生成並執行 PoC
validate_agent --in findings.json --emit-poc --run --out validated.json

# 3) 與既有資料庫去重並建立工單
triage_agent --in validated.json --dedup bugdb --create-ticket

驗測規劃

先用歷史已知漏洞集回放，量測召回率與假陽性率。再做灰度上線：先一個子系統，再擴到跨進程與 JIT 熱區，避免一次引爆修補洪峰。

常見陷阱

• 只看發現數量，不看可重現率，會造成錯誤 KPI。
• 沒有把去重與優先級策略產品化，導致修補排程失序。

上線檢核清單

• 觀測：驗證通過率、平均修補週期、重複回報率。
• 成本：每件漏洞的算力消耗、人審工時、回歸測試負擔。
• 風險：高權限測試隔離、資料外洩防護、模型輸出濫用治理。

競爭版圖

• 直接競品：傳統 SAST／DAST 平台、代碼審計服務商、漏洞獎勵生態。
• 間接競品：fuzzing 基礎設施供應商、CI 安全外掛、紅隊自動化工具。

護城河類型

• 工程護城河：可驗證管線、低誤報流程、與修補生命周期深度整合。
• 生態護城河：Glasswing 聯盟與關鍵基礎設施合作，形成資料與流程反饋。

定價策略

研究預覽後採每百萬 token 計價，輸入 25 美元、輸出 125 美元。高單價迫使企業重視任務選擇與批次調度，而非全面無差別掃描。

企業導入阻力

• 受限存取與審核門檻，短期供給不足。
• 法遵與責任邊界未定，尤其在雙重用途風險場景。

第二序影響

• 漏洞揭露節奏加快，供應鏈修補窗口被壓縮。
• 安全職能重心轉向「驗證與修補編排」，而非純手工尋洞。

判決先行佈局（價值在流程，不只在模型）

對多產品線與高攻擊面企業，現在就該投資 agentic 驗證管線。即使拿不到 Mythos，也能先建立可替換模型的工程底座，縮短未來能力落差。

基準表現

CyberGym 漏洞重現基準中，Mythos Preview 為 83.1%，對比 Opus 4.6 的 66.6%。SWE-bench Pro 為 77.8%，對比 53.4%。

實戰指標

Firefox 150 共 423 項安全修補，約 271 項來自 Mythos 流程。高嚴重性漏洞占比高，且含多年潛伏缺陷，顯示並非只抓邊角問題。