關於 #LLM 的內容

開始 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 代理相關技術，這兩者看起來相似卻不太一樣。

AI（人工智慧）領域的發展非常快速，在二月之前我還不覺得以 AI 來寫程式是有效的，因為我需要複製程式碼到編輯器中，然而 My LLM codegen workflow atm 這篇文章改變了我的看法，因為有一些工具已經足夠成熟能直接編輯檔案。

有非常多額外內容，我會把下半年連載的展示專案跟閒聊另外放在 YouTube 影片 裡面討論。