最近 LlamaIndex 連發了三篇關於「檔案」與 AI Agent 關係的文章，加上 Turso 推出的 AgentFS、Arize AI 從硬體記憶體階層的角度分析 agent 記憶管理，以及社群裡關於「filesystems are just bad databases」的辯論，這個話題蠻值得整理一下的。

核心觀點是: 檔案系統正在成為 Agent 與世界互動的主要介面。不是什麼新發明，就是你電腦上最原始的那個檔案系統。

為什麼是檔案?

LlamaIndex 的 Jerry Liu 在 Files Are All You Need 裡觀察到，現在 coding agent (Claude Code、Cursor 等) 跟外部世界互動的方式，核心其實就是檔案操作。Agent 不需要一百個 MCP tool，它只需要:

  • CLI 存取檔案系統
  • Code interpreter
  • Web fetch

這樣就夠通用了。他歸納了三個主要用途:

1. 長期記憶儲存

Context window 還是有限的。Claude Code 的做法是用 Claude.md 檔案讓 agent 在啟動時載入上下文。Cursor 更進一步，在 context compaction 時自動把對話歷史存成可搜尋的檔案，之後 agent 覺得資訊不夠時可以自己回去翻。Dex Horthy 的 Research → Plan → Implement 流程也是同樣思路: 每個階段都寫成 .md 檔，讓 compaction 後的 agent 還能接得上。

2. 取代傳統 RAG

這點比較有意思。Agent 搭配檔案搜尋工具 (grep、Read)，可以像人一樣掃描檔案、上下捲動，動態找到需要的資訊。LlamaIndex 自己的實驗發現，在中小型文件集合上，純檔案搜尋的正確性和相關性竟然優於傳統 RAG (8.4 vs 6.4 correctness, 9.6 vs 8.0 relevance)。原因很直覺: RAG 會因為 chunking 和次優的 retrieval 丟失上下文，但 agent 可以讀完整個檔案。

不過公平講，這個優勢在大規模時會消失。他們把實驗擴展到 1000 篇論文時，RAG 在速度上大幅領先，正確性也略勝。所以結論不是「RAG 已死」，而是小規模用檔案搜尋更省事，大規模還是需要向量索引。

3. 取代 MCP 的 Skills 機制

Simon Willison 早就說了: Skills 可能取代 MCP。與其給 agent 一堆 MCP tool，不如給它一堆 .md 檔案 + CLI + code interpreter。好處很明確:

  • 定義簡單，複製貼上 API spec 就好
  • 不會像 MCP 一樣一次灌 100k tokens 進 context window
  • Agent 可以透過程式碼靈活操作任何 API，不受 tool schema 限制

AgentFS: 讓檔案系統更安全

但直接讓 agent 操作你的真實檔案系統是有風險的。Turso 的 AgentFS 解決的就是這個問題: 它是一個基於 SQLite 的虛擬檔案系統，專門給 agent 用。

核心概念:

  • 所有操作都在虛擬副本上進行，不動你的真實檔案
  • 完整的審計軌跡: 每個檔案操作、tool call 都記錄在 SQLite 裡
  • 可快照、可還原: cp agent.db snapshot.db 就能備份整個 agent 狀態
  • 單一檔案可攜帶: 整個 agent 的運行狀態就是一個 .db 檔

LlamaIndex 的第三篇文章示範了怎麼把 AgentFS 整合進 Claude Code: 用 MCP 包裝虛擬檔案系統的 read/write/edit，然後用 hook 禁止 agent 使用內建的真實檔案工具。agent 改完檔案後，再由人決定要不要同步回真實檔案系統。

這個模式蠻優雅的: agent 有完整的檔案操作自由度，但一切都在沙盒裡。

從 CPU 快取到 Agent 記憶: 階層式記憶管理

Arize AI 最近發了一篇很有意思的文章 Hierarchical Memory Management in Agent Harnesses，從硬體記憶體階層的角度來看這件事。

他們的核心類比是: 1980 年代 CPU 面臨的記憶體問題，跟今天 agent 面臨的 context window 問題本質上是一樣的。當年 Commodore 64 只有 64KB 記憶體，後來靠 cache、RAM、虛擬記憶體建立了階層架構，讓程式「感覺」記憶體是無限的。今天 agent 的 context window 也是有限的，而檔案系統 + Unix 指令就扮演了類似的角色 — 讓 200K tokens 感覺像 200 兆 tokens。

他們比較了 Cursor、Claude Code 和自家的 Alyx agent，發現大家都收斂到同一組核心工具:

  • grep / ripgrep: 跨檔案搜尋字串或 regex
  • ls: 列出檔案，建立索引
  • find: 定位檔案和目錄
  • sort / uniq / cut: 結構化處理搜尋結果

動態索引 vs 傳統索引

這篇文章最有啟發性的觀點是把 Unix 指令理解為「動態索引產生器」。傳統資料庫的索引是預先建好的，佔儲存空間但查詢快。Unix 指令產生的索引是即時的、暫時的 — grep 的輸出不存在任何地方，它只在 pipe 裡流過，但語意上它就是一個「查詢 → 位置」的對映表。

  傳統索引 動態索引 (grep/ls)
建立時機 預先計算 查詢時即時產生
是否儲存 是 否 (暫存在 pipe 中)
成本 儲存 + 維護 CPU 運算
彈性 固定 schema 任意 pattern
可組合性 有限 無限 (pipe!)

這個對比很精準。Agent 不需要預先知道資料長什麼樣，它可以用 Unix 指令即時探索、篩選、組合，動態建立自己需要的「索引」。

實際案例: 一萬個檔案裡找澳洲地址

他們設計了一個評測: 給 agent 10,000 個包含姓名地址的檔案，其中只有一個檔案包含澳洲地址 (檔名看不出來)，要求找出澳洲地址並計數。

Claude Code 和 Cursor 的解法都是先用 grep 搜尋關鍵字縮小範圍，再用 cut、sort、uniq 做結構化處理，最後把結果放進 context window 回答問題。過程中 Claude 甚至會自我修正 — 發現某個指令的輸出太大塞不進 context window，就退回去換一個策略。

這種「動態自我修正」的能力，正是檔案系統 + Unix 指令比靜態 RAG 更靈活的地方。RAG pipeline 是預先設定好的，出錯了就是出錯了。Agent 碰到問題可以即時調整策略。

從檔案系統到資料庫: 記憶階層的延伸

Arize 自家的 Alyx 更進一步: 面對大量 trace 資料 (單筆資料可能就跟整個 context window 一樣大)，他們用截斷預覽 + ID 查詢的方式，讓 agent 先看摘要，再按需載入完整資料。這本質上就是一個多層記憶架構。

他們也坦承，當資料量大到連檔案系統都放不下時，就需要資料庫層。他們的結論是: 未來的 agent 記憶架構會是一個階層 — 從 context window、到檔案系統、到資料庫 — 就像 CPU 的 cache → RAM → disk 一樣。

「Filesystems are just bad databases」

不過也不是所有人都認同這個方向。Leonie (Weaviate 的 Developer Advocate) 在 Twitter 上提出了反面觀點: 檔案系統本質上就是一個很爛的資料庫。

這個批評其實有道理。檔案系統的問題很明顯:

  • 沒有 schema: 資料格式完全靠 convention，沒有強制約束
  • 搜尋能力差: grep 能做的事情有限，跟向量搜尋或全文索引沒得比
  • 不擴展: 到了上千上萬個檔案，ls + grep 就撐不住了
  • 沒有 transaction: 多 agent 同時寫檔案很容易出問題
  • metadata 管理原始: 檔案的 metadata 就那幾個欄位，想加自訂屬性得靠 workaround

有意思的是，AgentFS 的做法某種程度上驗證了這個批評 — 它把檔案系統的介面保留了，但底層換成 SQLite 資料庫。等於承認: agent 需要檔案系統的介面，但不需要檔案系統的實作。

我的看法

這件事的本質是: 檔案是 LLM 最自然的介面，但不一定是最好的儲存方式。

LLM 天生就理解文字檔案。你不需要教它什麼是 .md、.py、.json，它讀了就懂。相比之下，要讓 LLM 理解向量資料庫的 schema、SQL 查詢語法，門檻高很多。這就是為什麼 coding agent 自然而然走向了檔案操作。

但隨著 agent 處理的資料量增長、需要多 agent 協作、需要更精確的搜尋，檔案系統的局限就會浮現。未來的方向可能是: 對 agent 暴露檔案介面，底層用更強大的儲存引擎。AgentFS 已經在做這件事了。

Arize 的階層式記憶觀點把這件事講得更清楚: agent 的記憶架構正在重演 CPU 記憶體的演化史。Context window 是 cache，檔案系統是 RAM，資料庫是 disk。每一層都在速度和容量之間做取捨，而 Unix 指令的可組合性讓 agent 能在這些層級之間自由穿梭。

另外值得注意的是，這整個趨勢跟 Anthropic 推的 Skills 機制是一脈相承的。當 agent 的知識、記憶、技能都變成檔案，「context engineering」本質上就變成了「檔案管理」。這對工程師來說反而是好事 — 比起管理一堆分散的 MCP server，管理一堆 .md 檔案簡單太多了。

參考連結: