RAG 过时了吗，Agent 基础设施为什么开始换成 virtual filesystem？

过去很长一段时间， 大家一说 Agent 基础设施，默认答案都是 RAG。

知识库接上。 向量库建好。 检索结果塞进上下文。

这套东西当然有用。 但问题是，很多团队现在开始发现： RAG 够回答问题，却不够支持一个 Agent 持续工作。

所以最近一个越来越清楚的变化是： 一些团队开始把重点从 RAG 挪开， 转向 virtual filesystem 这样的东西。

这背后不是小优化。 而是 Agent 基础设施正在换代。

RAG 的强项，是“知道”；它的弱项，是“工作”

RAG 最擅长的事情，是把相关信息找出来。

当用户问一个问题时， 系统从知识库里抓几段最相关的内容， 再塞给模型， 让模型回答得更准。

这在问答场景里很好用。

但 Agent 不是只回答一次问题。 它要持续做事。

它要找文件。 要理解目录。 要跨多个上下文来回跳。 要知道上一步看了哪里， 下一步该去哪一层。

这时候，单纯“检索几段文本”就不太够了。

因为工作不是只靠“相关片段”推进的。 工作还需要位置感、结构感和连续性。

virtual filesystem 在补的，其实是环境

virtual filesystem 听上去像一个技术细节。 但它真正解决的问题，非常本质：

它不是只把一段知识塞给模型。 而是给模型一个更像“文件系统”的工作环境。

模型不再只是被动接收几段检索结果。 它开始像人在目录里找东西一样， 知道文件在哪， 知道结构怎么组织， 知道自己刚刚看到了什么， 接下来该往哪翻。

前者像把材料递到你手里。 后者像把你放进一个有地图的办公室。

差别非常大。

01-rag-vs-env

这说明 Agent 基础设施正在从检索层升级到环境层

如果只做问答， RAG 往往已经够用了。

但如果你要的是一个能持续推进任务的 Agent， 问题就变了。

你不只是要它“知道答案”。 你还要它：

• 找得到位置
• 走得动路径
• 保持状态
• 连续推进

这时候，基础设施的重点就会从“怎么检索更准”， 慢慢转成“怎么让模型处在一个可操作环境里”。

这就是为什么我觉得， virtual filesystem 不是一个孤立技巧。

它更像一个方向信号： Agent 基础设施正在从知识增强，走向环境增强。

02-upgrade

这对产品和开发者意味着什么

对做产品的人来说， 以后不能再只问： “我们的 RAG 命中率够不够高？”

还要问： “我们的 Agent 有没有环境感？”

它能不能定位。 能不能导航。 能不能保持连续上下文。 能不能把任务一路做下去。

对开发者来说， 这也是一个提醒：

下一轮 Agent 竞争， 可能不只是比模型和检索。 而是比谁先把“工作环境”这一层搭出来。

所以当越来越多团队开始拿 virtual filesystem 替代一部分 RAG， 这不是在否定 RAG。

而是在说明一件事：

只会把知识喂给模型，已经不够了。 真正新的基础设施，是让模型像在一个环境里工作。