只用文件系统和 Bash，Vercel 做出了一套高效 RAG

用户430799454767
0 阅读9分钟

不建向量库，也能做 RAG？Vercel 给了一个新答案

Vercel 发了一篇博客：Build knowledge agents without embeddings。开源了一个知识库agent问答项目 Knowledge Agent Template。

该项目不靠“embeddings”实现了一个知识库搜索问答系统。它把知识库当成一个可搜索的文件系统：模型在 sandbox 里调用 grep、find、head、cat 这些普通命令，先找文件，再读文件，再综合答案。

按照官方博客的说法，他们内部一个销售电话总结 agent 的单次成本，从大约 $1.00 降到了 $0.25，而且输出质量还更好。

为什么一套看起来很普通的文件系统操作，被 Vercel 重新组织之后，可以成为一条足够实用的 RAG 路线？

这篇文章就沿着这条主线展开，主要看三件事：

  1. Vercel 这个项目具体是怎么做的。
  2. 文件系统加 bash 为什么在代码、文档、知识库场景里有效。
  3. 这套方法的边界、代价和适用范围在哪里。

这是个什么项目

站在用户视角看，这个项目做的事情其实很好理解：

你先把知识接进来，用户再像平常聊天一样提问，Agent 则在后台真的去翻这些文件，然后把找到的内容组织成答案。

这里的“知识”，可以是 GitHub 仓库、文档内容、YouTube 转录等。接进来之后，它们不会先进向量库，而是会被整理成一份可以搜索的文件集合。

所以对用户来说，体验大概就是三步：

  1. 管理员先把知识源接进系统。
  2. 用户在 Web Chat、GitHub 或 Discord 里直接提问。
  3. Agent 在后台搜索真实文件、读取相关段落、整理答案返回给你。

一次真实问答中，Agent 在后台通过 bash 搜索和读取知识库文件

如果本地知识里找不到足够信息，当前这套实现还允许它再补一次 web_search。

从技术上看，这里面真正关键的动作也不多：

  1. 先把外部知识同步成一份 snapshot repo，内容都落成普通文件。
  2. 查询时把这份文件快照挂到 Vercel Sandbox 里，并尽量复用已有 sandbox，减少启动开销。
  3. 给模型开放 bash 和 bash_batch 两个受限工具，让它通过 grep、find、head、cat 这些命令完成搜索和阅读。

Vercel 这套方案最有价值的地方，是把文件系统检索做成了一条可复用、可解释、可控成本的工程路径。

文件系统 + bash，怎么被组织成一套 RAG

我找到了我关注的核心文本，其实就是一段系统提示词，源文件在 BASE_SYSTEM_PROMPT

重点是 Fast Search Strategy 这一段。

Agent 底层模型对bash读文件的操作天然了熟于心，Claude code/Codex 每次打开的时候就需要读文件，读系统指令，用户自定义指令，skill列表等。

所以这段提示词里最值得看的，是这些命令如何被约束、组合和工程化。

1. 优先批次bash，一次读写

BASE_SYSTEM_PROMPT 里开头一句是：

ALWAYS prefer `bash_batch` over sequential `bash` calls. Combine search and read in the same batch.

提示词首先约束优先使用 bash_batch 而不是串行 bash, 同时尽量在一次batch执行中完成搜索文件和读文件操作。整段提示词都是这一句话的详细展开。

内部定义了一个函数可以批量处理多条bash指令, 比如大模型可以一次把以下三条指令合并发下去：

bash_batch: [
  "grep -rl "keyword" docs/source1/ --include="*.md" | head -5",
  "grep -rl "keyword" docs/source2/ --include="*.md" | head -5",
  "head -100 docs/source1/getting-started/index.md"
]

bash_batch 的价值主要在于把多条命令打包成一次工具调用。

它省下来的主要是：

  • 多轮工具调用带来的模型思考开销
  • 中间步骤的 token 消耗
  • Agent 在长循环里越走越散的风险

对 Agent 来说，这更像是一次性打包检索计划：少几轮 tool loop，往往就少几轮试探和 token 消耗。

在实际运行中，多个搜索和读取动作会被合并成更少的工具调用

2. 克制检索文件，够用就行

提示词里面给出bash指令指导用法：

### Quick reference
| Task | Command |
|------|---------|
| Find files by content | \`grep -rl "keyword" docs/ --include="*.md" | head -5\` |
| Multi-keyword search | \`grep -rlE "term1|term2" docs/ --include="*.md" | head -5\` |
| Find files by name | \`find docs/ -name "*routing*" -name "*.md"\` |
| Read file (partial) | \`head -100 docs/path/file.md\` |
| Read file (full) | \`cat docs/path/file.md\` |
| Search with context | \`grep -n -C3 "keyword" docs/path/file.md\` |

然后提示词里面给出了正面样例和反面样例, 依然是提倡合并多个bash 调用。

### Good vs Bad

**Good** — 1-2 calls:
1. \`bash_batch\`: grep across likely dirs + read obvious files in one call
2. \`bash_batch\`: read remaining files from grep results

**Bad** — 5+ calls:
1. \`find docs/ -maxdepth 2 -type d\`
2. \`grep -rl "keyword" docs/source1/\`
3. \`grep -rl "keyword" docs/source2/\`
4. \`cat docs/source1/file1.md\`
5. \`cat docs/source2/file2.md\`

最后的Rules给出了更多bash优化的参考. 比如：

  • 使用head -N 输出更小的文本，而不是一下子获取整个文件内容
  • 使用grep -rlE "term1|term2" 同时搜索多个关键词
  • 使用grep -rl 而不是 grep -r，只获取文件路径，忽略匹配行

提示词里所有示例，本质都在强化同一个策略：

  • 先用 grep -rl 找路径
  • 用 head -N 只读局部
  • 一次搜索多个关键词
  • 尽量 1 到 2 次工具调用结束

它提供的是一种检索行为模板：

  1. 不要漫无目的遍历目录
  2. 不要一上来 cat 大文件
  3. 不要把一步一步的探索拆成很多轮工具调用
  4. 先拿到候选文件，再做有针对性的读取

如果说传统 RAG 的很多工作花在“如何切 chunk”，那 Vercel 这里花的心思更像是：如何让模型像一个克制的命令行使用者。

这套方案最适合什么场景

1. 个人知识库和 Agent 记忆

如果你的知识库本来就是一堆 Markdown、日报、想法笔记、命令记录、Prompt 模板，那么先走文件系统检索几乎是最自然的选择。

它比 embedding 更轻，也更接近日常工作方式：

  • 人自己就是按文件和目录在找东西
  • Agent 也可以按文件和目录找东西

同时这也启发我们，在做个人知识库的时候，语义化的文件命名和文件夹命名能极大提高agent的搜索效率。很多时候只要给 Agent 一份干净的目录，再配上一些 prompt 约束，已经能得到很不错的效果。

另外我说的文件系统检索完全不需要把 Vercel 这一整套都搬过来。

像 sandbox、snapshot、共享沙箱池这些设计，更多是为了把系统做成一个能稳定服务多用户、多会话、多平台的产品。对个人来说，这套工程通常太重了。

而且今天很多 Agent 本来就已经会做这件事。

无论是 Claude Code、Codex，还是其他带 bash 能力的 coding agent，它们本来就会：

  • 读目录
  • 搜文件
  • 看局部内容
  • 根据文件证据组织答案

所以个人最有参考价值的，不是整套 Vercel 基础设施，而是它向我们释放的信号：最简单的文本匹配也许是最高效的检索方式。

2. 代码库问答

这是它最天然的主场。

代码库里最重要的信息，本来就大量存在于：

  • 文件名
  • import 路径
  • 函数名
  • 类型名
  • 配置文件
  • 注释和 README

这些都非常适合 lexical search，而不太需要语义嵌入先做一层“翻译”。

3. API 文档和产品文档

文档站也很适合，尤其是有清晰目录树、标题层级和稳定术语的文档。

比如“认证怎么配”“路由在哪里定义”“某个 Hook 支持哪些参数”这类问题，本质都是在找明确的局部证据。

什么时候它会明显不如 embedding

说完优点，也得把边界说清楚。

文件系统 RAG 也有很清晰的边界。下面这些情况里，embedding 或 hybrid search 往往更稳。

1. 用户提问和文档表述没有词汇重合

这其实是 embedding 诞生的根本原因。

如果用户问的是模糊概念、近义表达、口语化描述，而知识库里的写法完全不同，grep 很可能就是搜不到。

例如：

  • 用户问“怎么做登录保护”
  • 文档写的是“route middleware” 或 “access control”

只靠关键词，很容易漏召回。

2. 知识非常松散、噪声很大

比如 OCR 文档、杂乱 PDF、客服工单、聊天记录、大量口语转写，这些内容往往命名不规范、结构不稳定、同义表达很多。

这种情况下，光靠路径和关键词，效果通常不会太好。

3. 语料规模很大，而且需要更强排序

原始 grep 擅长“找到包含这个词的文件”，但不擅长“把最相关的前几个文件稳定排到最前面”。

在文件很多、匹配很多的情况下，你很快就会遇到两个问题：

  1. 候选文件太多
  2. 排序质量不够

这时更自然的下一步，往往是先引入更成熟的 lexical ranking，比如 BM25、SQLite FTS、搜索引擎索引，甚至再叠一层 reranker。 。

4. 多语言、别名、企业黑话很多

如果同一件事在不同团队里有不同叫法，或者中文、英文、缩写混着来，文件系统检索的 recall 会变差。

这类场景里，语义检索或者至少 hybrid search 往往更稳。

总结

Vercel的做法是一种很“返璞归真”的工程方案。它不是万能解，但在代码库、API 文档、内部知识库这类强结构场景里，工程价值非常高。

这套方法很务实。但是它不覆盖所有检索问题

文件系统加关键词搜索，在这些场景里通常非常强：

  • 代码库
  • API 文档
  • 内部 Wiki
  • 术语稳定的知识库

但如果问题换成下面这些，embedding 或 semantic search 依然会更重要：

  • 用户表达很模糊，和文档用词不重合
  • 数据高度非结构化
  • 同义词、别名、企业黑话很多
  • 文件很多，排序质量开始明显影响结果

所以社区里比较成熟的结论，并不是“以后都不用 embedding 了”，而是：先看语料，再定检索原语；很多时候 hybrid 才是最后的形态。

不是抛弃 embedding，而是抛弃“默认先上 embedding”的思维惯性。

很多时候，真正好用的 RAG，并不需要一开始就很重；它更需要清晰的证据路径、稳定的检索行为和可解释的结果。

参考

avatar
文章
阅读
粉丝