---
title: "Kobako：打造 AI 時代的沙盒"
date: 2026-07-29T00:00:00+08:00
publishDate: 2026-07-29T00:00:00+08:00
lastmod: 2026-07-27T21:53:30+08:00
tags: ["LLM","AI","經驗","Ruby","WebAssembly","Gem","Harness Engineering"]
series: "kobako"
toc: true
permalink: "https://blog.aotoki.me/posts/2026/07/29/kobako-building-ai-era-sandbox/"
language: "zh-tw"
---


開始 [Kobako](https://github.com/elct9620/kobako) 的開發已經有幾個月的時間，接下來也會在 [COSCUP](https://coscup.org/2026/session/KZ9PTY) 分享這個專案，因為過程非常有趣，我認為很適合做一系列的更新，來介紹我怎麼開始「打造 AI 時代的沙盒」

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

<!--more-->

## 未來需要什麼？{#what-we-need-in-future}

2026 年 4 月，出發到日本 [RubyKaigi](https://rubykaigi.org/2026/) 前夕，正好 Harness Engineering（駕馭工程）變得熱門起來，裡面有許多不同的主題，其中一個比較少被關注，但剛好各大公司都默默做了一些解決方案的，就是沙盒（Sandbox）技術。

現有的方案很多，像是虛擬機器（Virtual Machine）、微型虛擬機器（microVM）、容器技術（Container）等都是選項，最大的差別在對環境的要求，越接近虛擬機器隔離性越好，但對小專案或者開發時的限制也越多。相較之下 WebAssembly 輕量很多，也被劃分在選項之一，讓我稍微記住這件事情。

RubyKaigi 在和人聊天時提到相關話題，我才想起來我對未來的判斷中，認為沙盒跟虛擬檔案系統（Virtual File System）大概會是關鍵之一，畢竟都是用於運行不被信任的程式碼，非常有效隔離、更容易確保安全的選項。

## Ruby 有沙盒嗎？{#the-sandbox-available-in-ruby}

在 RubyKaigi 期間我開始思考這個問題，結論是在對 AI 安全的情境下，很可能只有 [ruby.wasm](https://github.com/ruby/ruby.wasm) 符合條件，至少在 Harness Engineering 看到的候選條件中，幾乎都有相對強的隔離性，因此 WebAssembly 跟主程式記憶體隔離，內部跑獨立的虛擬機器的架構，更符合條件。

剛好該年度的 Code Party（由贊助商提供餐點和場地，跟開放原始碼專案作者協作）有 [dRuby](https://github.com/ruby/drb) 專案的作者，帶大家體驗 `drb` 這個歷史悠久的標準功能，這個 Gem 巧妙的利用 Ruby 語言特性，在數百行左右的規模就讓 Ruby 能做到 RPC（Remote Procedure Call）。

```ruby
# Client
class Proxy
  def method_missing(method, *args, **kwargs)
     raise if @target.respond_to(method)
     
     @server.send(method, *args, **kwargs)
  end
end

# Server
server = Server.new
object = Hash.new
server.bind(object) # Use `object` to handle remote call
```

原理上，當我們用 TCP 監聽時，會收到「我要呼叫某某方法」這樣的請求，此時 dRuby 會直接對 Proxy 物件呼叫，因為方法不存在就會由 `method_missing` 捕捉，最後轉發給真正的物件。

> 實際運作還有不少細節，這只是展示概念，並不是真實的 dRuby 實作

這樣的機制非常巧妙，我們可以在幾乎不特地定義 Server 和 Client 兩側的介面，只需要借助 Ruby 語言能動態處理未知方法的特性，就讓物件可以在遠端運作。我也因此受到啟發，開始思考如何讓 Ruby 跟 `ruby.wasm` 輕鬆互動的方式。

## 想法不同{#expectation-is-different}

目前 `ruby.wasm` 是基於 WASI Preview 1（WebAssembly System Interface）為基礎，但這個版本把所有 I/O 能力鎖定，也因此想直接藉由 CRuby 原生的 dRuby 能力通訊，直接失效，也無法利用像是 WASI 的 `stdio` 來互動，因此一開始的想法就完全無法實現。唯一符合隔離條件的選項，剛好卡在最需要的通訊能力上，最後也只能走自己開發這條路。

實際上這也是合理的，市面上大部分的解決方案，像是虛擬機器、容器等技術，在設計初期要應付的都不是 AI 生成、不可信任的程式碼，大部分都還是可信任，或者可以控制的前提。

最大的不同是，我想走的路線更接近 Cloudflare 提出的 [Code Mode](https://blog.cloudflare.com/code-mode/)，這本身就是沙盒技術的一種應用，LLM 寫出來的程式碼，就在 V8 的隔離環境執行，內建服務也能很自然的擴充。要讓 WebAssembly 裡的 Ruby 能呼叫外面的 Ruby，才能打造容易擴充和使用的沙盒。

在 RubyKaigi 期間，我同時思考有怎樣的替代方案可以達成目的。在搜集一些資訊後，選擇利用 WebAssembly 的 Host Linker（宿主連結器，讓 Guest 環境能呼叫 Host 註冊的函式）來處理，並且把 Kobako 的目標定調為「輕量」與「容易使用」來開發。

這是從我對使用 Ruby 開發軟體的期待，以及現況所得出最佳的情境，使用 WebAssembly 搭配 [mruby](https://github.com/mruby/mruby) 基本上可以非常輕量，使用 Host Linker 也很容易和 mruby 的 C API 一起協作，因為 Host 和 Guest 都使用 Ruby 對原本熟悉 Ruby 的開發者也會變得非常容易使用。

剩下的就是如何保持介面單純，以及輕量（啟動、呼叫都是流暢）要解決，這就開啟這長達數個月 Kobako 開發的旅程。

現在回頭看，這些選項本身都沒有問題，其他公司也都還在用，只是把我想要的條件拿去篩選之後，剩下 WebAssembly 搭配 mruby 最符合。