---
title: "Kobako：COSCUP 2026 演講後，來聊聊為什麼是 Ruby"
date: 2026-08-12T00:00:00+08:00
publishDate: 2026-08-12T00:00:00+08:00
lastmod: 2026-08-10T21:13:40+08:00
tags: ["LLM","AI","經驗","Ruby","WebAssembly","Gem","mruby"]
series: "kobako"
toc: true
permalink: "https://blog.aotoki.me/posts/2026/08/12/kobako-why-ruby-after-coscup-2026/"
language: "zh-tw"
---


上週末我在 COSCUP 的演講「[讓 AI 接管你的應用，打造微秒級無縫的 Ruby 安全沙盒](https://coscup.org/2026/session/KZ9PTY)」分享 [Kobako](https://github.com/elct9620/kobako) 設計過程中的一些考量，後續的提問被問到在 AI 時代不太需要考慮語言時，為什麼要選 Ruby 呢？

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

<!--more-->

## 實驗性{#experimental}

之所以會有 Kobako 專案誕生，剛好是 2026 年初 Harness Engineering 變得熱門，搭配我在 2025 年底的經驗，我對未來方向有一些預測。

大致上就是虛擬檔案系統（Virtual Filesystem）和沙盒技術（Sandbox）被我判斷是最值得的，正好四月的 RubyKaigi 我也跟不少人提到這幾個方向，又順便問自己，要不嘗試看看？

搭配 RubyKaigi 的 Code Party 活動被分配到 dRuby 組別，又更近一步讓我認為沙盒很可能是能夠實現，而且只需要把東西組裝，而不是去設計一套新的解決方案。

雖然最後因為 WASIp1 的標準讓我無法對 ruby.wasm 做任何擴充，鎖死了關鍵的幾個步驟，但這些都變成後續 Kobako 設計的基礎，像是使用相同的 Wasmtime 驅動 WebAssembly 環境、使用類似 dRuby 的方式設計宿主（Host）和客體（Guest）的互動機制，這也讓我後續的概念驗證順利成功。

## 開放標準{#open-standard}

在實際開發的過程中，我一直在思考「自由度」的問題，也就是使用的人能不能拿去做到他想做的那些事情，這對我自己來說也很關鍵。

運氣很好的是，在 Ruby 生態系有語法幾乎相同的 mruby 可以選擇，而 Wasmtime 本身就是 Rust 為基底，而前幾年 Ruby 社群推動使用 Rust 寫 Extension 的支援後，幾乎只需要考慮怎麼去設計 Kobako 就可以。

最初，我考慮的是 WebAssembly 本身就是可替換的，因此在設計 ABI（Application Binary Interface）的時候，就盡可能限縮到大多數語言都能用的組合，並且把預設的溝通協定用 MessagePack 處理，這表示即使不用 mruby 也能用任意可以編譯成 WebAssembly 的語言，所以是 Ruby 搭配任意語言，而非只有 mruby 而已。

後續的整理，我開始思考很多公開介面設計的問題，這剛好是因為朋友任職的公司是做 WasmEdge 這個專案，實際上就是 Wasmtime 的替代品，因此我很快的就推出 `Runtime` 的概念，可以透過實作這個特性，讓任何能運行 WebAssembly 的套件都能夠用來跑 Kobako 的架構。

更近一步的處理，我為了把耦合解開，所以加入很多新的介面設計，並且不斷地問「這裡可不可以替換？」這樣的問題，像是「MessagePack 可以換掉嗎？」「如果不需要動態的介面，是不是可以改用 Protobuf？」這樣的提問，一步一步的擴充。

到目前為止，Kobako 更像是一個通用介面的提案，你可以用 Rust 把底層跑的 mruby 換掉或者擴充，也能更換 MessagePack 或者 Wasmtime，這讓他像是一個框架，而不單純是 Ruby Gem。

## 開源的意義{#meaning-of-open-source}

在 COSCUP 前夕，我反而因為 Kobako 這個專案的調性，以及現在 AI 時代的變化，重新思考「開放原始碼」到底是什麼？

自從開放原始碼變成熱門話題後，非常多公司都用開放原始碼的招牌推廣自家產品，直到近年還發現許多公司乾脆收回開放原始碼授權，或者根本就不是開放原始碼，更接近 Source Available（只把程式碼公開）這樣的概念。

也就是說，我們在網路上或者 GitHub 看到的大量專案，很可能都是不能自由修改也無法自己重現的，這樣還是一種「開放原始碼」嗎？實際上所謂的「開源模型」對於開源社群的人來說更接近「開放權重模型」的原因就是這樣，因為這些模型只是公開程式碼，但大家無法自己修改也很難重現。

總而言之，對我來說開放原始碼更像是一種「歡迎大家來改造成自己好用的形狀」這種感覺，我在把專案放到 GitHub 上時確實也是下意識的這樣思考，如果只是覺得小工具有用那就不會花太多心力在上面。

如果是 Kobako 這種類型，我則是會很仔細思考這些東西的公開介面是怎樣的，使用者可以怎樣去客製化，光是能提供這些，就能讓使用者省下很多的時間。

基本上這就是為什麼 Kobako 選 Ruby 的原因，他是個人喜好沒錯，但是背後所有的考量都是「不限於 Ruby」去設計。