我不再使用 Grep,结果我的 Agent 速度提升了 10 倍

BBetter Stack
컴퓨터/소프트웨어창업/스타트업AI/미래기술

Transcript

00:00:00有一个叫 Claude Context 的 MCP 插件,它能索引你的整个代码库
00:00:06到一个向量数据库中,这意味着你的编码助手可以快速获取它所需的精确代码
00:00:11而无需使用 grep 或 glob 进行猜测,在那儿祈祷能找到正确的文件。
00:00:15它甚至会用 AST 解析你的代码,并使用一种混合搜索方法,结合了语义
00:00:20向量和关键字匹配,这最终能减少 40% 的上下文占用。
00:00:24但它确实需要一个 Zilliz 云账号和一个 OpenAI 密钥来获取嵌入向量,即使你用的是 Claude 的代码。
00:00:30那么,多付出的努力和成本换来这些 Token 的节省值得吗?
00:00:34点击订阅,让我们一探究竟。
00:00:35好的,Claude Context——我不太确定这个名字——是由 Zilliz 开发的,这是一家
00:00:43由 Milvus 的创始人创建的公司,Milvus 是一个性能非常强悍的向量数据库。
00:00:47它通过 MCP 连接到你的代理,这意味着它可以与任何代理框架配合使用,
00:00:52而不仅仅是 Claude Code。
00:00:54但它做了三件相当复杂的事情,让你的代码易于查找。
00:00:58首先,它使用 TreeSitter 遍历所有代码,创建函数和类的代码块,
00:01:03这支持九种语言,包括 TypeScript、Python、Rust 和 Go。
00:01:08然后,它使用自定义的 Merkle DAG 对每个文件进行哈希处理并生成 JSON 快照,这意味着它只重新索引
00:01:15发生更改的文件,而不是整个代码库。
00:01:18然后,当你真正想要搜索代码时,它会同时执行两种类型的搜索,
00:01:22一种是查找代码语义含义的向量搜索,另一种是用于精确关键字匹配的 BM25 索引
00:01:29搜索。
00:01:31这一切最终带来了高达 40% 的上下文缩减,对于大型代码库来说这非常可观。
00:01:37事实上,让我们通过测试 VS Code 代码库来看看它的实际效果,该代码库有
00:01:42大约 150 万行代码。
00:01:44在克隆的 VS Code 仓库里,我将使用 Open Code 和 GPT-4o Turbo,因为
00:01:50我不想耗尽我的 Claude Pro 每周额度。
00:01:53为了设置 MCP 服务器(你可以看到就在这里),我已经添加了
00:01:58相关信息到我的 Open Code JSON 文件中。
00:02:01关于这些信息,你可以在本地运行 Milvus,但我使用了 Zilliz Cloud。
00:02:06所以我有从那边获取的 API 密钥,并且创建了一个集群。
00:02:10这是一个 AWS 集群,并从这里获取了公共端点。
00:02:14说到集群,我确实尝试先使用免费版,但我一直遇到
00:02:19超时问题。
00:02:20所以我不得不弄了一个无服务器版(serverless),这虽然要花钱,但确实好用多了。
00:02:25一旦你设置好了 MCP 服务器,确保你运行的 Node 版本低于
00:02:2824 但大于或等于 20。
00:02:31我目前为了这个项目使用的是 22 版本。
00:02:34这将让你能够使用四个 MCP 工具:索引代码、搜索代码、清除索引和获取
00:02:39索引状态。
00:02:40现在你需要做的第一件事是索引代码库,我们可以用这个提示词来做。
00:02:44但在我们按下回车之前,让我们看看我们在 OpenAI 嵌入上已经花了多少钱,
00:02:48只有一美分,那是用于测试一个 23,000 行的代码库。
00:02:53我们还可以在集群中看到我们已经有了从代码库索引来的信息。
00:02:58所以现在如果我们索引这个代码库,它确实需要一些时间,并且会在后台
00:03:02开始索引。
00:03:03此时,我不建议进行任何搜索。
00:03:05因为这是一个大型代码库,它需要一段时间来索引。
00:03:09所以我稍后等索引完成后再回来。
00:03:11大约 50 分钟后,索引完成,我们可以看到我们的集群中多了一个
00:03:16包含超过 223,000 条加载条目的数据块。
00:03:21作为参考,我之前测试用的那个拥有 23,000 行代码的代码库大约有
00:03:271,000 条条目,而且索引时间不到一分钟。
00:03:32至于我们的 OpenAI 使用成本,已经从一美分涨到了 1.06 美元,这确实不少,但我
00:03:38不认为人们会经常需要处理 150 万行代码。
00:03:42好了,让我们看看搜索速度有多快。
00:03:45这里我们有一个使用 Claude Context MCP 服务器的 Open Code 实例,这里
00:03:49我们有另一个没有使用任何 MCP 服务器的实例。
00:03:52所以它将使用常规的 grep 和 glob 工具来搜索代码。
00:03:56我们要给它一个提示词:使用 Claude Context 找到这个项目
00:04:00启动时的入口点。
00:04:01看看这要花多长时间。
00:04:02好的,它正在使用索引工具,现在它在用搜索工具。
00:04:06整个过程花了大约 19 秒来搜索整个项目并找到
00:04:10主 .ts 文件。
00:04:11现在我们将给另一个 Open Code 类似的提示词,它在
00:04:1514 秒内找到了结果。
00:04:16所以,对于这个查询来说,仅使用常规的 GLM 快得多。
00:04:20让我们开始一个新的会话。
00:04:21然后我要给它一个新的提示词:什么函数用于打开一个新的无标题文档。
00:04:26这一个花了稍长的时间,用了 40 秒,找到了带有行号的
00:04:30主要函数,并使用了大约 23K 的 Token。
00:04:32而另一个实例在 12 秒内完成了,使用了 18K 的 Token,但看起来它找到了
00:04:37一个不同的文件。
00:04:38事实上,Claude Context 提供了更多信息,展示了代码以及与
00:04:44打开编辑器相关的其他文件。
00:04:45所以我要让它们俩都给我展示具体的代码。
00:04:48此时,Claude Context 在 23 秒内用代码回复,而没有使用 Claude
00:04:52Context 的 Open Code 在 49 秒内回复,几乎是前者的两倍时间。
00:04:56而且它找到的代码和 Claude Context 找到的完全一样,这给了我一个想法。
00:05:00我要给它一个更广泛、更笼统的提示词:查看代码并告诉我
00:05:04这个项目是如何工作的。
00:05:06Claude Context 在 49 秒内完成,使用了 41K Token,而另一个实例完成得
00:05:11更快,使用的 Token 也更少。
00:05:13但如果我们看看产生的结果,我们可以看到 Claude Context 提供了更多细节,
00:05:17给出了分层架构,甚至还有一些关于 Electron 应用
00:05:22和它所使用进程的信息。
00:05:23而没有使用 Claude Context 的选项也确实提供了一些架构信息,但
00:05:28不像另一个那么详尽。
00:05:30事实上,我知道看起来不像,但我认为 Claude Context 非常擅长
00:05:34快速、详细地提前获取代码信息。
00:05:37我的意思是,看看这个。
00:05:38所以针对这个提示词,我后续要求它提供关于 Electron 应用中主进程的
00:05:43更多信息,它在上面说明了。
00:05:47所以在我问了这个提示词之后,它花了大约 1 分 47 秒,但看看所有那些
00:05:52细节。
00:05:53它从启动序列开始,然后是第一阶段:服务创建和
00:05:58服务初始化。
00:05:59我们在第二阶段得到了更多内容,即代码应用 App,并附有所有相关文件的
00:06:04引用。
00:06:05所以我们有 app.ts 第 185 行,我们还可以一直列举下去。
00:06:10而在没有 Claude Context 的情况下,Open Code 仍然在使用多个
00:06:15子代理遍历所有文件。
00:06:16这有点欺骗性,因为我们无法准确看到每个子代理
00:06:21正在使用多少 Token。
00:06:22但如果我们等一会儿再回来,我们可以看到大约 5 分钟后,Open Code
00:06:26回复了大量关于 Electron 进程的信息,但这没有
00:06:31Claude Context 提供的那么多,而且它花的时间多了五倍。
00:06:34现在,是的,也许如果我使用像 Opus 4.7 这样更聪明的模型并加大力度,它会得到
00:06:40更多信息,但它仍然会花费很长时间并使用很多 Token。
00:06:44这些就是我在录制前测试 23K 行代码库时所看到的差异,即五分钟和一分钟。
00:06:48录制前测试的时候。
00:06:51所以最终,很难说谁是明确的赢家。
00:06:54我的意思是,Claude Context 确实总是提供更多细节,但它并不总是最快
00:07:00且最节省 Token 的。
00:07:01对于大型代码库,它的索引过程确实非常耗时。
00:07:05然而,对于中等规模的代码库,即 2 万到 3 万行代码,索引时间
00:07:10真的很快。
00:07:11而且结果在细节上的差异非常明显。
00:07:14事实上,对于中等规模的代码库,我更愿意使用 Claude Context
00:07:20而不是在大型代码库上使用它。
00:07:22所以这是值得考虑的一点。
00:07:23但老实说,这对 Zilliz 来说更像是一个很棒的营销工具,因为在使用 Claude
00:07:27Context 之前,我从未听说过他们,现在他们有了一个新的付费客户。
00:07:31但尽管它安装起来确实花了一些时间,而且索引大型代码库确实花费了
00:07:36很长一段时间。
00:07:37作为一个经常查阅开源代码库并进行提问的人,我认为
00:07:42这是我以后会更多使用的工具。
00:07:44我的意思是对于中等规模的代码库,无服务器方案并不太贵,而且
00:07:49OpenAI 的嵌入成本也不会太高。
00:07:52所以我很高兴承担这些费用。
00:07:53说到数据检索和人工智能。
00:07:55如果你想学习如何从零开始构建一个真正有效、
00:07:59好用的 RAG 系统,那就看看 Andris 的这个视频。
00:08:02而且如果你是星球大战迷,你尤其会喜欢这个视频。

Key Takeaway

通过部署 Claude Context MCP 插件,开发者可以利用混合检索技术大幅提升 AI 对代码库的理解深度,在处理中等规模项目时尤其能显著缩短获取详细架构信息所需的时间。

Highlights

  • Claude Context 插件通过向量数据库和混合搜索技术索引整个代码库,减少了 40% 的上下文占用。

  • 该工具结合了 TreeSitter 代码结构解析、基于 Merkle DAG 的增量更新机制以及向量+BM25 混合检索。

  • 在处理 150 万行代码的 VS Code 仓库时,大型索引过程耗时约 50 分钟,OpenAI 嵌入成本约 1.06 美元。

  • Claude Context 在面对复杂查询时,相比传统的 grep 搜索,提供的内容详细程度和架构描述能力高出数倍。

  • 对于中等规模的代码库(2 万至 3 万行代码),Claude Context 能实现极快的索引速度和明显的回复质量提升。

Timeline

Claude Context 的技术架构与功能

  • 插件通过向量数据库直接索引代码库,避免了传统 grep 搜索的猜测与低效。
  • TreeSitter 支持解析九种主流编程语言,形成函数与类的代码结构块。
  • Merkle DAG 技术确保系统仅重新索引已更改的文件,优化了大规模代码库的管理。

Claude Context 由 Zilliz 开发,通过 MCP 协议连接到各类代理框架。它通过向量搜索捕捉语义含义,并结合 BM25 索引进行关键字匹配,最终实现 40% 的上下文缩减。这种设计使得编码助手能够精准定位代码,而非盲目搜索。

大规模代码库的实际性能测试

  • 在 150 万行代码的仓库测试中,索引过程耗时 50 分钟并产生了 1.06 美元的 OpenAI 使用成本。
  • 常规 grep 搜索在简单查询中响应速度快于 Claude Context。
  • Claude Context 在复杂问题上表现出更强的代码关联与细节分析能力。

通过 VS Code 代码库的对比测试,发现 Claude Context 在简单查询中不占速度优势。但在处理复杂问题时,它提供了包含相关文件引用、行号及深层逻辑的详细信息,而常规搜索在相同时间内往往无法提供同等维度的架构解读。

回复质量对比与使用建议

  • Claude Context 在回复 Electron 应用主进程架构等复杂问题时,速度比普通方案快五倍且细节更丰富。
  • 中等规模代码库(2万-3万行)是该工具的最佳应用场景。
  • 无服务器版数据库方案在成本与便捷性之间提供了良好平衡。

针对笼统且宽泛的代码库架构查询,Claude Context 展现了强大的总结能力,能够清晰地划分启动序列与各阶段服务初始化逻辑。尽管索引过程在大型项目中较为耗时,但在中等规模项目中极具实用价值,是理解大型开源项目的有效辅助工具。

Community Posts

View all posts