知识库 Agent 可能根本不需要向量库，Vercel 这刀捅得有点狠
很多知识库 Agent 其实不一定需要 embedding 和向量数据库。 如果你的问题更像"配置写在哪""这个价格表在哪一页""权限规则藏在哪个目录"，那文件系统加 grep、find、cat 这种老派办法，可能反而更稳、更便宜，也更好排错。
这事听起来有点反常识。过去一年，大家一提知识库问答，默认流程几乎都是：切 chunk、做 embedding、丢进向量库、调召回、再祈祷别抽风。结果 Vercel 最近直接把桌子一掀：别上来就整这套，先让 Agent 去读文件。
他们到底干了什么？
Vercel 开源了一套 Knowledge Agent 模板，核心思路非常直接：不用向量库，直接把知识源同步成文件，然后让 Agent 在沙箱里跑 bash 命令检索。
翻成人话就是，Agent 不再靠"语义相似度"猜哪段文本最像答案，而是像一个有点勤快的工程师一样：
- 先找目录
- 再搜关键词
- 然后打开对应文件
- 最后基于读到的内容回答
这个思路听上去不性感，但它有个巨大优点：你知道它到底是怎么找到答案的。
为什么这套东西会让人眼前一亮？
因为太多 RAG 项目，死得不是因为模型不够强，而是检索链路太黑箱了。
你问一个很具体的问题，比如"企业版价格的附加席位怎么收费"。系统答错了。接着你就得开始考古：
- 是 chunk 切坏了？
- 是 embedding 没理解这句话？
- 是相似度阈值太低？
- 还是召回了正确片段，但排序没顶上来？
这种排错体验，真的很像在雾里找遥控器。
而文件系统流派就没那么玄学。它如果答错，你大概率能直接看到：哦，它搜了 pricing，结果打开了旧版文档，或者它关键词下错了，漏掉了另一个目录。这个问题一下就具体了。
不是"反向量库"，而是别默认它是标准答案
我觉得 Vercel 这次最有价值的地方，不是证明向量库没用，而是提醒大家：别把 embedding 管线当成知识库 Agent 的唯一正确姿势。
很多内部知识库，本来就是强结构化的：
- 文档有目录层级
- 文件名可读
- 配置项有明确关键词
- 内容经常是 markdown、代码、手册、FAQ
这种场景，本来就很适合文件检索。你硬塞进向量库，最后得到的可能不是"更智能"，而是"更复杂"。
更扎心一点说，很多团队做知识库系统，花的时间根本不在回答问题，而是在维护检索基础设施本身。模型倒成了最不折腾的那一环。
这套思路为什么还更便宜？
Vercel 给的案例里，某个销售通话总结 Agent 的单次成本从大约 1 美元降到了 0.25 美元。
原因也不神秘：
- 少了一层 embedding 生成和存储
- 少了一套向量索引维护
- 少了大量检索调参和重复试错
- Agent 直接对文件操作，路径更短
当然，不是所有场景都能这样降本。但对很多中小型知识库来说，这个方向确实很香：你不是在省几分钱，而是在省掉一整个会持续啃工程时间的系统。
它适合什么场景？
如果你手里的数据更接近下面这些，真的可以优先试文件系统方案：
- 产品文档中心
- 企业内部 SOP
- 帮助中心和 FAQ
- 代码仓库、SDK 文档、接口说明
- 版本清晰的 markdown/文本资料
尤其是开发者向产品，命令行检索本来就是母语。Agent 能直接用大家熟悉的方式找资料，整体心智成本会低很多。
顺带一提，这也挺像一个朴素但经常被忽略的原则：能先用简单系统解决的问题，就别急着上复杂系统。
如果你最近也在搭知识库或者企业问答工具，真可以先把这套思路过一遍。与其一上来就配齐向量库、重排器、切片策略，不如先问一句：我这个问题，文件系统能不能已经解？你可能还想看：更多 AI/开发文章。
但它也不是银弹
该说的也得说，这玩意儿不是万能解法。
如果你的数据特别松散，用户提问方式又很飘，靠关键词根本对不上；或者你需要跨大量异构内容做语义联想，那 embedding 检索还是有意义。
所以更靠谱的结论不是"以后别用向量库"，而是：
先判断你的知识库问题到底更像搜索问题，还是更像语义理解问题。
前者，文件系统和 bash 可能就够猛。后者，再上向量库也不迟。
我更喜欢这件事的哪一点？
不是省钱，也不是复古。
而是它把 Agent 这件事从"神秘魔法"往"可维护系统"拉回去了一点。你能看见它怎么查、怎么读、怎么答，工程上就更敢信它，也更容易把锅甩到正确的位置。
这点很重要。因为真正能在线上活下来的 Agent，最后拼的往往不是 demo 多惊艳，而是出错时你能不能十分钟内知道它错在哪。
Vercel 这次给的不是唯一答案，但确实像一巴掌扇醒了不少人：
知识库 Agent 不一定要先从向量库开始。很多时候，先把文件夹和命令行用明白，才是那条更短的路。