Vercel把向量數據庫扔了：1個銷售電話省0.75美元

去年Q4，Vercel內部有個銷售 call 總結 agent 跑得很痛苦。每次調用成本1美元，輸出還時不時出錯。工程師們查了三周，發現某個 chunk 把"企業版"和"團隊版"的價格混在一起了——但向量數據庫的檢索日志只顯示相似度0.82，沒人知道為什么這個 chunk 贏了0.79的那個。

他們干脆把整件事掀了。向量數據庫、嵌入模型、分塊管道，全拆。換成文件系統+bash命令，成本掉到0.25美元，準確率反而上去了。

3月19日，這套架構開源了。名字叫 Knowledge Agent Template，基于 Vercel Sandbox、AI SDK 和 Chat SDK。沒有嵌入，沒有向量檢索，agent 用 grep、find、cat 在隔離沙盒里翻文件。

為什么向量檢索成了黑箱

傳統知識 agent 的搭建路徑幾乎一模一樣：選向量數據庫→建分塊管道→挑嵌入模型→調檢索參數。這套流程對語義相似度有效，比如找"定價相關的段落"。

但結構化數據里的精確值是另一回事。用戶問"企業版年費多少"，向量檢索可能返回一個包含"企業版"和"價格"的 chunk，但里面的數字是去年的。失敗模式是靜默的：agent 自信地給出錯誤答案，而你無法追溯問題→chunk→答案的完整鏈條。

Vercel 的工程師在內部復盤時畫過一張圖：向量管道的調試是"調分塊邊界？換嵌入模型？改相似度閾值？"三個問號同時存在。文件系統搜索的調試是"它跑了 grep -r 'pricing' docs/，讀了 docs/plans/enterprise.md，拉錯了段落"——一個確定的動作鏈。

調試循環從幾周壓縮到幾分鐘。這是他們把架構開源的核心論據。

文件系統搜索怎么跑起來

Knowledge Agent Template 的架構分四層。最上層是接入層：GitHub 倉庫、YouTube 字幕、Markdown 文檔、自定義 API，都能接。管理員在后臺界面添加源，內容存 Postgres。

同步層用 Vercel Workflow，把內容推到快照倉庫。這一步是離線的，不占用推理時的資源。

查詢層是關鍵。用戶提問時，Vercel Sandbox 加載快照，agent 調用 bash 和 bash_batch 工具執行文件系統命令。grep 找關鍵詞，find 定位文件，cat 讀內容。結果是確定性的：同樣的輸入，同樣的命令序列，同樣的輸出。

最下層是交付層。同一套 agent 可以同時部署成網頁聊天、GitHub Bot、Discord Bot，不用改核心邏輯。

成本結構的變化很直接。向量數據庫的調用費、嵌入模型的 API 費、分塊管道的計算費，變成了沙盒的冷啟動時間和文件 I/O。Vercel 的測試數據顯示，銷售 call 總結場景從~1.00美元降到~0.25美元，降幅75%。

誰適合抄這個作業

文件系統搜索不是萬能藥。它的優勢場景很具體：數據源可控、更新頻率中等、需要精確值而非語義關聯。代碼倉庫、產品文檔、內部知識庫是典型例子。

不適合的場景同樣明顯。非結構化數據占主流、需要跨文檔語義關聯、數據源極度分散的情況，向量檢索仍有優勢。比如從10萬份客服對話里找"情緒相似"的案例，grep 無能為力。

Vercel 的模板設計了一個折中：Postgres 存元數據，文件系統存內容，agent 自己決定什么時候用哪種工具。這種混合架構可能是更務實的長期路線。

開源社區的反應分裂成兩派。一派認為這是對向量數據庫廠商的"背刺"——Vercel 自己之前推的 AI SDK 示例全是向量檢索。另一派覺得這是回歸常識：LLM 本來就會讀文件，為什么要用嵌入把它壓成一堆浮點數再展開？

一個未被回答的問題

模板開源一周后，GitHub 上最活躍的 issue 不是功能請求，而是關于規模的質疑：當快照倉庫超過10GB時，沙盒冷啟動時間會不會吃掉所有成本優勢？Vercel 的文檔里沒有給出明確閾值，只寫了"建議按業務場景測試"。

另一個沉默點是多語言支持。grep 對中文分詞不友好，模板目前依賴 LLM 自己處理編碼問題。有開發者試了日文文檔，發現全角半角混用時檢索漏率明顯上升。

這些細節沒有阻止模板的傳播。截至3月26日，Knowledge Agent Template 的 fork 數已經超過 Vercel 去年開源的 AI SDK 示例倉庫同期的三倍。一個可能的解釋是：它解決了一個真實的痛點——不是"怎么做 RAG"，而是"怎么在周五下午五點 debug 一個答錯的 agent"。

如果你現在想動手，模板的一鍵部署按鈕在 Vercel 官網。但有個問題想先問你：你的知識庫，最近一次被完整 grep 一遍花了多久？