--- title: "Kobako：為什麼要有 Filesystem 原生支援" date: 2026-10-21T00:00:00+08:00 publishDate: 2026-10-21T00:00:00+08:00 lastmod: 2026-10-19T20:33:04+08:00 tags: ["LLM","AI","經驗","Ruby","WebAssembly","Gem","mruby"] series: "kobako" toc: true permalink: "https://blog.aotoki.me/posts/2026/10/21/kobako-native-filesystem-support/" language: "zh-tw" --- 最近 Kobako 更新到 v0.28.0 後，改善了原本對 MessagePack 高度依賴的設計，這是從八月 COSCUP 結束後的第一個大改版。 然而，當我們要迎接明年（2027 年）的 AI 應用時，在 Ruby 生態系還缺少怎樣的能力，我認為答案再次回到[四月份我在日本 RubyKaigi 和朋友分享的](https://blog.aotoki.me/posts/2026/07/29/kobako-building-ai-era-sandbox/)「虛擬檔案系統（Virtual Filesystem）」上，因此 Kobako 也即將支援這個特性。 ## AI Native 按照我的印象，去年就開始有人提出這樣的概念，但當時呼叫模型還是很昂貴，要讓 Agent 自主地在一個環境中運作仍是困難，但到最近幾個月，不論是 GPT 系列模型的降價，或者 Claude 的 Haiku 5.5 也開始下降到足以支撐大規模使用，AI Native 這件事情就更加可行。 在這之中，我認為 Cloudflare 的生態系，也讓這件事情變得非常可行，他們推出了 [`@cloudflare/computer`](https://blog.cloudflare.com/zh-tw/cloudflare-computer/) 套件，深度整合 Cloudflare Workers 生態系，而且允許 AI 擁有一個自己的工作空間（Workspace）而且能夠在裡面編輯、修改檔案。 這對 AI Native 是非常重要的，直到目前為止大多數的 AI 應用情境都是在個人電腦中發生的，假設我離開電腦前面或者沒有開啟電腦，AI 就沒辦法運作，但是當我們擁有一個雲端的環境，像是 Claude Cowork 的虛擬機器，很多事情就得以實現。 如此一來，我們就可以在睡覺、聚餐或者任何時候，把任務交給一個 Agent 處理，而且是主動的，當事件發生（如：收到信、指定時間）就會自主的做完，等待人類確認或者審核，而這也是 AI Native 的核心概念，不是由人類驅動，而是自主的讓事情發生。 ## 按需使用{#on-demand} 如果要提供 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 的沙盒環境至少是及格的。 ## 可能性{#possibility} 既然原本 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 生態系有更多選項，仍是讓人期待的。