當我們把 RPC、Handle、Block 等機制完成後，已經是一個很好用的 mruby 腳本環境，但是作為沙盒（Sandbox）最關鍵的能力就是「安全性」也就是執行任意腳本時，都當作有危險去看待，那麼就需要有各種防禦情境。

Kobako：Handle 機制對許多支援腳本語言的專案並不算太特殊的機制，但是 Block 概念算是 Ruby 語言特有的能力，如果使用沙盒（Sandbox）時無法善用，那就太可惜。

然而，像這樣的寫法真的做得到嗎？

1sandbox.bind("Seq::Map", ->(items, &blk) { items.map(&blk) })
2sandbox.eval("Seq::Map.call([1, 2, 3]) { |x| x * 2 }").value
3
4# => [2, 4, 6]

我們竟然可以在沙盒裡面用一個 Block 接收外部的呼叫。

週末花了一點時間讀 NVIDIA 新公開的 OpenShell 是怎麼做到沙盒（Sandbox）的網路安全，因為 Anthropic 和 OpenAI 提供的 Managed Agent 也有相似的功能，但並不能看到原始程式碼，也就只能推測可能是利用哪些技術實作。

讓我比較意外的是，OpenShell 文件有提供對 AI 提問的功能，我在沒有讀原始程式碼的前提下，很快就驗證我的假設，也大概理解到目前是怎麼解決憑證（Credentials）的問題。

最近 Kobako 更新到 v0.28.0 後，改善了原本對 MessagePack 高度依賴的設計，這是從八月 COSCUP 結束後的第一個大改版。

然而，當我們要迎接明年（2027 年）的 AI 應用時，在 Ruby 生態系還缺少怎樣的能力，我認為答案再次回到四月份我在日本 RubyKaigi 和朋友分享的「虛擬檔案系統（Virtual Filesystem）」上，因此 Kobako 也即將支援這個特性。

在 Kobako：執行腳本已經看過一個完整的運作是怎樣設計的，但是現有的設計還有一些不方便的地方，當我們想將一個 Ruby 的物件在沙盒（Sandbox）中呼叫時，卻很難直接使用到那些回傳值。

週末在評估 Tsuzuri 的前端框架該從 Stimulus 換到哪一套時，為了維持整體的輕量，評估過程中我打開了 Svelte 的教學文件，沒想到全程禁止複製貼上，倒是久違的手寫了一遍程式。

花一小時左右手寫後，我對於 Svelte 用很精簡的語法實作許多功能感到讚嘆，也開始思考讓 AI 實作時，還能找到這樣的驚喜嗎？

近期我印象最深刻的，是 YouTuber 壹加壹開發的 What’Sub 這套字幕工具，大多數情境只要有人需要處理影片字幕，我通常會直接推薦。

然而，時間往回推半年前左右，朋友來問我「有沒有辦法做逐字稿？」「有辦法對逐字稿做翻譯嗎？」的問題時，都有一個前提「不能用雲端」這就讓市面上大多數選項無法使用。

這個時代很棒的一點，就是 AI 讓任何人都能針對自己需求客製化，而 Tsuzuri 剛好在這樣的背景下誕生。

當我們有了標準輸出能力後，執行腳本是否正常就可以順利地被驗證，這表示我們可以開始真正的來把 Ruby 跑在 Kobako 的沙盒（Sandbox）環境下。

解決 mruby 在 WebAssembly 執行的基本條件後，是時候開始考慮能夠有更多實際的應用方式，至少要讓一個腳本可以執行，然後順利看到 Hello World 這樣的訊息，但是 mruby 本身的設計並沒有考慮 WASI（WebAssembly System Interface）環境，因此有很多 Gem 是無法使用的。

在 Kobako：WebAssembly 的記憶體交換中解決了 Ruby 和 WebAssembly 互動的問題，也讓 Ruby 和 mruby 的數值能夠有互相交換的能力，基本上已經把「沙盒（Sandbox）」的問題處理乾淨。

然而 Kobako 的開發仍在非常初期，因為還有許多實際使用才會遇到的問題需要解決，其中一個就是「決定怎麼停下來」這樣的問題。