文件系统是 Agent 的省钱答案

决定 Agent token 效率的变量不只有模型和提示词，还包括Agent面对的操作界面(Interface/Surface)。

说「Agent 想要文件系统」，听上去像拟人化。更准确地说，是今天的大语言模型在训练数据、后训练任务和工具生态里，反复学到了一套非常稳定的工作模式：进入目录 → 列文件 → 搜关键词 → 打开局部内容 → 引用具体行号。

文件系统语义对 Agent 友好，主要不是因为「文件」这个存储介质，而是因为它提供了一种 progressive disclosure（渐进式披露）的交互方式：

• 先低成本发现：ls看有哪些东西，stat看对象卡片，catalog看可查询字段。
• 再按需读取：只有找到目标后，才用read打开内容。
• 搜索可以限定范围：全局grep用来发现线索，目录内grep用来提取证据。
• 路径是稳定句柄：/runs/abc/stdout.log 既是名字，也是后续继续操作的地址。

相比之下，SQL 更像是要求 Agent 先理解一张地图，然后一次性写出正确路线。对于清晰的结构化聚合，这很强；但对于「先找 cohort（样本组），再查日志，再引用证据」的复合探索任务，前置认知成本会变高。

Agent擅长搜索有名字、有层级、可局部打开的空间

很多人谈token成本时，只看输入prompt有多长、输出回答有多长。但对具备推理能力的模型来说，每个工具调用轮次里的一部分预算会花在「我现在看到了什么、下一步该查哪里、这些字段之间怎么关联、刚才的结果是否足够回答问题」上。换句话说Agent不只是在读取数据，它还在不断维护一张临时的任务地图。

如果接口迫使Agent先理解复杂schema、猜join路径、拼blob_ref、回忆哪些id对应哪些日志，那么模型的注意力就会被大量消耗在「拼上下文」和「找路」上。它虽然还在工作，但越来越像一个人一边翻十几张表、一边记临时编号、一边担心自己有没有漏掉关键字段。这种状态下，token不是被花在真正的判断上，而是被花在维持工作记忆上。

文件系统形态的接口会减轻这种负担。路径本身就是稳定句柄，目录天然表达范围，grep返回的是带位置的证据，find和aggregate可以把过滤、排序、limit和字段投影下推给系统Agent不需要在脑子里反复重建「数据在哪里」，而是可以顺着路径逐步缩小搜索空间

一般来讲，只要一个智能体系统高度依赖大量文件、日志、报告、模型、合同、图片、音视频、checkpoint 等外部产物，就会遇到类似问题。可以把这类系统称为 artifact-heavy（产物密集型）Agentic 系统

今天的训练、评测和推理系统会产生大量run、trace、日志、模型checkpoint、指标和配置。作为人的我们会问：「哪组配置最好？」「这批失败任务为什么取消？」「这个采样run到底加载了哪个模型？」这些问题往往不是一条SQL能解决的，而是要在结构化指标、非结构化日志和 artifact 元数据之间来回探索。

从 token efficiency 的角度看，这是一种很差的接口选择：Agent的预算被花在「我该去哪找这份文件、哪个版本才是当前版本、这个摘要对应哪段原文」上，而不是花在法律分析、实验判断或业务决策上。

这就是研究人员认为「文件系统语义」会重新变重要的原因–LLM 被训练得非常擅长在这种形态的空间里工作。