檔案系統可以讓Agent更高效地「找東西」，降低了認知負擔，提高了任務執行效率，減少了45%的token消耗和39%的成本，同時保持較高精準率。
當同一個模型面對同一份資料時，介面長什麼樣，會不會直接改變它花掉多少 token（模型上下文與計費的基本單位）？
答案是會，而且差別不小。
研究人員在部落格中分享了自己的實驗，做了一個開放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檔案系統產品線。
Agent到底在為什麼付費
想像你讓一個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。
LLM天然順著檔案系統語義工作
說「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 檢視。
實驗過程
由於大模型是個黑盒，所以為了把問題測清楚，我們把變數儘量壓到了足夠少。
實驗語料是一份真實機器學習實驗追蹤資料：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，不把上一次回答串進下一次。
成本按模型公開價格計算，並逐次寫入遙測。
實驗結果
主要結果如下：
更有意思的是「復合探索」任務。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。
這個結果並不意外：關係型介面本來就擅長明確的聚合與排序。
真正拉開差距的是復合探索任務。
案例一：掃參報告
任務要求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來說，嚴謹不等於低成本。
案例二：checkpoint溯源
任務要求找出某個資料集所有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暴露的後端檢視形態，是否需要重新設計？
對人類工程師來說，SQL、對象儲存key、日誌blob、臨時指令碼、Excel、儀表盤都能用，因為我們能在腦子裡做跨系統導航。但 Agent 的上下文窗口和工具呼叫都有成本。每次讓它先猜schema、再找id、再拼blob_ref、再讀日誌，都是把預算花在「找路」上，而不是「回答問題」上。
更合理的架構是分兩層：
- 底層: 繼續使用資料庫、對象儲存和API。
- 上層: 維護中繼資料、路徑、版本、權限、索引和引用關係。並且給 Agent 提供一個友好的類 POSIX 語義的 workspace以提供比如：路徑定址、目錄列舉、按需讀取、局部搜尋、權限邊界、原子發佈和可審計引用等功能
NoKV想做的就是上層：提供一個 Agent(或者說模型) 更偏愛的統一命名空間和中繼資料控制層。
未來應用：產物密集型 (artifact-heavy) 智能體系統都會遇到這個問題
第一個已經很明顯的應用場景，是實驗追蹤和觀測，但它不是唯一的場景。一般來講，只要一個智能體系統高度依賴大量檔案、日誌、報告、模型、合同、圖片、音視訊、checkpoint 等外部產物，就會遇到類似問題。可以把這類系統稱為 artifact-heavy（產物密集型）Agentic 系統。
今天的訓練、評測和推理系統會產生大量run、trace、日誌、模型checkpoint、指標和配置。作為人的我們會問：「那組配置最好？」「這批失敗任務為什麼取消？」「這個採樣run到底載入了那個模型？」這些問題往往不是一條SQL能解決的，而是要在結構化指標、非結構化日誌和 artifact 中繼資料之間來回探索。
法律諮詢類代理系統是另一個很直觀的例子。使用者把合同、判例、盡調材料和郵件附件丟進去，讓 Agent 做摘要、問答、風險提示和後續行動建議。真正讓系統變複雜的，不只是大模型本身，而是這些檔案對象背後的中繼資料：來源、版本、權限、引用關係、解析狀態、向量索引狀態、審計記錄、使用者批註、任務輸出等。如果這些中繼資料散落在對象儲存key、向量資料庫、業務資料庫、臨時快取和工作流元件裡，沒有一個統一的管理層，Agent每次工作都要重新拼接上下文，徒增心智負擔和token cost。
從 token efficiency 的角度看，這是一種很差的介面選擇：Agent的預算被花在「我該去那找這份檔案、那個版本才是當前版本、這個摘要對應那段原文」上，而不是花在法律分析、實驗判斷或業務決策上。
類似的場景還包括：
- 資料分析Agent：需要在notebook、CSV、資料庫結果、圖表和報告之間來回引用。
- 多媒體Agent：需要管理原圖、縮圖、轉寫文字、時間戳、向量表示和版本。
- 研發Agent：需要跨 issue、PR、日誌、CI 結果、建構產物和部署記錄定位問題。
- 多Agent協作系統：不同Agent需要共享中間產物、鎖定版本、監聽更新、回滾錯誤狀態。
如果這些系統沒有統一workspace，Agent就會不斷重複「重新發現世界」的過程。反過來，如果系統提供一個穩定、可搜尋、可快照、可審計的namespace，Agent就能把更多token花在推理和產出上。
這就是研究人員認為「檔案系統語義」會重新變重要的原因_LLM 被訓練得非常擅長在這種形態的空間裡工作。
如果越來越多的人開始意識到token是一種新型的計算單元，那麼介面形態就是這個計算成本結構的一部分。在實際業務場景中，Agent在執行任務的時候，被有限分配的token和注意力應該更多花在推理和執行任務上，而不是用在定位和拼接上下文。
資料說明與事實核查
文中涉及的公開事實均按公開資料核查：
- NoKV 項目狀態：CNCF Cloud Native Landscape中NoKV條目位於Runtime / Cloud Native Storage，並標註second_path為AI Native Infra / Storage；NoKV GitHub README 也說明其被列入CNCF Landscape與DBDB.io，同時說明DBDB是歷史資料庫條目、當前NoKV是Rust檔案系統產品線。
- DBDB 條目：dbdb.io將NoKV描述為Go-native log-structured key-value DBMS。本文據此寫作「早期自研儲存引擎的歷史條目被收錄」，不把它表述為當前 Rust 主線產品的完整描述。
- benchmark 數字：875個Yanex run、80.6萬行 metric、100次stateless run、
gpt-5.4-mini、5個任務、45%token 降低、39%成本降低等，均來自NoKV benchmark報告和已提交運行遙測。 - 外部案例：Letta、Anthropic、OpenAI tool search、Linux Foundation Tokenomicon等，僅用於解釋「按需發現、延遲載入、命名空間組織」這一介面趨勢。
- 實驗資料來源：Yanex是公開可核驗的輕量Git-aware Python實驗追蹤項目；「資料由一位曾任MongoDB ML Research負責人的研究者私下提供」屬於NoKV團隊披露，非公開第三方 benchmark站點聲明。 (新智元)