我测试了基于AST的上下文图用于编码代理；以下是我发现的变化

Reddit r/AI_Agents 工具
ast context-graphs coding-agents retrieval local-first lsp

摘要

实验表明，与宽泛的代码片段相比，基于AST的编码代理上下文图可以减少90%的令牌使用量，同时保持基础的准确性，建议采用混合方法来处理检索范围过窄的情况。

我一直在尝试为编码代理提供一个本地优先的上下文服务，该服务基于AST/LSP风格的事实构建仓库图，而不是让代理从宽泛的文件搜索开始。到目前为止有用的模式是：- 索引文件、符号、导入、调用、定义、包含关系及依赖边 - 让代理首先查询相关的子图 - 仅在证据不足时扩展到原始文件、搜索或LSP - 不仅衡量令牌数量，还评估检索到的上下文是否会增加幻觉风险。在一次基准测试中，图上下文比宽泛代码片段减少了约90%的输入令牌，同时保持了答案对测试任务足够基础的准确性。重要的提醒是，图优先并不意味着只能使用图。如果检索范围过窄，代理则必须回退到源代码读取和验证。我很好奇其他人如何处理编码代理的这一情况：你倾向于LSP优先检索、嵌入/RAG检索、图检索，还是混合方式？
查看原文

相似文章

我为智能编码构建了一个代码上下文图

Reddit r/ArtificialInteligence

作者构建了一个代码上下文图解析器，通过静态分析生成图，并通过MCP暴露给AI代理。在与Gemma 4 26B的直接比较中，使用该图的代理在不到2分钟内探索了Apache Kafka的请求流程，而没有图的基线代理在6分钟内耗尽了速率限制。

我们尝试了向量、抽象语法树（AST）以及粗暴地堆砌上下文以进行代码检索。带有大语言模型（LLM）生成语义的图结构效果最佳。以下是我们的经验总结。

Reddit r/LocalLLaMA

作者们详细描述了他们在构建代码索引系统的经验，最终得出结论：使用大语言模型（LLM）生成语义的图检索方式在性能上优于向量嵌入和纯抽象语法树（AST）解析。他们将该系统开源，命名为 Bytebell，它利用 Neo4j 存储语义上下文，以实现高效且精确的代码检索。