不建向量库，也能做 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 路线？
这篇文章就沿着这条主线展开，主要看三件事：
Vercel 这个项目具体是怎么做的。 文件系统加 bash 为什么在代码、文档、知识库场景里有效。 这套方法的边界、代价和适用范围在哪里。
这是个什么项目
站在用户视角看，这个项目做的事情其实很好理解：
你先把知识接进来，用户再像平常聊天一样提问，Agent 则在后台真的去翻这些文件，然后把找到的内容组织成答案。
这里的“知识”，可以是 GitHub 仓库、文档内容、YouTube 转录等。接进来之后，它们不会先进向量库，而是会被整理成一份可以搜索的文件集合。
所以对用户来说，体验大概就是三步：
管理员先把知识源接进系统。 用户在 Web Chat、GitHub 或 Discord 里直接提问。 Agent 在后台搜索真实文件、读取相关段落、整理答案返回给你。
如果本地知识里找不到足够信息，当前这套实现还允许它再补一次 web_search。
从技术上看，这里面真正关键的动作也不多：
先把外部知识同步成一份 snapshot repo，内容都落成普通文件。 查询时把这份文件快照挂到 Vercel Sandbox 里，并尽量复用已有 sandbox，减少启动开销。 给模型开放 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 次工具调用结束
它提供的是一种检索行为模板：
不要漫无目的遍历目录 不要一上来 cat大文件不要把一步一步的探索拆成很多轮工具调用 先拿到候选文件，再做有针对性的读取
如果说传统 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 擅长“找到包含这个词的文件”，但不擅长“把最相关的前几个文件稳定排到最前面”。
在文件很多、匹配很多的情况下，你很快就会遇到两个问题：
候选文件太多 排序质量不够
这时更自然的下一步，往往是先引入更成熟的 lexical ranking，比如 BM25、SQLite FTS、搜索引擎索引，甚至再叠一层 reranker。
。
4. 多语言、别名、企业黑话很多
如果同一件事在不同团队里有不同叫法，或者中文、英文、缩写混着来，文件系统检索的 recall 会变差。
这类场景里，语义检索或者至少 hybrid search 往往更稳。
总结
Vercel的做法是一种很“返璞归真”的工程方案。它不是万能解，但在代码库、API 文档、内部知识库这类强结构场景里，工程价值非常高。
这套方法很务实。但是它不覆盖所有检索问题
文件系统加关键词搜索，在这些场景里通常非常强：
代码库 API 文档 内部 Wiki 术语稳定的知识库
但如果问题换成下面这些，embedding 或 semantic search 依然会更重要：
用户表达很模糊，和文档用词不重合 数据高度非结构化 同义词、别名、企业黑话很多 文件很多，排序质量开始明显影响结果
所以社区里比较成熟的结论，并不是“以后都不用 embedding 了”，而是：先看语料，再定检索原语；很多时候 hybrid 才是最后的形态。
不是抛弃 embedding，而是抛弃“默认先上 embedding”的思维惯性。
很多时候，真正好用的 RAG，并不需要一开始就很重；它更需要清晰的证据路径、稳定的检索行为和可解释的结果。
