最近 Kobako 更新到 v0.28.0 後，改善了原本對 MessagePack 高度依賴的設計，這是從八月 COSCUP 結束後的第一個大改版。
然而，當我們要迎接明年（2027 年）的 AI 應用時，在 Ruby 生態系還缺少怎樣的能力，我認為答案再次回到四月份我在日本 RubyKaigi 和朋友分享的「虛擬檔案系統（Virtual Filesystem）」上，因此 Kobako 也即將支援這個特性。
AI Native
按照我的印象，去年就開始有人提出這樣的概念，但當時呼叫模型還是很昂貴，要讓 Agent 自主地在一個環境中運作仍是困難，但到最近幾個月，不論是 GPT 系列模型的降價，或者 Claude 的 Haiku 5.5 也開始下降到足以支撐大規模使用，AI Native 這件事情就更加可行。
在這之中，我認為 Cloudflare 的生態系，也讓這件事情變得非常可行，他們推出了 @cloudflare/computer 套件，深度整合 Cloudflare Workers 生態系，而且允許 AI 擁有一個自己的工作空間（Workspace）而且能夠在裡面編輯、修改檔案。
這對 AI Native 是非常重要的，直到目前為止大多數的 AI 應用情境都是在個人電腦中發生的，假設我離開電腦前面或者沒有開啟電腦，AI 就沒辦法運作，但是當我們擁有一個雲端的環境，像是 Claude Cowork 的虛擬機器，很多事情就得以實現。
如此一來，我們就可以在睡覺、聚餐或者任何時候，把任務交給一個 Agent 處理，而且是主動的，當事件發生（如：收到信、指定時間）就會自主的做完，等待人類確認或者審核，而這也是 AI Native 的核心概念，不是由人類驅動，而是自主的讓事情發生。
按需使用
如果要提供 Agent 自主執行的環境，大致上可以選擇把 Agent 執行在隔離環境內，或者提供 Agent 工具，並且讓這些工具在隔離的環境下執行。
以 Claude Cowork 的情境屬於前者，所以可以很輕鬆的在雲端上跑起來，至於 Claude Code 更接近後者，採取的是只有執行命令時會在隔離的環境下執行，控制影響範圍，兩種做法在不同的情境下都有優點跟缺點。
Cloudflare 則是善用 Workers 基於 V8 Isolate 的特性，在原生的隔離環境下執行 JavaScript 程式碼，再利用 JavaScript 模擬的虛擬 Shell 作為 Bash 工具來提供大多數 Agent 已經熟悉的操作方式，當需要檔案系統時，則更進一步利用 Durable Object 的 SQLite 模擬出虛擬檔案系統，那麼對 Agent 來說，就跟在一個接近真實的環境使用差異不大。
不過 Cloudflare 還可以更進一步，如果是需要真實用來開發的環境，還可以利用 Container 服務啟動容器，讓 Agent 從模擬的環境轉換到更真實的環境，大多數的應用情境下可以按照需求，使用不同費率的功能（Container 收費是按照執行時間，比 Durable Object 貴）
因為 Kobako 是受到 Cloudflare Workers 啟發，因此在虛擬檔案系統的條件是相同的，在更早之前的版本也有利用 Kobako 的 Binding 機制提供模擬的能力，因此作為 AI Native 的沙盒環境至少是及格的。
可能性
既然原本 Kobako 已經能做到虛擬檔案系統，為什麼還需要原生的能力呢？這是為了提供更多的可能性，並且按照不同的情境提供適合的能力。
Kobako 的 Binding 能力需要經過 MessagePack 的編碼，因此在內容達到 64 KiB 時會慢非常多，這幾乎無法避免，因為 Binding 的設計並不是為了一次性傳輸大量資料所設計，但這也限制了 Kobako 具備處理檔案的能力，這也包含 Ruby 應用需要傳輸比較大的資料時，會變成限制應用情境的問題。
原生的檔案系統就沒有這樣的限制，假設我們需要確認某個檔案是否存在，經過 Binding 路徑由 MessagePack 處理的路徑需要 2 microseconds 左右，但直接由原生的路徑只需要 0.2 microseconds 至少快了十倍以上。
另一方面，假設我們想處理一個比較大的檔案，在 Ruby 端存放到某個目錄後，可以直接在 Guest 讀取和處理，像是讓 Agent 寫一個按需的 CSV 處理工具就會變得很容易，也能夠讓 Agent 以串流的方式下載、處理檔案，原本有很多限制的情況都被解除。
除此之外，檔案系統對 UNIX 作業系統來說通常還具備另一層意義，網路傳輸也是透過類似的底層抽象實作的，這表示未來我們甚至能在 Kobako 直接存取網路、執行一個真正的 Agent 而且是完全隔離的，這還能再更進一步的讓更多應用情境出現。
Kobako 仍維持著最初的疑問「在 AI 時代，Ruby 還需要什麼？」這樣的問題繼續發展，雖然目前需要自己維護的範圍變得更大一些，但能讓 Ruby 生態系有更多選項，仍是讓人期待的。