Kobako on 弦而時習之

Kobako：Cold Start 原來能快 100 倍？

contact@aotoki.me (蒼時弦也) — Wed, 17 Jun 2026 00:00:00 +0800

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

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

預先編譯

WebAssembly 經過多年發展後，已經有很多新的技術跟規格，其中 cwasm（Wasmtime 把 .wasm 預先編譯後的產物）就是一種 AOT（Ahead-of-Time，預先編譯）的處理方式。

原因在於，我們編譯為 wasm 格式後，是針對 WebAssembly 的虛擬機器所設計，如果拿來跑 mruby 大致上就是在一個 WebAssembly 虛擬機器中，再啟動一個 mruby 虛擬機器，套了兩層在運作。

透過 cwasm 處理，會先在運行的環境直接編譯成當下環境 CPU 對應的機器碼，那就無限接近於把 WebAssembly 虛擬機器消除，只留下 mruby 虛擬機器的成本，啟動速度就從 500 ms 縮減到 5 ms 左右，因此 Cold Start 的時間馬上快上 100 倍。

簡單來說，Kobako 本身並沒有做太多處理，只是很單純的透過 WebAssembly 的標準，就極大的加速到跟一次簡單的 SQL 查詢差不多，對大部分應用幾乎等同無感。

今年 RubyKaigi 中 Matz 的新專案 Spinel 正好就是一種 Ruby 的 AOT 編譯器，至於 cwasm 我則是第一次接觸到，畢竟過往都還停留在 wasm 的認識，這次跟 AI 協作意外學到新的概念。

預先偷跑

當在裝置上啟動過一次 Kobako 後，後續的 Cold Start 就會因為 AOT 從 500 ms 變成只要 5 ms 就能啟動完畢，那麼 Kobako::Sandbox.new 也能變快嗎？

原本的設計上，我們會把每個 Kobako::Sandbox.new 都獨立建立一個實例（Instance）並且在每次 #run 或者 #eval 時重新初始化 mruby 虛擬機器，確保可重用與乾淨隔離，但每多一個沙盒就會多佔用約 560 KB 的記憶體，對於希望「大量產生、刪除」的設計不太友善，當數量增加記憶體就會急劇消耗，而且還有一個初始化的時間約 130 µs 的成本在，即使這已經非常快。

Wasmtime 提供了一個叫做 wizer 的機制，我們可以預先把運行的記憶體準備好。這是因為每次啟動新的 mruby 虛擬機器時，對所有使用相同 .wasm 的 Kobako::Sandbox 是完全相同的記憶體，那麼預先把把 mruby 虛擬機器跑到啟動好的狀態存到 .wasm 中，未來啟動時就不需要再次去計算。

接下來搭配 Wasmtime 的 InstancePre 和 Copy-on-Write 兩個設計，就可以把啟動時間跟記憶體使用壓的更低。

InstancePre - 把 Kobako 的 ABI（Application Binary Interface，應用程式二進位介面）先計算好，未來重新利用，不用每次都計算
Copy-on-Write - 建立新的 Kobako::Sandbox 時，使用同一份 Baked 的 mruby 虛擬機器，不另外建立

透過這些處理，做一次 Kobako::Sandbox.new 的時間，就從 130 µs 降低到 30 µs 左右，記憶體使用從 560 KB 減少到 1 KB，因為不再需要每個沙盒都保存完整的記憶體，在有改變之前都會使用同一份基礎。

設計取捨

原本在我的預期中，會透過消耗相對多的記憶體去換取更快的速度，但結果反而出乎我的預期，在速度跟記憶體使用上都得到很大的提升，更快地幫助我把專案推進到可以正式上線的等級。

尤其是這次用到的技術，很多都不是新技術，而是建構在已經被使用多年的機制。但透過 AI 的輔助，我很快的挖掘出這些技術，並且放置到恰當的位置。

這對軟體工程師這個職業的影響，依舊還是對應我們所熟知的衝擊，有經驗的工程師更有價值，原因就是「無條件接受」跟「有意識篩選」是兩件事情，後者是專業工程師的素養，在這次改版之前，我已經直覺的「可以用 Cache 重用」這樣的直覺判斷，先減少「每次都要等 500 ms」變成只等一次。

然而當整體功能完善後，考慮到每次啟動的時間跟佔用的記憶體，就讓我開始思考「還能更好嗎？」但受限於對 WebAssembly 技術不是熟悉的情境，透過 AI 大量搜集資料、探索，很快就確認 AOT、Bake 等技術是合理且有幫助的，分段處理（如果 AOT 不成立，做 Bake 大概也沒差異太大）一步一步推進來達到更好的成果。

我認為這在 AI 時代是很值得思考的問題，我們從 AI 身上拿到的「加速」是什麼？以 Kobako 的案例，整個專案極大的提升背後，是快速搜集資料，以及對軟體開發知識的熟悉得出適當的判斷。

Kobako：讓 Agent 安全的操作 Rails

contact@aotoki.me (蒼時弦也) — Wed, 20 May 2026 00:00:00 +0800

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

沙盒選擇：為什麼是 WebAssembly

要打造 AI Agent 可以運行的環境有很多路線，像是虛擬機器（Virtual Machine）、容器技術、WebAssembly 都可以實現。

目前有哪些路線，可以讀 Agent Sandbox 沙箱架構: 論兩種設計模式與七種隔離方式這篇文章的整理

選擇哪一種技術，就會影響到後續技術發展的路線，以及可以做的事情，在搜集現有的解決方案跟技術後，最終只能走自己開發。

舉例來說，Shopify 有 mruby-engine 的技術，這是相當理想的選項之一，但是這個做法只能保證 Host（宿主）跟客體（Guest）不是直接互通的，如果運行的 Ruby 腳本針對記憶體或是一些攻擊，都很容易打穿，給 Agent 使用強度還是稍嫌不足。

如果選虛擬機器或者容器技術，最大的困難是對環境的要求相對嚴苛，這種嚴苛對小專案或者開發都會有不少限制，所以最後 Kobako 選擇 WebAssembly 的路線，有類似虛擬機器的 WASI 標準，跟直接跑 mruby 來說，犧牲一些啟動、運行速度，換到更好的隔離性還算是划算。

後來 Shopify 也有投資元在 wasmtime 讓 ruby.wasm 可以替代原本 Shopify 的腳本功能，也因此 ruby.wasm 也是我考量的選項之一，但最終因為 ruby.wasm 本身的限制，讓我走向不同的路線。

WASI 的限制與 Kobako 的取捨

WASI 全名是 WebAssembly System Interface，簡單來看，是一種讓我們在 WebAssembly 環境中獲得類似 UNIX 介面的架構，像是 ruby.wasm 就是使用 Preview 1 版本的標準，並且正在測試 Preview 2 的標準。

然而，這個介面設計的非常的差，以 Preview 1 來說，除了有 Stdin / Stdout / Stderr 等介面，以及類似 VFS（Virtual File System）的機制外，基本上沒什麼能做的事情，也不支援 I/O 之類的行為，這也造成 Kobako 在評估是否要用 ruby.wasm 當基底時，只能放棄這條路線。

即使 ruby.wasm 能用，也不一定是好的選項，因為本身需要載入 20 MB 左右的 Ruby 環境，加上啟動時間可能還比容器技術慢

目前 WASI 有 Preview 1 ~ Preview 3 個不同版本，後面要建置跟編譯也有不同類型的麻煩，最後 Kobako 選比較穩定和普及的 Preview 1 標準來實作，跟 ruby.wasm 的差異在於額外的 ABI（Application Binary Interface）來實現一個 In-Memory RPC 的溝通，讓 Sandbox 中的 Ruby 腳本能夠呼叫 Host 提供的方法。

這也是沒有選擇 ruby.wasm 的主要原因，如果想增加 ABI 就必須完整編譯 ruby.wasm 背後的開發成本跟困難度會極大上升，但是 mruby 設計給嵌入式系統的特性反而就很適合。

在今年 RubyKaigi 也有 Uzumibi: Reinventing mruby for the Edges 這樣的主題，剛好呼應 Kobako 想要實現 Cloudflare 針對 MCP 問題所提出的 Code Mode 想法，同樣是從 Edge 環境運行為出發點，mruby 的規模也剛很好適合。

RPC：讓 Sandbox 與 Host 溝通

Kobako 受到 druby 啟發的地方，就是 druby 巧妙的運用 Ruby 語言特性來實現 RPC 機制，以下是 Kobako 實際使用的範例。

1User = Data.define(:name)
2
3sandbox = Kobako::Sandbox.new
4sandbox.define(:App).bind(:User, User.new(name: "Aotoki"))
5
6sandbox.run(<<~RUBY)
7 "Hello, #{App::User.name}"
8RUBY
9# => "Hello, Aotoki"

在 Sandbox 中，要怎麼知道 Host 端提供了 App::User 而且有 #name 這個方法呢？

Kobako 在每次 Sandbox#run 的時候，都會自動注入像這樣的程式碼：

1class App::User < Kobako::RPC::Client; end
2# ...

然後，就沒有然後，我們的 Sandbox 環境就能自然地知道 #name 可以呼叫，這是因為 Ruby 語言天生支援這樣的實作，因此 Kobako::RPC::Client 實現了這樣的行為

1class Kobako::RPC::Client
2 def method_missing(name, *args, &block)
3 __kobako_rpc_call__(name, *args)
4 end
5end

這個 __kobako_rpc_call__ 是利用 Rust 所定義的 ABI，負責將 Method Call 轉到 WebAssembly 外面，等外面回覆後再轉發回 WebAssembly。透過這個機制，就能在隔離性跟可擴充性之間達到平衡。

套用到 Rails 的情境，原本要整合 AI 需要重新設計跟定義工具，但是原本就有做不錯的 Service Object 封裝跟權限控管，就只需要利用 RBS 向 AI 說明介面定義，讓 Agent 自動轉寫操作的腳本即可。

 1sandbox = Kobako::Sandbox.new
 2ns = sandbox.define(:Merchant)
 3ns.bind(:Product, ProductManagementService.new(actor: current_user))
 4# - ProductManagementService#where
 5# - ProductManagementService#update
 6# - ...
 7
 8# Agent Tool
 9def execute_code(code)
10 sandbox.run(code)
11end
12
13# Merchant::Product.where(name: "%macOS%")
14# => [#<Product id=1>, #<Product id=2>]

這也是 Cloudflare 為什麼需要用他們的 Cloudflare Worker 底層技術，改造出 Code Mode 的使用方式，因為這樣可以很快的把大量 API 整合進去，但不需要提供大量的工具。

Cloudflare Code Mode 提供一個值得思考的選擇，利用 LLM 本身的程式能力來解決問題，Kobako 則從 Ruby 生態系提取經驗，讓這種整合更加無縫。Kobako 專案目前也有 examples/codemode 的範例，可以使用 OpenAI 相容的 API 或者本地 Ollama / LMStudio 搭配 Gemma 4 體驗 KeyValue Store + WebFetch 的功能，有興趣的可以嘗試看看。