90 lines
4.4 KiB
Markdown
90 lines
4.4 KiB
Markdown
---
|
||
title: "Agents Want Filesystems：为什么文件系统形态的接口让 Agent 更高效"
|
||
created: 2026-07-04
|
||
updated: 2026-07-04
|
||
type: article
|
||
tags: [agent, filesystem, interface, token-efficiency, workspace, nokv]
|
||
source: "新智元"
|
||
url: "https://mp.weixin.qq.com/s/VdjhAzjmdAkL-aHRGiEUHw"
|
||
---
|
||
|
||
# Agents Want Filesystems：为什么文件系统形态的接口让 Agent 更高效
|
||
|
||
> 新智元 · 2026-07 · [原始存档](raw/articles/xinzhiyuan-agents-want-filesystems-2026.md) · [源博客](https://nokv.io/blog/agents-want-filesystems)
|
||
|
||
## 核心观点
|
||
|
||
NoKV 团队通过 100 次独立运行的 benchmark 证明：**给 Agent 提供文件系统形态的 namespace 接口（而非原生 SQL），可减少 45% token 消耗、39% 成本，且正确率略高。**
|
||
|
||
核心洞察：决定 Agent 效率的变量不只有模型和提示词，还包括 Agent 面对的操作界面（Interface/Surface）。
|
||
|
||
## 为什么文件系统语义对 LLM 友好
|
||
|
||
LLM 在训练中被反复暴露于 shell、Unix 工具、Git、日志排查等语料中，学到一套稳定模式：**进入目录 → 列文件 → 搜关键词 → 打开局部内容 → 引用行号**。
|
||
|
||
文件系统提供 **progressive disclosure**（[[progressive-disclosure|渐进式披露]]）交互方式：
|
||
1. 先低成本发现：`ls` 看有什么，`stat` 看对象卡片，`catalog` 看可查询字段
|
||
2. 再按需读取：只有找到目标后才 `read` 打开内容
|
||
3. 搜索可限定范围：全局 `grep` 发现 + 目录内 `grep` 提取证据
|
||
4. 路径是稳定句柄：`/runs/abc/stdout.log` 既是名字也是地址
|
||
|
||
## 实验设计
|
||
|
||
- **数据**：875 个 Yanex 训练 run，80.6 万行指标，包含元数据、参数、artifact、git 状态、stdout/stderr
|
||
- **模型**：GPT-5.4-mini，100 次独立 stateless 运行
|
||
- **两种接口**：
|
||
- `sqlite_raw_v1`：原生 SQL + blob 读取 + `grep_blob`
|
||
- `nokv_native_v1`：NoKV namespace（`ls`/`stat`/`catalog`/`find`/`aggregate`/`read`/`grep`）
|
||
|
||
## 三类任务的结果
|
||
|
||
| 任务类型 | SQL Token | NoKV Token | 关键差异 |
|
||
|---------|-----------|------------|---------|
|
||
| 简单结构化查询 | **4.8k** | 9.3k | SQL 仍然更强 |
|
||
| 复合探索（扫参/溯源/分诊） | 127.4k | **53.3k** | NoKV 2.39× 更低 |
|
||
| 总体 | — | — | **-45% token, -39% cost** |
|
||
|
||
SQL 在简单结构化聚合上更强；NoKV 在需要「先定位 cohort → 再查日志 → 再引用证据」的复合探索任务上大幅领先。
|
||
|
||
## 减少的不只是 token，也是「心智负担」
|
||
|
||
更深层次：NoKV 减少了 Agent 的内部 reasoning token——模型不需要在每轮工具调用中重建「数据在哪」的临时地图。
|
||
|
||
- **[[attention-drifting|注意力偏移]]**：上下文塞进太多 schema 和无关日志时，模型容易被早期错误线索带偏
|
||
- **[[pushdown-in-agent-interface|下推]]**：过滤、排序、limit、投影放进一次调用，减少对话轮数和上下文回灌
|
||
|
||
## 架构定位
|
||
|
||
不是「文件系统替代数据库」，而是**两层架构**：
|
||
- **底层**：数据库、对象存储、API（可靠性、事务、持久化）
|
||
- **上层**：元数据控制层（路径、版本、权限、索引 → Agent-friendly namespace）
|
||
|
||
NoKV（[[nokv]]）就是这层上层。
|
||
|
||
## 应用场景：artifact-heavy agentic 系统
|
||
|
||
任何 Agent 系统高度依赖大量文件、日志、报告、模型、checkpoint 等外部产物时，都会遇到这个问题：
|
||
- 实验追踪与观测
|
||
- 法律咨询（合同、判例、尽调材料）
|
||
- 数据分析（notebook、CSV、图表交叉引用）
|
||
- 研发 Agent（issue、PR、日志、CI 结果）
|
||
- 多 Agent 协作（共享中间产物、锁定版本、监听更新）
|
||
|
||
## 外部佐证
|
||
|
||
- **Anthropic MCP code execution**：工具呈现为 TypeScript 文件树，代表性负载从 150k token → 2k token
|
||
- **OpenAI tool search**：建议把延迟加载工具组织到 namespace 或 MCP server
|
||
- **Letta memory benchmark**：对话历史保存为文件的 Agent 在 LoCoMo 上取得有竞争力结果
|
||
|
||
## 核心概念
|
||
|
||
- [[agent-workspace-filesystem|Agent 工作空间文件系统]]
|
||
- [[progressive-disclosure|渐进式披露]]
|
||
- [[attention-drifting|注意力偏移]]
|
||
- [[pushdown-in-agent-interface|Agent 接口下推]]
|
||
- [[artifact-heavy-agentic-systems|产物密集型 Agent 系统]]
|
||
- [[agent-interface-design|Agent 接口设计]]
|
||
- [[nokv|NoKV]]
|
||
- [[token-efficiency|Token 效率]]
|
||
- [[workspace-first-architecture|Workspace-first 架构]]
|