RAG（檢索增強生成）是文件問答的標準解法，但它有個致命缺陷：只能回傳「匹配查詢的文字區塊」。當答案分散在多個頁面，或者用戶需要精確的語法細節時，RAG 就會卡在「選不到正確區塊」的困境。

Mintlify 的工程團隊想通了這件事：為什麼不讓 AI 像「瀏覽程式碼庫」一樣瀏覽文件？於是他們用虛擬檔案系統 ChromaFs 取代了傳統的沙盒環境，把會話建立時間從 46 秒縮短到 100 毫秒，邊際運算成本從每次會話 $0.0137 降為零。

這不只是一個技術優化，更是一次對「AI 如何理解結構化資訊」的重新思考。

RAG 的天花板：它永遠只能「猜」你在找什麼

當你在文件問答系統問「如何設置 API 金鑰的權限」時，RAG 系統會做什麼？它會把你的問題轉成向量，在資料庫中尋找「語義最相似」的文字區塊。如果文檔寫得清楚，這通常能找到正確的區塊。

但如果答案分散在三個頁面呢？如果用戶問的是「那個關於 RBAC 的 JSON 結構怎麼寫」，而那個具體的 JSON 語法剛好沒被切進前 5 個最相關的區塊呢？RAG 系統就會回傳「我找不到資訊」，或者更糟——基於不相關的區塊胡亂拼湊答案。

Mintlify 的團隊發現，這個問題的根源不在於「向量檢索不夠準確」，而在於「RAG 假設答案存在於單一區塊中」。當你真正探索文件時，你會：
– 用 ls 看看當前目錄有哪些章節
– 用 cat /auth/oauth.mdx 讀取完整的 OAuth 設置頁面
– 用 grep -r "permissions" 全站搜索「permissions」這個關鍵字出現的位置
– 用 find /api-reference -name "*.mdx" 找出所有 API 參考檔案

這些都不是「語義相似度檢索」，而是「結構化瀏覽」。AI agent 需要的是一個檔案系統，而不是一個向量資料庫。

顯而易見的解法：給 AI 一個真的沙盒

最直接的解法就是：把文件網站克隆到一個隔離的沙盒中，讓 AI 用真實的 UNIX 命令去操作它。這個方案有兩個致命問題。

第一個問題是延遲。Mintlify 的 P90 會話建立時間（包括 GitHub clone 和其他設置）大約是 46 秒。當一個用戶正在等載入動畫時，幾乎半分鐘的冷啟動時間是不可接受的。

第二個問題是成本。如果每月有 850,000 次對話，即使是最小的沙盒配置（1 vCPU, 2 GiB RAM, 5 分鐘會話生命週期），根據 Daytona 的按秒計價（每 vCPU $0.0504/小時，每 GiB RAM $0.0162/小時），光是沙盒成本就會超過每年 $70,000。如果會話時間拉長，成本會直接翻倍。

這是基於一個非常天真的估算——真正的生產環境應該會有暖池和容器共享，但重點很清楚：為了「讀取靜態文件」而跑一個完整的虛擬機，是資源的嚴重浪費。

重新思考：Agent 不需要真實檔案系統，只需要「幻覺」

Mintlify 的文件已經被索引、切分並存儲在 Chroma 資料庫中，用於驅動他們的搜索功能。既然資料已經在 DB 裡了，為什麼不直接「偽裝」成一個檔案系統？

這就是 ChromaFs 的核心想法：一個虛擬檔案系統，它攔截 UNIX 命令並將它們轉換成針對 Chroma 資料庫的查詢。會話建立時間從 ~46 秒降到 ~100 毫秒，而且因為 ChromaFs 重用了已經存在的基礎設施，邊際每次對話的運算成本是零。

具體來說：

指標 沙盒 ChromaFs
P90 啟動時間 ~46 秒 ~100 毫秒
邊際運算成本 ~$0.0137/會話 $0（重用現有 DB）
搜索機制 線性磁碟掃描 DB 中繼資料查詢
基礎設施 Daytona 或類似提供商 已建置的 DB

技術實作：用 just-bash 攔截檔案系統調用

ChromaFs 建立在 Vercel Labs 的 just-bash 之上，這是一個用 TypeScript 重寫的 bash，支援 grep、cat、ls、find 和 cd 等基本命令。just-bash 暴露了一個可插拔的 IFileSystem 介面，所以它負責所有的解析、管道和標記邏輯，而 ChromaFs 負責將每個底層檔案系統調用轉換成 Chroma 查詢。

這個架構的巧妙之處在於：AI agent 完全不知道自己在操作一個「虛擬」檔案系統。從它的角度看來，它就是在跑標準的 UNIX 命令。

目錄樹的初始化：把 DB 變成檔案系統結構

ChromaFs 需要在 agent 執行任何命令之前就知道哪些「檔案」存在。Mintlify 將整個檔案樹存儲為一個壓縮的 JSON 文檔（__path_tree__）在 Chroma 集合裡：

{
  "auth/oauth": { "isPublic": true, "groups": [] },
  "auth/api-keys": { "isPublic": true, "groups": [] },
  "internal/billing": { "isPublic": false, "groups": ["admin", "billing"] },
  "api-reference/endpoints/users": { "isPublic": true, "groups": [] }
}

初始化時，伺服器獲取並解壓縮這個文檔，轉換成兩個記憶體中的資料結構：
– 一個 Set<string> 存儲檔案路徑
– 一個 Map<string, string[]> 將目錄映射到子項目

一旦樹建立完成，ls、cd 和 find 在本地記憶體中解析，不需要任何網絡調用。樹是被快取的，所以同一個網站的後續會話會完全跳過 Chroma 獲取。

存取控制：比 Linux 權限更靈活的設計

注意 isPublic 和 groups 欄位。在建構檔案樹之前，ChromaFs 會使用當前用戶的會話 token 修剪 slug，並對所有後續的 Chroma 查詢應用匹配的過濾器。如果一個用戶無法存取某個檔案，該檔案會被完全從樹中排除，所以 agent 既不能存取它，甚至無法引用被修剪的路徑。

在真實的沙盒中，這個層級的每用戶存取控制需要管理 Linux 使用者群組、chmod 權限，或為每個客戶層級維護隔離的容器映像。在 ChromaFs 裡，這只是在 buildFileTree 執行前的幾行過濾。

舉例來說，假設當前用戶的群組是 “none”：

路徑 存取 是否可見
/auth/oauth.mdx public ✓
/auth/api-keys.mdx public ✓
/internal/billing.mdx admin, billing ✗
/internal/audit-log.mdx admin ✗
/api-reference/users.mdx public ✓
/api-reference/payments.mdx billing ✗

這種設計意味著每個用戶看到的「檔案系統」都是不同的，但不需要建立不同的沙盒環境。

從區塊重組頁面：cat 命令的實作

Chroma 中的頁面被分割成區塊用於嵌入，所以當 agent 執行 cat /auth/oauth.mdx 時，ChromaFs 會獲取所有匹配該頁面 slug 的區塊，按 chunk_index 排序，並將它們組合成完整的頁面。結果被快取，所以在 grep 工作流中重複讀取永遠不會打到資料庫兩次。

不是每個檔案都需要存在於 Chroma 中。Mintlify 註冊了延遲檔案指標，在存取時解析存儲在客戶 S3 桶中的大型 OpenAPI 規格。agent 在 ls /api-specs/ 中可以看到 v2.json，但內容只在執行 cat 時才獲取。

唯讀檔案系統：確保狀態安全

每個寫入操作都會拋出 EROFS（唯讀檔案系統）錯誤。agent 可以自由探索，但從不會改變文件，這使得系統無狀態化，無需會話清理，也沒有一個 agent 污染另一個 agent 視圖的風險。

這個設計很關鍵：在文件問答的場景中，AI 不需要「編輯」文件，它只需要「理解」文件。把檔案系統設為唯讀，不只是一個權限問題，更是一個設計哲學——問答不應該改變源資料。

grep 的優化：從資料庫到記憶體

cat 和 ls 很容易虛擬化，但 grep -r 如果天真地對每個檔案進行網絡掃描會太慢。Mintlify 攔截 just-bash 的 grep，用 yargs-parser 解析標記，並將它們轉換成 Chroma 查詢（固定字串用 $contains，模式用 $regex）。

Chroma 充當粗過濾器，識別哪些檔案可能包含命中，然後將匹配的區塊大量預取到 Redis 快取中。從那裡，他們重寫 grep 命令，只針對匹配的檔案，並交回 just-bash 進行記憶體中的精細過濾執行。這意味著大型遞迴查詢在毫秒內完成。

實際運算：30,000 次對話/天的文件助理

ChromaFs 目前為數十萬用戶提供文件助理，每天處理 30,000+ 次對話。通過用虛擬檔案系統取代沙盒，他們獲得了：
– 即時會話建立
– 零邊際運算成本
– 無需新基礎設施的內建 RBAC

這不只是一個 Mintlify 的最佳實踐，它揭示了一個更大的趨勢：AI agent 正在趨同於將檔案系統作為它們的主要介面。grep、cat、ls 和 find 是一個 agent 需要的全部。如果每個文檔頁面是一個檔案，每個章節是一個目錄，agent 可以搜索精確字串、讀取完整頁面，並自行遍歷結構。

這件事對開發者意味著什麼？

對於正在構建 AI 應用的開發者，ChromaFs 提供了幾個重要的啟示：

  1. 重新思考你的檢索策略：如果你的應用涉及結構化資訊（如文件、程式碼庫、設定檔），純向量檢索可能不是最佳解。考慮把資料「偽裝」成檔案系統，讓 agent 用自然的探索方式操作它。

  2. 善用你已有的基礎設施：Mintlify 沒有為此建立新資料庫，他們重用了已有的 Chroma DB。虛擬層的成本是固定的，邊際成本是零。

  3. 權限控制不一定要在作業系統層：在應用層處理 RBAC（基於角色的存取控制）通常比管理 Linux 權限或容器隔離更靈活、更安全。

  4. 唯讀是一個特性，不是限制：如果你的場景是「讀取和問答」，把檔案系統設為唯讀可以大幅簡化架構。無需狀態管理，無需清理，無需擔心並發寫入。

未來的文件助理會長什麼樣？

隨著越來越多團隊採用類似的「檔案系統」介面，我們可能會看到：
– 標準化的「文件檔案系統」格式（類似於 OpenAPI）
– 能夠跨多個文件站點的 agent（像是全域的 grep）
– 檔案系統層級的智慧提示（agent 執行 ls 時自動標註「這是最熱門的章節」）

但無論技術如何演進，核心不變：AI 最強大的能力不是「生成文字」，而是「理解和操作結構」。當你給了它一個檔案系統，你給了它一種人類最自然的探索方式。

而這，正是下一波 AI 應用競爭的起跑線。

本文基於 Mintlify 官方部落格技術文章改寫。所有數據和技術細節來自 Mintlify 的公開分享。

你可以這樣試試看

如果你有 Mintlify 的文件站，或者想體驗這個文件助理，可以直接訪問 mintlify.com/docs。在對話框中，試試問：
– 「列出所有 API 端點的檔案」
– 「搜尋所有提到『權限』的段落」
– 「讀取 OAuth 設置頁面的完整內容」

你會發現它回答的方式不像一個「搜尋引擎」，而像一個「正在瀏覽檔案系統的開發者」。

這就是虛擬檔案系統的力量。