2026-04-23 — Mozilla×Anthropic 用 AI 炸翻 Firefox 找出 271 個漏洞；Olive CSS 以 Lisp 生成 Tailwind 風格 CSS

Agents CLI in Agent Platform: create to production in one CLI

developers.googleblog.com · 2026-04-22

AI agent 開發正在從「跑在本機的實驗腳本」快速演進成「跑在生產環境的正式服務」，但長期以來，構建、評估、部署 agent 所需的基礎設施仍然高度碎片化——你得自己拼湊評估框架、CI/CD pipeline、部署目標、以及與 AI 編程助手的整合。Google Cloud 這次推出的 Agents CLI（隸屬 Agent Platform），主打「統一的 Agent Development Lifecycle（ADLC）程式化骨幹」，目標是讓開發者從建立專案到上線生產，只需要一個 CLI 工具。

一個指令啟動整個開發環境

安裝方式極為簡單——透過 uvx google-agents-cli 即可啟動。Agents CLI 的核心概念是向 AI 編程助手（如 Gemini CLI、Claude Code、Cursor）注入「bundled skills」，也就是讓這些工具了解 Agent Platform 的 API 規格與最佳實踐，從而能夠立即生成符合標準的專案骨架。

這個設計很聰明：與其要求工程師背熟一套新 API，不如讓已經習慣使用 AI 助手的開發者，透過自然語言或既有指令，直接生成符合 Google Agent Platform 規範的程式碼。對於前端工程師來說，這類「IDE 整合工具鏈」的設計模式愈來愈值得關注——它改變的不只是 backend 工作流程，也會影響全端工程師的日常。

本地模擬與嚴格評估

Agents CLI 內建了本地模擬環境，讓開發者在不需要佈署到雲端的情況下，就能執行評估 harness：

Unit test 編排：驗證 agent 各個組件的行為
資料檢索驗證：確保 agent 取得的資料符合預期
評估結果比較：跨版本比對 evaluation run，確保品質不退步

這套流程的設計理念，類似前端工程師熟悉的「本地開發 → 測試 → CI/CD」循環，只是對象從 UI 組件變成了 AI agent。

自動化部署到生產

部署階段，Agents CLI 會自動完成以下步驟：

注入 Infrastructure as Code（IaC）配置
建立 CI/CD pipeline
部署到 Agent Runtime、Cloud Run，或 GKE

三個部署目標代表了不同的使用情境：Agent Runtime 是 Google 為 agent 專門優化的執行環境，Cloud Run 適合無狀態的輕量服務，GKE 則給需要更細粒度控制的場景。

Agent Mode 與 Human Mode

CLI 支援兩種操作模式：Agent Mode 供 AI 助手消費（機器可讀格式），Human Mode 則提供「確定性控制」，讓開發者在需要直接介入時有清楚的操作介面。這種雙模式設計，解決了純 AI 控制流程下難以調試的問題。

對前端工程師的啟示

即使你主要做前端，這個工具背後的思路仍然值得借鑑：工具鏈的設計正在往「AI-first」移動，意即工具的 API 和文件不只要給人看，還要讓 LLM 能高效消費。未來若你需要為自己的 library 或 SDK 提供「AI 友善」的整合，Agents CLI 的 bundled skills 概念會是很好的參考模板。官方 GitHub 與 Reddit 社群已開放，有興趣的工程師可以下載試用，並參與 Agent Ecosystems Google Group 的討論。

Mozilla 說跟 Anthropic 合作炸翻 Firefox 了

blog.gslin.org · 2026-04-23

Mozilla 宣布與 Anthropic 展開安全合作，利用 AI 模型主動挖掘 Firefox 中的安全漏洞。這是一個相當重要的里程碑：AI 輔助安全研究不再只是學術論文裡的概念，而是實際進入了主流瀏覽器的安全工程流程。

具體數字：Claude Opus 4.6 找到 22 個，Claude Mythos 找到 271 個

根據合作成果，早期使用的 Claude Opus 4.6 模型，識別出 22 個安全敏感 bug，這些 bug 已在 Firefox 148 中修補。預覽版的 Claude Mythos 模型更進一步，一口氣發現了 271 個漏洞，全部在 Firefox 150 中修補。

這個數字的落差非常驚人——從 22 跳到 271，增幅超過 12 倍。這一方面反映了 Mythos 模型在程式碼理解與安全推理能力上的大幅提升，另一方面也說明 Firefox 的程式碼庫（大量 C++ 與 Rust 混合）在 AI 輔助下仍然藏有相當多過去人工審計難以覆蓋的角落。

為什麼這對瀏覽器安全意義重大

傳統的瀏覽器安全審計依賴以下幾種方式：

人工 Code Review（速度慢、覆蓋率有限）
Fuzzing（如 libFuzzer、AFL++，擅長找記憶體錯誤但對邏輯漏洞效果有限）
Bug Bounty 計畫（被動式，靠外部研究者主動回報）
靜態分析工具（誤報率高，需要大量人工篩選）

AI 模型的加入，提供了一種新的互補路徑：它能理解程式碼的語義意圖，識別「邏輯上不一致」或「邊界條件處理錯誤」的模式，而這正是傳統工具最薄弱的地方。

Chromium 的隱性困境

文章作者 Gea-Suan Lin 提出了一個有趣的觀察：Chromium（背後是 Google）可能面臨相似的挑戰，但由於母公司本身就是 Anthropic 的競爭者之一（Google 有 Gemini），在公開宣傳「用 Anthropic AI 找到漏洞」這件事上有明顯的組織障礙。這意味著即使 Chromium 也在進行類似的 AI 輔助安全研究，我們可能永遠看不到公開的數字。

對前端工程師的實際影響

身為前端工程師，這件事有幾個層面值得關注：

瀏覽器安全性提升：Firefox 148 和 150 修補的這批漏洞，直接降低了使用者被攻擊的風險，也減少了需要繞過瀏覽器安全機制的 XSS、UXSS 攻擊面。
更新優先級：作者建議使用者優先保持瀏覽器更新。對於維護 Web 應用的團隊，這也意味著要確保在 CI 環境中使用的 headless browser（如 Playwright 的 Chromium/Firefox）保持最新版本。
AI 輔助安全審計的未來：這套做法可能很快就會下放到一般開發工具。想像一下，未來的 linter 或 CI 工具能用 AI 識別前端程式碼中的 DOM-based XSS 或 prototype pollution——這不是科幻，而是接下來 1-2 年可能發生的事。

結論

Mozilla × Anthropic 的合作，標誌著「AI 作為安全工程師的工具」正式進入主流瀏覽器的工程流程。Firefox 148 修了 22 個、Firefox 150 修了 271 個 AI 發現的漏洞，這些都是實實在在的安全改善。現在最重要的事：更新你的 Firefox。

Olive CSS: Lisp powered vanilla CSS utility-class a la Tailwind

codeberg.org · 2026-04-22

Tailwind CSS 幾乎成為了現代前端的「預設選擇」，但它龐大的 Node.js 依賴鏈、以及「用 JavaScript 配置 CSS 工具」的設計，讓部分工程師始終不太自在。Olive CSS 提出了一個截然不同的答案：用 Guile Scheme（一種 Lisp 方言） 來生成 vanilla CSS，提供類 Tailwind 的 utility class 語法，但完全不依賴 Node.js 生態系。

核心概念：Lisp 作為 CSS 的後設語言

Olive CSS 的哲學很清楚：CSS 本身是宣告式語言，缺乏抽象能力；與其用 JavaScript 橋接（Tailwind 的做法），不如用 Lisp——一個天生擅長程式碼生成與 DSL 建構的語言——來作為 CSS 的後設層。Guile Scheme 是 GNU 官方的 Scheme 實作，完全自由軟體（LGPL v3+），不依賴 npm 生態，符合 Olive CSS 對「最小化依賴」的堅持。

使用方式：語法和 Tailwind 高度相似

對已經熟悉 Tailwind 的工程師，上手門檻極低。以下是一個典型的 HTML 使用範例：

<div class="m-2 px-4 py-6 bg-jeans-blue-500 md:bg-asparagus-300">
  Hello, Olive CSS
</div>

語法和 Tailwind 幾乎一致：m-2 是 margin，px-4 py-6 是水平/垂直 padding，bg-jeans-blue-500 是背景色，md: prefix 是響應式斷點。差別在於，這些 CSS class 是由 Guile Scheme 程式在構建階段生成的，而非 Node.js。

支援響應式與 Hover 變體

Olive CSS 透過自定義函式支援多種響應式變體：

響應式斷點：sm、md、lg、xl、2xl，可透過 addmq 函式自定義
Hover 變體：透過 addhover 函式生成
Dark mode：可配置切換
色彩系統：使用描述性命名（如 jeans-blue、asparagus），可自定義調色盤

完整輸出控制

Olive CSS 的「完整輸出控制（Full output control）」意味著你可以精確決定最終 CSS 包含哪些 class，不會像 Tailwind 那樣依賴 content scanning 來 purge 未使用的樣式。對於特殊的構建環境（如靜態網站生成器、Guile Scheme 寫的後端），這種方式更加可預測。

授權與自由軟體立場

Olive CSS 採用雙授權：程式碼部分是 LGPL v3+，文件部分是 FDL 1.3+。這個選擇反映了作者 Josep Bigorra 對「自由軟體」的堅持，而非只是「開源」。對於需要在授權層面嚴格把關的專案（如政府、醫療、教育領域），這是一個重要的加分項。

適合誰用？

Olive CSS 目前最適合以下場景：

對 Node.js 依賴有顧慮的環境（如嵌入式系統、Guile Scheme 生態的專案）
希望完全掌控生成 CSS 的工程師
Lisp/Scheme 愛好者想在 CSS 工具鏈上實驗的場景
強調自由軟體授權的專案

對於大多數 React/Vue 專案，Tailwind CSS 仍然是更成熟的選擇，因為它有龐大的社群、豐富的插件生態、以及更完善的 IDE 支援。但 Olive CSS 的存在提醒我們：前端工具鏈不一定要綁在 Node.js 上，Lisp 在程式生成領域的能力是真實且有用的。若你對 Guile Scheme 有興趣，可以 clone Codeberg 上的倉庫，試著撰寫一個自定義的 utility rule——透過 Scheme 的 S-expression 語法定義 CSS 規則，理解「程式即配置」的設計思路。

LemmaScript: A Verification Toolchain for TypeScript via Dafny

midspiral.com · 2026-04-22

TypeScript 提供了靜態型別，大幅減少了執行時型別錯誤。但型別系統本身有其極限：它無法保證一個函式的邏輯行為在數學意義上是正確的。LemmaScript 嘗試填補這個缺口——它是一套將 TypeScript 編譯到 Dafny 或 Lean 的驗證工具鏈，讓你可以用形式化方法（Formal Verification）在數學層面證明程式碼的正確性，而不改動既有的 TypeScript 執行管線。

為什麼不直接用 Dafny 寫？

過去已有工具把 Dafny 編譯成 JavaScript（讓 Dafny 程式在瀏覽器執行），但這條路在實際工程中有兩個根本問題：

整合摩擦：在 TypeScript 專案的邊界處，引入另一種語言的編譯產物，會打破既有的模組系統、測試框架、CI 流程。
棕地（Brownfield）不友善：你不可能把一個已有數萬行 TypeScript 的代碼庫整個重寫成 Dafny。

LemmaScript 採用相反方向：保留 TypeScript 的可執行管線（TypeScript → JavaScript），另外建立一條獨立的「驗證管線」（TypeScript → Dafny/Lean），兩條路徑並行，互不干擾。

Brownfield 範例：trimCookieWhitespace 與 CVE-2026-39410

文章用一個來自 Hono web framework 的真實案例說明 brownfield 用法，涉及 CVE-2026-39410。這個函式的功能是從 cookie 值中去除空白字元，但「哪些算空白」是個細節問題：應該去除 space（0x20）和 tab（0x09），但不應該去除 non-breaking space（0xA0）及其他 Unicode 空白字元。

開發者在 TypeScript 函式上標注 LemmaScript 的驗證 annotation（這些 annotation 對 TypeScript 執行期完全無害，僅在 LemmaScript 編譯時有效）：

// @verify
// @ensures: result only strips 0x20 and 0x09
// @invariant: no 0xA0 characters removed
function trimCookieWhitespace(value: string): string {
  // ... implementation
}

LemmaScript 處理這些 annotation，生成對應的 Dafny 驗證代碼，並透過 Dafny 的 SMT solver（Z3）自動證明函式滿足這些性質。若邏輯不符，Dafny 會明確指出反例。這個案例的意義在於：CVE 的根因往往是「字元邊界條件的錯誤假設」——這類 bug 靠 unit test 很難完整覆蓋，但形式化驗證可以窮舉所有輸入可能性，給出數學保證。

Greenfield 範例：Equality Game 決策程序

對於全新專案，文章以一個「Equality Game」決策程序為例，示範從設計階段就引入形式化驗證。核心是一個 canEqualize 方法，判斷兩個卡牌序列是否可以透過數學操作達到相等。驗證目標是同時確保：

可靠性（Soundness）：若 canEqualize 回傳 true，則序列確實可以相等
完整性（Completeness）：若序列確實可以相等，則 canEqualize 必回傳 true

這透過 Dafny 的 ghost predicates（不影響執行、僅用於驗證的謂詞）來表達，讓驗證器能夠在不改變執行語義的情況下進行推理。

何時適合用 LemmaScript？

作者給出了務實的建議：對於 Greenfield 專案，從一開始就按照形式化驗證的原則設計，效果最好，驗證是設計的一部分而非事後補貼。對於 Brownfield 專案，選擇性地驗證關鍵組件（如安全相關的解析函式、加密邏輯、核心業務規則），或在安全關鍵的重寫中使用，效益最高。

作者也坦誠地指出目前的挑戰：TypeScript 的某些複雜結構（如複雜的泛型、動態型別操作）難以直接映射到 Dafny，可能需要差異測試（Differential Testing）來補充驗證。

對前端工程師的意義

形式化驗證過去主要出現在航空、金融、作業系統等領域。LemmaScript 把入口降低到 TypeScript 工程師熟悉的生態：你不需要學 Dafny 的完整語法，只需要在關鍵函式上加上 annotation，剩下的由工具鏈處理。特別值得關注的場景包括：涉及 cookie、token、URL 解析的安全相關函式（正如 CVE-2026-39410 案例）；複雜的業務邏輯計算（如折扣規則、金融計算）；以及資料轉換管線（確保 schema 不變量在整個轉換過程中成立）。LemmaScript 目前還在早期階段，作者鼓勵社群實驗並回報問題。

來源：developers.googleblog.com, blog.gslin.org, codeberg.org, midspiral.com

End of article