TL;DR当前最强的 Code Agent，在一个塞满 1000+ 个文件的真实数据环境里，准确率只有 61.1%。直接告诉它数据在哪，表现跳 27 个百分点。把数据接口从 SQL 换成文件系统，token 省 45%。结论：帮 Agent 找到该处理的数据，比让 Agent 变得更聪明，划算得多。

读完你会明白：

• 为什么你家的 Agent 明明很聪明却总在简单任务上翻车
• 当前主流 Agent benchmark 的盲区在哪
• 三个不花钱就能立竿见影的优化手段
• 以及一个你很可能从来没测过但至关重要的指标

想具体知道为什么、怎么做？往下看。或者直接跳到结尾看你能做什么。

让我们开始吧。

#他们发现了什么 ?  

##1000 个文件，一句任务，没有路径

你是一个 AI Agent，被丢进一台 Linux 服务器的工作目录。手里只有一句话的任务描述：

"What are the top 5 most frequently assigned genres for TV shows and their counts?"

就这一句。没有文件名，没有路径，没有数据 schema。

/workspace/data/ 下面堆了 170 多个数据集，每个一个子目录，CSV、JSON、Parquet 混在一起。目录名像这样：

哪个数据集包含 TV shows 的 genre 信息？netflix-shows 看起来有希望。你要先ls 进去看看，用 Python 读一下列名，确认有没有listed_in、type 这些字段，再过滤出 TV show，split genre，count，排序，才知道答案。

这还只是猜对了的情况。如果选错了——比如选了一个名字带 "show" 但实际是商品展示数据的数据集——你会在错误的数据上写正确的代码，得到错误的答案，然后 600 秒超时，不知道错在哪。

这就是 CoDA-Bench 创造的环境。 不是一道算法题，不是一个明确的文件路径。这是一个塞满 1000 多个数据文件的仓库，文件之间有主题关联、有结构相似性，Agent 必须先找到该用的数据，才能开始写代码。

表现最好的系统准确率只有 61.1%。在更难的子集上，跌到 49.6%，离随机猜测（47%）只差不到 3 个百分点。

当他们做了一次oracle 实验——直接告诉 Agent 正确数据路径，不改变其他任何条件——准确率从 45.4% 跳到 73.1%，差了超过 27 个百分点。

Agent 还是那个 Agent。模型还是那个模型。唯一的变化是它不需要自己找数据了。

当前 Code Agent 的真实瓶颈不是不会写代码，是在 1000 个文件里找到该处理的那一个。

##同一个模型，两个接口，2.39 倍的差距

NoKV 团队做了一个控制实验。同一份语料（875 个 ML 实验运行，含 80.6 万行指标），同一个模型（gpt-5.4-mini），同一组 5 个任务。唯一变化的只有接口。

接口 A：原始 SQLite（sqlite_raw_v1）

Agent 面对的是一张 SQLite 数据库文件。它要先自己发现 schema，SELECT name FROM sqlite_master，理解每张表的字段含义，自己写出 join 路径和聚合查询。想找验证集损失最低的 5 个训练 run，它要先在 80.6 万行指标表上写一个 min-per-run 聚合，再 join 参数表、artifact 表、git 状态表。写错一次，扣完 token 重来。

接口 B：NoKV 文件系统命名空间（nokv_native_v1）

Agent 面对的是一个文件系统。run 是目录，日志是文件，索引字段可以通过ls、stat、catalog、find、grep 操作。同样那个任务，Agent 先用一次catalog 查可用的字段，再用一次find 把过滤、排序、limit 和需要的字段一次搞定。两步完成。

在复合探索任务上差距更大：SQLite 用了 127,450 prompt tokens，NoKV 用了 53,300，2.39 倍。

接口形态不是细节问题，它是 Agent token 经济的结构性因素。

##但两篇都有盲区

CoDA-Bench 这边有三个问题。

Oracle 实验消除的不仅是"找数据"，还有不确定性本身。知道正确答案的 Agent 同时获得了"我没走错"的确信。在 1000 多个文件的环境里，每 ls 一次、每 cd 一次，都伴随"这是不是浪费时间"的认知负担。27 个百分点的提升是搜索加不确定性加错误累积的总和，不是数据发现能力的纯净度量。

Kaggle 数据污染被轻描淡写了。Agent 看到meta_kaggle 这个名字就能凭训练记忆知道该用它，不需要推理。作者说任务需要精确计算而非回忆。Agent 不需要回忆答案，只需要回忆该用哪个数据集，就已经不公平了。

980 个文件的挑战性不来自数量，来自组织方式。Kaggle 数据集的命名是有意义的（air-quality-data-in-india），比真实世界里一堆data_final_v3_revised(1).csv 要友好得多。

NoKV 这边也有三个问题。

工具能力不对等。SQLite 接口是裸接口，Agent 要自己发现 schema，自己写 join。NoKV 接口是高度封装的工具集，catalog 告诉你有哪些字段，find 把过滤、排序、limit 一次搞定。这比较的不是文件系统和 SQL，是精心设计的工具和原始接口。如果给 SQL 也配上等价的封装，45% 的差距还剩多少？

利益冲突。这篇博客由 NoKV 团队撰写，比较的是自家产品 vs. SQLite。实验设计、任务选择、接口实现、结果解读全部由同一方控制。这里不需要假设恶意，但 45% 少 token 在没有第三方复现之前是有待验证的声明。

两个被忽略的维度。文件系统接口的每一步（ls, cd, grep, read）都是独立的 API 调用，每步都有延迟。对延迟敏感的系统，步数本身就是成本。另外，5 个任务全部来自 ML 实验追踪这一个场景，更像一个有说服力的 demo，而不是一个 benchmark。

##让它们吵一架

CoDA-Bench 对 NoKV 说：

"你的环境太干净了。每个 run 规规整整一个目录。放进我的 1000 个主题相似的干扰文件里，你的 ls 和 grep 还能高效找到数据？"

NoKV 对 CoDA-Bench 说：

"你的 oracle 实验只给了路径。如果给的是 catalog 工具，告诉 Agent 有哪些表、有什么字段，那 73.1% 可能还能更高。你在说 Agent 不够好，我在说给 Agent 一个更好的工作台。"

##各打五十大板，各取一半真理

CoDA-Bench 确诊了疾病，但病因只看到了一半。它的构造方法严谨，1009 个任务有统计意义。但它的叙事暗示 Agent 需要更强的数据发现能力，解决方案藏在更好的模型里。这可能只是答案的一半。

NoKV 提出了一个治疗方案，但夸大了疗效数据。渐进式披露、路径即句柄、行号即引用——这些设计原则经得起推敲。但 45% 和 39% 被利益冲突和工具不对等夸大了。

两者结合起来，比任何单独一方更接近真相。

四个结论：

第一，数据发现是瓶颈。CoDA-Bench 的证据足够强，趋势是清晰的。

第二，接口形态影响 token 效率。渐进式披露更契合 LLM 的认知模式，但具体数字需要独立复现。

第三，工程问题不是二选一。不是更好的 Agent 或更好的接口。是在什么场景下，接口优化的 ROI 高于模型优化的 ROI。

第四，最被低估的方向是让工作空间自己变好。一个 Agent 每天在同一个仓库上工作，第一天 ls 十次才找到东西，第十天应该能直接记住路径。但现在的方案都假设 Agent 每次从零开始。加一层记忆，哪怕只是把走过的目录结构缓存起来，每次任务都在改善下一次的基础。

#那你能做什么

五件事，按投入产出比从低到高排列。每一件今天就能动手。

##最便宜的功夫：给数据配张地图

在丢 Agent 进数据目录之前，先给它一个 README。

CoDA-Bench 的 oracle 实验已经证明，Agent 知道数据在哪时，表现能跳 27 个百分点。你不会把新同事丢进没有文档的共享文件夹，对 Agent 也一样。

两种最常见的场景：

场景一：数据分析目录

场景二：GitHub 仓库

几行文本的成本，Agent 不需要先ls -R 三次、打开五个无关文件才能摸清目录结构。

##最反直觉的习惯：直接告诉它路径

直接告诉 Agent 数据路径。这不是作弊，是最佳实践。

很多人觉得让 Agent 自己找到数据才算真本事。但你不是在跑 benchmark，你是在完成工作。

❌ "分析一下这个季度的销售趋势"✅ "分析一下 sales_2023_q4.csv 这个文件里的销售趋势，文件在 /data/sales/ 目录下"

你觉得天大的区别，实际操作就是在文件管理器里右键点那个文件，复制文件地址，粘贴进 prompt。一个动作，不到一秒。

省掉的是 Agent 在几百个文件里挨个 ls、挨个 read header、猜错目录、再重来的几千个 token。

如果你在构建一个长期自主工作的 Agent（比如每周自动出报表），那它该学会自己找。但大多数情况下，你是一次性任务。告诉它路径，拿结果走人。

##最高效的改造：渐进式接口

把你的工具组织方式改成先看目录、再搜内容、再打开文件的结构。

大多数 Agent 系统的设计方式是平铺。把所有工具定义、API 接口、数据库 schema 一股脑塞进 system prompt。Agent 哪怕只需要用到其中 2 个，也得先把另外 48 个从头到尾读一遍。Anthropic 报告里说，一个平铺的 50 个工具的列表，Agent 要花 150,000 token 读完。换成文件树结构，Agent 先ls 看分类，再只打开自己需要的那个，同样的工作量降到 2,000 token，省了 98.7%。

把平铺的列表：

改成可浏览的目录：

Agent 先ls tools/ 看到三个分类（低成本），再ls tools/database/ 看到三个工具（中成本），最后需要用时才read tools/database/query.md 读取完整的参数说明（高成本）。每一步只看当前需要的信息。

如果你在给 Agent 暴露数据库 schema，给 Agent 一个search_schema("关键词") 工具。它要找客户数据时搜一下customer，只返回相关表和字段。

##最被忽视的常识：工具分场景

确定性操作用 SQL，探索性操作用 grep。让每种工具做它擅长的事。

选错接口的代价很具体。

反面案例 1：用 grep 做聚合。Agent 想知道去年每个地区的总销售额。你给了它一个文件系统接口。它开始grep "2023" sales.csv，拿到一堆行，手动加总，漏了一个分区，重来。干了 10 步，只是做一个SELECT region, SUM(amount) FROM sales WHERE year=2023 GROUP BY region 就能搞定的事。

反面案例 2：用 SQL 搜日志。Agent 想知道哪些实验的日志里有 timeout 错误。你给了它一个 SQL 接口。它要先查 schema，发现日志存在 blob 里，写一个LIKE '%timeout%'，发现 blob 不直接支持字符串搜索，再换工具绕路。干了 8 步，只是做一个grep -r "timeout" logs/ 就能搞定的事。

给 Agent 同时暴露两种查询方式，让它自己选：

架构上就是两层。底层是数据库或对象存储（系统的真实记录），上层是一层轻量级的元数据目录树（Agent 的操作视图）。Agent 先在树上探索，找到目标后再下到底层执行精确查询。

##最能暴露问题的一个指标

监控 Agent 的探索/执行比。

不看这个数字，你根本不知道 Agent 的 token 花在了哪。

一次 Agent 运行的步骤记录：

10 步里有 8 步在找东西，只有 2 步在真正做事。探索/执行比 = 80%。如果每次运行花 100,000 token，80,000 花在了认路上。

加一个指标，每次运行后自动统计：

CoDA-Bench 的数据暗示当前 Agent 的探索开销可能占总 token 的 40% 到 60%。NoKV 的实验展示了一个具体的优化效果：把探索开销降下来后，总 token 降了 45%。

一个实用的经验门槛：如果探索/执行比超过 30%，不要急着换模型。先优化数据组织（给 README、加目录地图）或接口设计（渐进式披露、混合接口）。成本远低于换模型，效果可能还更大。

#最后几句

##对使用者，对构建者

如果你在用 Agent： 两个习惯。派活之前，右键点文件，复制路径，粘贴进 prompt。就这一个动作，省下的 token 比你换什么模型都多。活干完之后，多问一句："把这个目录的结构整理成 ASCII tree，写到 README 里。"下次再找东西，地图已经在了。

如果你在构建 Agent： 在改模型之前，先检查 Agent 的工作空间。它能不能先 ls 看看有什么、再 grep 搜一下、再 read 打开需要的部分？还是第一步就要读完一整本说明书才能动手？

##站高一层看

过去两年大家都在比谁能做出更强的模型。Claude Fable 5、GPT-5.5。能力曲线确实还在涨。

边际收益在递减。

你抱怨 Agent 怎么这么笨、这点事都做不好。问题不是模型不够强。是你没有给它一个好的工作环境。没有告诉它数据在哪，没有给它一个可以先 ls 再 grep 再 read 的工作空间，没有把话说清楚、把路指清楚。

对绝大多数日常任务来说，把话说清楚、把路指清楚，比等下一代模型有用得多。

在你抱怨模型不够聪明之前，先检查一下你的 Agent 每次工作前要花多少 token 在认路上。有可能是 40%，有可能是 60%。如果是，改工作空间比等模型快得多，也便宜得多。

本文综合自：CoDA-Bench — arXiv:2606.15300 / https://coda-bench.github.io/Agents Want Filesystems — NoKV Blog / https://nokv.io/blog/agents-want-filesystems