朋友们,大家好。
这两天读到开源的代码 Agent,Cline 团队的一篇博客,《Why Cline Doesn't Index Your Codebase (And Why That's a Good Thing) 》,做了一些整理和探索,来分享一下这篇博客内容。
先放原文链接:https://cline.bot/blog/why-cline-doesnt-index-your-codebase-and-why-thats-a-good-thing
早期,在模型上下文窗口还不大的时候,RAG 一直是作为让模型获取到额外相关上下文信息的办法而存在。哪怕到现在,这个市面上大部分的 AI 知识库解决方案也依然是 RAG,因为这种方法非常简单—它将知识库进行分块、创建嵌入、存储到向量数据库中,并在需要时会根据问题进行相关片段的检索。
但是,代码数据与其他数据不同。它是互相关联且不断演变的。当你将传统的 RAG 方法应用于代码库时,会出现三个关键问题:
1. 代码不是以块的形式思考
RAG 大致上来说可以分为两个部分:索引知识库(代码库)和检索。但是当你将代码块用于嵌入时,实际上是破坏了原有的代码库逻辑。举个例子来说,假设一个函数被调用是在片段 47,但是它的定义是在片段 892,而解释它存在的关键上下文又可能是散落在其他十几个片段中,先不说模型最后是否能够真正解决问题,就连把这些相关片段一次性全部检索出来,都是十分困难的。因为对于自然语言来说,一般的段落和句子,为创建具有语义意义的片段提供了明显的边界点,但是代码库的构造那就是完全另一回事了,所以简单的分块方法在准确界定代码有意义方面存在许多困难。
2. 索引随代码演变而衰减
实际上生产环境中,代码库不是静态的,而是一直在不断变化的。所以,索引不是一次性或周期性的工作。每一次你的代码合并都可能导致 AI的理解 与你的代码库之间存在分歧。所以,这也会导致你的代码助手会自信地建议调用不再存在的函数。
3. 安全
使用 RAG 还有一个最大的问题是安全。当你将你的代码库文件转换为向量嵌入时,你需要将其存储在某个地方。不管是云服务商,还是自己部署托管,都要花费额外的资源去做保证安全。
Cline 采用的方法更像一个真实的开发者在处理代码库时一样。它不提供索引或者嵌入。它只是通过遵循代码的自然结构来构建上下文,进行智能探索。
举例来说,你如果开发一个 React 组件。Cline 读取它,看到导入语句,然后跟随它。那个文件又导入另一个文件,所以 Cline 也跟随了那个文件。每个文件都建立在之前的基础上,从而形成一个相互关联的理解,展示你的代码是如何运作的。
这种方法其实非常依赖模型的上下文窗口。
无论是 Claude 4 也好,还是Gemini 2.5 Pro,都提供了非常大的上下文窗口。Cline 的这种像人类工程师一样阅读代码库的方法自然能生成高质量的上下文,因为它遵循的是代码库里的逻辑结构,而不是像 RAG 一样,把代码库文件切块,依赖语义进行匹配。
示例
原博客里有一个具体的示例来说明 Cline 的方法和 RAG 的不同。
假如要 AI 给你的项目里的一个“支付处理函数”添加错误处理的逻辑。如果是 RAG 为基础的代码助手可能会在向量索引里找和“payment”,“error”有关的代码片段,然后从中挑几块认为相关的塞进错误处理的逻辑。但是这样做是有问题的,因为你的项目很可能有自己定制的错误处理框架,结果代码助手没有找到它,于是 AI 很可能给你建议在代码里加入一些通用的 try-catch。这和你的项目模式完全不吻合。
Cline 的做法则截然不同:它会真正找到支付函数的源码位置,接着顺着代码找出它 import 的错误处理工具模块,然后再看看这个工具模块是如何实现的,再然后,看看项目里有没有其他类似函数,它们是如何处理错误的,以学习整个项目的代码模式。最后,Cline 基于这一系列的“深入阅读”得来的理解,提出修改方案:新增的错误处理代码正好符合你现有的架构和风格(比如用上了你项目中的错误处理框架,而不是生搬硬套别处的通用代码)。
尽管实际文件搜索在某些场合中可能更慢,
但是 Cline 团队认为当模型足够强大到能真正理解代码时,瓶颈不是检索速度--而是上下文质量的比拼。
而且代码本身已经在本地了,直接让 AI 读取,更加自然,何必多此一举先弄个向量索引副本呢?也许 RAG 是能节省点 Token 调用成本,但是这种方法并不是想要 AI 真正读懂自己的代码。
既然如此, Cline 团队认为就不应该节省这个成本,应该将智能直接应用于用户的代码库上。
这篇博客其实非常好地阐述了 Cline 作为一个代码助手是如何处理一个庞大的代码库的,也从侧面说明了为什么使用 Cline 这么耗Token。
同样,越来越多的代码工具也意识到光靠 RAG 这样的静态检索,是不能带来很好的效果的。比如 Claude Code,它也没有事先构建索引以及通过向量嵌入的方式来处理代码。和 Cline 类似,但是又不同的是,它是通过调用工具,然后动态的、根据实际需求来搜索代码文件。
文章来自微信公众号 “ BubbleBrain ”
【开源免费】AutoGPT是一个允许用户创建和运行智能体的(AI Agents)项目。用户创建的智能体能够自动执行各种任务,从而让AI有步骤的去解决实际问题。
项目地址:https://github.com/Significant-Gravitas/AutoGPT
【开源免费】MetaGPT是一个“软件开发公司”的智能体项目,只需要输入一句话的老板需求,MetaGPT即可输出用户故事 / 竞品分析 / 需求 / 数据结构 / APIs / 文件等软件开发的相关内容。MetaGPT内置了各种AI角色,包括产品经理 / 架构师 / 项目经理 / 工程师,MetaGPT提供了一个精心调配的软件公司研发全过程的SOP。
项目地址:https://github.com/geekan/MetaGPT/blob/main/docs/README_CN.md
【开源免费】FASTGPT是基于LLM的知识库开源项目,提供开箱即用的数据处理、模型调用等能力。整体功能和“Dify”“RAGFlow”项目类似。很多接入微信,飞书的AI项目都基于该项目二次开发。
项目地址:https://github.com/labring/FastGPT
【开源免费】graphrag是微软推出的RAG项目,与传统的通过 RAG 方法使用向量相似性作为搜索技术不同,GraphRAG是使用知识图谱在推理复杂信息时大幅提高问答性能。
项目地址:https://github.com/microsoft/graphrag
【开源免费】Dify是最早一批实现RAG,Agent,模型管理等一站式AI开发的工具平台,并且项目方一直持续维护。其中在任务编排方面相对领先对手,可以帮助研发实现像字节扣子那样的功能。
项目地址:https://github.com/langgenius/dify
【开源免费】RAGFlow是和Dify类似的开源项目,该项目在大文件解析方面做的更出色,拓展编排方面相对弱一些。
项目地址:https://github.com/infiniflow/ragflow/tree/main
【开源免费】phidata是一个可以实现将数据转化成向量存储,并通过AI实现RAG功能的项目
项目地址:https://github.com/phidatahq/phidata
【开源免费】TaskingAI 是一个提供RAG,Agent,大模型管理等AI项目开发的工具平台,比LangChain更强大的中间件AI平台工具。
项目地址:https://github.com/TaskingAI/TaskingAI