Agent

朋友们，大家好。 这两天读到开源的代码 Agent，Cline 团队的一篇博客，《Why Cline Doesn’t Index Your Codebase (And Why That’s a Good Thing) 》，做了一些整理和探索，来分享一下这篇博客内容。 先放原文链接：Why Cline Doesn’t Index Your Codebase (And Why That’s a Good Thing) 为什么RAG不行？ 早期，在模型上下文窗口还不大的时候，RAG 一直是作为让模型获取到额外相关上下文信息的办法而存在。哪怕到现在，这个市面上大部分的 AI 知识库解决方案也依然是 RAG，因为这种方法非常简单—它将知识库进行分块、创建嵌入、存储到向量数据库中，并在需要时会根据问题进行相关片段的检索。 但是，代码数据与其他数据不同。它是互相关联且不断演变的。当你将传统的 RAG 方法应用于代码库时，会出现三个关键问题： 1. 代码不是以块的形式思考 RAG 大致上来说可以分为两个部分：索引知识库（代码库）和检索。但是当你将代码块用于嵌入时，实际上是破坏了原有的代码库逻辑。举个例子来说，假设一个函数被调用是在片段 47，但是它的定义是在片段 892，而解释它存在的关键上下文又可能是散落在其他十几个片段中，先不说模型最后是否能够真正解决问题，就连把这些相关片段一次性全部检索出来，都是十分困难的。因为对于自然语言来说，一般的段落和句子，为创建具有语义意义的片段提供了明显的边界点，但是代码库的构造那就是完全另一回事了，所以简单的分块方法在准确界定代码有意义方面存在许多困难。 2. 索引随代码演变而衰减 实际上生产环境中，代码库不是静态的，而是一直在不断变化的。所以，索引不是一次性或周期性的工作。每一次你的代码合并都可能导致 AI的理解 与你的代码库之间存在分歧。所以，这也会导致你的代码助手会自信地建议调用不再存在的函数。 3. 安全 使用 RAG 还有一个最大的问题是安全。当你将你的代码库文件转换为向量嵌入时，你需要将其存储在某个地方。不管是云服务商，还是自己部署托管，都要花费额外的资源去做保证安全。 Cline 的方法 Cline 采用的方法更像一个真实的开发者在处理代码库时一样。它不提供索引或者嵌入。它只是通过遵循代码的自然结构来构建上下文，进行智能探索。 举例来说，你如果开发一个 React 组件。Cline 读取它，看到导入语句，然后跟随它。那个文件又导入另一个文件，所以 Cline 也跟随了那个文件。每个文件都建立在之前的基础上，从而形成一个相互关联的理解，展示你的代码是如何运作的。 这种方法其实非常依赖模型的上下文窗口。 无论是 Claude 4 也好，还是Gemini 2.5 Pro，都提供了非常大的上下文窗口。Cline 的这种像人类工程师一样阅读代码库的方法自然能生成高质量的上下文，因为它遵循的是代码库里的逻辑结构，而不是像 RAG 一样，把代码库文件切块，依赖语义进行匹配。 ...

故事的开始是发生在 1 年多前，硅谷发生了令人震惊的杀妻案件。凶手用拳头一拳拳打死了自己的妻子，再加上 华人、高学历、清华、大厂这样的无敌光环，这件案子当时格外引人关注。 但是随着时间的推移，关注度来的快去的也快，而且再加上天高皇帝远的，毕竟是在美国开的庭，接触到的后续相关信息也很少，大家对这件事的关注度就慢慢散了。 但是最近，这个案子又终于开审了，很多案件的细节都被曝光了出来。 作为一个经常需要依靠 AI 才能不在各类繁杂的信息源中不迷失的用户，觉得DeepResearch 真的太适合这类多个资料的搜寻、整合、最后输出了。 这不，正好 Kimi 的 Researcher来了么～ 我用 Kimi 的 Researcher 对硅谷杀妻案做了一个深度的报告，梳理了整个事件的始末发展。 首先，Kimi 的深度研究会先根据我的指令进行反问确认，确保自己能进一步理解清楚我的需求。 与我进一步确认之后，它开始进行搜索工作。 有意思的是，为了扩大搜索范围，它不仅用不同的中文关键词进行搜索，还同样使用英文关键词进行了搜索。 和大部分 Agent 不一样的是，Kimi 的 DeepResearch 是调用 Python 来写入一个 Markdown 文件。 当然，整个执行的过程中，并不是一帆风顺的，Kimi 还是会遇到困难，但是得益于端到端的强化学习训练，它能自己学会找到合适的办法解决问题。 最终，Kimi 给了我一份 12460 字的报告，详细梳理了案件的始末，以及目前的进度，并且做到了几乎每句话都有迹可循。 甚至，它还搜到了一些案件的惊人细节，比如第三者： 以及凶手可能的辩护策略： 详细报告因为长度关系，就不放在这里了。感兴趣内容的小伙伴可以直接私信我领取查看哦。 最让我觉得惊艳的是 Kimi 最后给我生成的那份可视化的报告，信息量和美感都非常在线。 您的浏览器不支持视频标签。 这份可视化报告同样保留了引用源的标注，提高了可信度的同时也方便查询。同时，它还针对一些关键信息（案件凶手和被害人之间的关系节点、整个案件发生的前后时间线等）画了流程图，便于理解。最后它也结合一些搜索到的法律人士的专业意见，给出了案件可能的最终走向，以及给出了一些建议来避免这类悲剧的事情再次发生。 整个报告的预览链接在这里➡️： https://www.kimi.com/preview/197b74a5-b521-8674-ba47-02a74b00051e 看完整个报告，从案发到现在，还是难以想象受害者临终前的绝望，一拳一拳被自己曾经最心爱的人打死，被迫离开了这个美好的世界。 那个曾经应该是用来监控小猫进食的摄像头，却意外拍下了这最残忍、惊悚的一幕。 ...

本文为 Langchain 官方博客“The rise of context engineering”的双语对照版本。 推荐阅读理由：随着 Agent 的快速发展，”context“ 的概念越来越被重视。无论是 Vibe Coding，还是 Deep Research，提供的 ”context“越具体完整，最后出来的效果都会很棒！LangGraph 作为最著名的智能体框架之一，了解它们是如何看待上下文的重要性的，无论是对我们个人平时 AI 的使用还是企业业务上 AI 的落地，都有很大帮助。 Header image from Dex Horthy on Twitter 来自 Dex Horthy 的 Twitter 头图 Context engineering is building dynamic systems to provide the right information and tools in the right format such that the LLM can plausibly accomplish the task. 上下文工程是构建动态系统，以在正确的格式中提供正确的信息和工具，使得 LLM 能够合理地完成任务。 Most of the time when an agent is not performing reliably the underlying cause is that the appropriate context, instructions and tools have not been communicated to the model. ...