你的代码库, AI编程助手老是看不懂? 这个项目在热榜排第一, 用C语言, 3分钟搞定2800万行代码索引查询速度比眨眼还快, 还能省99%的Token。有没有尝试过借助Code或者Codex去帮自己找寻一段API的调用关系? 其过程一般是如此这般地: Agent起始便展开疯狂的grep行动去查找类名, 接着read数量众多的文件之后, 再执行grep参数类型的操作, 而后持续read……如此这般反复折腾几十回, 消耗掉几百个token, 最终也许给出的是一个带有“差不多”意味的答案, 。根源并非在于模型的聪慧程度不足, 而是在于其对于代码库欠缺结构化的理解, 每当Agent遭遇一个全新的仓库之时, 就好似在黑暗的夜里之中手持着手电筒穿梭于仓库之内, 先是对这个文件进行一番照射查看, 接着又去翻动那个函数, 开展一次grep操作, 完成一轮read作业之后, 再依照调用链逐一询问一通, 大量的时间乃至于算力均耗费在了寻找路径方面, 而非理解环节上。在2026年6月的时候, 开源的那个--mcp登上了榜首-, 一直到6月21日, 该项目的Star数已经达到了9681, 在趋势期内增长了5419颗星, 它所做的事情实际上并不复杂, 就是把代码库转成一个持久的、可查询的知识图谱-, 然而做到的方式却让人没办法忽视, 那就是用C语言。2800万行代码3分钟凭什么Linux内核有2800万行的代码, 其文件数量为7.5万个, mcp全量索引完毕用了3分钟, 查询响应时间低于1毫秒, 五次结构化查询大约消耗3400个token , 若采用传统逐文件grep加read的方式来做同样的事, 则需要约41.2万个token , 节省了99.2%。这组数据刚一呈现出来, 社区所做出的反应极具趣味性。存在这样一些人, 他们径直在评论区域进行算账: 每一次查询能够节省40万token, 按照主流模型的API定价标准来计算, 节省下来的这笔费用足以购买若干杯咖啡。然而, 这其中还并未将时间成本计算在内, 也就是说, 要让AI在几万份文件当中进行grep操作, 仅仅等待它读完这些文件所耗费的时间, 就足够你去刷两条短视频了。但真正能令开发者兴高采烈的关键绝非省钱。有一条在3000人技术群里被再三说起的评论是: 这一回总算有其他人把AI记不住代码库之问题给处理妥当啦。这句话所击中的痛点在于: 哪怕大模型聪慧至极, 然而每一次对话均会从最开始着手去领会阁下的项目。于今天跟它交流完模块A的架构, 明日转而处理模块B时, 它竟是连A都忘得彻彻底底的了。与mcp所做之事看齐, 就如同给AI安装了一个“长期记忆中枢”。代码仓库一旦被索引成知识图谱, 函数, 类, 调用链, HTTP路由, 跨服务链接全部统统被建模为图节点和边, 之后AI再询问“谁调用了这个函数”“这条调用链走下去会影响哪些模块”, 直接在图上游走查询即可, 不用再重新翻一遍文件。为什么非得是C语言这可能是整个项目最值得琢磨的技术决策。网上存在一份流传范围极为广泛的性能对比数据, 其中显示, 使用一种方式解析千万行代码, 所耗费时间约莫为42秒, 内存占用量为2.8GB, 查询延迟处于15至40毫秒之间用Rust来进行同样操作, 大约需要8秒, 内存占用1.1GB, 查询延迟为3至8毫秒而运用C做了优化之后, 耗时0.9秒, 内存占用380MB, 查询延迟在0.3至1.2毫秒。为何会存在差距呢? 对代码进行解析, 其本质情况是, 存在大量的字符串扫描, 还涉及哈希计算, 伴随图结构操作。每有一个对象被创建起来, 就会产生一次内存分配行为。要是处理千万行代码, 那就表明会有百万次对象分配这一情况。C语言借助mmap方式直接映射源文件, 运用Arena分配器来批量管理相关内存, 这能够在单次系统调用期间, 完成原本需要百万次操作才能够达成的任务。其实呢, C语言于这个场景里所具备的优势并非是“比其他快那么一点”, 而是“比其他快了一个数量级”。要是进行编写的话, 2800万行Linux内核索引在3分钟内根本就无法达成——仅仅是内存方面就承受不住了。这个项目, 做了好些关键设计: 先是采用tree-去做AST解析, 这里面内置有用于158种语言的语法器-接着针对Go, 针对Java, 针对Rust等11多种语言做了LSP语义类型解析然后, 使用Linux和W监听文件变更情况, 只有遭到修改的文件才会被重新解析。索引完成之后数据会写入到本地, 代码绝对不会离开你的机器。尤为让人感到意外的是其呈现的部署方式-, 此方式为单静态二进制文件, 对于macOS、Linux均予以全平台支持, 既不需要额外进行某些操作, 也不需要安装运行时-, 只需将其下载下来便能够运行起来。一个信号AI编程正在从“调用模型”转向“提升上下文”要是仅仅将--mcp视作一个“速度快的索引器具”, 那可就小瞧它了。本期, 存在一个显著的趋向, MCP服务、Agent技能、代码知识图谱、上下文压缩等项目, 呈现出集中式的大量兴起, 这表明开发社区的重点层面, 已然从“调用哪一个模型”转移至“该如何使得模型拿到更为高效的上下文”。MCPModel简写那个词是被提出的一个标准, 这个标准, 其存在所具备的目的, 是要使得AI能够、并且保证安全地在标准化状态下去调用关联的外部系列工具以及各种数据源, MCP就是处于MCP生态范围当中速度、速率方面最快的、而且支持涵盖语言种类最为齐全的代码智能服务器, 这款服务器, 它提供了14个MCP工具, 这些工具能够支持语义进行搜索、针对死代码展开相关检测、对调用链进行追踪、实施架构分析等一系列功能, 到目前为止已经能够毫无缝隙地集成到Code、Codex CLI等11款处于主流范畴的编码代理之内。这意味着啥? 意味着AI编程助手正从仅仅“能够编写代码”向着“能够理解代码”不断进化, 以往你要是让AI去修改一个跨模块的功能, 它或许得阅读几十个文件才能够弄明白影响范围, 现下它直接去查询知识图谱。这不是渐进式优化是范式变化。但话说回来这东西真没有短板吗社区讨论里也不全是叫好声。有人对内存占用存在担忧, 在索引完成过后内存会得到释放, 然而索引实施期间需把一整个知识图谱构建于内存之中, 针对超大型仓库, 内存方面的压力依旧是存有。有的人于技术论坛里进行了询问, 如果仓库存在五十万个文件该如何处理呢? 项目方给出的回应则是 “正向优化批量的索引策略”, 不过当前尚未见到具体的情况。还有人提及了二进制信任链方面的问题, 单个静态二进制的确是便利的, 然而这也表明你没办法去审计代码, 除非你亲自从源码进行编译, 对于一个需要“记住”你整个私有代码库的工具而言, 这一层面的顾虑并不是多余的。另外, LSP当前仅覆盖了十一种语言, 虽说tree-对一百五十八种语言的AST解析提供支持, 然而深度语义分析仍旧聚焦于主流语言之上, 要是你所采用的是小众语言, 获得的功能或许会大打折扣。话说回来, 这些问题更像是成长中项目的“待办清单”, 而非致命缺陷。它遵循MIT协议开源, 有36个贡献者, 116个Open, 社区在关注, 问题在解决。“--mcp登上”这件事, 其自身可是一个信号了, 这信号表明开发者对AI编程助手“记不住事”的毛病已然是非常厌烦了。其实你并非需要一个会写诗的大模型, 而你所需要的是这样一个工具, 它能够记住你昨天写下的内容是什么, 亦能记住你今天修改了些什么, 还能记住你明天打算改动的是哪里。此项目借助C语言将速度达成极致状态, 凭借知识图谱把结构变为可查询情形, 通过MCP协议把能力给予所有的AI编程代理。存在三个决策, 每一个均精准踩在了痛点之处。要说它可不可以成为AI编程这类的基础设施, 这得看后续的生态构建情况。不过起码在这个6月, 它使很多人目睹了另外一种可能性, 那就是AI并非一定要“明白”每一行代码, 只需晓得去哪里找答案就行。