WebAssembly 系統介面（WASI）0.2 預覽版於 2025 年底達成穩定狀態，伴隨元件模型晉升為候選 1.0 版——這項里程碑提供了一種名為 WIT（WASM 介面型別）的型別化、可組合介面定義語言。在此之前，WebAssembly 模組僅能透過臨時的主機綁定進行通訊，各語言工具鏈之間缺乏標準化的 ABI。有了 WIT，Rust 元件可以匯入 Go 元件的型別化介面，反之亦然，無需 JavaScript 主機墊片即可實現跨語言組合。
Bytecode Alliance（成員包括 Mozilla、Fastly、英特爾與 Red Hat）於 2025 年 9 月批准了 WIT IDL 規範。Fastly、Cloudflare Workers 與 Fermyon Spin 已推出正式環境支援。Wasmtime 28.0 與 WasmEdge 0.14 執行時期系列皆預設搭載 WASI 0.2。微軟正將元件模型整合至 Azure Container Apps 邊緣工作負載。
既有標準缺位之處的標準 ABI
WASI 0.2 解決的核心問題在於可組合性。在 WASI 0.1 之下，WebAssembly 模組是孤立的單元，缺乏標準化方式來跨語言邊界暴露或消費型別化介面。Rust 模組與 Python 模組之間的呼叫需要主機執行時期手動編排資料，通常透過 JavaScript 墊片層進行。這增加了延遲、提高了記憶體開銷，並迫使開發者以主機執行時期偏好的語言重寫效能關鍵邏輯。
WIT 透過提供雙方共同編譯的語言無關介面定義來改變此局面。Rust 元件在 WIT 中宣告其匯出，Python 元件則對其匯入做相同宣告。Wasmtime 與 WasmEdge 執行時期在邊界處理 ABI——無需協商共享記憶體佈局慣例，也無需呼叫慣例的破解手法。元件模型將每個模組視為具有明確型別化埠的可組合單元。
該規範支援整數、字串、列表、記錄、變體與資源——足以涵蓋真實世界的 API 表面，無需迫使開發者將所有內容序列化為最低公分母型別。WIT IDL 編譯為執行時期可直接消費的二進位格式。
主要執行時期的量產動能
從預覽版到正式版的轉換速度，比 WebAssembly 生態系中許多人預期的更快。Fermyon Spin 專門圍繞 WASI 建構其無伺服器平台，於 2025 年 1 月率先推出 WASI 0.2 支援。Cloudflare Workers 於 3 月跟進，讓 Rust 與 Python 元件能在邊緣端執行，並透過直接介面呼叫，而非經由 Workers 的 JavaScript 執行環境。Fastly 的運算資源@Edge 平台於 5 月加入 WASI 0.2 支援，鎖定相同的多語言組合模型。
在工具鏈方面，Wasmtime 28.0 於 2025 年 8 月推出，並以 WASI 0.2 為預設。WasmEdge 0.14 於 10 月發布，提供同等支援。兩個專案追蹤元件模型提案已超過兩年，WIT 的正式批准為它們提供了穩定的發布目標。
微軟將 WASI 0.2 元件整合至 Azure Container Apps，成為首家將 WASI 0.2 元件視為一級部署目標的主要雲端供應商。該公司將此定位為邊緣工作負載的基礎，讓延遲敏感的邏輯在使用者附近執行，同時連線至主容器應用程式中的 Python 或 .NET 服務。該公司於 2025 年 5 月的 Build 大會上預覽此整合，並預期於 2026 年第一季全面上市。
無伺服器經濟學的轉變
元件模型的意義超越技術成就。它改變了無伺服器與邊緣運算的單位經濟效益。在 WASI 0.2 之前，需要執行運算密集演算法的 Python 開發者面臨二選一：以 Python 重寫並接受效能折損，或透過 JavaScript 主機墊片包裝編譯模組並承擔序列化傳輸的額外開銷。兩種選擇權都非免費。
有了 WASI 0.2 與 WIT，Python 開發者可以匯入一個暴露型別化介面的 Rust 元件，將兩者作為獨立單元部署，且僅需支付介面邊界的成本——通常是單一函式呼叫，對原始型別採零複製傳遞。Rust 元件以原生速度執行，無直譯器額外開銷。Python 程式碼仍以 Python 撰寫，保持可讀性與可維護性。組合發生在部署層，而非應用程式碼中。
這是在 WASI 0.1 下根本不可能實現的能力，而此時邊緣運算正從簡單的請求 - 回應模式，擴展至更複雜的多語言工作負載。元件模型預期於 2026 年中達到完整的 1.0 正式批准，屆時將完成從前景可期的實驗到生產標準的轉變。
BossBlog 每日快報
一封信講完當天的 AI 與市場重點——13F 機構持股的異動、國會議員申報的交易，以及有什麼變了。沒有固定的發送時間，也不寫廢話：有值得寄的內容才寄。
隨時可退訂。名單不會外流或販售。