Kobako 系列

今年 RubyKaigi 2026 時，剛好在跟朋友聊 Harness Engineering 提到 Sandbox 的部分，覺得 Ruby 語言目前還沒有比較完善的解決方案，剛好第二天晚上的 Code Party 被分配到 dRuby（Ruby 語言內建的分散式系統）組別，讓我有了靈感，讓 Kobako 被設計出來。

Kobako 是近期我針對 Ruby 生態系中，對 Harness Engineering 支援所開發基於 WebAssembly 和 mruby 的沙盒（Sandbox）用來填補 AI 所撰寫的程式碼，沒有可以安全運行的環境。

關於 Kobako 的設計理念，我在 上一篇文章 已經介紹過，這次想聊的是效能。在初期的版本中 Cold Start（冷啟動，通常指初次啟動）大概要花上 500 ms 左右，這遠比最佳實踐通常會抓 200 ms 回應來說慢的不少，即使 AI 通常接受更慢的回應，但這不是等待 LLM 回應，仍該用過去的 API 標準來看待。

開始 Kobako 的開發已經有幾個月的時間，接下來也會在 COSCUP 分享這個專案，因為過程非常有趣，我認為很適合做一系列的更新，來介紹我怎麼開始「打造 AI 時代的沙盒」

到這篇文章撰寫為止，已經有 20 個左右版本發布，接下來我會盡可能按照時間順序，分享 Kobako 的演進，以及過程中做的決策。

雖然是受到 ruby.wasm 的限制才選擇 mruby 來作為沙盒（Sandbox）的語言，但也不代表跟 CRuby 都使用相同的語言標準（ISO/IEC 30170:2012）就讓這個目標輕鬆實現，相比 CRuby 在 mruby 上有很多限制存在。

這是 mruby 為了能夠在嵌入式系統這類環境運作必要的取捨，相對的輕量的特性剛好也是一種 Embedded Sandbox 的優勢，我們把 Ruby 語言沙盒嵌入到任何語言的這種想法，變成可行的選項。

上週末我在 COSCUP 的演講「讓 AI 接管你的應用，打造微秒級無縫的 Ruby 安全沙盒」分享 Kobako 設計過程中的一些考量，後續的提問被問到在 AI 時代不太需要考慮語言時，為什麼要選 Ruby 呢？

簡單地回答，單純就是「我喜歡用 Ruby 這個語言」然而在 Kobako 的設計，還有很多更深層的考量。