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

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

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

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

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

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

Kobako 的開發過程中有蠻多有趣的案例，延續上一篇 Kobako：用 AI 開發終究會翻車？的經歷，後續又再次撞到新的問題，而且是過去開發很擔心看到的 Segmentation Fault 錯誤，這表示在 Rust 和 WebAssembly 這段非 Ruby 的地方，很高機率做錯。

上週發表 Kobako：讓 Agent 安全的操作 Rails 介紹 Kobako 這個 Gem 的目標後，繼續透過 Claude Code 推進開發進度，然而很快地就遇到要大幅度修改的狀況，這難道就是使用 AI 開發的宿命嗎？

這是很值得討論的問題，也就是使用 AI 協助開發，到底是因為 AI 能力不足所以做不好，還是人類給的設計太差。

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

去年流行過的 Ralph Loop（一種讓 AI Coding Agent 自動重複執行的技巧）當時我並不太信任這種做法是否足夠安全，以及能有足夠的穩定性。

前幾個月 Claude Code 的更新加入了 /loop 技能，本質上是利用 Claude Code 內建的 Cron 工具，以固定間隔重複特定的提示詞（Prompt）來做到類似的效果，至少更安全、可控。

然而，事情通常不會這麼單純。

之前寫過該有自己的 Agent Skills 嗎？來說明我認為每個人都該維護自己的技能，然而另一個現象是很多「厲害的技能組合」真的有這麼神奇嗎？

就我自己的經驗，即使不用這麼多內容也一樣運作得非常好，放這麼多可能更浪費 Token 還有機會影響表現。

最近因為工作的關係，需要對 AI 代理人（AI Agent）進行評估，也順便做了 Agentic AI（代理式 AI）的比較。如果你也在評估或導入 AI 代理相關技術，這兩者看起來相似卻不太一樣。

我經常看到「某某工具超強」的討論，但實際用了別人的 Agent Skill 後，往往發現不太順手，效果也跟預期有落差。更何況讓任意的人提供你 Agent Skill 從安全角度來看也非常危險，因為我們會授權給 Agent 做很多事情，遠比工具軟體危險更多。

除了安全以外，還有很多理由應該要有一套自己的 Agent Skill 會更好。