大家好，我是小木头。同一个代码问题，换一套搜索工具，Agent 会不会回答得更快呢？会不会用掉更少的 Token 呢？最近我把 zvec-grep 做成了 DeepSeek Harness 和 Pi Agent 插件。今天我就用两个会话，基于相同的问题来对比原生的搜索工具和它，在真实项目里的某些问题上表现究竟有什么不同。
前几期视频里我们介绍了 zvec 和 zvec-grep。简单来说，zvec 是一个进程内、本地持久化的向量数据库，它像向量检索领域的 SQLite。应用可以直接把它嵌进自己的进程，并不需要另外维护一套数据库服务。zvec-grep 则在它上面补齐了文件发现、代码与文档切分、embedding、全文检索向量召回和最终结果的融合，最后变成一套可以给 Agent 使用的代码搜索层。
这里需要再强调一次：zvec-grep 并不是用向量搜索替代了 grep。如果已经知道函数名、错误信息、配置键、文件名或者正则表达式，精确的搜索通常更快也更加确定。但如果我们只知道一个功能大概在做什么，却不知道代码里用了什么名字；或者问题涉及架构、关系控制流和多个文件，语义搜索就更容易先找到入口。找到入口以后，仍然需要读取实时的源代码的时候呢，再来读取文件、读取代码做继续的验证。
在试用 zvec-grep 的过程中，我也想到一个问题：既然它最终是给 Agent 使用的搜索工具，能不能够直接把它放进 Agent 自己的生命周期？而不是要求每个用户先安装 zg，再为每个项目建立索引、配置 MCP。所以呢，我分别做了 DeepSeek Harness 和 Pi 的插件。插件只需要安装一次，以后每次会话启动它会自动识别当前的工作区，在后台建立或者更新索引，并且持续的监听文件的变化。Agent 会直接获得一个叫 zvec_search 的工具，正常使用并不需要运行 zg install、zg index，也不需要单独启动 MCP Server。
我们先看看 DeepSeek Harness 这边吧。运行 npx dsh plugin add，这个插件把插件加到 Web profile 完成插件的安装。完成以后，照常运行 npx dsh web 进入一个工作区。插件会在后台打开或者更新索引，第一次使用本地的 embedding model 可能还需要自动的下载模型，所以呢可能会多等一会。DSH Web 里面会有一个 zvec index 的状态胶囊在右下角，它会从 Indexing 变成 Ready。
变成 Ready 以后 Agent 就可以调用 zvec_search 工具了，实际上这个时候呢索引已经就绪。就有索引数据来支撑这个 zvec_search 插件的界面状态和搜索工具呢会一起出现，没有额外的前端配置。Pi Agent 这边呢同样也只有一条安装命令非常简单：pi install npm:@sugarforever/pi-zvec-grep。再从命令行启动 Pi，插件会找到当前的工作区自动协调索引，同时注册一个同名的工具 zvec_search。
需要确认状态时可以运行 /zvec-status 来查看当前的索引状态，还有一个命令 /zvec-reindex 主要用于诊断和恢复。正常使用呢并不需要手动去重建索引。接下来我们只在 DeepSeek Harness 里面做一次同问题的比对，在 Pi Agent 感兴趣的朋友呢也可以来做同样的测评。两个独立会话使用相同模型从相同的初始上下文开始，问题呢非常相似都是 "find out how the knowledge base is designed and implemented"。
普通组并不指定搜索路径或搜索工具，让 Agent 自己使用内置的工具；而 zvec 这一组呢明确要求使用 zvec_search。我们来记录5项信息：从提问到完整回答的时间、input Token 工具调用的总轮次、第一次命中关键入口的轮次，以及最终的回答覆盖哪些关键的信息。这里不能在问题里提前泄露文件名或函数名，否则呢就失去了语义发现的意义。
我们先看看使用内置搜索工具的 baseline 它最后给出了一份完整的回答，从数据模型到接口一直再到了文档的处理向量的存储检索路径和前端的入口。不过在这个过程中 Agent 需要不断地猜测项目词汇，再通过多轮的搜索和读取扩大范围。这个呢在工具调用的整个链路上咱们也能看到一些蛛丝马迹，整个任务走了大约30个步骤。
运行时间呢是1分34秒，Token 开销应该是在 136 万左右的 Token。具体的 input、cache 和 output 数据呢可以在画面里都看到。我们再来看看明确使用 zvec_search 的会话，它的步骤呢少了许多用了9个步骤。运行时间是37秒也少了许多，关于 Token 的开销上是339,000左右。
相较于刚才那会话看起来呢少了不少，对比下数据吧：和 baseline 相比这次的时间减少大约60%，步骤少了70%。Token 开销使用上减少了大约 75%。它同样找到了数据模型、文件的处理检索聊天调用等等，但更早进入了能够回答问题的关键文件。不过这里需要说明一个实际情况：如果大家细心比对两个会话输出的回答，它们虽然回答的呢是同一个问题覆盖的核心架构也有重合。
但展开重点细节和输出长度呢并不完全相同，所以咱们这并不是说相同答案用了更少 Token 的严格基准。只能看作同问题同模型下两条实际的调查路径的参考，不同的人对同一个问题也完全可能有不同的回答的预期。Pi 这次呢没有再做一轮性能对比，只是简单的咱们来总结一下插件提供的体验：安装一次以后从项目目录启动 Pi 插件自动识别工作区。
在后台建立或更新索引，监听运行期间的文件变化再向 Agent 注册 zvec_search 工具。索引正在更新时搜索呢并不会卡住整个会话，而是返回一个可以重试的状态。需要确认工作区和索引的情况呢可以使用 slash 命令 /zvec-status。也就是说，它跟 DeepSeek Harness 插件解决的是同一个问题：让这套检索能力跟着 Agent 的会话自动工作。
通过这些对比我们也可以更具体的判断什么时候值得维护一份索引：第一是较大且陌生的代码仓库，Agent 还不知道应该从哪里开始；第二是自然语言描述与代码命名并不一致的问题。第三是答案分散在代码、配置、文档之间需要跨文件综合的去检索；第四呢就是同一个项目会被多个会话反复的查询。第一次建索引的成本可以被后续的使用来摊薄。
当然它也是有代价的，一个小小代价呢就是首次模型的下载和建立索引需要时间。另一方面很重要的是召回质量受到 embedding model 和查询语言的影响，为了保证语义搜索能够达到最好的效果反映出当前的代码或文档的实际的情况呢索引还需要随时保持最新、随时保持更新，这个呢也是额外的代价。
DeepSeek Harness 和 Pi 这两个插件目前呢都已经开源也发布到了 npm，你可以从视频描述里的链接获取直接安装并且体验。也可以拿自己的仓库来做一次对比，不同项目、不同模型和不同问题可能都会得到不一样的结果。如果使用过程中遇到问题或者想到可以改进的地方，欢迎大家在 GitHub 提 issue，也欢迎直接提交合并请求。
比起一句“向量搜索更快”，我更希望这些插件能够给到大家或者为大家提供一个可以亲自尝试改进的起点。以上呢就是本期视频的全部内容，希望对大家有所帮助。我是小木头，我们下期再见吧。