文件系统是Agent的省钱答案？token消耗降低45%，费用减少39%

新智元报道 【新智元导读】 文件系统可以让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文件系统产品线。 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 视图。 图 1：文件系统形态不是把数据库换成磁盘文件，而是给Agent一个可浏览、可搜索、可快照和可监听的工作空间视图。 实验过程 由于大模型是个黑盒，所以为了把问题测清楚，我们把变量尽量压到了足够少。 实验语料是一份真实机器学习实验追踪数据： 875个 训练、采样和评估run，包含元数据、参数、 80.6万行 指标、artifact、git 状态，以及原始stdout/stderr日志。 这份数据不是手写的玩具demo。它来自Yanex（Yet Another Experiment Tracker，一个轻量、Git-aware / 感知Git状态的开源Python实验追踪系统）的真实运行记录。 据NoKV团队披露，数据由一位曾任MongoDB ML Research负责人的研究者，基于自己的