檔案系統可以讓Agent更高效地「找東西」，降低了認知負擔，提高了任務執行效率，減少了45%的token消耗和39%的成本，同時保持較高精準率。

當同一個模型面對同一份資料時，介面長什麼樣，會不會直接改變它花掉多少 token（模型上下文與計費的基本單位）？

部落格連結：https://nokv.io/blog/agents-want-filesystems

研究人員在部落格中分享了自己的實驗，做了一個開放benchmark：讓同一個模型，在同一份機器學習實驗資料上，完成同一組研究任務。唯一變化是介面。

一邊是原生SQLite/SQL；另一邊是NoKV的檔案系統形態namespace，也就是讓訓練run像目錄、日誌像檔案、搜尋像grep一樣工作。

結果很直接：檔案系統形態的介面少用了45%的token，帳單低了39%，正確率還略高。

NoKV是一個面向 智能體工作空間 (AI Agent workspace) 的中繼資料控制層：它把實驗run、日誌、checkpoint（檢查點）、artifact（實驗產物）等工作結果，放進一個檔案系統形態的命名空間裡，讓 Agent 可以像工程師一樣用ls、grep、read去找線索、看證據、引用行號。

在公開資料中，NoKV已經出現在CNCF Cloud Native Landscape（雲原生基金會前瞻項目）中。

CNCF是Linux Foundation（Linux 基金會）體系下的雲原生計算基金會；NoKV在這張 landscape 裡被歸類到了AI Native Infra / Storage分區。

NoKV早期自研的Go原生儲存引擎，也以歷史資料庫條目被 CMU Database of Databases（dbdb.io）收錄。這裡需要說明一下：DBDB條目對應的是歷史上的Go儲存引擎；當前NoKV主線已經演進為Rust實現的Agent workspace檔案系統產品線。

想像你讓一個AI Agent幫你做實驗復盤：

「幫我找出驗證集損失最低的5個訓練run，順便告訴我它們的學習率、batch size、stdout 有多大，以及當時的git狀態。」

一個人類工程師會怎麼做？大機率不是先背下整張資料庫的表結構，也不是先在腦子裡推導所有 join關係。更自然的路徑是：進入實驗目錄，列一下有那些run，搜尋相關欄位，打開必要日誌，再把證據貼出來。

也就是：ls → grep → read → 引用行號

但如果把同一件事交給一個只看SQL表的Agent，它要先理解：run中繼資料在那張表，指標在那張表，參數怎麼展開，日誌blob在那裡，run id和 artifact id怎麼關聯，stdout/stderr如何對應到檔案內容。

SQL當然能表達這些關係。問題是，Agent在找到答案之前，就已經開始付費了。

每多讀一段 schema、每多試一次錯誤查詢、每多把一整段日誌拖進上下文，都會消耗token；錯誤運行不因為錯誤就免費。

研究人員認為：決定Agent token 效率的變數不只有模型和提示詞，還包括Agent面對的操作介面(Interface/Surface)。

Fable 5的橫空出世給了開發者們一個警醒，如果獨立開發者能呼叫強模型、迅速搭建自己的 Agent，那麼「有 Agent」本身很快就不再稀缺。

真正拉開差距的，是Agent每天執行成千上萬次任務時的token economy harness：一次任務要讀多少上下文、走多少步、犯多少錯、燒掉多少 token。

說「Agent 想要檔案系統」，聽上去像擬人化。更準確地說，是今天的大語言模型在訓練資料、後訓練任務和工具生態裡，反覆學到了一套非常穩定的工作模式：進入目錄 → 列檔案 → 搜關鍵詞 → 打開局部內容 → 引用具體行號

這套模式並不神秘。網際網路上有大量shell、Unix 工具、Git、日誌排查、程式碼倉庫瀏覽和命令列偵錯語料；過去兩年英文coding agent大火，導致後訓練中在不斷強化基礎模型對目錄樹、檔案路徑、grep、cat、diff和行號的使用能力。今天最穩定能力最強的一批Agent還仍然主要是Coding Agent，不只是因為程式碼任務重要，也因為程式碼倉庫天然給了模型一個它熟悉的操作空間。

檔案系統語義對 Agent 友好，主要不是因為「檔案」這個儲存介質，而是因為它提供了一種 progressive disclosure（漸進式披露）的互動方式：

先低成本發現：ls看有那些東西，stat看對象卡片，catalog看可查詢欄位。

再按需讀取：只有找到目標後，才用read打開內容。

搜尋可以限定範圍：全域grep用來發現線索，目錄內grep用來提取證據。

路徑是穩定控制代碼：/runs/abc/stdout.log 既是名字，也是後續繼續操作的地址。

相比之下，SQL 更像是要求 Agent 先理解一張地圖，然後一次性寫出正確路線。對於清晰的結構化聚合，這很強；但對於「先找 cohort（樣本組），再查日誌，再引用證據」的復合探索任務，前置認知成本會變高。

近兩年，大模型公司和 Agent 系統開發者也在獨立收斂到類似結論：

Letta的Agent memory benchmark中，一個把對話歷史保存為檔案的Agent，在LoCoMo長對話記憶任務上取得了有競爭力的結果。

Anthropic在MCP code execution（用程式碼執行MCP工具）的設計裡，把工具呈現為TypeScript檔案樹，而不是把所有工具定義平鋪塞進上下文；他們報告的代表性工作負載從150,000 token降到2,000 token。

OpenAI 的 tool search文件也建議把大量延遲載入工具組織到namespace或MCP server裡，讓模型按需搜尋和載入。

這些案例指向同一個模式：Agent擅長搜尋有名字、有層級、可局部打開的空間。

所以，檔案系統形態不等於「把資料庫換成磁碟檔案」。更準確的說法是：底層資料仍然可以在資料庫、對象儲存和API裡；但對於Agent而言，最好有一個可瀏覽、可搜尋、可快照、可監聽的 workspace 檢視。

圖 1：檔案系統形態不是把資料庫換成磁碟檔案，而是給Agent一個可瀏覽、可搜尋、可快照和可監聽的工作空間檢視。

由於大模型是個黑盒，所以為了把問題測清楚，我們把變數儘量壓到了足夠少。

實驗語料是一份真實機器學習實驗追蹤資料：875個訓練、採樣和評估run，包含中繼資料、參數、80.6萬行指標、artifact、git 狀態，以及原始stdout/stderr日誌。

這份資料不是手寫的玩具demo。它來自Yanex（Yet Another Experiment Tracker，一個輕量、Git-aware / 感知Git狀態的開源Python實驗追蹤系統）的真實運行記錄。

據NoKV團隊披露，資料由一位曾任MongoDB ML Research負責人的研究者，基於自己的開放原始碼專案運行記錄以私下合作方式提供。為了避免把私人合作事實包裝成公開第三方背書，下面所有可復算的實驗結論仍以公開提交的harness（實驗框架）、judge（判分器）和telemetry（運行遙測）為準。

同一份資料通過兩種介面暴露給 Agent：

sqlite_raw_v1：原生 SQL 介面。Agent 可以發現 schema，可以在物化表上跑唯讀 SQL，也能讀取 blob，並使用行級 grep_blob 搜尋日誌。

nokv_native_v1：NoKV 的 namespace 介面。Agent 可以使用 ls、stat、catalog、find、aggregate、read 和遞迴 grep。run 是目錄，日誌是檔案，索引欄位可以在一次呼叫裡下推過濾、排序、limit 和投影。

任務設計也儘量貼近日常ML研究人員會問Agent的方式，比如：

找出驗證集損失最低的訓練run，並報告學習率、batch size、stdout 大小和 git 狀態。

找出某個資料集的TabDiff採樣run載入了那個checkpoint，以及模型參數量。

為未完成或被取消的任務整理事故記錄，指出stderr中是否出現KeyboardInterrupt，並給出最後一次出現的行號。

實驗設定為：同一個Agent模型gpt-5.4-mini，每個介面、每個任務重複10次，共100次獨立運行。

還保證了每次運行都保證Agent是stateless的——新runner處理程序、只給 system message、介面說明和任務prompt，不把上一次回答串進下一次。

成本按模型公開價格計算，並逐次寫入遙測。

圖 2：逐任務成本對比。藍色是NoKV namespace，灰色是原生SQLite；復合探索任務上的差距最明顯。

更有意思的是「復合探索」任務。Agent需要先定位一批run，再從日誌裡找事實，最後給出可審計的行號證據。

三個復合任務合起來看，namespace版本的prompt token是53,300，而SQL版本是127,450，後者約為前者的2.39倍；成本上，SQL是$0.0558，NoKV是$0.0286，接近2倍差距。

換句話說，Agent不是只需要更多工具，它還需要一種更適合自己「找東西」的工作空間。

少的不只是 token，也是Agent的「心智負擔」

這裡還有一個不太直觀、但對Agent系統很重要的現象：在公開benchmark主表之外，研究人員在內部運行記錄裡還觀察到一個額外訊號：用NoKV做interface的後端，模型在執行任務的時候，內部推理 (reasoning token)消耗明顯更少。

這件事值得單獨解釋一下。很多人談token成本時，只看輸入prompt有多長、輸出回答有多長。但對具備推理能力的模型來說，每個工具呼叫輪次裡的一部分預算會花在「我現在看到了什麼、下一步該查那裡、這些欄位之間怎麼關聯、剛才的結果是否足夠回答問題」上。換句話說Agent不只是在讀取資料，它還在不斷維護一張臨時的任務地圖。

如果介面迫使Agent先理解複雜schema、猜join路徑、拼blob_ref、回憶那些id對應那些日誌，那麼模型的注意力就會被大量消耗在「拼上下文」和「找路」上。它雖然還在工作，但越來越像一個人一邊翻十幾張表、一邊記臨時編號、一邊擔心自己有沒有漏掉關鍵欄位。這種狀態下，token不是被花在真正的判斷上，而是被花在維持工作記憶上。

檔案系統形態的介面會減輕這種負擔。路徑本身就是穩定控制代碼，目錄天然表達範圍，grep返回的是帶位置的證據，find和aggregate可以把過濾、排序、limit和欄位投影下推給系統Agent不需要在腦子裡反覆重建「資料在那裡」，而是可以順著路徑逐步縮小搜尋空間。

所以，NoKV降低的並不只是prompt token和帳單。更深一層看，它減少了Agent在每一輪工具呼叫中維持上下文、修正路線、重新組織線索所消耗的計算資源。更少的「找路成本」，意味著模型有更多有效注意力留給真正的問題：判斷、歸納、交叉驗證和生成最終答案。

這也解釋了為什麼研究人員會關心注意力偏移的問題 (attention drifting)。當上下文裡塞進太多schema、臨時查詢結果、無關日誌和中間失敗嘗試的時候，模型容易被早期的錯誤線索帶偏，或者在多輪呼叫後忘記最初的問題。一個更清晰的workspace介面，本質上是在幫Agent減少這種偏移的機率，讓它每一步都看到更少但更相關的資訊，並且能用穩定路徑回到證據現場。

因此，token efficiency不只是財務指標。它也是一種面向Agent的認知層面上的工程最佳化：好的介面把複雜性留在系統裡，把清晰、局部、可引用的操作面交給Agent。對長鏈路Agent來說，這往往會反映到更穩定的行為、更低的成本，以及更少的無效推理上。

平均值說明了「差距存在」，但真正重要的是差距從那裡來。

在簡單的單發結構化查詢上，SQL仍然很強。

例如某個leaderboard類任務，schema一展開，一條SELECT就能完成，SQLite只用了約4.8ktoken，而namespace用了約9.3ktoken。

這個結果並不意外：關係型介面本來就擅長明確的聚合與排序。

真正拉開差距的是復合探索任務。

圖 3：100次獨立運行的成本分佈。散點圖展示了平均值之外的穩定性問題：某些SQL運行會拖出更長尾的成本，錯誤運行仍然照樣計費。

任務要求Agent找出已完成訓練run中val_loss最低的5個，並報告學習率、batch size、stdout大小和git狀態。

在namespace介面上，Agent 先用一次 catalog 發現欄位，再用一次 find 把過濾、排序、limit 和欄位投影一起 push down給系統，答案 100% 正確，約 7.9k token。

在SQL介面上，Agent需要在80.6萬行指標表上做每個 run 的最小值聚合，再 join 參數、artifact和git狀態。模型有一半次數把查詢寫錯，而且錯得並不明顯；即便失敗，token仍然照樣計費，約23.6k token。

這個案例說明：很多Agent錯誤不是「模型不會思考」，而是介面要求它在找答案前先跨過一堆間接層。SQL把資訊組織得很嚴謹，但對Agent來說，嚴謹不等於低成本。

任務要求找出某個資料集所有TabDiff採樣run載入的checkpoint檔案，以及模型參數量。這些事實只存在於stdout日誌中。

在namespace介面上，一次遞迴grep就能找到相關run目錄。目錄路徑本身就是後續操作的 cohort handle，隨後在這些目錄裡繼續限定範圍搜尋Checkpoint: 和 Model parameters:行即可。

在SQL介面上，即使我們也給了grep_blob，Agent 然要先解開params、artifact、blob_ref之間的間接關係，再對多個 blob 分別搜尋。很多時候，它會把整段stdout拉進上下文裡再處理，答案可以對，但 token 成本很高。

這裡也有一個需要誠實說明的點：namespace 介面在這個任務上10次裡有4次失手，正確率是60%，SQL是100%。但按「每個正確答案的成本」計算，namespace仍然更便宜：$0.0297對$0.0322。

這不是為了證明namespace永遠贏，而是為了說明介面選擇會改變成本結構。SQL在這個任務上更穩；NoKV在同一任務上的平均token和平均成本更低，但還需要在可靠性上繼續工程化。

任務要求列出所有非completed run的狀態、stderr大小、是否包含KeyboardInterrupt，以及最後一次出現的行號。

namespace 的優勢很直接：一次find拿到cohort和stderr大小，再用限定目錄的grep返回帶行號的匹配行。行號就是天然的審計證據。

SQL也能答對，但要貴得多。原因是行號不是關係型投影裡的原生概念。要在 SQL 世界裡得到「最後一次出現在那一行」，Agent要做額外的字串和換行計算，或者依賴額外工具。

把三個案例合在一起看，namespace贏在四個地方：

路徑就是控制代碼。 找到一個run和讀取它的日誌，發生在同一個地址空間裡。

搜尋可以遞迴，也可以限定範圍。 同一個grep既能全域發現，也能在某個目錄內精確提取。

行號天然適合引用。 審計、debug（偵錯）、事故分析都需要「證據在那一行」。

下推減少對話輪數。 過濾、排序、limit、投影放進一次呼叫，就少一次上下文回灌和重新計費。

不是「檔案系統替代資料庫」，而是給 Agent 做一層工作空間

不是說資料庫沒用了，也不是說所有資料都應該搬進真實檔案系統。資料庫仍然應該負責可靠性、結構化查詢、事務和持久化；對象儲存仍然應該負責大檔案、checkpoint、日誌和二進制內容；業務API仍然應該負責權限和領域邏輯。

真正的問題是：對Agent暴露的後端檢視形態，是否需要重新設計？

彙整鉅亨號中所有使用「檔案系統」關鍵字，所發布的內容 (依照時間排序，最新在前，舊的在後)`