同一个AI模型，在相同的实验数据集上，面对不同的接口形态，token消耗量竟然天差地别——实验结果证实了这一结论，且差异远超预期。
研究人员开展了一项公开对照实验：让同一模型基于同一份机器学习实验数据，完成完全相同的一组研究任务。唯一变化的变量，就是交互接口。
一个接口是原生SQLite/SQL，另一个则是NoKV采用的文件系统形态namespace——训练run被组织为目录，日志像文件一样存放，搜索过程类似grep命令。
结果一目了然：文件系统接口节省了45%的token，账单降低了39%，且回答正确率略高一筹。
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；即便查询结果是错的，token也不会被退还。
研究人员指出：决定Agent token效率的关键变量，不只是模型和提示词，还包括Agent所面对的操作界面（Interface/Surface）。
Fable 5的横空出世给开发者敲响了警钟：如果独立开发者也能调用强模型、快速搭建自己的Agent，那么“有Agent”本身很快就不再稀缺。真正拉开差距的，是Agent每天执行成千上万次任务时的token经济（token economy）——完成一次任务需要读取多少上下文、经过多少步骤、犯多少次错，以及最终烧掉多少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先理解一张完整的地图，然后一次性写出正确路线。对于清晰的结构化聚合查询，SQL非常强大；但对于“先找cohort（样本组），再查日志，最后引用证据”这类复合探索任务，前置认知成本就变得很高。
近两年，大模型公司和Agent系统开发者也在独立地收敛到类似结论：
- Letta的Agent memory benchmark中，一个将对话历史保存为文件的Agent，在LoCoMo长对话记忆任务上取得了有竞争力的结果。
- Anthropic在MCP code execution的设计中，把工具呈现为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的开源Python实验追踪系统）的真实运行记录。数据由一位曾任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.8k token，而namespace用了约9.3k token。这一结果并不意外：关系型接口本来就擅长明确的聚合与排序。
真正拉开差距的是复合探索任务。
图3：100次独立运行的成本分布。散点图展示了平均值之外的稳定性问题：某些SQL运行会出现更长尾的成本，错误运行仍然照常计费。
案例一：扫参报告
任务要求Agent找出已完成训练run中val_loss最低的5个，并报告学习率、batch size、stdout大小和git状态。
在namespace接口上，Agent先用一次catalog发现字段，再用一次find将过滤、排序、limit和字段投影一起下推给系统，答案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，而是说明接口选择会改变成本结构。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系统是另一个直观的例子。用户将合同、判例、尽调材料和邮件附件丢进去，让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站点声明。