不用 Embedding 也能做知识 Agent？Vercel 用文件系统干掉了向量检索管线

不用 Embedding 也能做知识 Agent？Vercel 用文件系统干掉了向量检索管线

上周刷到 Vercel 的一篇博客，标题直接就是"Build knowledge agents without embeddings"。一开始以为是噱头——做知识检索不用向量数据库？读完发现，他们的思路确实巧妙：与其让 LLM 学会「语义检索」，不如让它做它最擅长的事——读文件、跑命令。

这个方案把成本砍了 75%，答案质量反而提高了。关键是调试变得极其直观：agent 答错了？打开 trace 看它跑了什么 grep 命令，拉了哪个文件的哪一段。几分钟定位问题。

本文提纲

1. 传统 RAG 的困境
2. Vercel 的替代方案：文件系统 + Agent
3. 架构拆解：Sandbox + AI SDK + Chat SDK
4. 核心组件详解
5. 对比 Embedding 管线：什么场景该用什么

传统 RAG 的困境

绝大多数知识 Agent 的搭建路径是这样的：

1. 选一个向量数据库（Pinecone、Weaviate、pgvector……）
2. 搭 chunking 管线——文档切成小块
3. 选 embedding 模型——把文本变成向量
4. 调检索参数——top-k、相似度阈值、reranking
5. 祈祷别出问题

然后 agent 回答错误。你开始排查：是哪个 chunk 被检索到了？为什么这个 chunk 得分 0.82 而正确答案只有 0.79？是 embedding 模型的问题？chunk 策略的问题？还是 reranking 逻辑的问题？

Embedding 管线擅长语义相似度检索，但在需要精确值的场景下经常翻车。 比如用户问"API 的速率限制是多少"，embedding 可能返回一段提到速率限制但没给出具体数字的段落，而正确答案在另一个被截断的 chunk 里。

更痛苦的是调试。向量的相似度分数是一个黑盒数字——你没法直观地理解为什么 0.82 大于 0.79，更没法告诉用户"因为向量空间中这两个 chunk 更近"。

Vercel 的替代方案：文件系统 + Agent

Vercel 的思路是：LLM 天生就理解文件系统。

它们在训练数据里见过海量代码——遍历目录、grep 搜索文件、跨文件管理状态。代码补全、文件操作本身就是 LLM 的强项。与其教模型一个新技能（向量检索），不如用它最擅长的能力（文件操作）。

核心架构异常简洁：

MERMAID_BLOCK_0

工作流程：
1. 数据源（GitHub repo、YouTube 字幕、Markdown 文档）同步到文件系统
2. 用户提问时，Vercel Sandbox 启动一个临时 Linux VM
3. Agent 在 Sandbox 里用 Bash 命令搜索文件（grep、find、cat）
4. 拿到搜索结果后，LLM 生成答案
5. 返回答案，附带来源引用

没有向量数据库，没有 chunking 管线，没有 embedding 模型。 文件就是文件，命令就是命令，结果可追溯。

成本数据也很直接：单次调用从 ~$1.00 降到 ~$0.25，降了 75%。

架构拆解：Sandbox + AI SDK + Chat SDK

Vercel 把这套方案打包成了 Knowledge Agent Template，一个开源模板，可以一键 fork、定制、部署到 Vercel。

技术栈由三个核心组件撑起：

组件	作用	技术
Vercel Sandbox	安全执行环境	Firecracker MicroVM，隔离的临时 Linux
AI SDK	Agent 编排	TypeScript，支持多模型
Chat SDK	多平台接入	Discord、Slack、Teams、GitHub 等适配器

Vercel Sandbox：用完即焚的 Linux VM

Sandbox 是整个方案的关键基础设施。它本质上是一个 Firecracker MicroVM——和 Vercel 每天 200 万次构建用的同一套底层技术。

import { Sandbox } from "@vercel/sandbox";

const sandbox = await Sandbox.create({
  source: {
    url: "https://github.com/your-org/your-docs.git",
    type: "git",
  },
  resources: { vcpus: 4 },
  runtime: "node24",
});

// Agent 在 Sandbox 里执行搜索
const result = await sandbox.runCommand({
  cmd: "grep",
  args: ["-r", "rate limit", "--include=*.md", "."],
  stdout: process.stdout,
});

每次搜索请求启动一个干净的 VM，跑完即销毁。没有状态污染，没有安全问题——agent 跑的是不可信代码，但被安全隔离在 MicroVM 里。

AI SDK：Agent 的编排大脑

AI SDK（GitHub: vercel/ai，24k+ stars）是 Vercel 的 AI 工具链，支持多种 LLM provider。在 Knowledge Agent 里，它负责：

• 工具调用（Tool Calling）：给 agent 提供 grep、find、cat 等文件操作工具
• 流式响应：实时输出答案
• 模型路由：根据问题复杂度自动选模型

模板里内置了一个 智能复杂度路由器（Complexity Router）：

简单问题 → 快速便宜的模型（如 GPT-4o-mini）
复杂问题 → 强力但昂贵的模型（如 Claude Sonnet）

这一层路由进一步压低了成本。大部分 FAQ 级别的问题用轻量模型就够了，只有需要多步推理的复杂问题才动用重模型。

Chat SDK：一次开发，全平台部署

知识 Agent 不应该只活在网页里。你的工程师在 Slack 上，社区在 Discord 上，Bug 报告在 GitHub 上——agent 应该跟到用户所在的地方。

Chat SDK 提供了一组平台适配器：

// Discord 适配器
import { createDiscordAdapter } from "@vercel/chat-sdk/discord";

// GitHub 适配器
import { createGitHubAdapter } from "@vercel/chat-sdk/github";

// 都指向同一个 Agent 管线
discordAdapter.onMention(async (message) => {
  const response = await agentPipeline(message.text);
  return response;
});

每个适配器处理平台特有的认证、事件格式、消息格式，而 agent 本身的逻辑保持不变。模板开箱自带 GitHub 和 Discord 适配器，Chat SDK 还支持 Slack、Microsoft Teams、Google Chat 等。

核心组件详解

数据源管理

通过 Admin 界面添加数据源，内容存入 Postgres。支持的数据源类型：

• GitHub 仓库：直接 clone，agent 用 grep 搜索代码和文档
• YouTube 字幕：自动提取，存为文本文件
• Markdown 文档：直接作为知识库文件
• 自定义数据：API 拉取或手动上传

数据同步后就是一堆普通文件，不需要任何预处理。

智能搜索策略

Agent 不是简单地跑一个 grep 就完了。它有完整的搜索策略：

1. 先用 find 定位相关文件
2. 用 grep 搜索关键词
3. 用 cat 读取具体段落
4. 必要时用多轮搜索交叉验证

这些步骤由 LLM 动态编排——它会根据问题类型决定搜索策略。简单的事实查询可能只需要一轮 grep，复杂的技术问题可能需要多轮交叉检索。

Admin 管理面板

模板自带完整的 Admin 界面：

• 使用统计：调用量、响应时间、token 消耗
• 错误日志：每个失败的请求都可追溯
• 用户管理：权限控制
• 数据源配置：添加/删除/同步
• AI Admin Agent：可以直接问"过去 24 小时有什么错误"或"用户最常问什么问题"

这个 Admin Agent 本身也是一个知识 Agent——它用 Vercel 的 Instrumentation 提供日志查询能力，让你用自然语言调试 agent。

对比 Embedding 管线：什么场景该用什么

维度	文件系统方案	Embedding 管线
精确检索	✅ grep 精确匹配，无歧义	❌ 语义相似度可能模糊
语义理解	⚠️ 依赖 LLM 的理解能力	✅ 天然支持语义搜索
调试难度	✅ 看命令和文件即可	❌ 向量相似度是黑盒
成本	✅ ~$0.25/调用	❌ ~$1.00/调用
规模	⚠️ 文件数量极大时搜索变慢	✅ 向量检索 O(log n)
实时性	✅ 文件更新立即可搜	❌ 需要 re-embed
搭建复杂度	✅ 无需额外基础设施	❌ 向量 DB + 管线
非文本数据	❌ 主要适用于文本	✅ 多模态 embedding

文件系统方案最适合的场景：

• 知识库以文档/代码为主（技术文档、API 文档、代码仓库）
• 需要精确答案而非模糊匹配
• 团队需要快速调试和迭代
• 数据源经常更新，需要实时同步

Embedding 管线仍然适合的场景：

• 超大规模数据（百万级文档）
• 多模态内容（图片、音频的语义搜索）
• "给我类似的内容"这种模糊查询

这两种方案不互斥。Vercel 的思路是：很多团队在不需要 Embedding 的场景下被迫用 Embedding，因为这是"标准做法"。而文件系统方案提供了一个更简单、更可调试、更便宜的替代——至少在特定场景下。

一键部署到 Vercel，配置数据源，开始回答问题。没有向量数据库，没有 chunking 管线，没有 embedding 模型。

---

作者: itech001
来源: 公众号：AI人工智能时代
网站: https://www.theaiera.cn/
每日分享最前沿的AI新闻资讯和技术研究。

本文首发于 AI人工智能时代，转载请注明出处。